Manejo de Reversos en terminales por integración COM

Un reverso es una transacción aprobada que se anula justo antes de entregar la respuesta en la terminal debido a un corte en la comunicación entre el servidor de NetPay y la terminal que provoca que exista incongruencia de estatus. Es decir, el servidor de NetPay logra aprobar la transacción, pero la terminal no logra enterarse de que la transacción aprobó por el corte de comunicación, por lo que la terminal devolverá un error de comunicación.

🚧
A nivel productivo, contarán con un portal web de NetPay que visualiza los estatus de las transacciones casi en tiempo real, sin embargo es muy importante siempre dar prioridad a lo que indica la terminal en pantalla y ticket impreso ya que las transacciones con tarjeta presente dependen mucho del hardware donde se realizó la operación. Esto conlleva a que el consumo de APIs / plataformas web de NetPay como Manager y otras alternativas ajenas a la terminal, pueden presentar incongruencias de estatus en reversos por la naturaleza de la situación que corta la comunicación de una transacción e impide que finalice con éxito.

¿Cuáles son las causas que provocan el reverso de una transacción en la terminal de NetPay?

A continuación, presentamos las formas en que puede generarse un problema de comunicación y posible reverso.

1.- Retiro de tarjeta durante el procesamiento de pago, en específico en la pantalla de "Esperando Autorización" que se presenta justo al ingresar el NIP.

2.- Por intermitencias e internet inestable.

3.- Escenarios aislados y poco comunes que interrumpan justo en el momento exacto del procesamiento de la transacción.

¿Cómo se deben manejar los reversos de las transacciones realizadas en la terminal de NetPay?

Actualmente NetPay, con la aplicación de Smart PinPad que se encarga del procesamiento de pagos con tarjeta presente en terminal, maneja los reversos de la siguiente forma:

1.- Si existen ligeras intermitencias en la conexión a internet o se retira la tarjeta durante el proceso de transacción, la Smart PinPad en su versión 2.6 de forma interna realiza 3 reintentos para reversar la transacción de forma automática, por lo cual la terminal seguirá marcando un error en pantalla, sin embargo en el portal web Manager aparecerá como estatus "Reversada".
Este proceso de reverso automático debería ser suficiente para validar que la transacción se cerró y no se aprobará ni cobrará al cliente por el corte de comunicación que interrumpió la transacción.

🚧
Los reversos automáticos se realizan internamente en NetPay, cuando ocurren ligeras intermitencias a internet y en movimientos de la tarjeta o retiro de la tarjeta durante el procesamiento de pago, que son las situaciones más comunes. La Smart PinPad 2.6 internamente realiza 3 reintentos para reversarla en ese mismo instante, sin embargo si fracasan estos 3 reintentos se debe seguir el punto #2.

2.- Si la conexión a internet es completamente inestable y el ancho de banda es menor a lo recomendado (3mb a 5mb de subida y bajada), los 3 reintentos de la Smart PinPad 2.6 podrían no ejecutarse con éxito, lo que conlleva a tener que manejar los reversos de forma manual, es decir, se tiene que realizar una siguiente transacción a partir de 1 centavo con cualquier tarjeta para que la anterior transacción con problema de comunicación sea reversada.

❗️
Para este segundo punto de reverso manual es muy importante manejarlo correctamente, ya que de no realizarse una siguiente transacción con cualquier tarjeta a partir de 1 centavo, puede no reversarse la transacción anterior con problema de comunicación y el cliente puede irse con el servicio o producto sin que se le cobre.

¿Cómo se puede identificar un posible reverso desde la terminal de NetPay?

Teniendo el contexto previo de los puntos anteriores mencionados, se anexa un ejemplo de cómo la Smart PinPad anuncia en pantalla este tipo de situaciones cuando se genera un corte en la comunicación entre el servidor de NetPay, que logra aprobar la transacción, pero la terminal no logra enterarse porque se retira la tarjeta antes de tiempo durante el proceso de pago o durante intermitencias en la conexión a internet que intervienen en el flujo de la transacción.

El ticket oficial de NetPay puede mostrar mensajes como "ERROR AL LEER LA TARJETA" o "ERROR DE CONEXIÓN", y en el JSON de respuesta que la terminal le entrega al punto de venta o aplicación del comercio que integra se presenta de la siguiente forma:

📘
Cambio de mensaje entre versiones
Anteriormente, con versiones previas de Smart PinPad, este escenario regresaba el mensaje "SIN COMUNICACIÓN". A partir de la Smart PinPad 2.6 + DLL 1.9.2, para este escenario de reverso el mensaje que se presenta es "Error al leer tarjeta", y la mayoría de los campos de la respuesta regresan vacíos o nulos, ya que la transacción no llegó a completar el procesamiento. No se descarta que "SIN COMUNICACIÓN" pueda seguir apareciendo en otros tipos de error ajenos a reversos.

{
  "data": {
    "affiliation": "9194",
    "amount": "0.00",
    "bankName": "",
    "bin": "",
    "cardType": "",
    "cardNumber": "",
    "cardTypeName": "",
    "cityName": "Guadalupe NUEVO LEON",
    "responseCode": "05",
    "folioNumber": "2-5650-1781118562363",
    "isReprint": false,
    "message": "Error al leer tarjeta",
    "moduleCharge": "0",
    "moduleLote": "2",
    "terminalId": "2841260371",
    "rePrintDate": "2.6.0.1.p.p_20260304",
    "rrnNumber": "",
    "storeId": "9194",
    "streetName": "AVE PABLO LIVAS 7200",
    "ticketDate": "JUN. 10, 26 13:10:16 ",
    "transType": "",
    "transactionId": null,
    "storeName": null,
    "reprintModule": null,
    "applicationLabel": null,
    "customerName": null,
    "preAuth": null,
    "transDate": null,
    "authCode": null,
    "tipLessAmount": null,
    "tipAmount": null,
    "aid": null,
    "arqc": null,
    "cardExpDate": null,
    "orderId": null,
    "promotion": null,
    "rePrintMark": null,
    "hexSign": null,
    "transactionCertificate": null,
    "preStatus": 0,
    "isQPS": 0,
    "hasPin": false,
    "cardOrigin": null
  },
  "idReport": -1,
  "applyCashback": false
}

📘
Este JSON corresponde a la respuesta inmediata del intento de venta, no a una reimpresión
Por eso el campo reprintModule viene null: aún no se ha consultado el estatus final de la transacción mediante una reimpresión por folio. Este es solo el momento en que se detecta el corte de comunicación; no confirma si el reverso ya se completó o sigue pendiente. Nótese también que idReport: -1 y campos como transactionId, orderId y rrnNumber vienen vacíos o nulos, reflejando que la transacción no llegó a generarse por completo del lado de la terminal.

Relación entre un reverso y la reimpresión por folio

El mensaje de error que aparece en pantalla al momento del corte solo indica que ocurrió un problema de comunicación, pero no indica si el reverso ya se completó o si sigue pendiente. Para confirmar el estatus real y definitivo de la transacción, es indispensable consultarla mediante una reimpresión por folio, validando el campo reprintModule:

Situación	Resultado esperado en `reprintModule`
Reverso automático completado con éxito (punto #1)	`RV` — Transacción reversada
Reintentos automáticos fallidos, reverso manual pendiente (punto #2)	`PRV` — Transacción pendiente de reverso

⚠️
No basta con ver el mensaje de error en pantalla para dar por cerrada una transacción
Debe confirmarse el estatus final mediante una reimpresión por folio. Si el resultado es PRV, es necesario ejecutar el reverso manual (venta de 1 centavo) descrito en el punto #2 para evitar cobrar al cliente por una transacción que en realidad no se completó.

🚧
Documentación relacionada sobre reimpresión por folio
Para conocer a detalle cómo consultar el estatus de un reverso mediante el campo reprintModule, consulte la documentación de reimpresión por folio según su modalidad de integración:

Reimpresión por folio en integración COM