Cinci ani de conectori PSD2: ce nu vă spune specificația

O placă de bancă conectată la sigla Trex Pi prin linii punctate de date

PSD2 a promis un singur API pentru fiecare bancă din Europa. Ce am primit este o singură familie de specificații și câteva sute de interpretări ale acesteia. După cinci ani de construire și operare a conectorilor de informare asupra conturilor și de inițiere a plăților pentru clienți din statele baltice, tiparul este clar: prima bancă durează o săptămână, a cincea durează o zi, iar apoi următoarea durează, pe neașteptate, o lună.

Fluxul de consimțământ este locul unde proiectele se blochează

Apelurile API sunt partea ușoară. Partea grea este ciclul de viață al consimțământului - modul în care un client vă autorizează accesul, cât timp durează acea autorizare și ce se întâmplă atunci când expiră la ora 03:00 într-o duminică.

  • Unele bănci emit consimțăminte valabile 90 de zile și le reînnoiesc în tăcere; altele impun o reautentificare completă.
  • Fluxurile de consimțământ din sandbox diferă de regulă de cele din producție. Bugetați o a doua rundă de integrare după lansare.
  • Taxonomiile de erori sunt inconsistente: același consimțământ expirat poate apărea ca 401, 403, sau - într-un caz memorabil - un 200 cu o listă de tranzacții goală.

Ultimul caz merită subliniat: un răspuns gol nu este același lucru cu un răspuns de succes. Dacă reconcilierea dvs. depinde de un flux de tranzacții, tratați „nicio tranzacție” ca pe o condiție de verificat, nu ca pe un fapt de înregistrat.

Pe ce ne standardizăm

Fiecare conector pe care îl livrăm rulează acum în spatele aceleiași interfețe interne, cu adaptoare specifice fiecărei bănci menținute deliberat subțiri. Aceeași disciplină se aplică și pe partea de inițiere a plăților - un singur obiect canonic de plată, mapat explicit la dialectul fiecărei bănci:

Maparea câmpurilor de plată ERP la elementele XML SEPA pain.001

Adaptorul gestionează particularitățile de autentificare și diferitele scheme de preluare a datelor pagină cu pagină; tot restul - reîncercări, idempotență, alertare, avertismente de expirare a consimțământului - trăiește în stratul comun, scris o singură dată și testat o singură dată.

Dacă o integrare bancară are nevoie de logică personalizată de reîncercare, acea logică aparține stratului comun, cu un feature flag - niciodată adaptorului. Adaptoarele lăsate în voia lor se învechesc; stratul comun, în schimb, este întreținut în permanență.

Rezultatul devine o rutină previzibilă - și exact acesta este scopul. O bancă nouă înseamnă un nou adaptor, un fișier de exemplu înregistrat din sandbox-ul ei și o listă de verificare - nu un proiect nou.