iDEAL Netherlands: A2A payments

1) iDEAL context and positioning

iDEAL is a national scheme for non-cash A2A payments (account-to-account) in the Netherlands. The buyer pays for the purchase directly from his bank account through the online bank/mobile application of the issuing bank. The stream is built on issuer-redirect (redirect to the bank) or on opening a banking application by deeplink/App2App. The calculation is fast, the commission for the merchant is lower than the card MDR, the final is like a bank credit transfer.

• Interoperability through issuing banks (ING, Rabobank, ABN AMRO, etc.).
• SCA/PSD2 correspondence - confirmation in the bank (PIN/biometrics).
• Instant authorization (status success online) and final loan through the acquirer/recipient bank.
• Rich metadata for reconciliation (purchaseId/orderId, description, reference).

2) Participant roles

iDEAL (scheme) - rules, certification, routing to issuing banks.
Issuer - customer authentication, payment confirmation, status.
Acquirer/CPSP (Payment Service Provider) - merchant connection, API/SDK, reporting and calculations.
Merchant - initiates payment, receives statuses/funds, maintains returns and reconciliation.

3) Payment flow options

3. 1 Issuer-redirect (classic)

1. Checkout merchant → choosing a bank from the Issuer Directory.
2. Redirect or App2App to the bank → SCA → confirmation.
3. Return to merchant with 'transactionId' and status (success/failed/canceled/open/expired).

3. 2 App2App / Embedded

On mobile devices, the merchant opens a banking application by deeplink/intent (better UX, less friction).
Embedded/Hosted: the provider gives a ready-made widget of the list of banks, redirect management, error handling.

3. 3 iDEAL QR (offline/online)

Dynamic QR per-order with embedded sum and reference; the buyer scans the banking app's camera and confirms the payment.
Static QR (rare for merchants; more for P2P/donations) - the amount is entered manually by the user.

3. 4 Recurring/mandates

The "first payment + e-mandate" model: the first write-off for iDEAL with an explicit SCA → the creation of an e-mandate (usually leads to SEPA Direct Debit for the next write-offs within the agreed limits/periods). Suitable for subscriptions.

4) Limits and policies of banks

• Per-transaction (maximum per operation).
• Per-day/24h and weekly (amount and/or number of transactions).
• New beneficiary/new merchant - reduced thresholds and/or exposure are possible.
• Channel/risk rules (mobile vs desktop, velocity, geo/device).

Practice: do not hardcode numbers - keep a directory of limits by banks and display the user an understandable error "exceeded the limit by the bank" with alternatives (splitting, another method, repeat later).

5) Commissions and Economics

• provider fees (gateway, widget, hosted checkout),
• cost of returns/ODRs,
• support and investigation of incidents.

6) Statuses, cancellations, returns

Transaction statuses: 'success', 'open' (waiting), 'failed', 'cancelled', 'expired'.
Cancellation before confirmation - from the client (at the bank) or by time (expired).
Chargers as in the cards - no. A refund is a new credit transaction from the merchant to the payer (refund), partial refunds are possible.
The return period depends on the PSP/bank; often T + 0/T + 1 on bank transfer.

7) Safety and compliance

SCA in the issuing bank + device binding and anti-fraud policies on the bank side.
Name/IBAN display in some issuers reduces the risk of misdirection.
PSD2/GDPR: PII minimization, web hook protection (HMAC), audit log.

8) Reconciliation and Reporting

Save 'transactionId' (iDEAL), 'purchaseId '/' orderId', time, issuer, final status, UTR/bank reference from PSP reports.
Set up daily auto-recon and periodic full-recon (reconciliation of turnovers, returns, adjustments).
In PSP reports: initial order parameters, statuses, late updates (for example, 'open → success/expired'), returns movements.

9) UX patterns

Directory → Bank pick: pre-fill and sort banks by popularity/last choice.
Mobile-first: automatically offer App2App, fallback - web-redirect.
Retry/recovery: If unsuccessful, show a simple repeat and alternative methods.
Idempotency: 'orderId' + idempotency key for safe repeats.
Checks: specify amount, date/time, 'transactionId', reference, channel (QR/App2App/Redirect).

10) Recurrent write-offs via e-tickets

Scenario "iDEAL first payment → mandate for future write-offs" (usually via SEPA Direct Debit).
The per debit limit, frequency, right to cancel are fixed in the mandate.
In the interface, there is a pause/cancel/update screen and notifications before decommissioning.

11) iDEAL and iGaming/high-risk categories

The availability of iDEAL for some verticals is limited to banks/PSPs on risk policy and local law.
For iGaming, expect: tightened checks, reduced limits, mandatory local compliance and transparent ODR/Refund flow.
Plan alternative rails (cards, SEPA, open-banking A2A) and traffic segmentation.

12) Merchant Integration: Options

1. Hosted/Embedded iDEAL Checkout от PSP

Quick start, auto-update of the list of banks, statuses and errors.

2. Server-to-Server + redirects

Flexible UX control: own bank selection page, QR generation, deep integration into the cashier.

3. iDEAL QR

For POS/offline: dynamic QR per-order with sum/marks, better for reconciliation and anti-cost.

• Эндпоинты: `createPayment`, `queryStatus`, `refund`, `webhook`, `reconcile`.
• Idempotence and dedupe table by 'orderId'.
• Webhooks with HMAC signature, retrai exponential, bullet polling on degradation.
• Catalogs: banks/limits/error codes; SLA metrics by issuer.

13) Architectural scheme "iDEAL Gateway"

API layer: REST for cash desk + integration with PSP/iDEAL API.
Event queues: status events → billing/CRM/analytics.
Observability: conversion metrics by banks/channels (Redirect/App2App/QR), share of 'open→expired', average latency to success.
Security: secrets in vault, IP-allowist from PSP, redirect URL protection, anti-replay tokens.
Data: payment/return registers, ODR log, ticket card.

14) Output checklist

1. Select the PSP/acquirer with iDEAL (Hosted/Embedded/App2App/QR).
2. Implement 'createPayment' + redirects/App 2 App, bank selection screen.
3. Enable web hooks, idempotency, timeouts, and status replays.
4. Set up recon (daily + full), uploads and alerts for out-of-sync.
5. Support partial/full refunds and ODR regulations in support.
6. Add UX-fallback (alternate methods, repeat), check with 'transactionId'.
7. Test App2App/QR on major banks (iOS/Android/desktop).
8. Prepare a limit guide by bank and an incident status page.

Limit Reference Card

Per-txn/24h/7d: store in config; check before starting the redirect.
New beneficiaries/merchants: reduced starting limits and/or delays.
Channel: On the mobile App2App, limits/fraud policies may differ from the web.
Tickets - Limits/frequency are set in the ticket conditions (for recurring write-offs).

Summary

Bet on conversion App2App/Embedded and dynamic QR for offline.
Do not lace hard amounts: keep configs of limits and behavioral rules for banks.
The process is built around webhooks + recon, clear statuses and partial refunds.
For subscriptions - the first payment iDEAL → e-mandate; Manage limits and notifications transparently.