La recarga que nadie sabe si se hizo

Un cliente pide una recarga de tiempo aire en una tienda. El sistema le descuenta el saldo a la tienda y manda la petición a la marca. La marca no contesta.

¿Le llegó la recarga al teléfono? En ese momento nadie lo sabe. Y con la marca, nadie lo puede preguntar: la respuesta llega mañana, en la conciliación.

Durante años trabajé en una plataforma de recargas electrónicas. Las peticiones entraban desde terminales, aplicaciones y puntos de venta, y llegaban a la marca después de dos, tres y hasta cuatro saltos, cada uno con su propio protocolo y su propio tiempo de espera. Pasó de todo: recargas dobles, cobros sin recarga. Esta nota es sobre por qué, y sobre el estado que casi ningún sistema diseña desde el principio.

Las cifras de los ejemplos son ilustrativas, calculadas para mostrar el mecanismo. No son las de aquella plataforma.

Hay tres respuestas, no dos

Un sistema que mueve dinero suele pensarse con dos resultados: la operación se hizo, o no se hizo. En la red hay un tercero: no sé. La petición salió y la respuesta nunca llegó. Pudo perderse la petición, y la recarga no existe. O pudo perderse la respuesta, y la recarga ya está en el teléfono.

Desde este lado del cable, los dos casos se ven idénticos.

Cada salto es un lugar más donde una respuesta se puede perder. Si cada uno pierde una de cada dos mil, con un salto son 50 recargas en duda de cada cien mil; con cuatro saltos son 200. Todos los días. No es un error que se corrija una vez: es una probabilidad que se administra siempre.

Y el caso más difícil está al final de la cadena: la marca no contesta, o su respuesta se pierde, pero el sistema interno ya debitó.

Cada quien decide qué hacer con el “no sé”

Cuando la pantalla se queda pensando, alguien decide, y cada decisión es una apuesta con dinero ajeno:

• El cajero vuelve a apretar el botón. Si la primera sí se aplicó, el cliente recibe dos recargas y la tienda paga dos.
• La terminal reintenta sola. Lo mismo, sin que nadie se entere.
• La plataforma reintenta hacia la marca. Lo mismo, un salto más adentro.
• La plataforma da la operación por fallida y le devuelve el saldo a la tienda. Si la marca sí la aplicó, la plataforma regaló una recarga.
• La plataforma la da por buena. Si la marca no la aplicó, el cliente pagó y no recibió nada, y va a reclamar.

Ninguna es correcta. Todas son apuestas mientras no se sepa qué pasó.

Un folio que viaja de punta a punta

La primera defensa es que cada recarga tenga un identificador único desde que nace, en la terminal o en la aplicación, y que ese mismo identificador viaje en cada salto. Nosotros lo llamábamos externalID.

Con eso, un reintento deja de ser una recarga nueva. Si una petición llega con un externalID que ya se procesó, el sistema no la vuelve a ejecutar: contesta con el resultado de la primera. El cajero puede apretar diez veces y la tienda paga una.

Y permite preguntar. Hacia atrás, de la plataforma hacia los puntos de venta, sí se podía: la terminal podía consultar qué pasó con su externalID en vez de mandar otra recarga.

Lo que no se puede preguntar

Con las marcas no. No había consulta de estado. Lo único era la conciliación en bloque: un archivo cada 24 horas con lo que la marca dice que aplicó, contra lo que la plataforma dice que mandó.

Eso significa que una recarga en duda se queda en duda hasta el final del día, o hasta el día siguiente. Mientras tanto, el saldo de la tienda ya se debitó, el cliente puede estar reclamando, y la plataforma no tiene con qué contestarle.

Y la conciliación, cuando llega, es una tortura: cruzar archivos, encontrar las diferencias, decidir cada una, y a veces resolverlas a mano.

Por qué no reversar

La salida que parece obvia es el reverso: ante la duda, cancelar la operación con la marca y devolver el dinero. En este negocio los reversos no son deseables: matan el negocio.

El margen de una recarga es muy chico. Cada reverso cuesta trabajo, tiempo y discusión con la marca, y se come la ganancia de muchas ventas. Y si se reversa algo que sí se aplicó, la pérdida es completa.

Lo que haría desde el principio

Diseñar el “no sé” como un estado de verdad. En la base de datos, en la pantalla del cajero y en los reportes: en proceso, no fallida ni exitosa. Que la pantalla diga “en proceso, no la repitas” vale más que cualquier validación posterior.

El externalID desde el origen, obligatorio, y respetado en cada salto. Una petición sin identificador no entra. Un identificador repetido devuelve el resultado guardado, nunca ejecuta otra vez.

Que ningún humano reintente a ciegas. El botón de reintentar consulta el estado primero. Si no hay respuesta, muestra que está en proceso; no manda otra.

Tiempos de espera escalonados. Cada salto tiene que esperar más que el siguiente. Si la terminal se rinde antes que la plataforma, la terminal reintenta mientras la primera petición sigue viva adentro.

Conciliación automática desde el primer día. No como una hoja de cálculo que alguien arma cuando ya hay problemas, sino como parte del sistema: el archivo de la marca entra, se cruza solo, y a una persona sólo le llegan las diferencias.

Medir las dudas. Cuántas recargas quedan en proceso por marca, por hora y por salto. Cuando ese número sube, algo se rompió, y es mejor saberlo hoy que en la conciliación de mañana.

Ninguna de estas medidas elimina el “no sé”. Lo que hacen es que deje de ser una apuesta: el dinero queda en un estado que todos ven, nadie lo duplica por desesperación, y la conciliación sólo tiene que resolver lo que de verdad no se podía saber. Mitigarlo fue mucho trabajo de programación y de infraestructura. No había atajo.

Israel Negrete Lepe es ingeniero en electrónica. Veinticinco años construyendo sistemas que llegan a producción: telemetría, rastreo vehicular, videovigilancia municipal, control de activos por RFID y plataformas transaccionales.