Toda operación que depende de un tercero (un banco, un proveedor de servicios, una pasarela de pago) enfrenta tarde o temprano el mismo problema incómodo: una transacción que quedó en el limbo. La enviaste, pero no recibiste confirmación clara de si se completó o no. ¿Se hizo? ¿No se hizo? No sabes. Y esa incertidumbre es peligrosa, porque las dos reacciones intuitivas son malas.
Reenviar a ciegas puede duplicar: si la operación sí se había completado, ahora la hiciste dos veces. Ignorar puede dejar un hueco: si no se había completado, quedó algo sin hacer y un saldo descuadrado. La forma correcta de manejar estas operaciones en estado incierto no es adivinar, es conciliar: averiguar qué pasó de verdad antes de actuar.
Por qué quedan operaciones en el limbo
El limbo aparece cuando se rompe la comunicación en el momento equivocado. Envías una instrucción a un tercero, el tercero quizá la procesó, pero la respuesta que te confirmaría no llegó: se cayó la conexión, hubo un timeout, el sistema del otro lado tardó demasiado. Tu sistema se queda sin saber el desenlace.
Esto no es un caso raro ni un defecto evitable: es una realidad de cualquier integración con terceros. Las conexiones fallan, las respuestas se pierden, los sistemas se caen a mitad de una operación. Lo que distingue a un manejo robusto no es evitar el limbo (no se puede del todo), sino tener un proceso claro para resolverlo cuando ocurre.
Por qué reenviar a ciegas es peligroso
La tentación más fuerte es reenviar: "no sé si se hizo, por si acaso lo hago otra vez". El problema es que si el tercero sí completó la operación original, el reenvío la duplica. En operaciones de dinero, duplicar es caro y difícil de revertir: pagaste dos veces, cargaste dos veces, enviaste dos veces.
Y aquí hay un detalle técnico importante: muchos servicios de terceros no garantizan que puedas repetir una operación sin efecto (lo que se llama idempotencia). Es decir, si mandas la misma operación dos veces, la hacen dos veces, no la reconocen como repetida. Por eso no puedes confiar en que el tercero "se dará cuenta" de que es un reenvío. La protección contra la duplicación tiene que estar de tu lado.
La respuesta correcta: conciliar contra la fuente
En lugar de adivinar, la operación en limbo se resuelve preguntándole a la fuente qué pasó realmente. Casi todos los terceros ofrecen una forma de consultar el estado de las operaciones: un reporte, una consulta de "¿qué operaciones registraste de mi parte?". Esa consulta es la que te saca del limbo.
El flujo sano:
- Marca la operación como incierta, no como exitosa ni fallida. No la trates como ninguna de las dos hasta saber.
- No reenvíes automáticamente. Una operación incierta se congela, no se repite a ciegas.
- Consulta a la fuente qué pasó de verdad con esa operación específica.
- Resuelve según la realidad: si el tercero la completó, la marcas como exitosa (sin reenviar). Si no la completó, ahí sí puedes reintentarla con seguridad.
La conciliación contra la fuente es lo que convierte una incertidumbre peligrosa en un hecho conocido sobre el que puedes actuar sin riesgo.
La protección de fondo contra duplicados
Además de conciliar, un sistema robusto se protege de la duplicación desde el diseño. Algunas defensas típicas:
- Identificadores únicos por operación: cada operación lleva un identificador propio, de modo que si por error se intenta procesar dos veces, el sistema detecta que es la misma y no la duplica.
- Bloqueos temporales: evitar que la misma operación (mismo destino, mismo monto, en una ventana corta de tiempo) se dispare dos veces seguidas por accidente.
- Estados que actúan como candado: una operación "en proceso" bloquea que otra igual arranque hasta resolverse.
Estas protecciones, combinadas con la conciliación, cierran el problema por los dos lados: previenen la mayoría de las duplicaciones, y para las operaciones que aun así quedan inciertas, dan un camino para resolverlas sin adivinar.
Lo que te llevas
Las operaciones que dependen de terceros quedan a veces en el limbo: enviadas pero sin confirmación de si se completaron. Reenviar a ciegas puede duplicar (caro, porque muchos terceros no reconocen los reenvíos como repetidos) e ignorar puede dejar huecos. La respuesta correcta no es adivinar sino conciliar: marcar la operación como incierta, no reenviarla automáticamente, consultar a la fuente qué pasó de verdad, y resolver según la realidad. A eso se suman protecciones de diseño (identificadores únicos, bloqueos, estados candado) que previenen duplicaciones desde el inicio. El limbo no se puede evitar del todo cuando dependes de terceros, pero sí se puede resolver con un proceso, en lugar de con una apuesta.
En Vreo, la app maneja las operaciones inciertas conciliándolas contra la fuente antes de actuar, con protecciones contra duplicados, para que nunca se reenvíe a ciegas ni se pierda una operación. Si quieres ver cómo se aplica a tu operación, platiquémoslo.