Mollie Guide: European Local Payment Methods, Onboarding, and Where It Fits
Mollie is a platform that is easy to misread. Many teams compare it as a European Stripe and conclude that the fee is similar and there is nothing special about it. Others assume it is a general gateway that can acquire globally, and only find out after going live that some markets and payment methods are outside its coverage. Both readings miss what it actually does well: aggregating European local payment methods for the European market, with onboarding that is relatively friendly to small and medium businesses. This guide follows the order in which you would really integrate it, covering what it aggregates, what onboarding looks at, how local methods are covered, how to choose between plugins and API, how subscription and platform products work, where fees come from, and what the real relationship with Adyen and Stripe is.
1. Where Mollie Fits: Aggregating European Local Methods
1.1 The problem it solves
Payment habits in Europe are highly fragmented. In the Netherlands iDEAL dominates online payments. In Belgium the Bancontact share is hard to ignore. In Germany and Austria, local bank transfer schemes and buy-now-pay-later methods have long held a meaningful share. In Poland and the Nordics, local transfer systems form their own ecosystems. A merchant that only connects an international card scheme channel loses a measurable share of orders that would otherwise have completed in these markets.
That is where the value of Mollie sits: it bundles local payment methods from across Europe into a single account and a single interface, so one team does not have to find a separate local acquirer, negotiate a separate contract and maintain a separate reconciliation flow for every country. Its headquarters being in the Netherlands matters here. Product design and payment method coverage grow out of European local habits rather than starting from a global footprint and backfilling local detail.
1.2 It is not a global acquiring platform
The boundary needs stating first: Mollie's home ground is Europe. Its local method depth concentrates on European countries, which is a different positioning from Adyen, which is built for multi-region, multi-currency, unified online and offline acquiring.
If your business sells mainly into Southeast Asia, Latin America, the Middle East or North America, the incremental value Mollie offers drops noticeably. This is not a question of product quality but of positioning. A platform that has invested heavily in European local methods does not automatically gain local acquiring capability and localised checkout just because you want to enter another market.
So the order of judgement should be: first look at where your buyers are, then look at what this platform covers there. For the wider regional picture of payment methods, see the Local Payment Methods by Region Guide, which organises mainstream methods and adaptation logic by region.
2. Onboarding and European Entity Requirements
2.1 Entities and documentation
Mollie serves merchants with genuine operating activity, and onboarding verifies entity registration, business model, website content and expected transaction volume. As with any acquirer, entity location is the central variable, because it decides whether you can open an account directly or need an agent or cross-border arrangement.
For a local European team this step is usually straightforward, because the entity, the bank account and the business scenario all sit in the same jurisdiction. For teams with a non-European background, the common route is to apply with a local European entity and prepare material that explains the business. Note that friendly onboarding does not mean no threshold: being friendly to small and medium businesses refers to a relatively streamlined process and standardised documentation, not to a review so loose that you never have to explain the business.
2.2 What reviews look at
The core question remains whether the business is explainable: what you sell, to whom, whether prices are plausible, whether clear terms and a refund policy exist, and whether a usable support channel is present. Whether this is complete on the site directly affects review speed.
A common misconception is that review only looks at registration documents. In practice, how verifiable the website is often matters more, because the reviewer has to judge the nature of the business from a page a third party can reach. If product descriptions are vague, terms are missing and the only contact route is a form, the number of rounds of back-and-forth rises noticeably.
A second layer of requirement in Europe comes from tax. Cross-border selling raises VAT registration and invoice content questions, and these come up when applying for an acquiring account as well. For background see the VAT and Sales Tax Compliance Guide.
3. Local Payment Method Coverage
3.1 Coverage scope
Working through Mollie's local methods country by country is more useful than reading a vague list of how many payment methods are supported. The table below groups the main local methods with their coverage status and the integration points that need attention.
| Local method | Mollie coverage | Integration notes |
|---|---|---|
| iDEAL | Supported, a core local method in the Netherlands | Bank selection and redirect are hosted by the platform, so verify the return path and order state sync |
| Bancontact | Supported, widely used in Belgium | Mobile redirects are frequent, so handle orders that never return to your site |
| Local bank transfer schemes | Covers several bank transfer methods in markets such as Germany | Settlement cadence differs from card payments, so design reconciliation separately |
| Buy-now-pay-later methods | Covers the main relevant schemes | Depends on buyer eligibility checks, so map dispute and refund flows separately |
| International card schemes | Supported, running alongside local methods | Card mix directly determines cost composition |
| Local methods in other countries | Mostly major European markets, confirm case by case | Do not assume blanket European support, check country by country |
3.2 Coverage is not enablement
Something appearing in the coverage list does not mean it is immediately available in your account. The distinction matters in day-to-day operations, because each local method has its own enablement conditions: some need extra explanation of the business, some restrict category, and some require a trading history first.
Another point that is often missed is that a local method is not simply one more button. Each method has a different checkout flow, different failure reasons, different refund path and different reconciliation rules. Treating them as variants of card payments is the first-quarter problem many teams run into after going live.
For the wider background on European local methods, see the European Local Payment Methods Guide, which walks through mainstream methods and merchant adaptation logic country by country.
4. Integration Paths and the Plugin Ecosystem
4.1 Plugins and hosted checkout
One of Mollie's advantages is its plugin ecosystem. Mainstream e-commerce platforms usually have an official or community plugin, so installing it, configuring keys and selecting which local methods to display is enough to process an order. For small teams without a dedicated payments engineer, this is the least effort path.
The hidden cost of the plugin route is limited control. Fields on the checkout page, the display order of payment methods and the interaction on retry after failure are mostly decided by the plugin. If your business has requirements on those details, check whether the plugin exposes the relevant configuration.
A more controllable option is a hosted checkout combined with a server-side API: your system creates a payment and receives a redirect address, the buyer completes payment on the platform side, and the result reaches you through a webhook. This path keeps sensitive data handling on the platform side, which keeps the compliance boundary relatively clean.
4.2 API and server responsibilities
On the API route there are three things the server must get right: idempotency, the state machine and reconciliation.
Idempotency means the same request arriving twice must not create two payments. Webhooks can be delivered more than once and networks retry after timeouts, so a creation endpoint without an idempotency key can end up with one order and several payments. The state machine means created, redirected, paid, expired, refunded and partially refunded states must close properly, with no stuck state where a refunded order still shows as awaiting payment. Reconciliation means your order records must match the platform settlement report line by line.
None of these three is platform specific; all of them are universal requirements for any acquiring integration. For idempotency patterns see the Payment Order Number and Idempotency Design Guide.
When abstracting across several local methods, the interface model of Mollie is relatively consistent, which helps reduce branch logic.
5. Subscriptions and Platform Products
5.1 Subscription capability
Mollie offers subscription product capability suited to recurring billing, for example memberships, software services and scheduled delivery. The basic model is that the buyer authorises once and later charges run automatically on a cycle.
The reminder is the same as before: the platform provides capability, not policy. How cycles are designed, how long a trial runs, how upgrades and downgrades handle proration, how many times a failed charge retries and how long before a subscription is paused are all business rules you define. For the full design of a subscription system see the Subscription Billing API Integration Guide.
Also note that subscription capability and whether a given payment method supports recurring charges are two different things. Some local methods are simply unsuitable for automatic charging, and building subscriptions on top of them pushes the renewal failure rate up sharply.
5.2 Platforms and marketplace splits
For teams running a platform, marketplace or aggregation business, the relevant topic is platform products: how one transaction is split across different parties, who gets settled, and who carries dispute responsibility. Such requirements are very different from plain merchant acquiring, and the capability boundary on the platform side has to be confirmed separately rather than assuming that the ability to accept payments implies the ability to split them.
6. Fee Structure
6.1 What the fee is made of
Mollie fees are composed of several parts rather than a single number. Judge cost by component rather than memorising one headline rate.
| Fee component | Description | What to judge |
|---|---|---|
| Transaction fees | Priced per payment method | Price structure differs by local method |
| Method differences | Cards, local methods and buy-now-pay-later are priced differently | Payment method mix drives total cost |
| Cross-border and FX | Determined by buyer region and currency | Sensitive for multi-market sellers |
| Subscription and platform | Tied to recurring billing and platform splits | Account for it separately for subscription business |
| Operating cost | Refunds, disputes and chargebacks | Not negligible at high dispute rates |
Current rates and conditions belong to the official pages. Percentages circulating in older articles are often outdated, and budgeting from stale numbers is the most common error of all.
6.2 How to judge the real cost
Comparing headline rate numbers across platforms side by side is the easiest mistake at this stage. The right method is to build a transaction mix that matches your business, with the same local method share, the same card mix and the same country distribution, then compare total cost and final received amount.
One dimension that is easily missed is that the payment method mix feeds back into conversion. Adding one more local method may raise conversion, and it may also add operational complexity. Comparing fees without conversion usually produces a biased conclusion. For comparison methods see the Payment Gateway Rate Comparison.
7. Trade-offs Against Other European Acquirers
7.1 Against Adyen
Framing the comparison of Adyen and Mollie as cheap versus expensive is the most common misreading. The real difference is one of route: Adyen targets enterprise customisation, covering multi-region and multi-currency acquiring with unified online and offline commerce, higher onboarding and volume thresholds and negotiated pricing. Mollie targets standardised out-of-the-box delivery, with strong European local method coverage, onboarding friendlier to small and medium businesses and a comparatively transparent price structure.
Put differently, if what you need is one team, one interface, negotiated pricing on demand and support for complex organisational structures and multi-entity settlement, Adyen fits better. If what you need is to get the main European local methods live within a couple of weeks without a heavy commercial process, Mollie fits better. For Adyen's detailed positioning see the Adyen Guide.
| Evaluation dimension | Mollie | Adyen | Stripe |
|---|---|---|---|
| Primary market | European local | Global, multi-region | Global, developer first |
| Local method breadth | Deep in Europe | Broadest coverage | Broad, local depth varies by market |
| Onboarding difficulty | Friendly to small and medium business | Higher, enterprise oriented | Lower |
| Pricing model | Public and standardised | Negotiated | Public rate card |
| Plugin and site-builder ecosystem | Mature across European site builders | Enterprise integration oriented | Most complete |
| Subscription and platform | Products available | Supported | Highly productised |
| Typical scale | Small to mid-market | Mid-market and enterprise | Any stage |
7.2 Against Stripe
Stripe wins on ecosystem breadth and developer experience, with a longer product line, more complete documentation and tooling, and more options for pure card acceptance and complex billing. Its local method coverage keeps expanding too, though local depth in some European countries may not match a domestic platform.
If your team is engineering led and wants full control of billing and payment flow through code, Stripe is usually the default, and the trade-offs are covered in the Stripe Pros and Cons. If your team has no dedicated payments engineer and prefers to install a plugin and start collecting, Mollie is the shorter path.
Domestic providers also deserve attention, because they often go deeper in a single market: Przelewy24 in Poland, Trustly and GoCardless across the Nordics and several European markets, Paysera in the Baltic region, and Klarna on the buy-now-pay-later side. Whether to layer them on depends on whether your order volume in a single market justifies the extra integration and reconciliation cost. For a broader platform comparison see the Cross-Border Payment Platform Comparison.
8. Who It Fits, Rollout Notes and Common Misreadings
8.1 Who it fits and who it does not
Good fit: e-commerce and digital product businesses selling into Europe; teams that want one integration to cover local methods across several countries without contracting separately in each; small and medium teams without a dedicated payments engineer that rely on site-builder plugins for a fast launch; businesses needing subscription or platform split capability whose volume has not yet reached enterprise negotiating thresholds.
Weaker fit: teams selling mainly outside Europe, where the incremental value of local method coverage is limited; large enterprises needing multi-currency, multi-market acquiring with complex organisational structures and multi-entity settlement, since those needs sit closer to enterprise acquiring; large merchants with strong pricing leverage whose volume already supports negotiation.
8.2 Rollout notes
| Rollout point | Practical approach |
|---|---|
| Check methods per country | Do not assume blanket European support, confirm availability for each target country |
| Design reconciliation separately | Card and local method settlement cadence differ, so keep the logic apart |
| Handle missing callbacks | Redirect-based local methods are common, so orders that never return must be handled |
| Filter methods for subscriptions | Only use methods that support automatic charging, or renewal failures spike |
| Leave room to migrate | Abstract payment methods and order state instead of coupling to one implementation |
If the acquiring arrangement may change later, keep the payment layer thin at integration time and reduce coupling to a specific platform. For the process and acceptance checklist see the Payment Gateway Migration Guide.
8.3 Common misreadings
The first misreading is treating Mollie as a global acquiring platform. Its local method coverage centres on Europe, and that positioning is both its strength and its boundary. If your buyers are mostly outside Europe, the incremental gain will be lower than expected.
The second misreading is assuming it suits large-value B2B and complex multi-entity settlement. The other side of standardised out-of-the-box delivery is limited customisation room. Scenarios needing complex organisational structures, multi-entity settlement and unified online and offline acquiring belong with enterprise acquiring options, not with a platform aimed at small and medium businesses that is expected to cover every requirement through configuration.
The third misreading is reducing the Mollie and Adyen relationship to price. The real difference is enterprise customisation versus standardised out-of-the-box delivery, and the price gap is only a visible symptom of it. Making price the sole decision input usually surfaces the problem about six months after go-live: either capability falls short and a second migration is needed, or you paid for customisation you will never use.
More acquiring and payment options are listed under Payment, organised by acquiring capability, local method and subscription scenario.
Source: 16IDC original. Product capabilities, pricing and eligibility requirements follow www.mollie.com and related official documentation and contract terms.