Cuando una empresa te reclama una venta que supuestamente autorizó y nunca recibió, la discusión no debería comenzar con “esa venta no existió”, sino con otra pregunta:
¿Dónde debería quedar registrada si realmente hubiera ocurrido?
Las transacciones electrónicas dejan rastros en varios sistemas: la tienda, el procesador de pagos, el banco, los equipos de interconexión y los archivos de liquidación. Si una operación no aparece en el lugar donde obligatoriamente debería estar, esa ausencia puede ser tan importante como una operación fraudulenta visible.
Pero una ausencia no se demuestra con una captura de pantalla. Se demuestra revisando el conjunto correcto de registros.
Primero: define qué están reclamando exactamente
Antes de revisar servidores, delimita la operación. Pide o identifica, según lo que tengas disponible:
Empieza por fijar la operación con precisión: fecha y hora aproximada, importe, moneda, identificador y número de autorización si existe. Añade la terminal o el comercio, la referencia de liquidación y el archivo de remesa en el que debió incluirse. Esos identificadores permiten que banco, procesador y vendedor busquen el mismo evento en lugar de responder sobre una venta genérica.
No compartas números completos de tarjeta, tokens ni credenciales para documentar el reclamo. Una referencia enmascarada puede acreditar el medio utilizado sin crear una segunda exposición. La comprobación técnica se hace con identificadores y registros, no enseñando a desconocidos toda la información financiera.
Después relaciona esos datos con la experiencia del cliente: qué producto esperaba, qué confirmación recibió y si llegó algo a su dirección. Una operación puede existir en banca y ser falsa en la entrega; otra puede ser un cargo legítimo cuyo concepto no reconoce el comprador. La pregunta no es únicamente si hubo dinero, sino qué se vendió, quién lo cobró y qué se entregó.
En un caso real de pagos electrónicos, una cadena comercial reclamó ventas que decía haber realizado y que nunca se le habían pagado. La afirmación parecía fácil de comprobar: bastaba seguir el recorrido que toda operación debería dejar. Sin embargo, las transacciones reclamadas no aparecían en el procesador ni en los equipos de interconexión. Tampoco llegaron al mecanismo por el cual debían liquidarse.
La pieza decisiva no fue una captura del reclamo, sino el archivo de remesa producido por la propia tienda. Esas operaciones tampoco estaban ahí. La ausencia coincidente cambió la pregunta: ya no era únicamente por qué alguien no había pagado, sino cómo podía afirmarse que la tienda había transmitido unas ventas que su propio mecanismo nunca reportó.
Para un comerciante, la enseñanza es conservar remesas completas y referencias, no solo estados de cuenta. Para el abogado, es separar ausencia de transmisión, rechazo y fraude. El análisis pericial puede demostrar inconsistencias entre sistemas; no atribuye automáticamente quién las originó ni descarta que exista una explicación técnica adicional.
Sin esos datos, buscar una venta es como buscar un tornillo en una caja llena de tornillos sin saber cuál necesitas.
Después: conserva las fuentes originales
No edites la base de datos para comprobar si la operación aparece. No ejecutes consultas que puedan modificarla. No exportes únicamente la página que te interesa y borres el resto.
Trabaja con copias íntegras y, cuando el caso lo requiera, con copias forenses, valores hash y documentación de quién extrajo cada elemento.
Reúne, según el tipo de operación:
- Registros del comercio.
- Base de datos del procesador.
- Archivos de liquidación o remesas.
- Bitácoras de equipos de interconexión.
- Reportes bancarios.
- Correos de notificación.
- Registros de errores y rechazos.
- Historial de cambios en el sistema de ventas.
Una captura de la pantalla actual puede ayudar a entender la operación, pero no reemplaza los archivos originales.
Cruza los sistemas, no las versiones
Una reclamación puede parecer sólida porque la otra parte presenta validaciones internas. El problema es que esas validaciones pueden ser generadas por la propia parte que reclama.
El contraste debe responder, por separado:
- ¿La operación aparece en el sistema del comercio?
- ¿Llegó al procesador de pagos?
- ¿Existe en los equipos de interconexión?
- ¿Fue incluida en el archivo de liquidación?
- ¿El banco la recibió o la rechazó?
Si una tienda asegura que una venta fue autorizada, pero no existe en el procesador, no aparece en los equipos de interconexión y tampoco fue incluida en los archivos que la propia tienda generó, la afirmación necesita una explicación técnica.
No es lo mismo “fue rechazada” que “nunca llegó”. Son hechos diferentes y dejan huellas diferentes.
La ausencia también se investiga, pero con cuidado
Demostrar que algo no ocurrió puede ser más difícil que demostrar que sí ocurrió.
Antes de concluir que una venta no existió, descarta explicaciones alternativas:
- Diferencias de zona horaria.
- Operaciones duplicadas.
- Reversiones o cancelaciones.
- Filtros de fecha incorrectos.
- Identificadores mal escritos.
- Cambios de adquirente o procesador.
- Archivos incompletos.
- Operaciones reportadas con otro identificador.
La conclusión no debe ser “no aparece en una consulta, por lo tanto es fraude”. Debe ser “la búsqueda se realizó en las fuentes donde la operación tendría que haber dejado rastro y no se encontró evidencia compatible con su presencia”.
Qué puede aportar el contexto
Los sistemas no solamente muestran operaciones. También muestran condiciones de funcionamiento.
Puede ser relevante revisar:
- Cambios recientes en el comercio.
- Interrupciones de conexión.
- Actualizaciones del sistema de punto de venta.
- Incidencias reportadas antes del reclamo.
- Reglas de agrupamiento de operaciones.
- Procesos manuales de carga.
- Modificaciones en archivos de remesa.
Un archivo puede explicar por sí solo qué salió mal. En otros casos, demuestra que la operación reclamada nunca fue reportada por el mecanismo contractual.
Lo que no debes hacer
- No fabriques una consulta que produzca el resultado esperado.
- No presentes solamente recortes de pantalla.
- No alteres archivos para “probar” una hipótesis.
- No acuses a un empleado antes de revisar la infraestructura.
- No confundas un error de conciliación con un fraude intencional.
- No ignores la posibilidad de que la otra parte esté equivocada de buena fe.
El objetivo no es encontrar un culpable. Es determinar qué ocurrió técnicamente, incluso si la respuesta contradice la sospecha inicial.
El detalle que suele faltar: conciliar la operación
Una venta inexistente u operación simulada debe analizarse desde pedido, pago y entrega. Que el comercio muestre una venta no basta si el procesador no tiene referencia compatible; que el banco registre un cargo tampoco identifica quién lo generó. Para un comerciante, la prioridad es evitar otro cargo; para su abogado, conservar identificadores y la relación entre sistemas sin difundir datos de otros clientes.
