Payment methods matter: why offering more options means more sales

Last reviewed June 2026, back-office paths (Payment → Preferences, Orders → Shopping Carts, Stats) confirmed current for PrestaShop 1.7 through 8 and 9.x.

Here is a checkout most merchants never see, because it happens after they have stopped looking: a customer fills their cart, reaches the payment step, scans the available options, and finds nothing they trust. No PayPal. No BLIK. No Apple Pay on their phone. They do not email you to complain, they simply close the tab. The sale is gone, and your analytics will record it as "abandoned at payment" without ever telling you why. The single most common why, across surveys of cart abandonment, is some version of "my preferred way to pay was not there."

This post is about one decision specifically: how many payment methods to offer, and how to decide which ones earn their place. It is not a roundup of the best modules, not a tutorial for any single gateway, and not a country-by-country atlas of local methods. Those are covered by siblings, linked where they belong. The job here is the business case for breadth, the cost math that proves it, and how PrestaShop actually lets you present and manage a wider set of methods without turning your checkout into a wall of logos.

Why more options means more sales, the mechanism, not the slogan

"Offer more, sell more" sounds like a platitude until you look at what is actually happening at the payment step. Payment preference is not a rational shopping decision; it is a habit formed over years. A customer who pays for everything with PayPal has a saved address, a saved card, and a one-tap flow they trust. Ask them to type a 16-digit card number instead, and you have not offered them a small inconvenience. You have replaced a 5-second habit with a 60-second task at the exact moment their commitment to the purchase is weakest.

So the mechanism is not "more choice is nice." It is this: each payment method you add captures the segment of customers for whom that method is the path of least resistance. Add PayPal and you capture the trust-driven buyers. Add a wallet and you capture the mobile one-thumb buyers. Add a local method and you capture an entire country that treats cards as a foreign inconvenience. You are not stacking marginal improvements. You are unlocking discrete buyer segments that were previously bouncing.

That also explains the ceiling. Once a customer's preferred method is present, a fourth or fifth option does nothing for them. It only helps the next segment. This is why the right question is never "how many methods is enough?" in the abstract. It is "which segments of my traffic are leaving because their method is missing?". A question your own data answers, and we get to that below.

The cost calculation that actually matters

The objection to adding methods is always the same: fees. Every gateway takes a cut, typically in the 1.5–3.5% range per transaction depending on method, card type and region. Some merchants reason that more methods means more fee exposure, so they keep the list short. That reasoning quietly compares the wrong two numbers.

The fee is a percentage of orders you complete. The abandonment is a percentage of orders you lose entirely. Those are not the same currency. A worked example makes the gap obvious:

The fee went up in absolute terms and the store still made more money, because a fee on a recovered sale is pure upside. That order did not exist before. (The numbers above are illustrative, to show the shape of the trade-off; your real AOV, fee mix and recovery rate are yours to measure, not ours to promise.) The correct framing is never "what does this method cost me?" It is "how much revenue walks out without it?" A method only loses money if its fees exceed the margin on the sales it uniquely enables, and for any method that captures a real segment, it almost never does.

There is a second, quieter benefit to a mixed payment book: different methods carry different risk. Card payments concentrate chargeback exposure; bank-transfer and many local methods settle with near-zero chargeback risk; Buy Now Pay Later providers typically absorb the fraud risk themselves. A diversified payment mix is not only a conversion play, it spreads your risk profile too.

A decision framework: which methods earn a place in your checkout

Breadth has a real cost that is not fees: every option you add is one more line for the customer to read, one more logo competing for attention, one more integration to keep working through PrestaShop upgrades. So "add everything" is the wrong instinct. Use a tiered framework instead.

The two middle tiers are where most of the money is, and each has its own sibling post because the detail matters. For the wallet / BNPL question of which processor unlocks which methods, see Stripe vs PayPal. For Buy Now Pay Later specifically, how Klarna and Clearpay change average order value and who they suit, see Buy Now Pay Later. For the market-driven tier, local payment methods that unlock local markets covers BLIK, iDEAL and Bancontact, and there is a dedicated walkthrough for setting up Przelewy24 for Polish payments. If you sell across the EU and want the wider picture of what shoppers expect by country, start with payment methods for European e-commerce.

How PrestaShop actually handles multiple payment methods

This is where the generic "offer more options" advice runs out and the platform specifics begin. In PrestaShop, every payment method is a payment module, and each one hooks into the checkout through paymentOptions (the hook was displayPayment in 1.6; from 1.7 onward the standard is paymentOptions / hookPaymentOptions, which returns one or more PaymentOption objects). The practical consequence: you do not need ten separate modules to offer ten methods. A single aggregator module, the kind Stripe and Mollie provide, registers multiple PaymentOption entries from one integration, so cards, wallets and several local methods all appear at checkout while you maintain just one module and one set of API keys.

That has a direct bearing on the breadth decision. The reason "more methods" used to mean "more maintenance headache" was the one-module-per-method era. With an aggregator, adding iDEAL or Bancontact is often a checkbox in the provider dashboard, not a new PrestaShop install. The cost of breadth drops sharply. Two of the most common aggregator setups have full guides: Mollie as a multi-method gateway and the Stripe integration guide. When you are choosing which module(s) to standardise on, the head-to-head is in best payment modules for PrestaShop.

Day to day, you manage the active set from the back office:

• Improve → Payment → Payment Methods lists every installed payment module and lets you enable or disable each without uninstalling, useful for testing a method's pull, then switching it off if the data does not justify it.
• Improve → Payment → Preferences is the lever most merchants miss: you can restrict payment methods by currency, country, customer group, and carrier. This is how you keep the checkout clean instead of overwhelming, show BLIK only to customers in Poland, or hide a high-fee method from your wholesale group. (Note: the native matrix restricts by these dimensions, not by order amount. A per-order-value rule needs a dedicated restriction module.) The customer sees a short, relevant list; you still offer breadth across your whole audience.
• Order of methods at checkout is controlled in Design → Positions via the paymentOptions hook (tick "Display non-positionable hooks" to see it): the methods your data shows convert best belong at the top, because the first recognised logo is the one most customers click.

That Payment → Preferences restriction matrix is the answer to the real tension in this whole topic. Breadth wins sales, but a cluttered payment step costs them, and PrestaShop resolves it through the Payment → Preferences restriction matrix: you offer many methods at the store level while each individual customer sees only the few that apply to them. The matrix decides which methods a customer sees; how those methods are laid out on the page is the other half, and keeping them beside the order total on a single screen is where our Checkout Revolution one-page checkout fits. It gives Stripe (cards, Apple Pay, Google Pay, Link), PayPal and your local rails a tidy, in-flow place to render so breadth reads as choice rather than clutter.

Find the leak before you add anything, using your own data

Do not guess which methods you are missing. PrestaShop already records what you need, and the point of looking first is to spend your integration effort where there is proven demand rather than where a blog told you the trend was hot.

• Stats → Best countries / Carrier distribution give you the aggregate picture of where your customers physically are. A cluster of orders from one country with no local method enabled is your highest-return fix. To dig into abandoned carts specifically, use Orders → Shopping Carts, which lists carts that never became orders, filter that against the same countries to confirm a missing-method leak.
• Orders, filtered by payment method, shows the live distribution across what you already offer. A method handling 15% of revenue is one you protect; a method with zero orders in 90 days is one you can disable to declutter.
• Device split (your analytics, cross-referenced with PrestaShop's mobile conversion) tells you whether wallet support is a priority or a nicety. High mobile traffic with a card-only checkout is a wallet-shaped hole.

If you want the after-the-fact view of which orders are actually pulling their weight, revenue, costs and margin over any date range, that financial reporting is exactly what a tool like our Financial Revolution module surfaces, so you can weigh the profit each segment contributes rather than guessing. So what does that get you? You stop paying integration and fee overhead for methods nobody uses, and you spot the country or device segment that is quietly leaking orders before it shows up as a bad quarter.

Where this leaves you

The thesis holds, but with a sharper edge than the slogan: offering more payment methods sells more because each one captures a buyer segment that was otherwise leaving, and PrestaShop makes that affordable through aggregator modules and a per-customer restriction matrix, so breadth no longer means clutter or maintenance pain. Start with the baseline tier, read your own Stats and Orders data to find the segments you are losing, add methods deliberately against that evidence, and use Payment → Preferences to keep each customer's checkout short. The methods you choose to add, wallets, BNPL, the specific local options for your markets, are decisions the sibling guides above will help you make one at a time.

Frequently asked questions

How many payment methods should I actually offer?

There's no fixed number. The right answer is "enough that every meaningful segment of your traffic finds its preferred method, and no more." Start with the baseline tier (cards plus PayPal), then add a method only when your own Stats and Orders data show a segment leaving without it: a country with orders but no local rail, or high mobile traffic with no wallet. Once a segment's method is present, a further option does nothing for them, so stop adding once the leaks are closed.

Won't adding more payment methods just cost me more in fees?

Only if a method's fees exceed the margin on the sales it uniquely enables, which for any method that captures a real segment almost never happens. The fee is a percentage of orders you complete; abandonment is the loss of orders entirely. A fee on a recovered sale is pure upside, because that order didn't exist before. The number to watch isn't "what does this method cost me?" but "how much revenue walks out without it?"

How do I find out which payment method I'm missing?

Read your own data before installing anything. Stats → Best countries shows where your customers are; Orders → Shopping Carts lists carts that never converted, filter those against your top countries and a cluster from a market with no local method enabled is your highest-return fix. Cross-reference device split too: high mobile traffic on a card-only checkout is a wallet-shaped hole.

Does offering many methods make my checkout cluttered?

It doesn't have to. PrestaShop's Payment → Preferences restriction matrix lets you offer breadth at the store level while each customer sees only the methods that apply to them, BLIK to Poland, a wholesale method to your B2B group, and so on. You get the conversion benefit of breadth without the friction of a wall of logos, because the customer's payment step only renders the few that pass the gate for their cart.

Can I restrict a payment method by order amount in PrestaShop?

Not with the native matrix. Payment → Preferences restricts by currency, country, customer group and carrier, not by basket value. If you need a rule like "only show BNPL above €80," that takes a dedicated payment-restriction module; the core grid won't do amount-based logic on its own.