Cinq ans de connecteurs PSD2 : ce que la spécification ne vous dit pas

La PSD2 promettait une seule API pour toutes les banques d'Europe. Ce que nous avons obtenu, c'est une seule famille de spécifications et plusieurs centaines d'interprétations de celle-ci. Après cinq ans à construire et exploiter des connecteurs d'information sur les comptes et d'initiation de paiement pour des clients dans les pays baltes, le schéma est clair : la première banque prend une semaine, la cinquième prend un jour, puis la suivante prend, contre toute attente, un mois.

Le flux de consentement, là où les projets s'enlisent

Les appels d'API sont la partie facile. La partie difficile, c'est le cycle de vie du consentement - comment un client autorise votre accès, combien de temps cette autorisation dure, et ce qui se passe quand elle expire à 3 heures du matin un dimanche.

• Certaines banques émettent des consentements de 90 jours et les renouvellent silencieusement ; d'autres imposent une réauthentification complète.
• Les flux de consentement en bac à sable (sandbox) diffèrent systématiquement de ceux de production. Prévoyez une seconde passe d'intégration après la mise en service.
• Les taxonomies d'erreur sont incohérentes : le même consentement expiré peut se manifester par un 401, un 403, ou - dans un cas mémorable - un 200 accompagné d'une liste de transactions vide.

Ce dernier cas mérite d'être souligné : une réponse vide n'est pas la même chose qu'une réponse réussie. Si votre rapprochement dépend d'un flux de transactions, traitez « aucune transaction » comme une condition à vérifier, pas comme un fait à enregistrer.

Ce que nous standardisons

Chaque connecteur que nous livrons aujourd'hui fonctionne derrière la même interface interne, avec des adaptateurs par banque volontairement minces. La même discipline s'applique côté initiation de paiement - un objet paiement canonique unique, mappé explicitement au dialecte de chaque banque :

L'adaptateur gère les particularités d'authentification et les différentes façons de récupérer les données page par page ; tout le reste - relances, idempotence, alertes, avertissements d'expiration de consentement - vit dans la couche partagée, écrite une fois et testée une fois.

Si une intégration bancaire a besoin d'une logique de relance personnalisée, cette logique appartient à la couche partagée, derrière un feature flag - jamais dans l'adaptateur. Un adaptateur laissé à lui-même devient obsolète ; la couche partagée, elle, continue d'être entretenue.

Le résultat devient de la routine - et c'est exactement l'objectif. Une nouvelle banque, c'est un nouvel adaptateur, un fichier d'exemple enregistré depuis son bac à sable pour les tests, et une checklist - pas un nouveau projet.