WooCommerce Payment Gateways for EU Stores: Stripe, Mollie, PayPal and More

Choosing between WooCommerce payment gateways is one of the few store decisions that touches everything at once: your fees on every single order, your conversion rate at the most fragile moment of the purchase, your cash flow (payout timing), your admin workload (disputes, refunds, reconciliation) and even how hard it will be to leave later. Yet most store owners pick a gateway the way they pick a font – whatever the tutorial used – and then wonder why Dutch visitors abandon the checkout or why the fee line in the accounts keeps growing faster than revenue.

I build and maintain WooCommerce stores for clients in Germany, the Netherlands, Austria, Switzerland and the UK, and I have set up, migrated and debugged every gateway in this guide many times. This is the honest EU-focused comparison I wish more owners read before launch: how gateways actually work, where Stripe, Mollie and PayPal genuinely differ, what the fees add up to at real order volumes, which local payment methods matter in which market, how SCA and 3DS affect your checkout, and how to test the whole thing properly before real money flows through it.

Table of contents

• How payment gateways actually work
• The big three for EU stores: Stripe, Mollie and PayPal
• Klarna and buy now, pay later
• Bank transfer and invoice for B2B stores
• The fee mathematics: worked examples
• Local payment methods by market
• Apple Pay and Google Pay
• SCA and 3DS in plain language
• A multi-gateway strategy that works
• Testing your payment setup properly
• Switching gateways later: the token problem
• Frequently asked questions

How payment gateways actually work

Some vocabulary first, because the confusion between these words causes real configuration mistakes. A payment method is what the customer sees and chooses: Visa, iDEAL, PayPal, SEPA direct debit, TWINT. A payment gateway (or processor) is the company that runs the transaction, moves the money and pays it out to your bank account: Stripe, Mollie, PayPal, Adyen. One gateway usually offers many methods – Mollie can process iDEAL, cards, Bancontact and Klarna through a single contract – and one method can be offered by many gateways. When someone says “should I use Stripe or iDEAL?” they are comparing a shop to a shelf.

The money flow matters for your accounting. The customer pays the gateway, the gateway holds the money briefly, then pays it out to you in batches – daily, weekly or on a rolling delay – minus fees. That means your bank statement never matches your order list one to one; you reconcile payouts, not payments. It also means the gateway is the party that deals with the card networks when something goes wrong: a dispute or chargeback is the customer asking their bank for the money back, and the gateway passes that fight (and usually a EUR 15-25 fee) on to you. Gateways differ meaningfully in how disputes are handled, how much evidence tooling you get and how often you win.

In WooCommerce, each gateway is a plugin that adds its methods to the checkout, talks to the gateway’s API, and updates order status via webhooks when the payment settles or fails. That last part – webhooks – is the piece most broken setups get wrong. If the webhook is misconfigured, orders sit in “pending” while the money arrived fine, and the store owner refunds confused customers who already paid. When I audit a store’s payment setup, webhook delivery is the first thing I check.

The big three for EU stores: Stripe, Mollie and PayPal

For a small or mid-sized EU store, the realistic shortlist is Stripe, Mollie and PayPal – usually two of them together. Adyen is excellent but built for enterprises; the classic bank-owned gateways are rarely worth the paperwork below serious volume. Here is how the three compare in practice.

Stripe: the developer-friendly default

Stripe is the gateway I install most often, and for good reasons. The official WooCommerce plugin is mature, the documentation is the best in the industry, and the method coverage is broad: cards, Apple Pay and Google Pay, SEPA direct debit, iDEAL, Bancontact, Klarna and more, all under one contract and one dashboard. EU consumer cards cost around 1.5% + EUR 0.25 per transaction on the standard plan; non-European cards cost noticeably more, and currency conversion adds its own margin. Payouts typically arrive in two to three working days on a rolling schedule.

Strengths beyond fees: Radar, the built-in fraud tooling, catches card-testing attacks that would otherwise fill your store with junk orders; the test mode is genuinely useful; and if your store ever needs custom payment behaviour – deposits, split payments, marketplace payouts, subscription logic – Stripe’s API can do it, which matters if you plan to grow. Weaknesses: support is ticket-based and can be slow when something urgent breaks, and Stripe occasionally freezes payouts of new accounts in “risky” categories while it verifies the business, which hurts if you did not see it coming. Verify your account fully before launch, not after the first sales spike.

Mollie: the EU-native specialist

Mollie is a Dutch processor built around European payment habits, and for stores selling mainly into the Netherlands, Belgium, Germany and DACH it is often the more natural fit. iDEAL, Bancontact, SEPA transfers, TWINT, EPS, Przelewy24 and Klarna are first-class citizens, not add-ons. Pricing is per transaction with no monthly fee: EU consumer cards around 1.8% + EUR 0.25, iDEAL at a flat fee of around EUR 0.29 regardless of order value, and similar flat pricing for several other local methods. For a Dutch store where most orders run through iDEAL, that flat fee is dramatically cheaper than any card percentage.

The dashboard is clean, the onboarding is straightforward for EU businesses, and support is European in both time zone and temperament. The trade-offs: the developer platform is good but smaller than Stripe’s, some advanced subscription and marketplace scenarios need more workarounds, and if a large share of your customers pay with non-EU cards the card pricing is slightly less favourable. Mollie only onboards businesses with an establishment in Europe, which is exactly right for its audience and irrelevant for everyone else.

PayPal: the habit you cannot ignore

PayPal is not really a competitor to Stripe or Mollie; it is a payment habit with a gateway attached. A meaningful share of shoppers – especially in Germany – simply trust the PayPal button more than any card form, because their card details never touch your site and they know the dispute process favours them. Removing PayPal from a German-facing checkout usually costs measurable conversion; I have seen it in the numbers on client stores more than once.

The costs of that habit: fees around 2.99% plus a fixed amount per transaction in most EU countries (roughly double a Stripe or Mollie card payment), a dispute process that does lean towards the buyer, and a checkout flow that bounces the customer to PayPal and back, which you should test on mobile with real thumbs. My honest advice: offer PayPal as an additional method next to cards and local methods, and never as the only gateway. Stores that run everything through PayPal pay the highest blended fees in this guide and have the least control over their money.

The short version in one table:

Pricing changes and negotiated rates exist, so treat the numbers as the shape of the comparison, not gospel – check the current price lists before you commit, and re-check them once a year.

Klarna and buy now, pay later

Buy now, pay later is the method category store owners feel most pressure to add and understand least. Klarna dominates it in Europe – pay in 30 days, pay in instalments, or pay now – with strong recognition in the Nordics, Germany and Austria. The pitch to you as a merchant is real: you get paid in full up front, Klarna takes the credit risk, and average order values genuinely rise for some product categories because the customer spreads the cost.

The costs are equally real. BNPL fees are noticeably higher than card fees – typically a bigger percentage plus a fixed amount per order – and returns get more complicated, because the customer may not have paid anything yet when the parcel comes back. For fashion and furniture, where high prices and high return rates meet, Klarna usually earns its fees. For a store selling EUR 25 consumables, it mostly adds cost and checkout clutter. You can add Klarna through Stripe or Mollie rather than a direct contract, which keeps your setup simpler and your reporting in one place; a direct Klarna contract only starts making sense at volumes where you can negotiate.

• Add BNPL when: average order value is above roughly EUR 80-100, your audience skews to markets where Klarna is a habit, and margins can absorb the fee.
• Skip it when: orders are small, margins are thin, or your accounting is not ready for the settlement and returns flow.
• Either way: measure. Add it, watch conversion and average order value for two months, and keep it only if the numbers say so.

Bank transfer and invoice for B2B stores

If you sell to businesses, the payment conversation changes completely. German and Austrian companies in particular expect to pay by invoice with 14 or 30 day terms, or by SEPA bank transfer – not by credit card at a checkout. WooCommerce’s built-in BACS (direct bank transfer) method handles the simple case: the order is placed, the customer receives your bank details, and you mark the order paid when the transfer arrives. It costs you nothing in fees, which on large B2B orders is a serious argument – 1.5% of a EUR 4,000 order is EUR 60 saved on every single order.

The trade-off is manual work and risk: someone has to match incoming transfers to orders, chase late payers and decide who deserves invoice terms at all. A sensible middle path I set up for wholesale clients: invoice or bank transfer for approved, logged-in B2B customers only, cards and PayPal for everyone else. That per-role gateway control is exactly the kind of thing WooCommerce does well with a little configuration, and it pairs naturally with the pricing and account structures covered in my B2B and wholesale store guide. SEPA direct debit (via Stripe or Mollie) is the automated cousin: you pull the payment from the customer’s account with their mandate, fees are low (Stripe charges around 0.8% capped at EUR 5), and it suits recurring B2B relationships – with the caveat that direct debits can be returned for weeks after payment, so treat very fresh direct debit revenue as provisional.

The fee mathematics: worked examples

Percentages look abstract until you run them against your own numbers, so let us do exactly that. Take a store doing EUR 20,000 a month across 308 orders (average order EUR 65) and compare what the payment mix costs per month:

• All EU cards via Stripe (1.5% + EUR 0.25): EUR 300 in percentage fees + EUR 77 in fixed fees = EUR 377 a month.
• All PayPal (2.99% + EUR 0.39): EUR 598 + EUR 120 = EUR 718 a month – almost double, for the same revenue.
• Dutch store, 80% iDEAL via Mollie (EUR 0.29 flat), 20% cards: EUR 71 for iDEAL + EUR 108 for cards = EUR 179 a month – less than half the all-card cost.

Three lessons fall out of this arithmetic. First, the fixed fee punishes small orders: on a EUR 8 order, EUR 0.25 is over 3% before the percentage even starts, which is why low-ticket stores care about flat-fee local methods. Second, the method mix matters more than the gateway choice: pushing customers who would happily pay by iDEAL or SEPA towards cards is a self-inflicted fee increase. Third, PayPal-heavy stores pay for trust – sometimes it is worth it, but you should know the price you are paying and keep cheaper methods visible next to it.

Now the pricing-model question that arrives with growth: blended versus interchange++. The rates quoted so far are blended – one flat price whatever card is used, simple to predict, slightly padded so the gateway wins on average. Interchange++ passes through the true card cost (interchange + scheme fee) plus a fixed processor margin, which is usually cheaper for European consumer debit cards but noisier to reconcile. As a rule of thumb: below roughly EUR 30,000 a month, take blended pricing and spend your energy elsewhere. Above EUR 50,000 a month, email your gateway and ask for custom or interchange++ pricing – a saving of 0.2-0.4 percentage points is realistic and worth EUR 100-200 a month at that volume for one email. Gateways rarely offer this unprompted; you have to ask.

Local payment methods by market

Here is the part international guides get wrong most often: Europe is not one payment market. Card-first advice written for the US or UK quietly loses sales in half of the EU, because in several countries the default way to pay online is not a credit card at all. If you sell cross-border, match the checkout to the market:

• Netherlands: iDEAL, full stop. The large majority of Dutch online purchases run through iDEAL, a bank-transfer-based method with a flat fee of around EUR 0.29. A Dutch-facing checkout without iDEAL looks broken to Dutch buyers. Both Stripe and Mollie offer it; Mollie treats it as a first-class citizen.
• Germany: PayPal, SEPA direct debit and invoice. Germans are famously card-sceptical; PayPal is the trusted wallet, direct debit is normal, and invoice (“Kauf auf Rechnung”) is loved – via Klarna for B2C or your own terms for B2B. One historical note: giropay, the German bank-transfer scheme, was wound down – if a tutorial tells you to enable it, the tutorial is old. Do not offer dead methods; a greyed-out or failing option damages trust.
• Belgium: Bancontact. The national debit scheme is the default habit; add it via Stripe or Mollie for a small flat-ish fee and watch Belgian conversion improve.
• Austria: EPS, cards and PayPal. EPS is the Austrian bank-transfer scheme; smaller than iDEAL in absolute numbers but expected by local buyers. Klarna is also well established.
• Switzerland: TWINT plus cards, priced in CHF. TWINT, the Swiss mobile payment app, has become near-universal domestically. Swiss customers also strongly expect CHF prices – a EUR-only checkout reads as “foreign shop, foreign problems”.
• Nordics and France: Klarna and other invoice/instalment methods are strong across Sweden and the wider Nordics; in France, cards dominate but they are usually Cartes Bancaires co-badged cards, which good gateways route correctly without you doing anything.

The practical method: look at your analytics (or your ambitions) for the top three countries you sell to, enable the one or two local methods each of those markets expects, and stop there. Every extra method adds checkout clutter, reconciliation lines and another thing to test; the goal is the shortest list that covers real habits. And display logic matters: Stripe and Mollie can show methods conditionally based on the customer’s country and currency, so the Dutch see iDEAL and the Swiss see TWINT without either seeing the other’s noise.

Apple Pay and Google Pay

Wallets are the cheapest conversion win in this entire guide. Apple Pay and Google Pay are not separate payment rails – they are card payments with the card details stored on the phone – so they cost you exactly the same as a normal card transaction. What changes is the checkout experience: instead of typing a 16-digit number on a phone keyboard, the customer confirms with a fingerprint or glance, and the wallet passes verified card and address data straight through. On mobile-heavy stores, enabling wallets is one of the highest-impact changes I make, and it usually takes under an hour.

Setup is genuinely easy now: with Stripe or Mollie, Apple Pay requires a domain verification step (the plugin largely automates it) and Google Pay switches on with a checkbox. Requirements to know: HTTPS everywhere (which you must have anyway), and the buttons only appear for customers whose device and browser support them – Apple Pay in Safari on Apple devices, Google Pay in Chrome. So test on a real iPhone and a real Android phone, not just your desktop. Wallets also interact beautifully with SCA (next section), because the biometric confirmation counts as strong authentication – which means fewer of those annoying bank verification popups. If your checkout page itself is slow or cluttered, wallets can only do so much; fixing the page around the payment buttons is its own discipline, which I cover in the checkout optimization guide.

SCA and 3DS in plain language

If you sell in the EU, you have met the acronyms. Here is what they actually mean. SCA (Strong Customer Authentication) is a legal requirement under the EU’s PSD2 payment regulation: most electronic payments in Europe must be confirmed with two factors – something the customer knows, has or is. 3D Secure (3DS) is the mechanism card payments use to satisfy it: that step where the bank’s app asks “was this you?” or a code arrives by SMS. Version 2 of 3DS made this far less painful than the old redirect-and-password flow, often confirming silently in the background.

What this means for your store, practically:

• You do not implement SCA yourself. Stripe, Mollie and PayPal handle it, triggering 3DS when the bank requires it. Your job is to use a current, official gateway plugin – ancient plugin versions predating SCA are a real source of failed payments on old stores.
• Some payment failures are SCA failures. When customers abandon at the bank-verification step or the app confirmation times out, the order fails through no fault of your checkout. Expect a baseline of these; watch the rate rather than chasing individual cases.
• Exemptions exist and your gateway plays them for you. Low-value transactions and low-risk payments can skip the challenge; good gateways request exemptions automatically to keep friction down. This is a reason to use a major processor rather than a bargain one – their exemption logic is measurably better.
• Local methods sidestep the drama. iDEAL, Bancontact, TWINT and wallets have strong authentication built into their normal flow, which is partly why they convert so well – the “extra security step” is just how the method already works.
• Saved cards and subscriptions still work. Merchant-initiated transactions (a subscription renewal charging a saved card) are exempt from per-payment SCA once the initial mandate was authenticated – the gateway flags them correctly if the subscription was set up through its official integration.

A multi-gateway strategy that works

Almost no serious EU store runs on a single gateway, and yours probably should not either. The baseline I recommend for most stores: cards + wallets + local methods through one processor (Stripe or Mollie), plus PayPal beside it. That combination covers card buyers, mobile wallet users, local-method loyalists and PayPal-trusters with exactly two contracts, two dashboards and two payout streams to reconcile – enough coverage without operational sprawl.

Which processor takes the lead role? My honest rule of thumb after many of these decisions: if your revenue is mostly the Netherlands, Belgium and DACH and your needs are standard, lead with Mollie – the local-method depth and flat fees fit the market. If you sell more broadly, expect custom development, subscriptions or API-heavy features, lead with Stripe – the platform depth pays off. Both are good enough that the wrong choice between them costs you little; the expensive mistakes are running PayPal alone, or adding five overlapping gateways “to be safe” and then reconciling five payout streams forever.

Two operational details that bite people later. Payout timing: your gateway holds several days of revenue at any moment (a new Stripe account might start on a 7-day rolling schedule before settling to 2-3 days), so a store doing EUR 3,000 a week always has a meaningful float in transit – plan cash flow around payouts, not orders, and remember refunds are pulled from future payouts. Payout currency: get paid out in the currency you price in, to a bank account in that currency. If you charge in EUR and pay out to a non-EUR account, you silently pay a conversion margin on every payout; a borderless-style EUR account fixes this for non-eurozone merchants and pays for itself immediately. If you sell in several currencies, most gateways can route each currency to a matching account – set it up once and stop donating a percentage to conversion.

Testing your payment setup properly

Payment bugs are the most expensive category of store bug, because every hour they exist costs real orders – and they love to hide in the gaps between “the plugin is active” and “money actually arrives”. Test in two stages:

• Sandbox first. Stripe’s test mode and Mollie’s test profile let you simulate everything: successful cards, declined cards, 3DS challenges, iDEAL flows, expired sessions. Walk each enabled method through success, failure and abandonment, and confirm the WooCommerce order status lands correctly each time – paid orders processing, failed orders failed, abandoned orders pending and later cancelled.
• Then live, with small real orders. Sandbox does not prove webhooks, domain verification for Apple Pay, or your live API keys. Before launch, place a real EUR 1-5 order with every single live method – your own card, your own PayPal, a real iDEAL payment – and then refund each one through the gateway dashboard, checking the refund reaches the bank and the order status updates. This finds the classic failures: webhook URL pointing at staging, live keys missing, wallet buttons absent on the live domain.
• Test the emails and the edge cases. Does the order confirmation fire on payment, not on order creation (a customer who abandoned at 3DS should not get a confirmation)? Does a partial refund behave? Does the bank-transfer method show the correct account details?
• Re-test after every gateway plugin update – one small live order takes two minutes and has caught silent breakage for my maintenance clients more than once.

This end-to-end money-path test belongs on every launch plan; it sits alongside the taxes, emails and legal checks in my WooCommerce store launch checklist, and it is the section of that checklist I would keep if I could keep only one.

Switching gateways later: the token problem

A question I get from stores who chose quickly and regret it: “how hard is it to switch?” For one-off payments, honestly easy – install the new gateway plugin, run both side by side for a transition period, disable the old one for new orders once you trust the new one, and keep the old account open for a few months to handle refunds and late disputes on historical orders (refunds must go back through the gateway that took the payment).

The hard part is saved payment data. Card details are never stored in your WooCommerce database (nor should they be – full card storage would put you into serious PCI compliance territory); they live as tokens in the gateway’s vault. Those tokens belong to that gateway. If you run subscriptions or saved-card checkout, switching processors means migrating the vault: PCI-compliant providers can transfer card data directly to each other at the customer’s request – Stripe, Mollie, Adyen and the other majors all support this – but it is a formal process between the two providers that takes weeks, needs project management, and ends with token IDs that must be remapped to your WooCommerce subscriptions so renewals keep charging without asking every customer to re-enter their card. I have run this migration; it is entirely doable and absolutely not a Friday-afternoon job. The practical conclusions: choose more carefully if subscriptions are your business model, favour gateways that support standard token export (all the majors do; some smaller ones quietly do not), and when migrating, test renewal charges on a small batch of migrated tokens before pointing the whole subscriber base at the new processor. If your store talks to accounting, ERP or subscription tooling around the gateway, the webhook and API remapping is its own workstream – the kind of plumbing I handle as API integration work alongside the store itself.

One last teaser, because it deserves its own article: whichever gateway you choose, turn its fraud tooling on from day one. Card-testing attacks – bots firing thousands of stolen card numbers at any checkout they can find – hit small WooCommerce stores constantly, and a gateway-level rule set (velocity limits, CVC and postcode checks, block lists) is your first line of defence long before it becomes your problem at the dispute stage.

Need help setting up payments for your EU store?

I set up, fix and migrate WooCommerce payment gateways for EU stores – method selection per market, Stripe and Mollie configuration, wallets, SCA-proof checkout flows and proper end-to-end testing – as part of my WooCommerce development service. Fixed price quoted within 24 hours. See recent store work in the portfolio or tell me about your store – I reply within 24 hours.

Frequently asked questions

What are the best WooCommerce payment gateways for an EU store?

For most EU stores: Stripe or Mollie as the main processor (cards, wallets and local methods like iDEAL, Bancontact and TWINT) plus PayPal as a second option. Mollie fits EU-first stores; Stripe fits broader markets and custom requirements.

How much do WooCommerce payment gateways cost?

The plugins are free; you pay per transaction. Expect around 1.5-1.8% + EUR 0.25 for EU cards via Stripe or Mollie, around EUR 0.29 flat for iDEAL, and roughly 2.99% plus a fixed fee for PayPal. Always check current price lists.

Do I need PayPal if I already have Stripe or Mollie?

Usually yes. A meaningful share of EU shoppers – especially in Germany – trust PayPal specifically, and removing it costs measurable conversion. Offer it beside cheaper methods, not instead of them.

Is iDEAL worth adding for a store selling to the Netherlands?

Essential rather than worth it: the large majority of Dutch online payments run through iDEAL, and its flat fee of around EUR 0.29 makes it cheaper than cards on almost every order.

What is SCA and do I have to implement it myself?

SCA is the EU rule requiring two-factor confirmation of most online payments; 3D Secure is how card payments meet it. Your gateway handles it automatically – your only job is to run a current, official gateway plugin.

Can I switch payment gateways later without losing customers?

Yes. One-off payments switch easily by running both gateways in parallel. Saved cards and subscriptions require a formal token migration between the two providers – doable with all major gateways, but plan weeks, not days.

How do I test WooCommerce payments before launch?

Test every method in sandbox mode first, then place small real orders (EUR 1-5) with every live method and refund each one, confirming order statuses, webhooks and emails behave correctly end to end.