Por qué la arquitectura de payment intent supera a la llamada charge del gateway

Las pasarelas clásicas exponen los pagos como una llamada a función: envía un charge, recibe éxito o error. Esa abstracción aguanta justo hasta que interviene la realidad — un timeout en el que no sabes si el banco cobró, un reintento en un segundo adquirente, una captura parcial, un reembolso sobre una captura que a su vez fue parcial. Un booleano no puede cargar con esa historia.

Un intent modela el pago como una máquina de estados de larga vida: iniciado, procesando, esperando 3-D Secure, autorizado, parcialmente capturado, capturado, reembolsado — con cada transición legal definida y todo lo demás rechazado. El código no puede reembolsar “sin querer” un pago no autorizado, porque esa transición simplemente no existe.

El estado más infravalorado es el honesto: pendiente-de-conciliación. Cuando un banco agota el tiempo, el estado veraz es “desconocido”, y fingir lo contrario es la receta del doble cargo. Un intent puede aparcar ahí mientras un barrido pregunta al banco qué pasó de verdad — y solo entonces avanzar. Una llamada charge no tiene dónde aparcar; tiene que mentir en una dirección u otra.

Los intents también hacen natural el enrutamiento multi-adquirente. El intento uno se rechaza; la cascade dispara el intento dos bajo el mismo intent — mismo alcance de idempotencia, mismo registro de auditoría, un solo cargo garantizado. Con pasarelas de charge, cada reintento es un pago nuevo de cero, y coserlos en una sola historia del cliente pasa a ser tu problema.

Por último, un intent emite eventos en cada transición — una historia solo-añadir que puedes encadenar por hash, auditar y reproducir. No es solo higiene de cumplimiento; es el sustrato sobre el que se construyen los webhooks, el ledger y la evidencia de disputas. El gateway te dio una respuesta. El intent te da un expediente.