Skip to content
5.0 Upwork, 100+ reviews Adobe Certified since 2021 New: become your own Magento developer Learn more →
Hire me
Toggle Nav
My Cart
Magento glossary

What is Mollie for Magento?

Short answer Mollie for Magento is the official mollie/magento2 module, free and maintained by Mollie, that adds Mollie Payments to the Magento 2 checkout. It covers iDEAL, the method most Dutch shoppers use, plus Bancontact, cards, Apple Pay, Google Pay, PayPal, Klarna, Trustly, EPS, Przelewy24 and BLIK. Pricing is set per payment method with no monthly fee, and signup is self-service. That is why I reach for it first on stores selling into the Netherlands, Belgium, Germany and Austria.

Need Mollie + iDEAL setup? How it works

Written by Kishan Savaliya, Adobe Certified Magento & Hyvä developer, 10+ years on the platform

How it works
  1. Composer-install the official Mollie module 01
  2. Run setup:upgrade and flush cache 02
  3. Sign up at mollie.com and fetch your API key 03
  4. Configure Mollie in admin and enable methods 04
  5. Checkout renders methods; Mollie webhook closes the loop 05
Each step is explained below

Most common mistake Enabling iDEAL without the bank-issuer dropdown

How it works

Five steps from composer install to live checkout

The Mollie module is open source, so you can read exactly what it does. These are the steps I follow from install to the first paid order.

  1. 01

    Composer-install the official Mollie module

    Run composer require mollie/magento2 from the Magento project root. The package is on Packagist, free, and maintained by Mollie itself. There is nothing to buy and no licence key. Before I install it, I check the module’s release notes for the Magento and PHP versions it supports, so it matches the store’s 2.4.x version.

  2. 02

    Run setup:upgrade and flush cache

    Run bin/magento setup:upgrade --keep-generated && bin/magento cache:flush. That registers the module, creates its database tables and clears the caches, so the Mollie settings show up in the admin. On production mode stores I follow it with setup:di:compile and a static content deploy as usual.

  3. 03

    Sign up at mollie.com and fetch your API key

    Signup at mollie.com is self-service, much like Stripe, with no sales contract like Adyen usually needs. Mollie checks the business before live payments are allowed. Each website profile in the Mollie dashboard has two API keys: a test_ key for testing and a live_ key for real payments.

  4. 04

    Configure Mollie in admin and enable methods

    Open the Mollie section in Stores » Configuration, paste the test key first, and pick the scope (default or per website). Then switch on the methods you want one by one: iDEAL, Bancontact, cards, Apple Pay, PayPal, Klarna and the rest. Only methods that are also active in your Mollie dashboard will show at checkout, which is the first thing I check when a method is missing.

  5. 05

    Checkout renders methods; Mollie webhook closes the loop

    At checkout the shopper picks a method, is sent to their bank or a Mollie payment page, approves the payment and comes back to your success page. Separately, Mollie calls /mollie/checkout/webhook on your store, and the module moves the order from pending to processing. That webhook works even if the shopper closes the tab before returning, so it must be reachable: no basic auth, no firewall block.

When to use

Four situations where Mollie is the obvious answer

Mollie does not suit every store, for example one selling mostly in the US. In these four cases it is the one I would pick.

  • Dutch, Belgian, German, or Austrian stores

    In the Netherlands most shoppers pay online with iDEAL, and in Belgium Bancontact plays the same role. A Dutch store without iDEAL loses buyers at the payment step. Mollie supports both out of the box, along with the local methods German and Austrian shoppers expect. For a store selling mainly into NL, BE, DE or AT, it is usually the first PSP I look at.

  • D2C brands wanting one-click multi-method support

    Mollie puts the common European methods behind one account and one admin screen: cards, Apple Pay, Google Pay, PayPal, Klarna, and bank methods such as iDEAL, Bancontact, Trustly, EPS, Przelewy24 and BLIK. If a brand wants to add Klarna and Apple Pay without wiring up several payment providers, it is one module and one payout account instead of three or four.

  • Stores wanting per-method pricing transparency

    Mollie publishes a separate price for each payment method on its website, so a cheap bank payment like iDEAL is not charged at a card rate. There is no monthly fee. If the finance team wants to know what each method costs per order, this makes the sums simple. Check mollie.com for the current rates before you quote them to anyone.

  • Multi-store Magento across multiple countries

    One Magento install with NL, BE, DE and FR storefronts can send each one to its own Mollie website profile. You set the API key at default scope and override it at website or store view scope. Each profile then has its own methods, its own payouts and its own reporting, which keeps country-level bookkeeping clean.

Common mistakes

Three Mollie misconfigs that hurt conversion

When a Mollie checkout misbehaves, it is usually one of these three. Check your admin config and the webhook log for them.

  • Enabling iDEAL without the bank-issuer dropdown

    iDEAL is a bank-direct method, the buyer picks their bank (ABN AMRO, ING, Rabobank, etc.) before being redirected, so the bank-issuer dropdown is part of the iDEAL UX, not optional chrome. The Mollie module has a show_issuers setting in admin (Payment Methods » iDEAL » Show Issuers). Leave it on. Turning it off forces the buyer to pick a bank on a Mollie-hosted page after redirect, which adds an extra click and tanks conversion by 5-10% on a Dutch storefront.

  • Not whitelisting the Mollie webhook in your firewall

    Mollie pings /mollie/checkout/webhook after every payment to confirm or fail the order, the customer return URL is best-effort, the webhook is the source of truth. If your WAF / Cloudflare / nginx geo-block rules drop Mollie’s callback IPs, the webhook fails silently and orders sit in «pending_payment» forever. Always whitelist Mollie’s documented webhook IP range and tail var/log/mollie.log in staging to confirm webhook delivery before going live.

  • Confusing Klarna-via-Mollie with direct Klarna

    Mollie resells Klarna Pay-Later / Pay-Now under its own contract, convenient because you get Klarna with one signup, but Mollie applies a fixed pricing markup over Klarna’s direct merchant rate. For stores under ~€50k/month of BNPL volume the markup is rounding error; for high-volume BNPL merchants (~€500k/month+), going direct with Klarna’s own Magento module is meaningfully cheaper. Model the all-in cost on your last 12 months of BNPL volume before defaulting to Mollie’s Klarna passthrough.

Related concepts

Five neighbour concepts most readers want to look at next. Click through for the full deep-dive.

FAQ

Mollie for Magento: frequently asked questions

  • Mollie vs Adyen for Magento, when do you pick which?
    Same country (Amsterdam), different segment. Mollie targets SMB and mid-market: self-service signup in 10 minutes, per-method flat pricing on the public website, MIT-licensed Magento module pulled from Composer, no minimum volume. Adyen targets enterprise: ~€100M+ GMV merchants, negotiated interchange-plus pricing, dedicated implementation manager, sales-led onboarding that takes weeks. If you can sign up with a credit card and an email address, you want Mollie. If your finance team is negotiating interchange+ rates with a named account manager, you want Adyen. Most Magento stores in Europe (sub-€50M GMV) belong on Mollie.
  • Mollie vs Stripe for European stores?
    Both work, the decision turns on three factors. (1) Geography: Mollie wins decisively in NL / BE / DE / AT because iDEAL and Bancontact are first-class methods with proper bank-issuer dropdowns; Stripe supports them but the UX is bolted on. Stripe wins in UK / FR / IT / ES where cards dominate. (2) Pricing model: Mollie publishes per-method flat rates (iDEAL €0.29 + 1.8%); Stripe charges a blended ~1.5% + €0.25 on EU cards. For an iDEAL-heavy mix, Mollie is cheaper; for a cards-only mix, Stripe is cheaper. (3) Developer DX: Stripe’s API and docs are still the industry benchmark, but Mollie’s Magento module is genuinely well-built and Mollie-maintained, so the integration gap is smaller than it used to be.
  • What is iDEAL and why is it mandatory in the Netherlands?
    iDEAL is a Dutch bank-direct payment method launched in 2005, the buyer picks their bank from a dropdown at checkout, gets redirected into their bank’s online banking environment, authorises the payment with their normal banking 2FA, and is bounced back to the merchant. It is owned by the Dutch banks collectively (Currence is the scheme operator). As of 2026, iDEAL accounts for ~70% of all e-commerce transactions in the Netherlands. It is not literally mandatory by law, but offering a Dutch storefront without iDEAL effectively means refusing 70% of buyers’ preferred method, conversion craters. Mollie is the cleanest way to enable iDEAL on Magento because the bank-issuer dropdown, redirect, and webhook are native.
  • Can I get Klarna BNPL through Mollie?
    Yes, Mollie resells Klarna Pay-Later (Pay in 30 days), Pay-Now, and Pay in 3 / Pay in 4 under its own merchant contract. Enable Klarna inside the Mollie admin tab and it surfaces at checkout alongside the other methods. Pros: one signup, one settlement account, one dispute queue across all methods. Cons: Mollie applies a fixed pricing markup over Klarna’s direct merchant rate (Mollie’s Klarna sits at ~2.99% + €0.39 vs Klarna direct at ~2.49% + €0.30 depending on volume tier). For sub-€50k/month BNPL volume the markup is negligible. For €500k/month+ BNPL volume, integrate Klarna directly via its own Magento module and keep Mollie for the rest.
  • Does Hyvä work with Mollie for Magento?
    Yes, Mollie’s 2.x line ships Hyvä Checkout compatibility. The Mollie module exposes a checkout step component that works against both the legacy Luma / KnockoutJS checkout and the Hyvä Checkout Alpine.js-based stack. For the iDEAL bank-issuer dropdown specifically there is a Hyvä-flavoured template override that renders the dropdown as a native Alpine select rather than the Luma Knockout binding. Confirm against the module changelog before pinning a version, Hyvä Checkout support landed in mollie/magento2 v2.30 and has improved with each minor since. Setup is the standard Hyvä compatibility module install pattern; no custom integration work needed for the common case.
  • Multi-store Magento, can each store have its own Mollie profile?
    Yes, Mollie supports a separate profile_id per website scope inside Magento. Configure the API key at default scope (one Mollie account) and override the profile_id at website scope for each storefront (NL profile / BE profile / DE profile). Each Mollie profile carries its own settlement bank account, VAT registration, method enablement matrix, dispute queue, and webhook URL. This is the standard pattern for a Magento install running multiple country storefronts off one codebase, and it is one of the reasons Mollie beats single-profile PSPs for multi-country setups. The website-scope override lives at Stores » Configuration » Sales » Payment Methods » Mollie » General » Profile ID; remember to switch the configuration scope dropdown to the target website before saving.
Mollie audit

Want a Mollie integration audit on your Magento store?

Send your storefront URL: I will audit your Mollie module version, method enablement, iDEAL issuer dropdown, webhook delivery, and per-website profile setup, then reply with a written fix plan, fixed-price quote, and earliest start date. 24-business-hour turnaround.

Get a Mollie audit Hire me directly
Kishan Savaliya Online 10 AM to 7 PM IST Chat on WhatsApp