Let's look purely at Amazon (example from the comments) and compare it to a payments processor.
First, Amazon is more complex because it is itself a payments processor as well as a retailer and warehouse manager.
Second, Amazon has to communicate with customers. Most payment processors only need to communicate with clients. So it's the client's responsibility to notify the customer of problems. Amazon is actually simpler in some ways than other retailers, as they operate their own payment processor. Others have to interact with an external payment processor and compensate for its shortcomings (e.g. confusing error codes). Thus high usability is needed.
Third, Amazon still has to collect all the data that a payment processor needs, as it is the only source for such data. Some other retailers may farm out that work (e.g. PayPal will collect payment details for you). But customers often prefer to interact with just one site. So most retailers large enough to have a full time developer will try to collect the data themselves. So high security is needed.
Fourth, retailers have to encourage sales. A payment processor gets business from a retailer getting a sale. Once they've signed the retailer as a client, there is little to manager. Customers need to be convinced to purchase from the retailer on every transaction. Yes, sometimes someone just needs to order a new toothbrush. But many times, the customer doesn't know what they might buy. Is it a book by a new author that is similar to other books in the customer's purchase history? A piece of apparel that meets the customer's unique style? A new gadget?
Fifth, many retailers need to look pretty. People expect a certain level of gloss and attraction from a retailer that they don't require from a payment processor. If they ever see the payment processor's work at all. Amazon admittedly is on the low end of this.
Sixth, reviews. You'd be surprised at how important reviews are to customers. Amazon's large set of existing reviews makes it a place for consumers to check out products before buying. Brick and mortar retailers complain that Amazon uses them as showrooms, yet they never offer a commission on the sales that derive from Amazon reviews. Reviews need to be available and performant.
Seventh, cart management. Payment processors may not even see the cart, only the total. If they do see the cart, they only need a snapshot of it. Amazon not only has to calculate taxes and shipping, it has to maintain the cart itself. It has to show the cart to the customer and process changes. It has to update quickly and always produce data.
Eighth, after an order is completed, Amazon has to ship it. Third-parties need to be notified if they are managing the shipping. Or if Amazon is handling the shipping, they have to pick a warehouse. The warehouse needs to have availability, and they would prefer to pick the one with the cheapest and quickest delivery route.
Ninth, Amazon has to deal with hardened interfaces. A payment processor can establish a new gateway and migrate clients gradually, as they are ready. The actual customers may never even see a change. Amazon is stuck with the interfaces with suppliers and also things like search engines. Note that Amazon shut down Obidos years ago, but it still uses /exec/obidos URLs to maintain page rank. It has to map those to the real URLs behind the scenes.
Tenth, taxes and shipping. A payment processor has to charge taxes and shipping, but it usually won't have to calculate it. The client typically calculates taxes and shipping. Note that taxes are often different in each state and sometimes in different counties.
Eleventh, Amazon is too big to manage a single deployment. They used to have a single team (called Houston, as in "Houston, we have a problem" from space movies) that managed deployments, but the number of areas of responsibility grew too large for one team to handle. More modernly, unless the pendulum has swung back the other way, any team is responsible for its own deployments to the retail site (www.amazon.com and the international variants).
This is not necessarily a typical state for a retailer. Amazon is uncommonly large. I mostly mention it because the discussion in the comments is missing one of the largest problems. Any team that has even one page or service client on the retail website might have to deploy. And any deployment has the potential for causing problems, which is one reason why deployments are limited to certain hours except for emergencies.
Not only does Amazon have more resources to handle outages, it also has more potential causes. A payment processor is one possible thing that can go wrong. Amazon in particular and retailers in general have to worry about merchandising, cart management, payments, and shipping. Increased resources may offset increased traffic, but increased complexity is orthogonal to that and multiplies the problems caused by traffic.
All that said, it's quite possible to pick up and learn the skills needed for retail. As a practical matter, you may not have to work in every area. The bigger the retailer, the more programmers can specialize. But smaller retailers can lack the resources to do the training and specialization that larger retailers can do. So it may be worth reading "Needs e-commerce experience" as an indication that they will expect you to do a lot of things without more senior developers to train you. Some contractors may also prefer specific experience because they aren't able to put multiple developers on the same job as much as they'd like. Sometimes they try to use experience to compensate for limited Quality Assurance.
Figure out what you do well and present it. Either that's what they need or it isn't. The truth is that most interviews and even more applications will fail. You shouldn't expect to get hired after most interviews, as people typically aren't. The better the job, the more applicants they are likely to have. So they may be picky.
Of course, picky is fine if you happen to be the one that best fits their criteria.
