¿Puede desaparecer un pago que ya estaba confirmado?

Una reorganización de la cadena descarta los bloques de una rama perdedora. Ocurre cuando la red decide que la rama buena de su historia reciente era otra, y una transacción que solo vivía en esa rama deja de estar en la cadena.

Nadie devolvió nada y nadie revirtió nada. Lo que desaparece es el registro: las monedas están donde diga la rama que ganó, que casi siempre significa que siguen en la billetera de quien pagó.

Para un comercio es el fallo de la cadena que merece entenderse. Ningún otro convierte un pedido ya entregado en un pedido sin pagar, así que el resto de la página va sobre esa decisión y no sobre el consenso.

Qué demuestra una confirmación está en la guía de confirmaciones. Por qué el listón cambia con la red y con el importe, en confirmaciones escalonadas. Aquí solo importa qué tiene que hacer tu sistema de pedidos.

¿Qué le hace una reorganización a un pago?

Le borra el registro, no el dinero.

Esta es la distinción que hace confusas las reorganizaciones. La billetera firmó una transacción, la transacción entró en un bloque y después la red eligió una historia que no contiene ese bloque. Desde el punto de vista de la cadena, ese pago no ha ocurrido nunca.

Casi siempre la transacción vuelve enseguida. Entra en un bloque uno o dos más tarde y el asunto se resuelve solo, porque era válida y la red no tiene ningún motivo para rechazarla. El caso peligroso es estrecho: el pago se cayó, tu procesador ya te había dicho que estaba confirmado y tú ya habías actuado.

¿Esto es un contracargo?

No, y la diferencia decide qué puedes hacer.

Un contracargo lo pone en marcha una persona. El titular pide a su emisor que dispute el cargo, hay reglas de la red de tarjetas, plazos y pruebas, y el caso puede perderse meses después de la venta. En una reorganización no hay nadie que reclame: la red elige entre dos versiones de su propia historia reciente y descarta la que pierde. Un pago en cadena que alcanza la finalidad exigida no se puede revertir por la vía del contracargo.

De ahí sale una forma distinta de trabajar. No hay expediente que preparar ni respuesta que enviar, y del riesgo de cobro que sigue en pie se ocupa el artículo de contracargos. Aquí queda una sola pregunta abierta: qué le pasa a tu saldo.

¿Puede caerse un pago que Paymos ya confirmó?

El bloque sí. El abono no.

Confirmar antes de la finalidad del protocolo es una decisión deliberada. Esperar la finalidad absoluta en todas las redes dejaría algunos pagos en una espera inservible para una tienda, así que el listón se fija por red y por importe. La consecuencia honesta es la que sigue: puede ocurrir —rara vez— que se confirme un pago cuyo bloque acabe descartado.

Lo que no ocurre es que esa decisión te llegue a ti. Cuando el bloque de un pago confirmado resulta estar fuera de la cadena, el abono del comercio se queda exactamente donde estaba. La regla está escrita al lado del asiento contable, en el propio código del libro mayor: al comercio no se le toca, su abono sobrevivió, no se revierte y no se duplica.

¿Quién asume esa diferencia?

Paymos, contra sus propias cuentas.

Merece la pena ser preciso con lo que eso significa. El procesador tomó una decisión de riesgo —confirmar a esta profundidad, en esta red, para este importe— para que la página de pago no dejara esperando a quien compra. Cuando la decisión sale mal, las monedas no están y algún saldo tiene que absorber el hueco. Dejarlo del lado del comercio significaría que tu exposición depende de un cálculo que no hiciste y que no puedes ver.

Así que el hueco se anota en las cuentas de la plataforma. En el libro mayor tiene nombre propio: pérdida por reorganización, con su asiento y su cuenta.

Es una política, no una ley de la naturaleza. La misma pregunta se le puede hacer a cualquier procesador: cuando confirmas antes de la finalidad y la cadena te lleva la contraria, ¿qué saldo se mueve? Quien nunca se lo haya planteado no tendrá respuesta. Quien sí, sabrá decirte el nombre de la cuenta.

¿Por qué no se borra la transferencia?

Porque borrarla es como nacen los abonos duplicados.

Cuando un bloque se descarta, el impulso es quitar el registro. El pago no ocurrió, así que fuera la fila. Aquí se hace lo contrario: la transferencia se queda, el camino de reorganización la marca como fantasma y no la borra nunca.

El motivo se ve cuando la transacción vuelve. Si el registro original ya no estuviera, la reinclusión llegaría como si fuera un pago nuevo y el comercio cobraría dos veces por una sola transferencia. Mantener la misma identidad hace que la vuelta se reconozca como el mismo pago que regresa y no como otro que llega. Dos registros para un pago están prohibidos de plano, y están prohibidos justo por esto.

¿Cuándo se da un bloque por perdido?

Solo cuando lo dice la finalidad del protocolo.

Las cadenas cambian de punta con normalidad. Un nodo puede ver un bloque en la cabeza y otro distinto un segundo después sin que nada vaya mal y sin que se pierda ninguna transacción. Tratar cada cambio de punta como una reorganización marcaría pagos fantasma sin parar, y en una semana nadie haría caso de esa marca.

Por eso hace falta una señal más fuerte que la punta. Una transferencia se marca como fantasma únicamente cuando la finalidad confirma que ese bloque no está en la cadena finalizada, el punto a partir del cual el propio protocolo da su historia por cerrada.

Por debajo de esa altura no hay conciliación automática. Si una reorganización llega ahí, el cursor de esa red se detiene en ese punto, porque una violación del protocolo no es un caso que deba resolverse solo.

¿Cómo te enteras de que ha pasado?

En los canales de pago, por webhook. payment_channel.deposit.reorged es uno de los tres eventos de depósito, junto a confirming y confirmed, y llega por la misma suscripción.

Trátalo como un aviso de operaciones, no como un apunte contable. Tu saldo no cambió, así que no hay nada que cuadrar en tus libros.

El evento te apunta a un pedido concreto. Ese pedido salió apoyado en una prueba que después desapareció, lo cual importa si es un envío físico que todavía puedes parar en el almacén, y importa mucho menos si era una descarga que el cliente ya tiene.

¿Y si la transacción vuelve a entrar?

La pérdida se revierte, y el saldo del comercio tampoco se mueve.

Una transferencia reincluida vuelve bajo su misma identidad. La anotación se deshace contra las mismas cuentas que la absorbieron: las monedas volvieron, la pérdida queda en cero y la comisión de esa factura se vuelve a reconocer. El saldo del comercio sigue quieto, porque nunca llegó a moverse.

Cobrar una vez y seguir cobrado una vez es el objetivo. A través de una caída y de una vuelta, eso es todo el diseño, y es también la razón por la que el mismo depósito conserva su identificador en lugar de aparecer otra vez como uno nuevo.

¿Qué tiene que cambiar en tu sistema de pedidos?

Menos de lo que parece. La trampa está en hacer de más.

Tu lado del pago ya tiene la forma que necesita. Un pedido está sin pagar, después confirmado, después entregado, y una reorganización no añade un cuarto estado a ese recorrido: tu saldo no se mueve y no hay nada que conciliar.

Algo sí puede añadir, si vendes caro y físico. Un motivo para dejar una ventana corta entre la confirmación y la salida del paquete, de modo que un aviso tenga dónde aterrizar. No es un cambio de arquitectura: es media hora de margen en el almacén.

Fuera de ese caso, la respuesta correcta es no hacer nada. Programar el tratamiento de las reorganizaciones en una tienda de descargas es trabajo que no se paga solo, y la pérdida de la que protege no es tuya.

¿Cómo se ensaya antes de que ocurra?

Simúlalo. El simulador de depósitos del sandbox acepta una etapa, y reorged es uno de los tres valores que admite, junto a confirming y confirmed.

Vale la pena hacerlo una vez. El motivo poco tiene que ver con las reorganizaciones: es la forma más barata de averiguar si tu manejador de webhooks sobrevive a un evento que no esperaba. La mayoría de las integraciones se escriben contra el caso en que todo sale bien y se encuentran con el primer evento raro en producción.

Este puedes encontrártelo un martes por la tarde, sin nada en juego. La referencia del simulador trae los parámetros exactos, y los eventos de webhook el resto del contrato.