iDEAL Paesi Bassi: pagamenti A2A

1) Contesto e posizionamento del iDEAL

iDEAL è uno schema nazionale di pagamenti in contanti A2A (account-to-account) nei Paesi Bassi. L'acquirente paga l'acquisto direttamente dal proprio conto bancario tramite la banca/applicazione mobile della banca emittente. Il flusso è costruito su issuer-redirect (reindirizzamento alla banca) o all'apertura di un'applicazione bancaria su deeplink/App2App. Calcolo rapido, commissione per il merchant sotto le MDR cartucce, finalità - come i crediti bancari.

• Interoperabilità attraverso banche emittenti (ING, Rabobank, ABN AMRO, ecc.).
• SCA/PSD2 - conferma in banca (PIN/biometria).
• Autorizzazioni immediate (status success online) e credito finale tramite equayer/banca destinataria.
• Metadati ricchi da comprimere (purchaseId/orderId, descrizione, reference).

2) Ruoli dei membri

iDEAL (schema) - regole, certificazione, routing verso le banche emittenti.
Issuer - autenticazione del cliente, conferma del pagamento, stato.
Acquirer/CPSP (Payment Service Provider) - Connessione merchant, API/SDK, report e calcoli.
Merchant - Avvia il pagamento, riceve lo stato/denaro, i rimborsi e la verifica.

3) Opzioni di flusso di pagamento

3. 1 Issuer-redirect (classic)

1. Checkout Merchant seleziona una banca da Issuer Directory.
2. Redirett o App2App alla SCA Bank.
3. Restituisce il merchant con «transactionId» e lo stato (success/failed/canceled/open/expired).

3. 2 App2App / Embedded

Sui dispositivi mobili, il Merchant apre un'applicazione bancaria per deeplink/intent (migliore UX, meno attrito).
Embedded/Hosted: il provider fornisce il widget pronto per la lista delle banche, la gestione dei reading, l'elaborazione degli errori.

3. 3 iDEAL QR (offline/online)

QR dinamico per-order con somma incorporata e reference; L'acquirente scansiona la fotocamera dell'applicazione bancaria e conferma il pagamento.
QR statico (raramente per merchant; più per P2R/Donat) - L'importo viene immesso manualmente dall'utente.

3. 4 Recurring/mandates

Il modello «first payment + e-mandate» è il primo prelievo di con SCA esplicito, che consente di creare un e-mandato (solitamente porta a SEPA Direct Debit per i seguenti prelievi entro i limiti/periodici concordati). È adatto per le iscrizioni.

4) Limiti e politica delle banche

• Per-trasmissione (per un massimo di un'operazione).
• Per-day/24h e week (importo e/o numero di operazioni).
• Nuovo beneficiario/nuovo merchant - possibili soglie ridotte e/o superamento.
• Regole di canale/rischio (mobile vs dectop, velocity, geo/device).

Pratica: Non fare l'hardcoding dei numeri - Mantieni l'elenco dei limiti bancari e mostra all'utente l'errore comprensibile «superato il limite della banca» con alternative (frazionamento, altro metodo, ripetere in seguito).

5) Commissioni ed economia

• incassi di provider (gateway, widget, hosted checkout),
• costo dei rimborsi/operazioni ODR,
• Supporto e indagini sugli incidenti.

6) Stati, annullamenti, rimborsi

Gli stati delle transazioni sono «success», «open» (in attesa), «failed», «canceled», «expired».
Annulla prima della conferma dal client (in banca) o dal timeout (expired).
I Charjback non sono come le carte. La restituzione è una nuova operazione di credito da parte di un venditore (refund), che può essere restituita parzialmente.
Il termine di rimborso dipende da PSP/banca; spesso T + 0/T + 1 per trasferimento bancario.

7) Sicurezza e conformità

SCA in banca emittente + device binding e politica antifrode sul lato della banca.
Name/BAN display in alcuni emettitori riduce il rischio misdirection.
PSD2/GDPR: riduzione del PI, protezione del web hook (HMAC), registro di controllo.

8) Accoppiamento e reporting

Salva «transactionId» (iDEAL), «purchaseId »/« orderId», time, issuer, stato finale, UTR/giudizio bancario dei rapporti PSP.
Regolare il daily auto-recon e il full-recon periodico (comprimere giri, ritorni, regolazioni).
I report PSP includono le impostazioni originali dell'ordine, gli stati, gli aggiornamenti tardivi (ad esempio, «open n'success/expired»), i movimenti di restituzione.

9) pattern UX

Directory → Bank pick: predisporre e ordinare le banche per popolarità/ultima scelta.
Mobile-first: offre automaticamente App2App, fallback - web-redict.
Retry/recovery: in caso di fallimento, mostrate una semplice ripetizione e metodi alternativi.
Idempotency: 'orderId' + chiave di idempotenza per ripetizioni sicure.
Assegni: specificare l'importo, la data/ora, 'transactionId', reference, canale (QR/App2App/Redirect).

10) Riscrittori tramite e-mandati

Lo script «primo pagamento il mandato per i prelievi futuri» (solitamente tramite SEPA Direct Debit).
Il mandato fissa il limite per debit, la frequenza, il diritto di annullamento.
L'interfaccia contiene la schermata di gestione dei mandati (pausa/cancel/update) e le notifiche prima del prelievo.

11) iDEAL e iGaming/categorie ad alto rischio

La disponibilità per alcune verticali è limitata alle banche/PSP per le politiche di rischio e il diritto locale.
Per i iGaming, attende controlli più severi, limiti ridotti, compilazione locale obbligatoria e OPR/Refund-flow trasparente.
Pianificare binari alternativi (mappe, SEPA, open banking A2A) e segmentazione del traffico.

12) Integrazione merchant: opzioni

1. Hosted/Embedded iDEAL Checkout от PSP

Avvio rapido, aggiornamento automatico dell'elenco delle banche, degli stati e degli errori.

2. Server-to-Server + riduttori

Controllo UX flessibile: propria pagina di selezione della banca, generazione QR, profonda integrazione nella cassa.

3. iDEAL QR

Per POS/offline: QR dinamico per-order con somma/etichetta, meglio per i controlli e i supporti.

• Эндпоинты: `createPayment`, `queryStatus`, `refund`, `webhook`, `reconcile`.
• Idampotenza e tabella dedupe per «orderId».
• Webhooks con firma HMAC, retrai esponenziale, pool-interrogazione durante il degrado.
• Cataloghi: banche/limiti/codici di errore; Metriche SLA per emittenti.

13) Schema architettonico «iDEAL Gateway»

livello API: RESTE per la cassa + integrazione con API PSP/iDEAL.
Le code di eventi sono States-Ivent-Billing/CRM/Analista.
Osservabilità: metriche di conversione in banca/canale (Redirect/App2App/QR), quota «open→expired», latitanza media fino a success.
Sicurezza: segreti in vault, IP-allowlist da PSP, protezione URL readyct, token anti-replay.
Dati: registri dei pagamenti/rimborsi, registro ODR, carta dei mandati.

14) Assegno foglio di output

1. Seleziona PSP/Equyer con iDEAL (Hosted/Embedded/App2App/QR).
2. Metti in pratica «createPayment» + ready/Arr2Arr, schermata di selezione della banca.
3. Attivare il Web Hook, l'idempotenza, i timeout e le ripetizioni di stato.
4. Configura i recon (daily + full), i download e gli alert per le rassincroni.
5. Supporta partial/full refunds e il codice ODR nello zappino.
6. Aggiungi UX-fallback (metodi alternativi, ripetizione), assegno con «transactionId».
7. Prova App2App/QR sulle principali banche (iOS/Android/desktop).
8. Preparare un elenco dei limiti per le banche e una pagina degli stati degli incidenti.

Scheda di riferimento dei limiti

Per-txn/24h/7d: memorizzare in un configh; Controlla fino all'avvio del redirect.
Nuovi beneficiari/merchant: limiti di partenza ridotti e/o ritardi.
Canale: Su App2App mobile i limiti/regole di frodo possono essere diversi dal Web.
I mandati sono i limiti/periodicità impostati durante il mandato (per i prelievi ricorrenti).

Riepilogo

Puntate su App2App/Embedded per la conversione e su QR dinamico per offline.
Non ingigantirvi i limiti e le regole comportamentali sulle banche.
Il processo è costruito intorno a webhooks + recon, stati chiari e partial refunds.
Per le sottoscrizioni è il primo pagamento di un mandato e-mail; gestire i limiti e le notifiche in modo trasparente.