Idempotencia y Consistencia: Por Qué tus Pagos No Pueden Duplicarse

WAU Marketing
hace unos segundos
5 min de lectura

La confiabilidad de tus pagos no es un supuesto: es una característica que se diseña. Si nadie la diseñó a propósito, lo que tienes no es un core confiable, es uno que todavía no ha fallado delante de ti.

Hay una creencia cómoda en muchas instituciones: "los pagos simplemente funcionan". Salen, llegan, se concilian. Hasta que un día un cliente reclama que le cobraron dos veces, o que su transferencia "se perdió" y reapareció horas después. Entonces queda claro que la confiabilidad nunca fue gratis. Detrás de cada pago que no se duplica hay dos disciplinas técnicas que casi nadie nombra en una junta de negocio, pero que definen si tu core es confiable o solo afortunado: la idempotencia y la consistencia transaccional.

El problema empieza con algo tan tonto como la red

La red es poco confiable, y eso no es opinión: es la premisa con la que se diseñan los sistemas de pago serios. El equipo de ingeniería de Stripe lo describe con tres escenarios de falla que cualquier integración enfrenta: la conexión inicial puede fallar; la llamada puede caerse a media operación, dejando el trabajo "en el limbo"; o la operación puede tener éxito en el servidor, pero la conexión se corta antes de avisarle al cliente, como explica Stripe en su artículo de ingeniería sobre idempotencia.

El tercer caso es el peligroso. Tu app de banca envía "cobra $5,000", el cobro sí ocurrió en el core, pero el cliente nunca recibió la confirmación. ¿Qué hace casi cualquier sistema bien intencionado? Reintenta. Y ahí nace el cargo doble. El problema, en palabras de Stripe, es que "el éxito de la operación es ambiguo desde la perspectiva del cliente, y este no sabe si reintentar es seguro".

Idempotencia: que reintentar sea seguro

La idempotencia es la propiedad que hace que repetir una operación produzca el mismo resultado que ejecutarla una sola vez. En pagos, esto se implementa con una llave de idempotencia (idempotency key): un identificador único que el cliente genera y envía con la solicitud, de modo que el servidor reconozca un reintento como lo que es —el mismo pago— y no como uno nuevo.

El mecanismo es elegante por lo simple. Stripe guarda el código de estado y el cuerpo de la primera respuesta para cada llave; cualquier solicitud posterior con la misma llave devuelve exactamente ese resultado, incluso si fue un error, según su referencia oficial de API. En esa misma documentación recomienda usar UUIDs v4 como llaves, fija una expiración de 24 horas, y —detalle crítico— la capa de idempotencia compara los parámetros entrantes contra los del request original y arroja error si no coinciden, para evitar que una llave se reutilice por accidente sobre un pago distinto.

Traducido al negocio: la llave de idempotencia es la diferencia entre "el cliente tocó pagar tres veces porque la app se trabó" y "se procesó un solo cobro". No es un lujo de ingeniería; es la condición mínima para que reintentar —algo que va a pasar— no le cueste dinero ni confianza a tu institución.

Consistencia: que el dato cuadre, siempre

La idempotencia evita el cargo doble. La consistencia transaccional resuelve un problema gemelo: que un pago quede a medias. Un movimiento de dinero casi nunca es una sola escritura; es varias —debitar una cuenta, acreditar otra, registrar la comisión, notificar—. Si el sistema se cae justo en medio, no puedes quedarte con el débito hecho y el crédito pendiente. O todo, o nada.

En un core monolítico clásico, esto lo resolvía la base de datos con transacciones ACID. Pero las arquitecturas modernas son distribuidas: varios servicios, varias bases. Ahí entra el patrón saga, que el arquitecto Chris Richardson define como "una secuencia de transacciones locales", donde cada una actualiza su base y dispara la siguiente; y si una falla por una regla de negocio, "la saga ejecuta una serie de transacciones compensatorias que deshacen los cambios" de las anteriores, según microservices.io. Es decir: si el crédito falla, se compensa el débito. El sistema vuelve a un estado coherente en lugar de quedar partido a la mitad.

El "exactly-once" que casi nadie tiene gratis

Aquí conviene una verdad incómoda que la industria suele maquillar: el "exactly-once" (procesar cada mensaje exactamente una vez) es extremadamente difícil y caro de garantizar en sistemas distribuidos. La mayoría de los buses de mensajes —Kafka, RabbitMQ, SQS— entregan al menos una vez, lo que significa que tu sistema va a recibir mensajes duplicados. El "exactly-once" real no viene de la infraestructura; se construye haciendo idempotentes a los consumidores. Sin esa disciplina, una saga que reintenta "cobrará una tarjeta dos veces, enviará un paquete dos veces y devolverá dinero a quien ya recibió su reembolso". La confiabilidad, otra vez, es algo que se diseña.

Por qué esto se volvió urgente: el pago instantáneo no perdona

Antes, un cargo duplicado se atrapaba en la conciliación nocturna y se revertía sin que el cliente se enterara. Esa red de seguridad desapareció con los pagos instantáneos. En México, el SPEI permite "realizar en cuestión de segundos pagos electrónicos" y, por banca móvil, opera "las 24 horas, todos los días del año", según el Banco de México. Y lo decisivo: bajo el marco de la Circular 14/2017, una vez que el pago se acepta en el punto de autorización de Banxico, es irreversible.

Brasil va en la misma dirección con Pix, donde una transferencia es prácticamente irreversible una vez confirmada; el Banco Central tuvo que crear un Mecanismo Especial de Devolución (MED) que permite a las víctimas de fraude reclamar hasta 80 días después, justamente porque el sistema no permite "deshacer" un pago como antes, según reportó CommerceGate. Cuando el dinero se mueve en segundos y no se puede revertir, un cargo doble ya no es un asiento que se corrige mañana: es plata real que salió y que tu institución tiene que perseguir.

No es teoría: a los bancos les pasa

Esto no es un escenario hipotético. En marzo de 2022, TSB —uno de los grandes bancos del Reino Unido— sufrió una falla técnica que duplicó pagos salientes de miles de clientes, dejando a algunos en sobregiro de la noche a la mañana; el banco tuvo que revertir automáticamente todos los cargos duplicados al día siguiente y absorber los costos, según reportó MoneySavingExpert. Un banco con cinco millones de clientes, duplicando pagos por un fallo de proceso. La idempotencia y la consistencia no son paranoia de ingenieros: son lo que separa "incidente menor" de "portada de prensa y miles de clientes furiosos".

Cómo lo vemos en WAU

En WAU tratamos la confiabilidad como lo que es: una característica que se diseña en el core desde el primer día, no un supuesto que se reza. Construimos pagos idempotentes —con llaves que vuelven seguro cualquier reintento—, transacciones consistentes —donde un movimiento es todo o nada, con compensación cuando algo falla— y consumidores que toleran duplicados sin cobrar dos veces. Esto se conecta directo con dos cosas de las que hablamos seguido en este blog: la conciliación en tiempo real, que deja de ser una red de rescate para volverse un control en vivo, y los pagos instantáneos, donde no hay margen para deshacer.

Si tus pagos "simplemente funcionan" pero nadie te puede explicar qué pasa cuando se cae la red a media transacción, no tienes un core confiable: tienes uno que aún no te ha fallado en público. Te ayudamos a que sí lo sea, por diseño. 👉 Agenda una conversación con nuestro equipo.