El ciclo de vida del pago: de la autorización a la liquidación
El ciclo de vida del pago es la secuencia fija por la que pasa un pago desde que se aprueba hasta que los fondos llegan a la cuenta del comercio: autorización, captura, compensación, liquidación y payout. Cada paso hace exactamente una tarea, y el dinero está en un estado distinto después de cada uno. Casi todos imaginan un pago con tarjeta como un único evento al acercarla al terminal; en realidad es una cadena, y casi todo lo que sale bien o mal en pagos ocurre porque estos pasos son independientes, no simultáneos.
Entender la cadena marca la diferencia entre un pago que se concilia solo y un ticket de soporte. Así que recorrámosla una vez, de principio a fin y en orden.
Autorización: una retención, no una transferencia
La autorización es una pregunta, no un movimiento. Cuando se acerca una tarjeta, la solicitud viaja hasta el emisor, que comprueba que la cuenta existe, está al corriente y dispone de fondos o crédito para el importe. Si es así, coloca una retención —reserva el dinero para que no pueda gastarse dos veces— y devuelve un código de autorización. No se ha movido dinero. El comercio tiene ahora la promesa de que los fondos son buenos, válida durante una ventana definida por la red. Una autorización puede revertirse (una anulación) antes de cobrar nada, y caduca por sí sola si nunca se usa. Por eso el saldo de una tarjeta baja en el instante en que pagas, pero la línea del extracto se confirma más tarde: la bajada es la retención, no el cargo. Una autorización también puede denegarse de plano —fondos insuficientes, una regla antifraude, una tarjeta caducada— y una buena pasarela de pagos distingue entre una denegación blanda que merece reintento y una dura que no. Como la retención es la promesa del emisor de que el dinero es bueno, el comercio puede entregar la mercancía confiando solo en el código de autorización, antes de que una sola unidad de moneda haya salido de la cuenta del cliente.
Captura: convertir la retención en un cobro
La captura es el comercio diciendo «cobra esto ahora». Convierte la retención en una solicitud real del dinero. La captura puede ser total, parcial (un importe final menor que el autorizado: un artículo enviado más barato que la preautorización) o diferida (autorizar al pedir, capturar al enviar). Autorizar y capturar en un solo paso es lo habitual en la caja de una tienda; autorizar primero y capturar después es como funcionan hoteles, gasolineras y marketplaces, porque no conocen el importe final cuando se presenta la tarjeta. El intervalo entre autorización y captura es una costura deliberada y útil: es donde el comercio decide cuánto cobrar realmente.
Compensación: el lote que concilia
Los pagos capturados no se liquidan uno a uno en tiempo real. Se agrupan en ficheros y se intercambian por lotes entre el adquirente del comercio y las redes de tarjetas: es la compensación (clearing). En este paso se casan las transacciones, se netean los importes y se aplican las tasas de la red y la interchange, de modo que todos coincidan en quién debe cuánto a quién. La compensación es una tarea de conciliación, no un movimiento de dinero: produce los totales acordados sobre los que actúa el paso siguiente. Es también, por estructura, un proceso por lotes, y esa es la verdadera razón de que un pago que parecía instantáneo en caja tarde días en llegar como efectivo. Nada de esto es una limitación de los ordenadores; así están diseñadas las redes para netear con eficiencia miles de entidades entre sí, intercambiando totales acordados una vez por ciclo en lugar de lanzar una transferencia por cada café.
La autorización es una promesa, la captura es un cobro y la liquidación es el único paso en el que el dinero se mueve de verdad. Confundir los tres es la forma de contabilizar ingresos que aún no se tienen.
Liquidación: el dinero se mueve de verdad
La liquidación es el momento en que los fondos cambian realmente de manos entre bancos. Con los totales neteados de la compensación, la red mueve dinero de los emisores a los adquirentes, y cada entidad liquida su posición neta en lugar de cada transacción individual. La liquidación se ejecuta con una fecha valor —el día en que los fondos están realmente disponibles—, y por eso los pagos siguen un ritmo T+1 o T+2: el dinero es real, pero llega según el calendario de la red, no el reloj del cliente. Todo lo anterior era contabilidad; este es el paso en el que los asientos del ledger se convierten en saldos disponibles. La entidad que debe en neto paga; la que tiene saldo a favor cobra. Y como es en neto, las sumas que se mueven realmente entre bancos son una fracción del valor bruto de los pagos del día, lo que convierte a una red con millones de transacciones en un número manejable de movimientos de liquidación.
Payout: del adquirente a tu cuenta
La liquidación deja el dinero en el adquirente; el payout lo lleva al comercio. Con una periodicidad —diaria, semanal o bajo demanda—, el adquirente abona el saldo acumulado del comercio en su cuenta bancaria, descontadas las comisiones de procesamiento y cualquier reserva retenida para reembolsos y disputas. Es la cifra que un negocio ve realmente, y el punto en que la conciliación funciona o duele: el payout es un importe neto que cubre muchas transacciones, así que cuadrarlo con los pedidos individuales es un ejercicio en sí mismo. Una pasarela que mantiene la identidad de cada pedido de principio a fin lo vuelve trivial; una que no, convierte cada payout en una hoja de cálculo. El flujo de nuestra pasarela, /products/gateway, está diseñado para que un payout concilie con los pedidos que lo componen.
Dónde añade un puente el cripto
Un pago en cripto o stablecoin no sustituye esta cadena: le añade un tramo de conversión al principio. En lugar de la retención de autorización de un emisor, el pago se confirma on-chain: el cliente firma una transferencia, y la finalidad se alcanza a medida que la red añade confirmaciones, no cuando un banco aprueba una retención. Una vez confirmado, un off-ramp convierte el cripto en fiat, y desde ahí el dinero vuelve a entrar en el mismo camino de compensación, liquidación y payout que usa cualquier otro pago. La novedad queda contenida en ese primer tramo; la segunda mitad sigue siendo deliberadamente aburrida. Esa es la regla de diseño —mantener la liquidación ordinaria y poner la mecánica nueva solo donde es inevitable—, porque la tesorería, la conciliación y el auditor que vienen después no deberían poder saber cómo empezó el pago. Cuántas confirmaciones se consideran definitivas es una decisión de política, no una ley de la cadena: un listón más alto cambia velocidad por certeza frente a una reorganización, y el off-ramp espera la profundidad que fije el apetito de riesgo antes de liberar el fiat hacia el circuito de liquidación.
Por qué importan las costuras en la operativa
Los reembolsos, las reversiones y las disputas se asocian cada uno a una etapa concreta, y acertar con la etapa lo es todo. Cancela antes de la captura y anulas una autorización: nunca se movió dinero, no hay nada que devolver. Cancela después de la liquidación y emites un reembolso: un pago nuevo en sentido contrario, con su propio ciclo de vida. Un contracargo retrocede a través de la compensación para reclamar un importe ya liquidado. Trátalos como una «cancelación» indiferenciada y el ledger se desajusta; trátalos como operaciones sobre etapas distintas y cada caso tiene un movimiento correcto y auditable. El vocabulario —autorización, captura, compensación, liquidación, fecha valor— está recogido en /glossary.
La idea que merece la pena llevarse: un pago es una cadena de estados, no un evento. La autorización reserva, la captura reclama, la compensación acuerda, la liquidación mueve y el payout entrega; y un tramo cripto solo acopla una conversión al principio. El dinero es una promesa hasta la liquidación y un hecho después, y un negocio que lo contabiliza antes del hecho está contando dinero que aún no tiene. Sabe en qué estado está un pago y el resto de la operativa de pagos deja de ser un misterio.
¿Tienes un sistema que construir?
Cuéntanos el problema. Volveremos con una arquitectura y un plan.