iDEAL payment integration for custom web apps, SaaS platforms and mobile apps

What is iDEAL payment integration, and when is a plugin not enough?

iDEAL payment integration means connecting your own software to a payment service provider so customers can pay from their Dutch bank account and your system learns the result automatically. For a standard webshop a platform plugin handles that. For anything with its own data model, you need code.

iDEAL is the Dutch online bank payment method, now shown to shoppers as “iDEAL | Wero” on the official iDEAL site. The customer picks iDEAL, approves the payment in their banking app or by scanning a QR code on a desktop, and the money moves as a bank transfer. The merchant never sees card numbers or bank passwords.

A plugin stops being enough when payment has consequences a shop system does not model. A SaaS account has to become active. A booking slot has to be held for fifteen minutes and released if the customer walks away. A B2B invoice in your portal has to be marked settled in your ledger. A mobile app has to show a receipt after the banking app hands control back. Each of those needs code that listens to your PSP and changes your own records.

• Plugin territory: Shopify, WooCommerce or Lightspeed shops with ordinary carts.
• Payment link territory: a handful of invoices a month, paid from an emailed link.
• Custom integration territory: SaaS billing, portals, booking engines, apps, marketplaces and anything that must react to payment in real time.

How an iDEAL payment moves through your software, step by step

Every iDEAL payment integration follows the same five-step loop, whichever PSP you sign with. Get these steps right and the rest is interface work.

• Create. Your server calls the PSP's API with the amount in euros, a description, your internal order ID, a return URL and a webhook URL. The PSP answers with a payment ID and a checkout URL.
• Redirect. The browser or app opens that checkout URL. The customer lands on the iDEAL payment page, chooses their bank or scans the QR code, and approves in the banking app.
• Return. The customer is sent back to your return URL. At this moment you do not yet trust anything; the page shows “checking your payment” and asks your server for the status.
• Confirm. The PSP calls your webhook. Your server fetches the payment by ID from the API, reads the real status and updates the order once, inside a database transaction.
• Follow up. Paid orders trigger emails, access, stock changes or invoices. Expired, failed or cancelled payments free up whatever was reserved.

The most common bug we fix in inherited code is an order marked paid on the return page alone. A customer who closes the tab, or a slow bank, then produces either a paid order that shows as open or, worse, an open order that shows as paid. The webhook-plus-fetch pattern closes both gaps.

Which payment service provider should you use for iDEAL?

Choose the PSP by your volume, your method mix and the features your product needs, not by the logo. Merchants reach iDEAL through an acquirer or a collecting payment service provider; the iDEAL site lists both routes. We integrate whichever you sign with and do not resell any of them.

The Dutch market has roughly four kinds of provider. Developer-friendly PSPs founded in the Netherlands suit start-ups and SMEs that want quick onboarding and a clean API. Enterprise acquirer-processors suit high-volume merchants selling across many countries, often with negotiated pricing and minimums. Global card-first platforms have added iDEAL and suit SaaS businesses already billing cards worldwide. Benelux PSPs focused on local methods suit smaller shops and organisations that want Dutch-language support. Some businesses still go straight to their own bank as acquirer.

iDEAL and Wero: what the transition means for your integration

iDEAL is becoming part of Wero, the European payment wallet run by European Payments Initiative. The official iDEAL site already shows the co-brand “iDEAL | Wero”, and EPI states it launched Wero in Belgium, France and Germany in 2024 and is working towards the Netherlands. For a merchant, the practical point is that customers will see new branding and payment screens while your PSP keeps the API stable.

Because the redirect goes to a page hosted by iDEAL and your PSP, most of the visual change happens outside your code. What your code should do now is avoid hard-wiring assumptions that the transition may break.

• Do not build your own bank-selection dropdown; the newer iDEAL payment page handles bank choice itself.
• Treat the payment method name as data from the PSP, not a hard-coded string in receipts and emails.
• Keep your logos and checkout labels in one component so a rebrand is a single edit.
• Subscribe to your PSP's changelog and plan one maintenance slot when they announce the Wero changes.
• Test on both desktop (QR) and phone (app switch) after every PSP update.

We do not predict dates beyond what the scheme and EPI publish. When your PSP announces a change, maintenance covers the update, whether it falls in the free two months after launch or a later plan from US$120/mo.

iDEAL payment integration for SaaS subscriptions and recurring billing

iDEAL itself is a one-off payment, so recurring billing uses a first iDEAL payment to set up a SEPA Direct Debit mandate, then charges that mandate each period. The customer authenticates once in their banking app; later invoices collect without them doing anything.

Most PSPs that offer this return a customer or mandate ID when the first payment succeeds. Your billing code stores that reference against the account, never the IBAN in plain view, and schedules later charges through the API. The build then has to deal with what makes subscriptions hard: plan upgrades mid-period, proration, trials, failed debits, dunning emails and cancellations.

One rule changes how you design dunning. EU rules give consumers the right to have a direct debit refunded within eight weeks, as Your Europe explains. A SEPA charge that looks settled today can come back later, so your app needs a “reversed” state and a policy for access when it happens.

Can a mobile app use iDEAL instead of Apple or Google billing?

Yes, for physical goods and services used outside the app; no, for digital content consumed inside it. Apple's App Review Guidelines require in-app purchase for digital features and subscriptions (guideline 3.1.1) and require other methods, such as card entry, for physical goods and services consumed outside the app (3.1.3(e)). Google Play's payments policy draws a similar line.

So a food ordering app, a cleaning service booking app or a ticket app for live events can take iDEAL. A language-learning subscription or a premium tier inside a productivity app must use store billing on both platforms, and iDEAL can then only be offered on your website, within whatever each store's current rules allow for your region.

Technically, the app asks your backend to create the payment, opens the checkout URL, and expects the customer to come back through a deep link or universal link after the banking app approves. Phones behave differently here: some banking apps return to the browser rather than your app. Our flow therefore shows a “waiting for confirmation” screen that polls your backend, so the receipt appears even when the return hop fails. Building an app like this starts from US$600; the app cost guide for the Netherlands breaks the rest of the budget down.

Webhooks in an iDEAL payment integration: getting the status logic right

A webhook is the PSP calling your server when a payment changes state. It is the backbone of any serious iDEAL payment integration, and it is where most production incidents start.

The safest pattern treats the webhook body as a hint, not a verdict. Your handler receives the payment ID, fetches that payment from the PSP's API with your secret key, and acts on the status that comes back. Where a PSP signs its webhooks, we also verify the signature. The handler answers quickly with a success code and does slow work, such as emails and PDF invoices, in a background job.

• Idempotency: the same event can arrive twice; a paid order must not send two emails or grant access twice.
• Ordering: events can arrive out of sequence; the fetched status wins, not the order of arrival.
• Expiry: an unpaid iDEAL payment eventually expires; your reserved stock or booking slot is released when it does.
• Retries: if your server is down, the PSP retries; your handler must still work when the retry arrives hours later.
• Logging: every event is stored with its raw payload so support can answer “did my payment arrive?” in one search.

We add an alert for webhooks that fail repeatedly and a small admin view listing payments whose PSP status and order status disagree. That view catches problems days before a customer complains.

How do refunds work with iDEAL?

iDEAL refunds are issued by the merchant through the PSP, which sends the money back to the customer's bank account. The customer does not start them from their bank the way they would dispute a card payment, so your refund process is the customer's main route to getting money back.

In custom software that means a refund button in your admin panel, not a trip to the PSP dashboard. We build it with the controls finance teams ask for: partial refunds, a mandatory reason, a record of who pressed the button, and a check that the refund does not exceed what was paid. The order history then shows the original payment, each refund and the remaining balance.

Two practical limits shape the design. Your PSP needs enough balance or a linked funding source to pay refunds out. And for goods sold online to consumers, EU rules give buyers a 14-day right of withdrawal from delivery, set out on Your Europe, so refund volume after a busy week can be significant. Returns policy wording is for your own adviser to sign off; the software simply follows the rules you choose.

iDEAL for marketplaces and platforms that pay out to others

If your platform takes an iDEAL payment on behalf of someone else, such as a tutor, a venue or an independent seller, you need your PSP's platform or connected-account product, not a simple merchant account. Collecting money for third parties on your own account raises licensing questions that the PSP's platform product is designed to handle.

Integration work on platforms is larger. Sellers go through onboarding and identity checks at the PSP; your app stores their account reference and shows their verification state. Each payment carries a split: the seller's share, your commission and, sometimes, a delayed release after the service is delivered. Refunds and reversals have to pull the right amount back from the right party.

We build the onboarding screens, the split rules, seller payout reports and a dispute view. The PSP decides who may join and how funds are held. Whether your model needs a licence of its own is a question for a Dutch payments lawyer, and we will not guess at it. For the platform itself, see our marketplace development page.

Security and privacy in an iDEAL payment integration

Because the customer approves the payment inside iDEAL and their bank, your system never touches bank credentials. That removes the heaviest security burden, but not all of it.

• API keys live in server-side environment variables or a secrets manager, never in a mobile app bundle or front-end code.
• Live and test keys are separated, and only the production server can read the live key.
• Webhook endpoints accept only the fields they need and are rate-limited.
• Amounts are calculated on the server from your price data; the browser never sends the amount to charge.
• Admin refund rights are role-based and logged.
• Personal data stored with payments is minimised: an order ID and PSP reference usually suffice, and IBANs shown to staff are masked.

Payment data sits alongside personal data under the AVG, the Dutch name for the GDPR. We build consent screens, data minimisation and deletion routines; your processing agreements and legal sign-off stay with you and your adviser. The sibling guide on GDPR-compliant website development goes further into transfers to a team in India.

Adding iDEAL payment integration to an app you already run

Retrofitting iDEAL into live software starts with reading the code, not writing it. Before quoting, we ask for read access to the repository and a description of how orders or invoices move today.

The first week is usually spent building a thin payment layer: one module that knows how to create a payment, fetch a status and issue a refund with your chosen PSP. The rest of the app talks only to that module. When you later add cards, Bancontact for Belgian customers or a second PSP, the change stays inside that one layer.

We then add the database fields your orders were missing (payment ID, method, status history, refunded amount), the webhook route and the admin screens. Existing checkout pages get a new payment option rather than a redesign unless you ask for one. Everything ships behind a feature flag so iDEAL can go live for staff first, then a small share of customers, then everyone.

iDEAL payment integration cost: what moves the number

The cost of an iDEAL payment integration depends less on iDEAL and more on what has to happen before and after the payment. A single checkout with a success email is small. A subscription engine with proration, dunning, invoices and a customer billing portal is a project.

We price the surrounding software from our published starting points: US$900 for a custom web app or SaaS product, US$600 for an Android and iOS app, US$750 for a webshop. Payment work inside those is itemised as separate flows, so you can see what one-off checkout, recurring billing, refunds and reporting each add. Work on existing code is estimated after we read it.

Quotes from other developers vary widely for the same brief, usually because of three things: whether webhooks and refunds are included or left for later, whether the price assumes an existing codebase is clean, and whether testing on real phones is in scope. Ask every bidder the same questions and compare line by line. Our guide to pricing models explains how milestone quotes differ from hourly billing.

Testing an iDEAL payment integration before real money moves

Every PSP that offers iDEAL has a test mode where you can simulate paid, failed, cancelled and expired payments. We script tests for each state, then run them again after every change to the payment layer.

• Paid payment: order moves to paid once, email sent once, access or stock updated.
• Cancelled at the bank: customer returns to a page offering a retry.
• Expired: reservation released after the expiry window.
• Webhook arrives before the return page loads, and after it.
• Webhook delivered twice.
• Partial and full refunds, including one that exceeds the paid amount (must be refused).
• Phone flows: banking app returns to your app, returns to the browser, or does not return at all.

After test mode, you make one small live payment with your own bank account and refund it from the admin panel. That single step proves the production keys, the payout account and the refund funding all work, and it takes five minutes.

Working with a team in India on an iDEAL integration from the Netherlands

India is three and a half hours ahead of the Netherlands in summer and four and a half in winter, so our working day covers the European business day from late morning onward. A call at 10:30 in Amsterdam is early afternoon for us, and a bug reported at 16:00 Dutch time can still be looked at the same evening IST.

The first two weeks look like this. In week one we hold a 45-minute video call about your order model, read your repository, confirm which PSP you have signed with and write down every payment state your product needs. You create the PSP account in your company's name and invite us as developers. In week two the payment layer and webhook handler run in test mode, and you get a staging link to try each flow yourself.

• Contracts and invoices come from India, quoted in USD; you pay in USD or EUR by Wise or bank wire.
• Nothing is billed before you approve the written quote.
• The code lives in your Git repository from day one, and the PSP account, domain and hosting stay in your name.
• Messages go through WhatsApp 7 days a week, with longer discussions on a video call.

What we do not offer: on-site visits, a Dutch-speaking account manager, or legal and tax advice. If you need those, pair us with a local adviser. For the wider picture of outsourcing, see outsourcing web development to India.

Worked example: iDEAL payment integration for a small Dutch SaaS

Picture a hypothetical scheduling tool for Dutch physiotherapy practices, sold at a monthly price per location. The founders want practices to sign up online, pay the first month by iDEAL, and be charged automatically after that.

The build we would propose: a sign-up flow that creates a PSP customer, a first iDEAL payment that also creates a SEPA mandate, a subscription table with the next charge date, a daily job that charges due subscriptions, webhook handling for paid and failed debits, reversal handling within the eight-week window, an invoice PDF per charge, and a billing page where the practice can see invoices, update its bank details with a fresh iDEAL payment and cancel.

Timeline in that scenario: roughly a week of design, four to six weeks of build inside the wider product, and a week of testing including real-phone checks. Because this lives inside a custom SaaS, it would be quoted from US$900 with the billing module itemised. The PSP's per-transaction fees would be paid by the founders directly to their provider. None of this is a past project; it is how we would approach the brief.

Red flags when hiring someone for iDEAL payment integration

A developer who is vague about webhooks, keeps payment keys in the front end, or offers to receive payments into their own account is a risk to your cash and your customers. Walk away from any of these.

• “We'll mark the order paid when the customer lands on the thank-you page.”
• Payment API keys committed to the repository or shipped inside the mobile app.
• An offer to use the developer's own PSP account “to save you the paperwork”.
• No plan for refunds, expired payments or duplicate webhooks.
• A mobile app that sells digital subscriptions through iDEAL, which the stores can reject.
• No test plan, or testing only on the developer's own laptop.
• Code that stays on the developer's server until the final invoice is paid.

Our questions to ask an app developer list works well for payment projects too. Ask every candidate to walk you through what happens when a webhook arrives twice; the answer tells you a lot.

Checklist before you start an iDEAL payment integration

Gather these before the first call and your iDEAL payment integration can be quoted accurately within two working days.

• Which PSP or acquirer you have signed with, or a shortlist of two.
• Every product or service you sell, and whether it is physical, a real-world service or digital.
• One-off payments, recurring billing, or both.
• Other methods you need beside iDEAL: cards, Bancontact, SEPA transfer, buy-now-pay-later.
• What must happen after payment: access, emails, invoices, stock, bookings.
• Who issues refunds, and what limits apply.
• Accounting software the payments must reach, such as Exact Online or Moneybird.
• Read access to your repository, or a description of the stack if nothing exists yet.

Send the list on WhatsApp or through the contact page. If your need turns out to be a standard webshop, the Shopify developer page is the better starting point.