BLIK, iDEAL, Bancontact: local payment methods that unlock local markets

Gateway rail coverage (Mollie, Stripe, Przelewy24, Adyen) reflects the methods these modules carried at time of writing; availability depends on your merchant account, so confirm the current list in the provider's dashboard before you commit.

Here is the uncomfortable truth about selling cross-border from a PrestaShop store: in the markets where you are losing the most checkouts, the customer often cannot pay you with the methods you offer. A Belgian shopper holding a Bancontact-only debit card cannot type it into a Visa field. A Dutch shopper who has used iDEAL for fifteen years sees a card form and quietly closes the tab. A Polish shopper under forty reaches for BLIK on their phone, doesn't find it, and assumes your store is foreign and risky. This isn't a pricing problem or a trust-badge problem. It's a payment-rail problem, and on PrestaShop it has a concrete, configurable fix.

This guide is specifically about getting BLIK, iDEAL and Bancontact, the three dominant local rails of Poland, the Netherlands and Belgium, live in a PrestaShop checkout: which gateway module actually delivers each one, where the settings live in the back office, and how to show each method only to the customers who use it. For the broader case of why a wider payment mix lifts sales, see why offering more payment options means more sales; for a country-by-country map of what European shoppers expect, see payment methods for European e-commerce.

The three rails, and why each is a hard requirement (not a nice-to-have)

BLIK, iDEAL and Bancontact aren't "alternative" payment methods in their home markets. They are the default, and card is the fallback. The distinction matters because it changes the question from "should I add this?" to "can my customers here pay me at all?"

So what does that mean for your store? If you ship to these countries and don't offer the matching rail, the lost sale doesn't show up as a complaint, it shows up as a checkout abandonment you can't explain. The customer who can't pay the way they always pay doesn't email you. They leave. That's why this is the one payment change worth doing before you tune anything else on the checkout.

The PrestaShop reality: you don't integrate three rails, you pick a gateway

The instinct is to hunt for "a BLIK module," "an iDEAL module" and "a Bancontact module." Don't. On PrestaShop, each of these rails is delivered through a payment service provider's gateway module, and a single well-chosen gateway covers all three plus cards under one integration, one settlement account, and one set of reporting. Three separate modules means three places to keep PCI/SCA settings aligned, three sets of upgrades to chase across PrestaShop versions, and three chances for a hook conflict on the payment step.

The practical question, then, is which gateway module delivers which rail, because coverage genuinely differs, and that's what should drive the choice for your specific market mix.

Coverage and availability shift over time and depend on your merchant account's enabled methods, so confirm the current list in the provider's dashboard before you commit, but the pattern is stable: a Benelux-led store leans Mollie, a Poland-led store leans Przelewy24, and a store that wants cards plus these rails under one roof leans Stripe. Each of these has its own setup depth, covered where it belongs: Mollie as a multi-method gateway, setting up Przelewy24 and Polish payments, and the Stripe integration guide. If you're still choosing a primary processor at all, Stripe vs PayPal and the full payment-module comparison are the right starting points.

Turning the rails on: where the settings actually live

Whichever gateway you choose, the PrestaShop side follows the same shape. After you install the module (Modules → Module Manager, upload the ZIP or install from the catalogue), the methods are enabled in two places that merchants routinely confuse:

• In the gateway dashboard (Mollie/Stripe/P24 side): the rail has to be activated on your merchant account first. iDEAL and Bancontact may already be available, but must be enabled or approved in the PSP dashboard depending on your account and country; BLIK frequently must be explicitly enabled, sometimes after a short review. If a method never appears at checkout no matter what you do in PrestaShop, this is almost always why, the rail isn't switched on at the account level.
• In the module configuration (PrestaShop side): open the module and you'll find a list of payment methods with per-method toggles, ordering, and (in Mollie's and Adyen's modules) per-method country and currency rules. This is where you decide which rails render, and in what order, on the order controller's payment step.

Two PrestaShop-specific settings make or break the result. First, currency. iDEAL, Bancontact and BLIK are euro/PLN rails, BLIK settles in PLN, the others in EUR. Under International → Localization → Currencies, make sure PLN exists and is enabled if you're targeting Poland; a BLIK method will silently refuse to show on a cart priced in a currency it can't process. Second, SCA/3-D Secure: these are European rails under PSD2, so leave Strong Customer Authentication active in the gateway. The redirect-to-bank step is the authentication, and disabling it doesn't speed anything up, it just breaks the flow.

Show the right rail to the right customer

This is the step most stores skip, and it quietly costs conversions. Showing every rail to every customer turns the payment step into a wall of logos: a French shopper scrolling past iDEAL, Bancontact and BLIK to find a card field is friction, and on the final screen before conversion, friction is expensive. The goal is the opposite, each customer sees the three or four methods that are theirs, card included as the universal fallback.

PrestaShop gives you this filtering, and there are three levels of control:

• Gateway-module country rules. The Mollie and Adyen modules let you bind a method to billing countries directly in their config. Set Bancontact to Belgium, iDEAL to the Netherlands, BLIK to Poland. This is the cleanest route because the logic lives with the method.
• Core payment restrictions. PrestaShop's own Payment → Preferences page lets you restrict modules by currency, country, group and carrier. A restrictions matrix where you can switch a payment module on or off per dimension. It's coarser than per-method rules but works against any gateway.
• Module hook ordering. The payment step renders the options returned by each module on the paymentOptions hook (called displayPayment on 1.6); the order they appear is the order you set in the module's config or the hook position. Put the dominant local rail first for that market, card second. The customer should see their default before the fallback.

If you want this targeting to read as deliberate rather than cluttered, it pairs naturally with a tidy payment step on a one-page checkout, where the relevant methods sit together with the order total in view instead of buried under a step gate.

Test it before you trust it, the part that bites in production

Local rails fail in ways cards don't, and they fail after the customer leaves your site, so a quick "it loads" check isn't enough. Walk each rail end to end in the gateway's test/sandbox mode before you go live:

• The return journey. iDEAL and Bancontact use bank redirects; BLIK can use code entry at checkout with confirmation in the banking app. The order only confirms when the gateway calls your store's webhook/IPN, not when the customer returns. If your server blocks the callback URL, or a caching/CDN layer or a security module sits in front of the module's webhook controller, you get the classic ghost: money taken, order stuck in a pending/incomplete state. Confirm the webhook lands and flips the order to a paid state.
• The abandoned redirect. Test what happens when the customer reaches the bank screen and closes it. The cart should remain recoverable and the order shouldn't be marked paid. This is also where an abandoned-cart follow-up earns its keep, since redirect drop-off is a normal part of these flows.
• Currency match. Place a real test order in PLN to confirm BLIK appears and settles, and in EUR for iDEAL/Bancontact. A method missing at checkout is nearly always a currency or country-rule mismatch, not a bug.

What the webhook controller actually does

The "ghost order" above is worth understanding rather than just testing for, because it's the failure mode that quietly costs you reconciled sales. On a redirect rail, the order is created in a pending state when the customer leaves for their bank; it's the gateway's server-to-server callback, not the browser returning, that confirms payment. In a PrestaShop module that callback hits a dedicated front controller, and its job is narrow: verify the notification is genuinely from the gateway, then move the order to a paid state. The shape is always this:

// controllers/front/webhook.php – reached at
// index.php?fc=module&module=yourmodule&controller=webhook
class YourModuleWebhookModuleFrontController extends ModuleFrontController
{
    public function postProcess()
    {
        // 1. Read + verify the notification really came from the gateway
        //    (signature / API re-fetch – never trust the raw POST alone).
        $paymentId = Tools::getValue('id');
        $status    = $this->module->api->getPaymentStatus($paymentId);

        // 2. Only on a confirmed-paid status, flip the order forward.
        if ($status === 'paid') {
            $this->module->validateOrder(
                (int) $cartId,
                (int) Configuration::get('PS_OS_PAYMENT'), // "Payment accepted"
                $amountPaid,
                $this->module->displayName
            );
        }

        // 3. Answer 200 fast – the gateway retries on timeout/non-200.
        http_response_code(200);
        exit;
    }
}

Two things in there are where real stores break. The verification step (1) is why you never mark an order paid just because the customer's browser came back to the success URL. That URL can be reached without payment; the authoritative signal is the verified webhook. And the fast 200 (3) is why a heavy CDN or security layer in front of that controller is dangerous: if the gateway's POST is challenged, rewritten or times out, it never gets its 200, the order never flips, and you get the paid-but-pending ghost. You don't write this controller, the gateway module ships it, but knowing its three jobs tells you exactly what to check when an order hangs: is the callback URL reachable, is it returning 200, and is anything sitting in front of it.

How to know it worked

Don't judge this on a feeling or on three days of data. Before you add the rails, record two numbers segmented by country from your analytics: checkout abandonment rate and cart-to-order conversion for the Netherlands, Belgium and Poland specifically. After the rails are live, compare the same per-country numbers over at least 30 days and a meaningful order count, enough volume that you're seeing a trend, not week-to-week noise. The win here is rarely a uniform site-wide lift; it's a sharp recovery in the specific markets that previously couldn't pay you, which is exactly why you measure them separately. Whatever uplift you've seen quoted for adding a dominant local rail, treat it as directional and let your own segmented numbers be the verdict.

One more rail worth a mention while you're in the payment settings: in these same markets, buy-now-pay-later (Klarna in particular) sits right next to BLIK and iDEAL in shopper expectations, and most of the gateways above can switch it on the same way. Whether it's worth offering is a separate decision. We work through it in buy now pay later and what it means for your conversion.

The principle underneath all of this is simple: every customer who reaches your payment step has already decided to buy, and your only job is to not stand between them and the method they trust. On PrestaShop, that means picking one gateway that carries iDEAL, Bancontact and BLIK, enabling each rail on both the account and the module side, targeting it to the country that uses it, and proving the return-journey webhook fires before you celebrate. Get those four things right and the markets that were quietly leaking orders start converting like your home market does.

Frequently asked questions

Do I need a separate module for BLIK, iDEAL and Bancontact?

No, and you shouldn't. Each rail is delivered through a payment service provider's gateway module, and one well-chosen gateway carries all three plus cards under a single integration and settlement account. Mollie covers all three as first-class methods; Stripe carries them alongside cards; Przelewy24 is the Poland-first route with BLIK native. Three separate modules just means three sets of upgrades, three places to align SCA settings, and three chances for a payment-step hook conflict.

Why isn't BLIK showing at my checkout even though I enabled the module?

Two usual causes. First, the account level: BLIK frequently has to be explicitly enabled in the gateway dashboard (sometimes after a short review) before it can ever appear, enabling the PrestaShop module isn't enough. Second, currency: BLIK settles in PLN, so it silently refuses to render on a cart priced in a currency it can't process. Confirm PLN exists and is enabled under International → Localization → Currencies, and that BLIK is switched on in the provider dashboard.

The customer paid with iDEAL but the order is stuck pending, what happened?

The return journey completed in the browser but the gateway's server-to-server webhook didn't reach your store, so the order never flipped to paid. The order is confirmed by the webhook, not by the customer landing back on your success page. Check that the module's webhook/callback URL is publicly reachable, returns a fast 200, and that no CDN, cache layer or security module is sitting in front of it challenging or rewriting the gateway's POST.

Which gateway should I pick if Poland is my main market?

Lean Przelewy24, it's BLIK-native and centred on Polish bank transfers, so it's the deepest fit when Poland is your centre of gravity. If you also need strong card and global coverage in the same store, Stripe carries BLIK (in PLN, subject to account enablement) alongside cards, which can be the simpler single-roof choice. The dedicated Przelewy24 setup guide walks the Poland-first route end to end.

Do these redirect rails still need 3-D Secure / SCA?

They're already built around it. iDEAL, Bancontact and BLIK are European rails under PSD2, and the redirect-to-bank (or in-app confirmation) step is the strong authentication. Leave SCA active in the gateway. Disabling it doesn't speed anything up, it breaks the flow. For the card fallback alongside these rails, the same gateway handles 3-D Secure for you; you don't hand-code any of it.