Payment methods for European e-commerce: what your customers expect

Last reviewed June 2026, back-office paths confirmed against PrestaShop 1.7 through 8 and 9.x; the Payment → Preferences restriction grid and SCA behaviour described below are current.

A customer in Amsterdam fills their cart, reaches your payment step, and sees Visa, Mastercard and PayPal. They leave. Not because your prices were wrong or your shipping was slow, because the one method they actually trust, iDEAL, wasn't there. To a Dutch shopper, a checkout without iDEAL reads the same way a checkout with no card option reads to you: this store isn't really set up for me. Multiply that by every market you ship to, and "what payment methods do you offer" stops being a back-office detail and becomes one of the quietest, most expensive conversion decisions you make.

This guide is about one specific thing: what European customers expect to see at checkout, country by country, and how you turn that into the right set of methods showing to the right shopper in PrestaShop, using the back-office controls most merchants never touch. It is the map, not the manual for any single gateway. When a method or processor deserves its own deep dive, Stripe vs PayPal, Mollie, BLIK and friends, Buy Now Pay Later. You'll find the link where you need it.

Why the "right" method is different in every country

There is no European payment standard. There is a patchwork, and each square of it was shaped by local banking history, regulation and habit. A German shopper grew up paying invoices after the goods arrive; a Dutch shopper grew up confirming payments in their own bank's app; a Polish shopper expects a six-digit BLIK code. None of these people are doing anything unusual. They are using the method that feels normal and safe to them. Your card-and-PayPal default feels normal to you.

The cost of the gap is well documented in direction if not in a single reliable percentage: a meaningful share of shoppers abandon specifically because their preferred method is missing, and that share runs higher on cross-border orders where the mismatch is sharper. Treat any single figure you read (including ones below) as directional and measure your own, there's a method for that at the end of this post. The principle holds regardless of the exact number: at the payment step the customer has already decided to buy, so every reason you give them to hesitate is the most expensive kind of friction there is.

The expectation map: what each market wants to see

Use this as a targeting brief, not a shopping list. You do not need every method everywhere. You need the locally-trusted one or two in each market you actually sell into, on top of cards. The table is the at-a-glance version; the notes under it carry the nuance that decides whether you've genuinely met the expectation or just ticked a box.

Three things this table hides that matter in practice. First, Germany's invoice expectation is about timing, not technology. The customer wants to pay after the goods arrive, and you provide that without taking on the debt risk by routing it through a provider (Klarna, Billie) that pays you up front. Second, France's Carte Bancaire is a co-badged network, not a brand of Visa; a gateway that processes it as CB rather than forcing the international rails tends to see fewer declines. Third, the local-method markets are unforgiving, in the Netherlands and Poland, the absence of iDEAL or BLIK isn't a minor inconvenience the shopper works around, it's a wall.

Each of the headline local methods has enough depth to warrant its own treatment. We cover the BeNeLux and Polish bank-redirect family, iDEAL, Bancontact, BLIK, and exactly when each one unlocks a market in local payment methods that unlock local markets. The pay-later wave (Klarna, Clearpay and the rest) gets its own conversion analysis in Buy Now Pay Later and what it means for your conversion. And the broader case for breadth, why more options at all tends to lift sales, is laid out in why offering more options means more sales.

From "what they expect" to "what they see": PrestaShop's controls

Here is where most guides stop and PrestaShop merchants get stuck. Knowing a Dutch shopper wants iDEAL is useless if iDEAL also shows to a Spanish shopper who'll never use it, cluttering the checkout. The thing that makes this manageable is that PrestaShop has built-in payment restriction controls, and almost nobody configures them deliberately.

In modern PrestaShop (1.7 through 8 and 9.x) the screen lives at Payment → Preferences in the back office. The page gives you a grid where every installed payment module can be switched on or off against four independent dimensions:

• Currency restrictions, show a method only for specific currencies (useful when a local method only settles in, say, PLN or DKK).
• Country restrictions. The one that does the heavy lifting here. You can limit iDEAL to the Netherlands, BLIK to Poland, Bancontact to Belgium, so each shopper's checkout shows the methods they actually recognise and nothing they don't.
• Customer-group restrictions, e.g. offer invoice/pay-later only to a "verified" or B2B group, or expose a wholesale-only method to resellers.
• Carrier restrictions, tie a method to specific carriers, so (for example) cash on delivery only appears with a courier that actually supports it.

Internally each tick in that grid is stored as a row in the module_country, module_currency, module_group and module_carrier tables, and the front-office checkout asks every payment module, through the paymentOptions hook (the hookPaymentOptions method on the module class, which superseded the older displayPayment hook from 1.6), what it wants to offer for this cart. The restriction grid is the gate that decides whether the module is even asked. So when you set country restrictions correctly, you're not hiding methods with CSS or hoping the gateway sorts it out, PrestaShop genuinely won't present them to the wrong shopper. So what does that buy you? A Dutch customer gets a clean iDEAL-first checkout, a Polish customer gets BLIK, and neither sees the other's irrelevant options. Which is exactly the "this store is set up for me" signal that converts.

A practical sequence for getting this right on your store:

• Install the gateway module(s) that cover your target methods (one good aggregator usually covers most of Europe, more on choosing one below).
• Go to Payment → Preferences and, for each local method, untick every country except the one(s) where it belongs. Leave cards and PayPal available everywhere.
• If you run B2B, use the group column to gate invoice/pay-later to the customer groups you actually want to extend terms to.
• Order matters at checkout, surface the locally-relevant method high. Most gateway modules let you set display position; for hook-based ordering you can transplant or reorder the module under Design → Positions, though many gateways also expose their own position/ordering setting within the module's configuration.

One module or many? Choosing how to deliver the methods

You broadly have three ways to get these methods live, and they trade off coverage against control:

For most European stores the aggregator route wins on day-to-day effort, because the alternative is maintaining half a dozen gateway modules through every PrestaShop and PHP upgrade. Mollie's PrestaShop module is the textbook example, one integration that fronts iDEAL, Bancontact, SEPA, cards and Klarna, and we walk through it in its own guide. If your weighting tips toward cards and global reach, the Stripe integration guide covers that setup end to end, and the head-to-head most merchants actually agonise over is settled in Stripe vs PayPal. If Poland is your market, the dedicated Przelewy24 setup guide is the direct route. And if you simply want the field compared side by side before committing, start with our complete comparison of the best PrestaShop payment modules.

The compliance layer you can't opt out of: SCA / 3-D Secure

Whatever methods you choose, European card payments fall under PSD2's Strong Customer Authentication rules, in practice, 3-D Secure, the step where the shopper confirms the payment in their banking app. This isn't optional and it isn't something you bolt on; your gateway handles the authentication flow for you. Two things are worth your attention as a merchant rather than a developer:

• Use a gateway on 3-D Secure 2.x. The newer version authenticates many low-risk payments silently in the background instead of bouncing every customer to a clunky redirect, markedly less checkout friction. If a gateway still leans on the old redirect-heavy 3DS1 flow, that's a reason to look elsewhere.
• Exemptions exist but are the gateway's job. Low-value transactions, certain recurring payments and low-risk flows can skip the challenge; you don't hand-code this, you just want a processor that applies the exemptions intelligently so trusted, returning customers aren't challenged needlessly.

The takeaway for this post: SCA is a constant across every market, so it doesn't change which methods you offer, but a gateway that handles it gracefully protects the conversion gains you make by offering the right ones.

Presenting the methods so the right one gets picked

Meeting the expectation is half the job; making the expected method obvious is the other half. A Dutch shopper who has to scroll past four irrelevant options to find iDEAL is still paying a friction tax you could have removed. A few decisions that consistently matter:

• Order by local relevance, not by your convenience. Because PrestaShop already lets you restrict methods by country, the shopper ideally sees a short, relevant list. Put their dominant method first within it.
• Show the methods before checkout. Payment logos in the footer and on product pages are a trust signal that reassures the shopper long before they commit; seeing a familiar iDEAL or Bancontact badge early reduces the "will this store work for me?" hesitation.
• Price pay-later inline. "Pay in 3 instalments of €33.33" converts better than a bare Klarna logo. The number does the persuading. (The full conversion case for BNPL is in the Buy Now Pay Later guide.)
• Keep the payment in the flow. Embedded payment fields convert better than a jarring redirect to an external page. This is exactly where checkout layout and payment presentation meet. Our Checkout Revolution module keeps the whole flow, including embedded payment, on a single page, so a returning customer never loses momentum between picking a method and confirming.

How to measure whether you got it right

Don't change your payment line-up on instinct and don't judge it on a long weekend of data. Before you add a market's local method, record three numbers, segmented by country if your analytics allow: checkout abandonment rate (shoppers who reach payment but don't finish), payment-step drop-off specifically, and conversion rate for that country's traffic. Add the method, configure its country restriction in Payment → Preferences so it shows only where it belongs, then compare the same numbers over at least 30 days and a few hundred orders from that market, enough volume to see a real trend rather than the week-to-week noise that tempts merchants into reverting a change that was actually working.

The pattern you're looking for is specific: abandonment falling in the market you targeted while the rest of your store holds steady. That's the signature of a genuine expectation being met, as opposed to a generic uplift you'd have got anyway.

The payment step is the most decided-upon page in your store. Every shopper who reaches it has already chosen to buy, and your only job is to not hand them a reason to stop. In Europe that means accepting that "what your customers expect" is a different answer in Amsterdam, Munich, Warsaw and Madrid, then using PrestaShop's own country restrictions to show each of them the short, familiar list they were hoping for. Get the map right, configure the gate, and let the deeper guides handle each method's particulars.

Frequently asked questions

How do I show iDEAL only to Dutch customers and BLIK only to Polish ones?

Use the country column in Payment → Preferences. For each local method, untick every country except the one(s) where it belongs, iDEAL to the Netherlands, BLIK to Poland, Bancontact to Belgium, and leave cards and PayPal ticked everywhere. PrestaShop then genuinely won't offer that method to the wrong shopper; it's a server-side gate, not a CSS hide, so a Spanish customer never even has iDEAL presented to them.

Does adding a local method for one country slow down or clutter checkout for everyone else?

Not if you set the country restriction. The restriction grid means each customer's payment step only renders the methods that pass the gate for their cart, so adding BLIK for Poland doesn't add a logo to a German shopper's checkout. That's the whole point of the grid, you offer breadth at the store level while each individual customer sees a short, relevant list.

Do I have to handle SCA / 3-D Secure myself?

No. Strong Customer Authentication under PSD2 is the gateway's job. It runs the 3-D Secure flow where the shopper confirms in their banking app. You don't code it. What you should do is pick a gateway running 3-D Secure 2.x, which authenticates low-risk payments silently in the background instead of bouncing every customer to a clunky redirect, and that applies the available exemptions so returning customers aren't challenged needlessly.

Is cash on delivery worth offering in markets like Italy?

It can be, for first-time buyers from an unknown store, where COD reads as a safety net. Italy is the clearest example. PrestaShop ships a cash-on-delivery option you can gate by country and carrier, so you can offer it only where it earns its keep and only with couriers that actually support it, using the carrier column in Payment → Preferences.

How long should I wait before judging whether a new method helped?

At least 30 days and a few hundred orders from the target market, judged on country-segmented numbers, checkout abandonment and that country's conversion rate, not a site-wide average. The signal of success is specific: abandonment falling in the market you targeted while the rest of the store holds steady. Shorter windows just show week-to-week noise, which is what tempts merchants into reverting a change that was actually working.