Mollie for PrestaShop: the multi-method payment gateway

Last reviewed June 2026, the Mollie module behaviour described here (single-dashboard multi-method config, webhook-driven order confirmation, status mapping, per-store and per-currency method selection) is current for PrestaShop 1.7, 8.x and 9.x. Per-method availability and fees depend on your Mollie account and contract, confirm them in your own dashboard.

Here is the problem Mollie was built to solve for European stores: your customers don't all pay the same way. A Dutch shopper reaches for iDEAL, a Belgian for Bancontact, a German for a bank transfer or Klarna, a Pole for BLIK. Serve them all the traditional way and you're installing, configuring and maintaining a separate PrestaShop module for each method. Five admin pages, five sets of API keys, five things that can break at your next core upgrade. Mollie's pitch is consolidation: one module, one account, one dashboard, and you switch payment methods on and off with a checkbox. This guide is about exactly that. What the Mollie module does on PrestaShop specifically, how to wire it in correctly, and the integration details (webhooks, order-status mapping, multi-store, currency) that decide whether it runs smoothly or leaves orders stuck in limbo.

If you're still deciding which gateway to standardise on, that's a different question with its own answer, see our comparison of the best payment modules for PrestaShop. This post assumes you've chosen Mollie, or are close to it, and want to get it working properly.

What "multi-method" actually buys you on PrestaShop

The "So what?" of a single multi-method gateway is mostly about what you don't have to do. With separate modules, every payment method is its own integration surface: its own settings page, its own update cycle, its own support thread when something goes wrong. Each one is an independent point of failure in the single most important page of your store. With Mollie, the methods become rows in one configuration screen. You enable iDEAL, Bancontact and cards, leave the rest off, and they all flow through the same webhook, the same order-status logic, and the same module update.

The practical payoff: fewer moving parts to maintain, one place to look when a payment doesn't confirm, and the ability to add a new market's preferred method by ticking a box rather than sourcing and testing a new module. For the strategic case for offering more methods in the first place, and the conversion logic behind it, see why offering more payment options means more sales. The point here is narrower: Mollie is the mechanism that makes "offer everything your market expects" a configuration job instead of a development project.

The payment methods, and where they fit

Mollie's module exposes a long list of methods, but you'll only ever enable the handful your markets actually use. They group cleanly:

• Local bank-based methods, iDEAL (Netherlands), Bancontact (Belgium), EPS (Austria), Przelewy24 with BLIK (Poland), plus SEPA Direct Debit and bank transfer for the wider SEPA zone. These are usually the reason a European merchant picks Mollie at all.
• Cards, Visa, Mastercard, Amex, Maestro, and France's Carte Bancaire, handled through Mollie's card processing.
• Wallets. Apple Pay and Google Pay (processed as card transactions), and PayPal through Mollie's integration.
• Buy now, pay later, Klarna and in3, where available for your account and market.

Two things worth knowing before you lean on this list. First, the exact methods, availability and per-method fees depend on your Mollie account, your country and your contract, always confirm the current numbers in your own Mollie dashboard rather than trusting a figure in a blog post, because they change. Second, several of these methods deserve a closer look than a bullet point. The local bank-based methods are the ones that genuinely unlock markets. We cover what they are and why they matter in BLIK, iDEAL and Bancontact. The BNPL methods carry their own conversion and risk trade-offs, covered in buy now, pay later and what it means for your conversion. And if Poland is a serious market, Przelewy24 through Mollie is one route, but a dedicated setup has its own considerations, see setting up Polish payments with Przelewy24.

Installing and configuring the Mollie module

The official Mollie module is free and published on PrestaShop Addons; Mollie also distributes builds on GitHub. The whole process is a back-office job, no theme edits, no core changes, and realistically takes well under an hour, most of which is waiting on account verification rather than configuration. The sequence:

1. Create and verify a Mollie account

Sign up at mollie.com, supply your business details, upload identity documents and confirm the bank account where payouts land. Verification typically takes a few business days; some business types take longer. You can install and test the module on the test key while this is pending, so it's worth starting the account verification first and building the integration in parallel.

2. Install the module

In the back office go to Modules → Module Manager → Upload a module and drop in the Mollie ZIP, or find it via the Addons marketplace. Install, then click Configure.

3. Connect your API keys

In the Mollie dashboard, open Developers → API keys and copy both the Test and Live keys. Paste them into the module's configuration page. Start in test mode. The module keys off which key is active, so a test key means test transactions, and you flip to live when you're confident.

4. Enable the methods you want

Once the key is connected, the module pulls the list of methods your account supports and shows them as toggles. Enable only the ones your markets use, a checkout cluttered with payment options nobody recognises hurts more than it helps. For each enabled method you can set the display name per language, minimum and maximum order amounts (handy because some methods aren't economical on a €3 order, and BNPL often has its own floor), the order in which methods appear, and the description shown on the payment page. Spending five minutes ordering the methods so your dominant market's choice sits first is one of the easiest wins here.

[SCREENSHOT: The Mollie module configuration screen in the PrestaShop back office, showing the list of payment methods as enable/disable toggles with the per-method order and min/max amount fields]

5. Confirm the webhook and run test payments

The module sends the webhook URL to Mollie when it creates each payment, but verify it works, because the webhook is the single most important part of the integration (next section explains why). The way to confirm it is to run test payments and check Mollie's payment view and your webserver logs that the callback actually fired. Then, on the test key, run a payment through each enabled method. Mollie supplies test card numbers and test flows. Check that the order is created, the status updates after payment, the success and failure pages render, and the confirmation email goes out.

6. Go live

Switch to the live key and put a small real transaction through to confirm production behaves like test. Watch the first day or two of real orders for any that hang in "Awaiting payment". That's almost always a webhook problem, which is the next thing to understand.

The webhook: the one detail that breaks most often

If a Mollie integration goes wrong, the symptom is nearly always the same: the customer pays, but the order sits in Awaiting payment in PrestaShop and never advances. That's not a payment failure, the money moved. It's a webhook failure. Mollie doesn't tell your store the payment succeeded by keeping the browser tab open; it sends a server-to-server callback to a URL on your store, and the module updates the order when that callback arrives. If the callback can't reach you, PrestaShop never learns the payment cleared.

You don't paste the webhook URL into Mollie by hand, the module passes it to Mollie automatically on each payment. It's a module front-controller endpoint, roughly of the form below; knowing the shape helps you test that it answers from outside your network:

https://yourstore.com/module/mollie/webhook

Open that URL in a browser from a connection that isn't your office network. You should get some response (even an error or a short "OK" body), never a timeout. A timeout means Mollie's servers can't reach it either. The usual culprits, in roughly the order worth checking them:

• The endpoint isn't reachable from the outside. A firewall, CDN rule, IP allowlist or staging-style HTTP basic-auth in front of the store will silently block Mollie's servers. The webhook URL must be publicly reachable, not just reachable from your office.
• A slow or erroring response. Mollie expects a fast, clean reply to the callback. A slow endpoint that takes too long, or one throwing a 500, will look like a delivery failure, check your server error log for 500s on the Mollie endpoint.
• SSL problems. An expired or misconfigured certificate breaks the callback.
• localhost / dev quirk. Mollie can't call a webhook on a site it can't see from the public internet, so callbacks won't fire on a local dev box, expected behaviour, not a bug.

The diagnostic habit worth building: when an order hangs, don't assume the payment failed. Open the Mollie dashboard, find the payment, confirm its status there, then look at your webhook delivery and server logs. The mismatch between "paid in Mollie" and "awaiting payment in PrestaShop" points straight at the callback.

Order-status mapping

Mollie has its own payment states: open, pending, authorized, paid, failed, canceled, expired (refunds are tracked as separate objects, not a payment state), and the module maps each onto a PrestaShop order status. The default mapping works for a standard store out of the box. Where you need to look is if you run custom order statuses (a common setup once a store has its own fulfilment workflow): check the module's status-mapping settings so a Mollie "paid" lands on the PrestaShop status your shipping and accounting processes actually watch, not a generic one they ignore. Refunds are worth a check too: verify whether refunds issued from the Mollie dashboard sync back into your module version and create the expected PrestaShop refund records, and if they don't, record those dashboard refunds manually in PrestaShop and your accounting so the two don't drift into two disconnected places.

Multi-store and multi-currency behaviour

Two PrestaShop-specific mechanics are worth knowing because they trip up merchants who assume one global setting:

• Multi-store. If you run PrestaShop's multi-store feature, each store can carry its own Mollie configuration, different API keys, different enabled methods, different settings. That's exactly what you want when each store fronts a different market: your Dutch storefront leads with iDEAL, your German one with bank transfer and Klarna, without one bleeding into the other.
• Multi-currency. Some methods are currency-bound. IDEAL, for instance, is EUR-only. The module shows the customer only the methods valid for their selected currency, so a shopper checking out in GBP won't be offered a EUR-only method. The thing to verify: that your multi-currency setup still leaves each market with at least one sensible method in its own currency, so you're never showing a customer an empty payment step.

What this costs to run

Mollie's model is pay-per-transaction: no monthly fee, no setup fee, no minimum commitment, so a low-volume store isn't paying for capacity it doesn't use. The headline that makes it attractive for European stores is that local bank-based methods like iDEAL and Bancontact are priced as low flat per-transaction fees rather than a percentage. Which, on higher-value orders, works out far cheaper than a percentage-based card or wallet fee.

The honest caveat: the exact per-method fees depend on your account, country and contract, and Mollie can revise them, so model your real numbers from your own dashboard before you commit, don't budget off a fee quoted in an article. The structural point that doesn't change is the shape of the saving: the more of your volume runs through cheap local methods instead of cards, the lower your effective blended rate. That's the genuine financial argument for putting the local methods in front of the right markets, and it's measurable on your own settlement reports rather than something you have to take on faith.

Where Mollie sits among the alternatives

Mollie's sweet spot is a store selling into Benelux, the DACH region or other European markets where local bank-based payments dominate and you want broad method coverage from one integration. It is not automatically the right answer for every store, if your market is largely outside Europe, or you need deep developer-level payment customisation or complex subscription billing, a card-first processor may fit better.

Rather than re-fight those comparisons here, the cluster covers them properly: the head-to-head between the two big card processors is in Stripe vs PayPal, the dedicated Stripe-on-PrestaShop setup is in our Stripe integration guide, and the wider question of what European customers actually expect at checkout, which is really the demand Mollie is answering, is in payment methods for European e-commerce.

Keeping every method inside one checkout

Mollie already consolidates the methods behind one module, but they still surface on whatever checkout your theme renders. If you want the methods Mollie gives you (iDEAL, Bancontact, BLIK, cards, wallets) to appear cleanly inside a single, modern one-page payment step rather than a stack of redirect buttons, that's a checkout-layer job, and it's what our Checkout Revolution module is built for: one streamlined payment step that the customer self-selects from, with the order data landing consistently in PrestaShop regardless of which Mollie method took the payment. The funnel matters where the method count is high. The more options Mollie puts on the page, the more the presentation of that page decides whether the started payment finishes.

The bottom line

For a European PrestaShop store, Mollie's argument is simple and mostly operational: it turns "support every payment method my customers expect" from a stack of separate modules into a single, maintainable integration you manage from one back-office page and one dashboard. Get three things right and it runs quietly in the background, a publicly reachable webhook so paid orders actually advance, an order-status mapping that matches your fulfilment workflow, and a per-store, per-currency method selection that fits each market. Get the webhook wrong and you'll spend your first week chasing orders stuck in "Awaiting payment." The setup is genuinely a back-office job; the value is in offering the right methods to the right markets without maintaining a separate integration for each one.

Frequently asked questions

Why does my order stay "Awaiting payment" after a customer paid through Mollie?

Because the money moved at Mollie but the webhook callback that tells your store didn't arrive. Mollie confirms payments with a server-to-server call to a URL on your shop, not through the customer's browser, if a firewall, CDN rule, expired SSL certificate or staging basic-auth blocks that call, PrestaShop never learns the payment cleared. Confirm the payment status in the Mollie dashboard, then check your webhook delivery and server error log. A mismatch between "paid in Mollie" and "Awaiting payment in PrestaShop" points straight at the callback.

Do I have to enter the webhook URL into Mollie myself?

No. The module passes the webhook URL to Mollie automatically when it creates each payment, so there's no field to fill in the Mollie dashboard. Your job is just to make sure that endpoint (a module front-controller, roughly https://yourstore.com/module/mollie/webhook) is reachable from the public internet. Open it from a connection outside your office network. You should get some response, never a timeout.

Is Mollie cheaper than a card processor like Stripe?

It depends on your method mix. Mollie prices local bank-based methods such as iDEAL and Bancontact as low flat per-transaction fees rather than a percentage, which works out far cheaper than percentage-based card fees on higher-value orders. So the more of your volume runs through those local methods instead of cards, the lower your effective blended rate. On a card-heavy, non-European store the advantage shrinks. Model it from your own settlement reports, since per-method fees depend on your account and contract.

Can each store in a PrestaShop multi-store run a different Mollie setup?

Yes. Mollie's module supports per-store configuration, so each store can carry its own API keys and its own set of enabled methods. That's exactly what you want when each storefront fronts a different market. Your Dutch store can lead with iDEAL while your German store leads with bank transfer and Klarna, without one bleeding into the other.

Why isn't iDEAL showing up for some customers?

Most often because they're checking out in a currency it doesn't support, iDEAL is EUR-only. Mollie's module shows each customer only the methods valid for their selected currency, so a shopper paying in GBP won't see iDEAL at all. Verify that your multi-currency setup still leaves every market at least one sensible method in its own currency, so a customer is never shown an empty payment step.