FINORA Pago · Conceptos

Aprobado, en duda y rechazado: los veredictos

ImplementadoImplementado

Un cobro siempre termina en un veredicto. Tu caja decide qué hacer con la venta mirando solo ese veredicto: si se entrega la mercancía, si se ofrece otro medio o si hay que esperar. Equivocarse aquí es caro, y casi siempre por el mismo motivo: confundir «no sé» con «no».

Los estados de un cobro

stateDiagram-v2
    [*] --> EN_CURSO
    EN_CURSO --> RECHAZO_PARCIAL: el banco rechazó un intento
    RECHAZO_PARCIAL --> EN_CURSO: el cliente reintenta
    EN_CURSO --> APROBADA
    EN_CURSO --> RECHAZADA
    EN_CURSO --> EN_DUDA: sin respuesta del banco
    EN_CURSO --> CANCELADA
    EN_CURSO --> EXPIRADA: venció el plazo
    RECHAZO_PARCIAL --> RECHAZADA: el cliente desiste
    APROBADA --> [*]
    RECHAZADA --> [*]
    EN_DUDA --> [*]
    CANCELADA --> [*]
    EXPIRADA --> [*]

Estado	¿Es final?	Qué pasó	Qué hace tu caja
`EN_CURSO`	No	El cliente está eligiendo, tecleando o pagando en el terminal	Esperar
`RECHAZO_PARCIAL`	No	El banco rechazó un intento (por ejemplo, fondos insuficientes), pero el cliente puede intentarlo otra vez o elegir otro medio	Mostrar «esperando reintento» y seguir esperando. No cierres la venta
`APROBADA`	Sí	El banco aprobó	Entregar e imprimir. Guarda la referencia del banco
`RECHAZADA`	Sí	El banco no aprobó, o el cliente desistió después de un rechazo. No se movió dinero	No entregar; ofrecer otro medio
`EN_DUDA`	Sí	Se envió el cobro y no llegó la respuesta del banco	No entregar y no volver a cobrar. Esperar la aclaración
`CANCELADA`	Sí	Lo canceló el cajero, el cliente o tu caja	No entregar
`EXPIRADA`	Sí	Venció el plazo sin que el cliente terminara	No entregar; si el cliente sigue ahí, crea un cobro nuevo

Junto al estado viene un código: el código de respuesta del banco (00 aprobada, 51 fondos insuficientes, 05 no honrar…) o un motivo técnico de FINORA, como CANCELADA_POR_CLIENTE o MERCHANT_INALCANZABLE. La lista está en la referencia de la API local.

«En duda» no es un rechazo

Este es el error más caro de una integración de caja, así que merece su propia sección.

Imagina la escena. El cliente pasó la tarjeta, escribió su clave y el terminal envió el cobro al banco. En ese momento se cae la conexión. El banco pudo haber aprobado: quizá el dinero ya salió de la cuenta del cliente, pero la respuesta nunca llegó.

Si tu caja lo trata como rechazo y el cliente se va sin la mercancía, el cliente queda con el cargo hecho y sin producto. El reclamo llega días después.
Si tu caja vuelve a cobrar, el cliente puede terminar pagando dos veces.

Por eso EN_DUDA es un estado aparte, con su propia regla: no entregues, no reintentes a ciegas, espera. FINORA Merchant consulta al banco y resuelve la duda en minutos; el cobro termina como aprobado o rechazado. Mientras tanto, la pantalla del cliente dice exactamente eso: «Aún no tenemos la respuesta del banco. No pagues de nuevo».

El rechazo con segunda oportunidad

Desde la versión 1.3 de FINORA Pago, un rechazo del banco no cierra el cobro de inmediato. Si el cliente tenía la cuenta equivocada o tecleó mal su clave, la ventana le ofrece Intentar de nuevo, Otro medio o Cancelar. Mientras decide, el cobro está en RECHAZO_PARCIAL.

Para tu caja, la consecuencia es sencilla:

Si esperas el veredicto en la misma llamada ("esperar": true), no notas nada: la respuesta llega cuando el cobro termina de verdad.
Si consultas con GET /v1/cobros/{id}?esperar=1, la consulta vuelve también con RECHAZO_PARCIAL, para que puedas mostrarle al cajero «esperando reintento: 51 Fondos insuficientes». Vuelve a preguntar hasta tener un estado final.

El veredicto final trae la lista de intentos: un cobro aprobado al segundo intento muestra los dos.

Lo que ve el cliente

Estas pantallas son de FINORA Pago para Android en un emulador, con datos de demostración y lector simulado. La versión de Windows usa el mismo lenguaje: mismos colores, mismos mensajes, mismo orden.

Pantalla Autorizando con el total Bs 2.499,00, la referencia de venta y la indicación No retires la tarjeta — Mientras el banco responde: el total y una sola instrucción. Datos de demostración.

Pantalla Pago aprobado en verde con el monto, la marca y los últimos cuatro dígitos de la tarjeta y el número de autorización — Aprobado: monto, últimos cuatro dígitos y autorización. Nunca el número completo de la tarjeta.

Pantalla Pago rechazado en rojo con el motivo Saldo insuficiente, los botones Intentar de nuevo y Cancelar, y el código 51 — Rechazado con motivo en lenguaje llano y el código del banco (51) en pequeño para soporte.

Pantalla Pago rechazado por clave incorrecta, con el aviso Te quedan 2 intentos y los botones Intentar de nuevo, Otro medio y Cancelar — Un rechazo con segunda oportunidad: el cliente elige reintentar, cambiar de medio o cancelar.

Pantalla Verificando el pago en ocre: Aún no tenemos la respuesta del banco. No pagues de nuevo. El comercio confirmará si el cobro entró — En duda: sin botón de reintento, a propósito. Así se evita el doble cobro.

Los tres veredictos en movimiento

Tres grabaciones cortas, sin sonido, en el emulador y con datos de demostración.

Aprobado: el veredicto y el comprobante, con la tarjeta enmascarada. Emulador, datos de demostración.

Rechazado por saldo insuficiente (código 51), con la opción de intentar de nuevo. Emulador, datos de demostración.

En duda: la pantalla le pide al cliente que no vuelva a pagar. Emulador, datos de demostración.

Para probarlo sin dinero

En modo de prueba ("sandbox": true), el banco simulado decide el veredicto según los céntimos del monto: .51 rechaza por fondos insuficientes, .96 deja el cobro en duda y luego lo aprueba, y así. La tabla completa está en Montos de prueba del banco simulado.