El reenviador de SMS vio una transferencia. ¿Se puede cerrar la orden?

Que el reenviador de SMS figure «en línea» solo significa que algún componente del sistema respondió hace poco. De ahí no se deduce que reciba las notificaciones bancarias, extraiga bien los importes y transmita todos los eventos. Para un operador P2P la diferencia se vuelve dinero: un mensaje perdido retrasa el reconocimiento del pago y uno mal interpretado puede confirmar dinero que no existe.

Aquí llamamos reenviador a la herramienta que transmite notificaciones autorizadas sobre operaciones desde un dispositivo u otra fuente acordada hacia el sistema de procesamiento. Ayuda a detectar antes un posible ingreso. El rol contractual del receptor del dinero, la autorización del banco para ese modelo de trabajo y el fundamento del reconocimiento financiero se determinan por separado. Instalar la aplicación no cambia ninguna de estas condiciones.

Entre el banco y la orden hay varios eventos independientes

Primero, el banco registra la operación. Después genera la notificación y la entrega al dispositivo. El sistema operativo pone el mensaje a disposición de la aplicación dentro de los permisos otorgados. La aplicación extrae los campos necesarios, guarda el evento, lo envía al servidor y el servidor confirma la recepción. Solo entonces el algoritmo busca la orden correspondiente y evalúa las pruebas.

Cualquier tramo puede retrasarse o completarse por separado del siguiente. El banco acreditó el dinero, pero la notificación aún no llegó. El dispositivo recibió el mensaje, pero perdió la red. El servidor guardó el evento, pero la respuesta no llegó y la aplicación repitió el envío. El sistema emparejó la notificación con una orden, pero después el extracto bancario mostró otro importe. Estas situaciones exigen acciones distintas, aunque en la pantalla del cliente todas parezcan «pago atascado».

Por eso, para cada evento se guardan la hora de la operación, si está disponible de forma fiable, la hora de recepción en el dispositivo y la hora de recepción en el servidor. La hora de análisis y de emparejamiento puede registrarse aparte. Si se mezclan en una sola marca, es imposible saber si lo que frena es el banco, el dispositivo, la red o la propia cola de procesamiento.

Ante todo, acordemos qué datos hacen falta realmente

Para localizar un ingreso suelen ser útiles el importe, la moneda, un identificador de cuenta enmascarado, la referencia bancaria, la hora disponible y el tipo de evento. El conjunto concreto depende de la fuente. El archivo completo de SMS, las conversaciones personales, los saldos de otras cuentas y los códigos de acceso no son necesarios para cerrar una orden de pago concreta.

Los permisos los otorga el titular del dispositivo y de los datos para una finalidad y un destinatario concretos. El acceso a las notificaciones no debe interpretarse como consentimiento para transmitir todo el contenido del teléfono. Google Play restringe por separado el uso de SMS y de registros de llamadas; disponer de un medio técnico para leerlos no significa que distribuir o usar la aplicación sea admisible. Los requisitos aplicables de la plataforma y del banco se verifican antes del lanzamiento.

Los mensajes de autenticación, los códigos de un solo uso y las solicitudes de confirmación de acciones quedan excluidos de este canal. El filtrado debe impedir la transmisión innecesaria, no intentar borrar el secreto cuando ya llegó al servidor. Si no es posible separar con fiabilidad las notificaciones admisibles, esa fuente no sirve. Un acceso más amplio no es un precio razonable por la comodidad de la conciliación.

El parser puede equivocarse incluso con un mensaje auténtico

Una notificación de ejemplo contiene un abono de 12 000 y un nuevo saldo de 524 000. Tras un cambio en la plantilla del banco, extraer el primer importe que coincida empieza a devolver el saldo de la cuenta en lugar del importe de la operación. El mensaje es auténtico, el remitente es el habitual, la conexión está protegida, pero el resultado del procesamiento es financieramente incorrecto.

Por eso la versión de la plantilla y del parser forma parte de la traza probatoria. Un formato desconocido se envía a revisión en lugar de recibir un resultado seguro por una coincidencia aproximada. El protocolo debe distinguir abono, cargo, anulación y mensaje informativo. No se puede convertir cada número positivo en un nuevo ingreso de fondos.

La combinación «importe más hora más cercana» tampoco basta si hay dos órdenes abiertas de 12 000 al mismo tiempo. Los rasgos adicionales se usan solo en la medida en que la fuente realmente los transmite. Si falta la referencia necesaria, el sistema reconoce la ambigüedad. No la inventa a partir del número de orden para completar el emparejamiento.

La entrega repetida debe ser aburrida

Supongamos que el servidor guardó la notificación, pero el dispositivo no recibió la confirmación. El reenvío debe devolver un enlace al evento ya aceptado, sin crear un segundo registro monetario. Un identificador estable del mensaje y el estado de entrega guardado ayudan a distinguir una repetición de un evento nuevo. Pero que dos notificaciones tengan el mismo texto no prueba que la transferencia real haya sido solo una.

Cuando aparecen los datos del banco, las observaciones se agrupan en torno al ingreso real. Un SMS, un push y una línea del extracto pueden referirse a la misma operación. A la inversa, dos referencias bancarias distintas por el mismo importe pueden confirmar dos pagos. Por eso, la deduplicación del canal de entrega y la deduplicación de los ingresos de dinero resuelven tareas diferentes.

Cuando se restablece la conexión, la cola se envía de forma controlada y conservando las horas originales. Los mensajes antiguos no deben parecer pagos recientes solo porque el servidor los recibió ahora. Algunas de las órdenes vinculadas pueden haber vencido o haber pasado a revisión manual; su tratamiento debe tener en cuenta el estado actual y el historial de los datos de pago entregados.

«El dispositivo está vivo» y «la fuente funciona» se verifican por separado

El panel operativo puede mostrar la última conexión, el estado de la fuente autorizada, la antigüedad del evento sin enviar más viejo, el número de entregas sin confirmar y la última conciliación exitosa. La ausencia de notificaciones puede ser normal cuando no hay operaciones. Pero si el banco muestra ingresos y el canal está en silencio, ya hay una discrepancia observable.

Android documenta los estados de conexión y desconexión del listener de notificaciones, y los modos de ahorro de energía pueden aplazar el trabajo de red en segundo plano. Estas propiedades deben tenerse en cuenta en las pruebas. No justifican ampliar permisos a escondidas ni eludir las protecciones del dispositivo. Una arquitectura operativa prevé la detección de fallas, una escalada clara y una verificación alternativa y autorizada de los ingresos.

Si se pierde una fuente fiable, el operador puede detener las nuevas asignaciones a la ruta afectada y mantener el procesamiento de las instrucciones ya entregadas. Los clientes existentes todavía pueden transferir dinero. Apagar el canal sin una lista de órdenes abiertas dejaría ingresos fuera de observación justo en el momento de máxima incertidumbre.

Medimos el resultado contra el banco, no por el número de mensajes

Imaginemos un día con 100 ingresos bancarios confirmados. El reenviador transmitió a tiempo las notificaciones de 95, otras tres con retraso, y omitió dos. Además, ocho eventos llegaron repetidos. El servidor recibió 106 mensajes: 98 observaciones únicas más ocho repeticiones.

El indicador «106 eventos por 100 pagos» no dice nada sobre la calidad. La cobertura de detección en este ejemplo es del 98%, y la puntualidad respecto de todos los ingresos, del 95%. Aparte se cuentan los errores de emparejamiento, la antigüedad de las excepciones y la proporción de operaciones encontradas solo en la conciliación. Sin un conjunto bancario independiente, los mensajes perdidos ni siquiera entran en el denominador y el sistema parece mejor de lo que funciona.

El resultado final del reenviador es una observación verificable, apta para una decisión posterior. Si el contrato admite un reconocimiento acelerado con una señal más débil, se trata de un riesgo aparte y asumido conscientemente, con límites, un responsable y una conciliación posterior. Esa señal no puede llamarse confirmación bancaria definitiva. Una buena automatización acorta el tiempo de búsqueda del dinero y conserva la capacidad de demostrar qué dinero se recibió realmente.