Book a call

iDEAL Wero integration in practice: the Dutch checkout from button to refund

iDEAL Wero integration for Dutch checkouts: the migration dates, the payment button, app switch and QR, subscriptions, refunds and accessibility.

Maniruzzaman JubayerDesign engineer and product design lead · Published Nov 9, 2026 · 16 min read
Summarize with
Line drawing of gabled canal houses and a boat on the canal in Amsterdam with a map pin, linked to a product screen

An iDEAL Wero integration is two jobs on two clocks. The iDEAL | Wero co-branding had to go live between 29 January and 31 March 2026. The move of iDEAL payments onto Wero's rails is due to finish by 31 December 2027, the European Payments Initiative (EPI) says. Customers keep paying through their own bank; what changes is the button, the hand-off page, subscriptions, refunds and, from 2028, disputes.

With a hosted checkout, your provider does much of the work; with your own payment step, you own every new state.

I'm Maniruzzaman Jubayer, and I work as a Next.js developer in Amsterdam for Dutch teams, remotely. This guide is for founders, product leads and developers who own a Dutch checkout on the web or in an app: what is confirmed, what is still a plan, and the order I build it in.

What is confirmed for the iDEAL to Wero move, and what is still a plan

The Dutch Payments Association says 72% of Dutch online purchases are made via iDEAL. EPI bought iDEAL and is folding it into Wero, its wallet for account-to-account payments. This is the timeline as the primary sources state it on 13 October 2026.

WhenWhatStatusSource
28 October 2025Banks announce the rebrand; DNB must approve the technical migrationAnnouncedWero
29 January to 31 March 2026Co-branded logo and the name "iDEAL | Wero" on every checkoutDeadline passedideal.nl, Adyen, Stripe
October 2026All Dutch issuing banks connected to Wero, then payments move across graduallyPlanned for October 2026EPI
Q4 2026Wero offered to Dutch buyers as its own methodPlannedStripe, Mollie
31 December 2027Migration complete, iDEAL brand phased outTargetEPI, Wero
1 January 2028Full Purchase Protection coverageTargetEPI

EPI's 15 July 2026 release sets the October bank connection and the end-2027 target. The October 2025 announcement adds that De Nederlandsche Bank oversees both schemes, and Wero's Dutch page says every iDEAL merchant will have moved by the end of 2027.

My reading: the co-branding dates were firm and are behind us. The October connection is a plan I'd confirm with your provider before writing it into a sprint, and later dates are targets. Stripe's migration note still gives an estimated 2027 to 2028 window for the iDEAL shutdown.

What the iDEAL Wero integration changes in your code

How much work you have depends on where your payment step lives.

Stripe. Hosted products got the logo and text update automatically; API and custom integrations had to change both by hand, and missing 31 March could get iDEAL deactivated. From Q4 2026 you enable Wero, then switch iDEAL off, and Stripe suggests an A/B test first. On 13 October, Stripe's Wero docs list Belgium, France and Germany as customer locations, not yet the Netherlands.

Adyen. The iDEAL | Wero page gave API-only merchants two tasks: rename to "iDEAL | Wero" and swap the logo. The API-only guide keeps the method type as ideal. Adyen's Wero page says Wero is in development, runs on parallel rails, and is a distinct method you adopt at your own pace.

Mollie. Mollie's Wero docs mark it beta, with France and the Netherlands expected in October 2026. Its Wero guide for merchants says custom integrations may need visual updates by hand.

I'm not ranking these. The point is the same everywhere: Wero arrives as a second method, so your code must show iDEAL, both during a test, or Wero only, without a release each time. I put the method list behind a server setting; it's the first thing I set up in the iDEAL and Wero checkouts I build.

The payment button and the payment step

The iDEAL | Wero branding page asks for the co-branded lock-up in its light or dark version, never altered, with the name "iDEAL | Wero" wherever the logo appears. The marketing guidance on ideal.nl adds what I'd call product advice:

  1. Put iDEAL | Wero at the top of the payment method list.
  2. In a radio list, keep it selected by default.
  3. Add one line under it, such as that it's free, especially when other methods carry a fee.
  4. Tell people beforehand that they'll be sent to a payment page.
  5. Show the total order amount before they pay.

The Dutch Payments Association also says 60% of online buyers know which method they want before they reach the payment page. So I don't hide the methods behind an accordion, and the button repeats the amount: "Betaal € 64,90", not "Doorgaan".

One trust detail: Stripe's iDEAL | Wero docs say the scheme rules require a Dutch merchant to show its KVK number on the website, or an equivalent registration number abroad. I put it in the footer and on the checkout page, next to the support contact.

One iDEAL | Wero payment from the payment step to the confirmed order, with eight numbered checks, from sources read on 13 October 2026.
One iDEAL | Wero payment from the payment step to the confirmed order, with eight numbered checks, from sources read on 13 October 2026.

Redirect, app switch and the return trip on mobile

On a phone, the payment leaves your app or site and comes back. Adyen describes the Wero mobile flow as a redirect to the Wero payment page, a choice between the Wero app and the bank's app, biometric authentication, then a redirect to your confirmation page. Mollie describes the same shape.

Three things break it, and all three are fixable:

  • The WebView. Adyen's API-only guide strongly recommends the device's default browser over an in-app WebView, citing app-to-app redirection and error handling. In native apps I use Chrome Custom Tabs on Android and the system browser sheet on iOS.
  • The way back. The return URL should reopen your app, not a browser tab: universal links on iOS and verified App Links on Android, tested on real phones with real bank apps.
  • The lost session. The phone may kill your app while the bank app is open, so on return it rebuilds the checkout from the server, using the payment id.

In a Next.js web checkout, the return route likewise asks your server for the status by payment id.

QR on desktop, and the clock behind it

On a laptop, the hand-off becomes a QR code. Adyen describes a dynamic Wero QR code that the shopper scans with the Wero or bank app. Stripe's Wero docs say customers scan a QR code to open the Wero app and approve there. iDEAL's new payment page already offers approval by QR code, by a banking app confirmation, or through the bank as before.

You don't design that page, but you design what surrounds it, and the clock matters most. Mollie's iDEAL docs list a 15 minute session; its Wero docs list 10 minutes.

WCAG 2.2's timing adjustable criterion asks you to let people adjust or extend time limits you set. You can't extend the scheme's session, so I handle my side:

  • the basket and address never expire with the payment session;
  • an expired payment lands on a page that says nothing was charged, with one "Opnieuw betalen" button;
  • the payment step always offers another method, for anyone who can't scan.

Pending, paid, failed: the statuses your server owns

A redirect tells you the person came back, not that they paid.

Mollie's webhook docs show the design: the webhook carries only the payment id, and your server fetches the status, so a fake call can't mark an order paid. Mollie retries up to 10 times over about 26 hours if you don't answer with a 200. Its Wero page says confirmation is asynchronous, typically within 60 seconds, and a payment may sit in pending during banks' fraud checks. Adyen works similarly: send the redirectResult to /payments/details, then rely on the result code and the webhook.

So I build the return page as a waiting room:

  1. A pending state: "We controleren je betaling", with a line saying it usually takes seconds.
  2. Announced: the message sits in a role="status" region, as WCAG 2.2's status messages criterion describes, so a screen reader hears it.
  3. Polling your own server, never the provider from the browser, until the webhook settles it.
  4. One of four outcomes: paid, cancelled, expired or failed, each saying whether money moved.
  5. The confirmation email from the server, so someone who closed the tab still gets it.

Subscriptions and recurring payments during the move

A Dutch subscription paid "with iDEAL" is really an iDEAL first payment that creates a SEPA Direct Debit mandate. Mollie's recurring guide lists iDEAL among methods that create a directdebit mandate; Stripe lists iDEAL recurring as "with SEPA Direct Debit"; Adyen stores a SEPA Direct Debit token.

On 13 October 2026, Adyen, Mollie and Stripe all list Wero recurring as not supported. Stripe's migration note says it arrives from 2027 with a different mechanism, and that subscriptions started through iDEAL run on SEPA rails and aren't affected if you switch iDEAL off. EPI lists subscription management as planned, with no date.

What I build from that:

  • Renewals stay on the mandate flow for as long as your provider supports it.
  • One-off and recurring checkouts are separate in code, so moving one-off payments to Wero doesn't touch renewals.
  • The sign-up says what happens, in Dutch: the first payment in your bank app, then automatic collection, with the next date. Mollie suggests a reminder a few days before each collection.

Refunds and disputes: what really changes for the merchant

iDEAL never had chargebacks. Wero will, which touches help pages, admin screens and emails.

iDEAL | Wero todayWero
Refund window180 days at Stripe, 365 days at Mollie730 days at Stripe and Mollie
Partial refundsYesYes
DisputesNone with the bank (Stripe)Pre-dispute within 120 days, longer for some delayed-delivery sectors (Adyen, Mollie)
In the NetherlandsNot applicablePre-disputes not allowed before 1 January 2028 (Adyen)

Adyen's Wero page gives the merchant 7 days to answer a pre-dispute and notes that a full refund closes the case. Mollie's guide recommends refunding a verified claim early and showing your business name clearly so people recognise the payment.

Before 2028, I'd make "request a refund" easy to find on the order page, show the trading name customers know on receipts, and give support one admin view with the payment id, status history and refund button.

Dutch copy, trust and accessibility at checkout

In EPI's Payments Barometer for the Netherlands, 1,061 Dutch respondents surveyed from 30 April to 12 May 2026, 82% said they trust their bank and 56% named security and fraud as their leading concern about digital payments. My reading: the copy should keep pointing to the bank people already use. "Je betaalt in je eigen bank-app" does more than a badge.

The iDEAL | Wero FAQ says payment is in English only if the customer's bank offers English online banking, so an English storefront can hand people to a Dutch bank screen. I write the redirect notice in the page's language, mark Dutch phrases on an English page with lang="nl", as WCAG's language of parts asks, and keep "iDEAL | Wero" exact in both.

The Dutch Payments Association notes that checkouts must meet the European Accessibility Act, in force since 28 June 2025, and the directive's Annex I names payment functions directly. Who must comply is in my guide to the European Accessibility Act for Dutch web shops; the checks specific to this flow are:

  • payment methods as native radios in a fieldset with a legend, the logo named "iDEAL | Wero";
  • a pay button that meets the target size minimum of 24 by 24 CSS pixels;
  • a retry that keeps the address, as the redundant entry criterion requires;
  • another way through the QR step for anyone who can't scan.

The component detail is in my WCAG 2.2 checklist for React. If you also sell in the Gulf, my notes on Saudi checkout with mada and Tamara show the same step under another country's rules.

From my work: ZenPay, a mobile wallet for sending, receiving and tracking money, that I designed.
From my work: ZenPay, a mobile wallet for sending, receiving and tracking money, that I designed.

Where I would start

I'd check the co-branding first: a custom checkout still showing the old iDEAL logo after 31 March risks being switched off. Then I'd put the method list behind a server setting, rebuild the return page as a waiting room driven by the webhook, and test the app switch on real phones with Dutch bank apps. Subscriptions stay on the mandate flow, with a written plan for when your provider supports Wero recurring. Disputes can wait until 2027; the refund button in your admin can't.

That's the order I follow on every Dutch checkout, as part of my React and Next.js development service. If you'd like help, see my development work for Amsterdam teams: a free 30 minute intro call where you share the checkout and your provider, then a written scope and one fixed quote.

Frequently asked questions

When does iDEAL become Wero?

In steps. The iDEAL | Wero name and logo had to be live between 29 January and 31 March 2026. EPI planned to connect all Dutch issuing banks to Wero in October 2026, after which payments move across gradually, with the migration due to finish by 31 December 2027. Stripe still gives a 2027 to 2028 window for the final shutdown, so confirm dates with your provider.

Do I need a new integration for Wero?

Usually a small one. Adyen, Mollie and Stripe all add Wero as a separate payment method rather than changing iDEAL in place, so you enable it, show it, and later switch iDEAL off. With a hosted checkout that may be a dashboard setting. With a custom payment step you add the method, its states and its branding in your own code.

Do my customers need the Wero app to pay?

Not for iDEAL | Wero today: people pay in their own bank's internet or mobile banking. In the Wero flow Adyen describes, a shopper on a phone chooses the Wero app or their bank's app, and on a desktop scans a QR code with either. Write your checkout copy around the bank app, which every iDEAL user already has.

Will iDEAL subscriptions keep working after the move to Wero?

Subscriptions started with an iDEAL first payment run on a SEPA Direct Debit mandate, and Stripe says they aren't affected if you deactivate iDEAL. On 13 October 2026, Adyen, Mollie and Stripe all list Wero recurring as unsupported, and Stripe expects it from 2027. Keep renewals on the mandate flow, separate from one-off payments.

Can customers dispute a Wero payment?

Yes, unlike iDEAL. Adyen and Mollie describe pre-disputes within 120 days of the payment, longer for some sectors with delayed delivery. Adyen says pre-disputes are not allowed for shoppers in the Netherlands until 1 January 2028, the date EPI targets for full Purchase Protection. A full refund closes a dispute, so make refunds easy to request.

How should the return page handle a pending payment?

As a waiting room. Show a pending message in a status region, poll your own server, and wait until the provider's webhook has settled the payment; Mollie's webhook carries only the payment id, so your server fetches the real status. Then show paid, cancelled, expired or failed, and send the confirmation email from the server.

Sources and method

I read and opened every source on 13 October 2026. Wero details change often: Adyen calls it in development, Mollie beta. I couldn't read the iDEAL | Wero brand manual PDF as text, so branding points come from the ideal.nl pages. I found no primary source confirming the October 2026 bank connection has happened, so I describe it as planned. The diagram is illustrative.

Tags: Payments, iDEAL, Wero, Netherlands, Checkout, Next.js

Keep reading

Let’s look at your product.

A free 30 minute call. You leave with a clear next step, whether we work together or not.

Book a free intro call