Cinco años de conectores PSD2: lo que la especificación no te cuenta

Una ficha de banco conectada al logotipo de Trex Pi mediante líneas de datos discontinuas

PSD2 prometía una única API para todos los bancos de Europa. Lo que obtuvimos fue una familia de especificaciones y un par de cientos de interpretaciones de ella. Tras cinco años construyendo y operando conectores de información de cuentas e iniciación de pagos para clientes de todo el Báltico, el patrón está claro: el primer banco lleva una semana, el quinto lleva un día, y luego el siguiente, inesperadamente, lleva un mes.

El flujo de consentimiento es donde los proyectos se estancan

Las llamadas a la API son la parte fácil. La parte difícil es el ciclo de vida del consentimiento - cómo autoriza un cliente tu acceso, cuánto dura esa autorización, y qué pasa cuando caduca a las 03:00 de un domingo.

  • Algunos bancos emiten consentimientos de 90 días y los renuevan silenciosamente; otros obligan a una reautenticación completa.
  • Los flujos de consentimiento del sandbox suelen diferir de los de producción. Reserva presupuesto para una segunda pasada de integración después de la puesta en marcha.
  • Las taxonomías de error son inconsistentes: el mismo consentimiento caducado puede manifestarse como 401, 403 o - en un caso memorable - un 200 con una lista de transacciones vacía.

Ese último merece énfasis: una respuesta vacía no es lo mismo que una respuesta exitosa. Si tu conciliación depende de un feed de transacciones, trata «sin transacciones» como una condición que verificar, no como un hecho que registrar.

En qué estandarizamos

Cada conector que entregamos ahora funciona detrás de la misma interfaz interna, con adaptadores por banco mantenidos deliberadamente delgados. La misma disciplina se aplica en el lado de iniciación de pagos - un único objeto de pago canónico, mapeado explícitamente al dialecto de cada banco:

Mapeo de campos de pago del ERP a elementos XML pain.001 de SEPA

El adaptador gestiona las particularidades de autenticación y las distintas formas de recuperar los datos página a página; todo lo demás - reintentos, idempotencia, alertas, avisos de caducidad de consentimiento - vive en la capa compartida, escrita una vez y probada una vez.

Si una integración bancaria necesita una lógica de reintento personalizada, esa lógica pertenece a la capa compartida con un feature flag - nunca al adaptador. Un adaptador abandonado a su suerte se queda obsoleto; la capa compartida, en cambio, se mantiene siempre al día.

El resultado se vuelve rutinario - y ese es exactamente el objetivo. Un banco nuevo es un adaptador nuevo, un archivo de ejemplo grabado desde su sandbox para las pruebas y una checklist - no un proyecto nuevo.