Cinque anni di connettori PSD2: quello che la specifica non vi dice

Un riquadro bancario collegato al marchio Trex Pi da linee di dati tratteggiate

Il PSD2 prometteva un'unica API per ogni banca in Europa. Quello che abbiamo ottenuto è una famiglia di specifiche e qualche centinaio di interpretazioni di essa. Dopo cinque anni a costruire e gestire connettori di informazioni sui conti e di iniziazione dei pagamenti per clienti in tutti i Paesi Baltici, lo schema è chiaro: la prima banca richiede una settimana, la quinta un giorno, e poi la successiva, inaspettatamente, richiede un mese.

Il flusso di consenso è dove i progetti si bloccano

Le chiamate API sono la parte facile. La parte difficile è il ciclo di vita del consenso - come un cliente autorizza il vostro accesso, quanto dura quell'autorizzazione, e cosa succede quando scade alle 03:00 di una domenica.

  • Alcune banche emettono consensi di 90 giorni e li rinnovano silenziosamente; altre impongono una riautenticazione completa.
  • I flussi di consenso in sandbox differiscono regolarmente da quelli in produzione. Preventivate un secondo passaggio di integrazione dopo il go-live.
  • Le tassonomie degli errori sono incoerenti: lo stesso consenso scaduto può presentarsi come 401, 403, o - in un caso memorabile - un 200 con un elenco di transazioni vuoto.

Quest'ultimo merita un'enfasi particolare: una risposta vuota non è la stessa cosa di una risposta di successo. Se la vostra riconciliazione dipende da un feed di transazioni, trattate "nessuna transazione" come una condizione da verificare, non come un fatto da registrare.

Su cosa standardizziamo

Ogni connettore che consegniamo ora gira dietro la stessa interfaccia interna, con adattatori per singola banca mantenuti deliberatamente sottili. La stessa disciplina si applica sul lato di iniziazione dei pagamenti - un unico oggetto pagamento canonico, mappato esplicitamente al dialetto di ciascuna banca:

Mappatura dei campi di pagamento ERP sugli elementi XML SEPA pain.001

L'adattatore gestisce le particolarità dell'autenticazione e i diversi schemi di recupero dei dati pagina per pagina; tutto il resto - retry, idempotenza, allerta, avvisi di scadenza del consenso - vive nello strato condiviso, scritto una volta e testato una volta.

Se un'integrazione bancaria richiede logica di retry personalizzata, quella logica appartiene allo strato condiviso con un feature flag - mai nell'adattatore. Gli adattatori lasciati a sé stessi invecchiano; lo strato condiviso, invece, continua a ricevere manutenzione.

Il risultato diventa pura routine, prevedibile - ed è esattamente questo l'obiettivo. Una nuova banca è un nuovo adattatore, un file di esempio registrato dalla sua sandbox, e una checklist - non un nuovo progetto.