If you’re building checkout for the Netherlands and “iDEAL” keeps showing up in PSP payment method lists, developer docs, or search results for iDEAL payment, here’s the short version: iDEAL is the dominant way Dutch shoppers pay online, a bank-redirect method that sends the customer straight into their own bank’s app to authorize a transfer. It confirms almost as fast as a card payment but settles like a bank transfer, and it’s currently mid-transition to a new pan-European scheme called Wero. This covers what iDEAL is, how the payment flow works, what changes over the next two years, and how to add support without building a dedicated integration.
Key takeaways:
- iDEAL accounts for roughly 70% of Dutch ecommerce transactions and processed more than 1.5 billion payments in 2025 (Dutch Payments Association)
- The bank-authentication step satisfies PSD2’s Strong Customer Authentication requirement by design, with no separate card-style challenge needed
- iDEAL is rebranding to “iDEAL | Wero” starting January 2026, with full merchant transition required by the end of 2027
- Direct Currence certification takes about six months; routing through an already-certified PSP or orchestration platform skips that timeline
- Accepting iDEAL through an orchestration layer turns scheme-level changes, like iDEAL 2.0 or the Wero transition, into a platform-level update instead of a codebase change per PSP
What is iDEAL?
iDEAL is a bank-transfer payment method issued by Dutch banks and governed by Currence, the Netherlands’ payment scheme operator. A customer pays by authenticating directly inside their own bank’s app or online banking environment, entering no card details and connecting no separate wallet.
It’s not a niche option.
Key stat: According to the Dutch Payments Association (Betaalvereniging Nederland), iDEAL accounts for roughly 70% of all Dutch ecommerce transactions, and processed more than 1.5 billion payments in 2025, up from about 1.3 billion in 2024, averaging over 4 million transactions a day with peak days reaching 6.3 million.
For a platform selling into the Netherlands, iDEAL is the default rail most Dutch shoppers expect at checkout, not an optional add-on payment method.
How iDEAL payments work
The flow: a customer selects iDEAL at checkout and is redirected to a centralized iDEAL Payment Page, where they pick their bank and log in with their normal online banking credentials to approve the payment amount and recipient. They’re redirected back to the merchant, and the merchant receives near-instant confirmation.
Underneath, iDEAL settles over SEPA Credit Transfer rails, the same underlying network SOFORT used in Germany, with iDEAL’s redirect and authentication layer on top. Because the customer authenticates inside their own bank’s environment using their existing multi-factor login, iDEAL satisfies PSD2’s Strong Customer Authentication requirement by design.
Two mechanical differences from a card payment matter for how you build around iDEAL. It’s a push payment: the customer’s bank sends the funds, and there’s no pull-based retry the way a failed card charge can be retried. And it has no chargeback scheme.
Warning: Mollie, Adyen, and Airwallex all describe the same underlying mechanics: an iDEAL payment is typically confirmed within minutes, and once confirmed, it isn’t reversible through the payment scheme itself. Refunds happen directly between merchant and customer, not through a dispute process.
iDEAL’s role in the Netherlands (and its reach beyond it)
iDEAL’s issuing side is strictly Dutch. Only customers with an account at a Currence-licensed Dutch bank, ABN AMRO, ING, Rabobank, and others, can pay with it. The acceptance side isn’t geographically limited. Any merchant, anywhere, can accept iDEAL from Dutch customers, provided they route through a PSP or orchestration platform that already holds a certified iDEAL connection.
That distinction matters for scoping the work. A platform doesn’t need a Netherlands entity or a direct relationship with a Dutch bank to accept iDEAL from Dutch customers. It needs a payment method connection, reachable through a provider that already holds a certified integration with Currence.
iDEAL is becoming Wero: what’s changing and when
iDEAL is mid-transition, not a stable end state. According to the Dutch Payments Association, corroborated by ABN AMRO’s own customer communications, the shift to Wero follows this timeline:
- End of January 2026. iDEAL begins rebranding to “iDEAL | Wero.”
- Through end of 2026. New Wero capabilities roll out, including cross-border person-to-person payments.
- End of 2027. Every iDEAL merchant is expected to have transitioned to Wero, after which the iDEAL brand phases out.
This isn’t iDEAL’s first scheme-level change. iDEAL 2.0 centralized bank selection into the single Currence-hosted iDEAL Payment Page described above, and required merchants to remove any custom bank-selection screen from their own checkout. The deadline for merchants to comply was March 31, 2025, and Currence has been actively monitoring non-compliant merchants since April 1, 2025, according to iDEAL’s own migration documentation, corroborated by Adyen’s deadline notice to its merchants.
That’s two protocol-level changes inside about three years, on a payment method most integrations treat as a one-time build. A developer integrating iDEAL directly today is integrating a payment method that has already changed its own checkout requirements once and is scheduled to change its brand and capabilities again before 2028.
iDEAL vs. cards, wallets, and other bank-redirect methods
| Method | Region | Status | Notes |
|---|---|---|---|
| iDEAL | Netherlands | Active, transitioning to Wero (2026-2027) | ~70% of Dutch ecommerce transactions (Dutch Payments Association) |
| Klarna Pay Now (successor to SOFORT) | Germany, Austria, wider Europe | Active | SOFORT was discontinued 2024-2025 |
| Cards (Visa, Mastercard) | Global | Active | Chargeback scheme exists; higher dispute overhead than bank-redirect |
| Apple Pay, Google Pay | Global | Active | Wallet-based and tokenized, not a bank-redirect flow |
| FPX | Malaysia | Active | Parallel bank-redirect method outside Europe |
Cards carry a chargeback mechanism and interchange fees; bank-redirect methods like iDEAL trade that for faster, non-reversible confirmation, at the cost of requiring the customer to hold an account at a participating bank. Every row in this table except cards is also a reminder that local, bank-tied payment methods change on a schedule set by their scheme owner, not by the merchants who depend on them.
Integrating iDEAL: technical requirements and payment flow
Whichever PSP or orchestration platform provides the underlying connection, integrating iDEAL means building around requirements that don’t change between providers:
- Redirect-based flow, not a hosted field or iframe. The customer has to leave your checkout, authenticate on their bank’s own domain, and return. An integration built purely around card-style tokenization won’t handle this pattern without adding a redirect step.
- EUR only. iDEAL doesn’t support other settlement currencies. A checkout that defaults to USD or GBP needs a currency branch for Dutch customers.
- Webhook-driven confirmation, not a synchronous response. Because the customer authorizes inside their bank’s own environment, your backend needs to listen for a webhook or callback event rather than trusting the redirect alone, and handle it idempotently in case the notification arrives more than once.
- A certified connection to route through. Direct Currence certification requires registering as a European payment service provider and completing a process that, per Currence’s own certification documentation, “normally takes about six months.” Almost no platform integrating iDEAL certifies directly; they route through a PSP or orchestration platform that already holds the certification.
What differs between providers is the API surface built on top of those requirements. JPMorgan, Adyen, and PPRO each publish their own iDEAL-specific developer documentation, with different parameter names, different redirect handling, and different webhook payload shapes, for what is, from the customer’s side, the exact same payment method.
Integration challenges developers hit in practice
The iDEAL 2.0 migration is a concrete, recent example of what a scheme-level change costs a direct integration. Every merchant running a custom bank-selection screen had to rebuild that step of checkout and hit the same March 31, 2025 deadline, individually, regardless of which processor sat behind the integration.
That cost multiplies with every additional PSP a platform integrates directly. A platform running iDEAL through two providers for redundancy, or supporting multiple PSPs because different customers use different processors, had to make that same checkout change twice, once per PSP-specific implementation, against the same deadline. It’s the same maintenance burden that shows up with any local payment method a platform needs to support as it expands into new markets: each direct integration multiplies the surface a scheme-level change can hit, and the iDEAL-to-Wero transition still ahead means touching that surface again for every PSP integrated directly, the same way iDEAL 2.0 already did.
SOFORT went through a comparable pattern before Klarna deprecated it in 2024. Two bank-redirect methods, two separate scheme-level disruptions, both requiring direct integrations to individually track a migration deadline set outside their own release cycle.
Accepting iDEAL through a payment orchestration platform
An orchestration layer doesn’t remove Currence’s certification requirement, and it doesn’t stop Wero from replacing iDEAL on its own schedule. It changes who absorbs the work when the scheme changes underneath you.
Orchestra routes transactions to whichever payment service provider among the 130+ providers in its network supports a given local payment method, rather than requiring a platform to hold a direct, provider-specific integration for every method it needs, and its PSD2 Strong Customer Authentication support covers European markets as part of that routing. New PSP and payment-method connections are added to Orchestra’s network at no additional cost to customers already on the platform. The same logic applies to a scheme-level change like iDEAL 2.0 or the iDEAL-to-Wero transition: when a PSP in the network updates how it handles iDEAL, that update is the PSP’s connection to maintain, not a code change a platform’s own team has to plan, test, and ship against a deadline set by Currence or a PSP. Check current PSP coverage for iDEAL specifically before committing a build to it; Orchestra’s public integration pages don’t itemize which payment methods are live behind each PSP connection.
That’s the same argument that applies to every local payment method a platform adds as it expands into new markets: the deprecation, migration, or rebrand risk doesn’t disappear, but it stops landing on a backlog every time a scheme changes how a payment method works. Cross-border teams weighing whether iDEAL is worth adding on its own or as part of a broader European payment acceptance strategy are really asking the same question about every bank-redirect method they’ll eventually need.
Frequently asked questions
What is iDEAL payment?
iDEAL is a Dutch bank-transfer payment method that redirects a customer to their own bank’s app or online banking environment to authorize a payment directly from their account, rather than entering card details.
Is iDEAL the same as Wero?
They’re merging. iDEAL is transitioning into Wero, a pan-European payment scheme: rebranding to “iDEAL | Wero” started in January 2026, and the Dutch Payments Association expects all iDEAL merchants to have transitioned to Wero by the end of 2027, after which the iDEAL brand phases out.
Is iDEAL only available in the Netherlands?
iDEAL is issued by Dutch banks for Dutch bank account holders, so the payer side is Netherlands-specific. Merchants outside the Netherlands can still accept iDEAL from Dutch customers through a PSP or orchestration platform that supports the method.
How does an iDEAL payment work at checkout?
The customer selects iDEAL, picks their bank, and is redirected to that bank’s own login and confirmation screen. After they approve the payment, they’re redirected back to the merchant, and the transaction settles with near-instant confirmation.
Why does iDEAL matter for ecommerce?
iDEAL accounts for roughly 70% of Dutch ecommerce transactions (Dutch Payments Association), so merchants that don’t offer it are asking the majority of Dutch online shoppers to use a payment method they don’t prefer.
Is iDEAL the same as SEPA?
No. iDEAL payments settle over the same underlying SEPA Credit Transfer rails, but iDEAL adds the bank-redirect authorization and near-instant confirmation layer that a plain SEPA transfer doesn’t have.
Does iDEAL support recurring or subscription payments?
iDEAL itself is a single-use, real-time push payment. Recurring billing on top of iDEAL typically relies on a separate mandate mechanism, such as an iDEAL Mandate or a conversion to direct debit, rather than iDEAL charging the same way a stored card does.
How do I add iDEAL to an existing checkout?
iDEAL is added through a PSP or payment orchestration platform that already holds a Currence-certified iDEAL connection. Certifying directly with Currence as an acquirer typically takes about six months; routing through an already-certified connection skips that timeline.
