😀 Al recargar y abonar para el usuario, lo más peligroso no es no poner un concepto, sino tratar ese concepto como si fuera un documento de identidad.
En la guía de escaneo de recarga Moonlight de @Dusk , identifiqué dos frases casi consecutivas.
El documento devuelve el memo en hexadecimal y lo clasifica como “datos de ruta no confiables” que requieren verificación previa del formato.
La advertencia inmediatamente siguiente es aún más directa: nunca uses el memo como una clave idempotente. Lo que de verdad debe ser único es el ID de transacción de Dusk.
Esa diferencia determina qué considera como un hecho el sistema de abono. El memo solo le dice al sistema pistas sobre “a quién podría corresponder”. El ID de transacción es lo que puede responder “si este dinero ya se procesó”.
Si la plataforma mezcla ambos, el marcador conveniente del frente (interfaz) puede malinterpretarse como el libro contable del backend.
El peor escenario es que dos recargas incluyan el mismo memo, o un memo que esté ausente o con formato anómalo. Si el sistema deduplica según el memo, podría omitirse un abono; si en cambio lo atribuye directamente, podría empujar la solicitud anómala a la cuenta equivocada. El usuario verá que la recarga tarda mucho en acreditarse; el equipo de operaciones, en cambio, tendrá que reconciliar repetidamente entre fondos, registros y clientes.
Esto no es un problema del diseño del memo de $DUSK ; el problema es si el integrador quiere o no admitir que la información de enrutamiento, por naturaleza, necesita validación. La documentación de @Dusk ya marca el rumbo: los metadatos desconocidos o inválidos deben pasar a una revisión manual, no a ser descartados en silencio.
Lo que realmente vale la pena comprobar es si el partner de integración incorpora esa regla al producto y hace que el usuario vea que está pasando por una revisión manual. #dusk