The moment a software project needs to handle money, things get more complicated. Not because payment providers are hard to use — modern APIs from Mollie and Stripe are well-documented — but because payments have more edge cases than almost any other integration. A user pays, then disputes it. A webhook arrives twice. A subscription renews, but the IBAN has changed. The happy path is easy. Everything around it is engineering work.
For Dutch businesses, there's an additional layer: the local payment landscape is different from the rest of Europe, let alone the US. Get it wrong and you'll lose conversions before the software even launches.
The Dutch payment landscape
iDEAL handles roughly 70% of Dutch online transactions. It's a bank-redirect payment: the customer selects their bank, authenticates, and the money transfers immediately — settled, not pending. Unlike a card payment that can be disputed weeks later, a completed iDEAL transaction is final.
For a Dutch consumer-facing software product, iDEAL is non-negotiable. Launching a checkout without it is the equivalent of accepting only Amex in the US — technically possible, practically a conversion disaster.
The rest of the Dutch mix:
- SEPA direct debit — B2B recurring billing, membership fees, SaaS subscriptions with monthly invoicing
- Credit cards — around 10% of Dutch transactions, but 50%+ once you serve German or Belgian customers
- Bancontact — Belgium's equivalent of iDEAL; essential if your customer base crosses the border
- PayPal — declining, but still relevant for certain demographics and international buyers
Choosing a payment provider
For most Dutch projects, the decision comes down to two providers.
Mollie — Dutch company, excellent iDEAL support, flat-rate pricing with no monthly minimum. iDEAL costs €0.29 per transaction; cards run 1.2%–1.8% + €0.25 depending on card type. At 1,000 iDEAL transactions per month, that's €290 in provider fees — versus potentially €500+ with a percentage-based provider that doesn't offer a flat iDEAL rate. My default choice for NL-first projects.
Stripe — Stronger for international scale and more mature subscription tooling. Cards at 1.4%–2.9% + €0.25 depending on card origin. iDEAL via Stripe adds a percentage on top of the transaction amount — a meaningful difference at volume. Worth it if you're building for an international market from day one.
Adyen — Enterprise-grade, interchange-plus pricing, genuinely better per-transaction rates above roughly €500,000 annual volume. Monthly minimums make it expensive below that threshold.
I've used both Mollie and Stripe in production. The integration effort is similar. Mollie's Dutch support team and flat iDEAL pricing give it the edge for domestic projects; Stripe's documentation and ecosystem win internationally.
What PSD2 and SCA actually require
The EU's revised Payment Services Directive (PSD2) introduced Strong Customer Authentication: card payments above €30 require two-factor verification. In practice, this means 3D Secure 2.0 for card transactions in Europe.
If your software processes cards and doesn't implement 3DS2 correctly, one of two things happens: the payment declines, or the fraud liability shifts from the card issuer to you.
The good news: Mollie and Stripe handle the 3DS2 redirect and liability rules automatically when you use their standard checkout flow. The risk appears when you build a custom payment UI, skip the managed checkout, or process recurring charges without flagging them correctly as merchant-initiated transactions. Those edge cases — subscriptions, saved cards, installment payments — require extra configuration, not just a basic integration.
The technical complexity that surprises clients
Payment integrations don't fail loudly — providers send webhooks asynchronously, not just synchronous responses. But webhooks introduce their own complexity:
- Idempotency — The same webhook can arrive twice. Your system must process it once without duplicating an order or double-crediting a wallet.
- State machine — A payment moves through states: created → pending → paid → refunded → disputed. Each transition has business logic attached.
- Reconciliation — What the provider reports as settled must match your database. Off-by-one errors here cause compliance and audit headaches.
- Disputes and chargebacks — Card disputes happen. Your software needs to handle the state change, pause the related service and document within the evidence window.
None of these are hard problems individually. Together, they add up to integration work that's three to four times the scale of simply "calling the API and storing the result." A project that budgets only for the happy path will run over.
What integration actually costs
As part of a larger custom software project, payment integration typically adds:
- Simple checkout (iDEAL + cards, single product type): €4,000–€10,000 — API integration, webhook handling, basic refund flow, payment state management
- Multi-method checkout (iDEAL, Bancontact, cards, SEPA): €10,000–€20,000 — added complexity per method, especially SEPA direct debit mandate handling
- Subscription billing: €12,000–€25,000 — proration, free trials, dunning logic, SCA-exempt recurring flows, invoice PDF generation
- Marketplace or split payments: €25,000+ — Mollie Connect or Stripe Connect, sub-merchant onboarding, payout logic and regulatory obligations
Transaction fees are separate and ongoing. For a Dutch project doing €50,000/month in iDEAL and €30,000/month in cards via Mollie: roughly €145 in iDEAL fees (500 transactions × €0.29) plus €540 in card fees (€30,000 × 1.8%). That €685/month is pure provider cost, not infrastructure — and it's worth modelling before you commit to a provider, especially if card volume will grow. See what API integrations typically cost for the broader framework.
Questions to ask before you start
Whether you're commissioning payment software or evaluating a quote, these separate the prepared from the guessing:
- Which payment methods does your customer base actually use — and have you verified this, not assumed it?
- Is the integration compatible with Mollie Connect or Stripe Connect if you later add a marketplace model?
- How are recurring payments handled, and what happens when a card expires or a direct debit is rejected?
- Where does payment data live, and does that meet your GDPR processor agreement requirements?
- Can someone trigger a refund without calling a developer?
The last one matters more than people expect. A business owner who needs a developer for every refund has a product design problem, not just a technical one.
If you're building something that handles money — a booking system, a membership platform, an order flow — describe what you need and I'll give you a realistic picture of provider choice, integration work and the ongoing transaction costs for your volume.