Payment Hub · Conceptos
Cómo viaja un pago por el Payment Hub
Por qué vive fuera del core
Sección titulada «Por qué vive fuera del core»El core bancario es el sistema de registro: cuentas, saldos y contabilidad de todos los clientes. Tiene que cambiar poco y no caerse nunca. La mensajería con otras instituciones es lo contrario: cambia seguido (una versión nueva de un mensaje, una red nueva, un banco nuevo) y depende de redes externas que a veces no responden.
Por eso el diseño los separa:
- El core nunca habla XML ISO 20022. Publica eventos propios («se ordenó una transferencia») y recibe eventos («la transferencia fue aceptada»).
- El Payment Hub traduce entre esos eventos y los mensajes de cada red, y aísla al core de sus fallas.
Así, cuando una red cambia de versión, se toca el Payment Hub y no el sistema que lleva los saldos de millones de cuentas.
Las etapas de una transferencia
Sección titulada «Las etapas de una transferencia»Recibir y decidir
- RecepciónLa orden del core, con su identificador de punta a punta
- ValidaciónDatos completos y bien formados
- CumplimientoLímites por moneda, países e instituciones bloqueados
- RuteoQué riel le corresponde
- Política de direcciónSi el riel exige dirección estructurada
Enviar y seguir
- TraducciónDe evento a mensaje pacs.008 con su cabecera
- Bandeja de salidaSe guarda antes de enviar
- Envío y seguimientoReintentos hasta el acuse
- Estado entranteEl pacs.002 cambia el estado y avisa al core
Nada se pierde, nada se envía dos veces
Sección titulada «Nada se pierde, nada se envía dos veces»Dos garantías sostienen el diseño:
- Bandeja de salida transaccional (outbox). La orden se guarda primero y se envía después. Si el servicio se cae entre una cosa y otra, un barrido periódico encuentra lo que quedó a medias y lo retoma. Lo que no puede entregarse, por ejemplo porque su riel no tiene transporte configurado, queda en vuelo y visible en una lista de excepciones, no perdido en silencio.
- Idempotencia de salida. Cada orden se identifica por su identificador de punta a punta. Si el core manda la misma orden dos veces, el Payment Hub la reconoce y no emite un segundo pago.
Y un caso que se suele olvidar: un informe de estado que llega sin orden conocida (un huérfano) se detecta y se señala, en vez de descartarse.
Rieles genéricos: el país lo pone la configuración
Sección titulada «Rieles genéricos: el país lo pone la configuración»El diseño no nombra ningún país en el código. Habla de rieles genéricos, y cada perfil de país dice qué es cada uno:
| Riel | Qué es | En Venezuela, por ejemplo |
|---|---|---|
| Alto valor (RTGS) | Liquidación bruta en tiempo real entre bancos | El sistema de liquidación bruta del banco central |
| Compensación (ACH) | Pagos de menor valor compensados por lotes | La cámara de compensación electrónica |
| Inmediato | Pagos instantáneos entre personas o comercios | Pago móvil interbancario |
| Internacional | Mensajería entre bancos de distintos países | Mensajería internacional ISO 20022 |
| Interno | Los dos extremos en la misma institución | Traspaso entre cuentas del mismo banco |
Sin un país configurado, el Payment Hub no arranca. Es a propósito: sin jurisdicción, emitiría mensajes con una identidad inventada.
Lo que todavía falta
Sección titulada «Lo que todavía falta»- Despliegue. No está en ningún ambiente productivo.
- Validación oficial. El XML sale bien formado, pero no está validado contra los esquemas y las guías de uso de ninguna red.
- Más mensajes. Devoluciones, transferencias entre instituciones por cuenta propia, solicitudes de cancelación y estados de cuenta entrantes.
- Transporte nativo hacia la red internacional; hoy el diseño envía por HTTP a cada riel.
- Cifrado en reposo del contenido de cada mensaje.
- Un solo generador. El core todavía tiene un generador propio de transferencias internacionales que debe delegar en el Payment Hub: dos generadores del mismo mensaje terminan diferenciándose.