Los estados de una sesión de cobro

Tu tienda solo necesita saber una cosa de cada sesión: en qué estado terminó. De eso depende si entregas el pedido, si lo dejas en espera o si lo anulas. Esta página explica los siete estados y la decisión que corresponde a cada uno.

El ciclo completo

flowchart TB
    C([CREADA]) -- elige medio --> E([EN_CURSO])
    E -- terminal sin respuesta --> C
    C -- cancela o vence --> X([CANCELADA o EXPIRADA])
    E -- aprueba --> A([APROBADA])
    E -- no confirma --> D([EN_DUDA])
    E -- cancela tras rechazo --> R([RECHAZADA])
    D -- se resuelve --> A
    D -- se resuelve --> R

Un intento rechazado no aparece como flecha porque no cambia el estado: la sesión sigue EN_CURSO y el cliente puede volver a intentar. Una sesión EN_CURSO también puede vencer sin veredicto y terminar EXPIRADA.

Qué hace tu tienda en cada estado

Estado	Qué pasó	¿Final?	Qué haces
CREADA	La sesión existe y el cliente todavía no eligió medio	No	Esperar
EN_CURSO	Hay un cobro en vuelo, o un intento se rechazó y el cliente puede probar otra vez	No	Esperar
APROBADA	El banco aprobó. Trae el recibo	Sí	Entregar el pedido
RECHAZADA	El cliente o el comercio cerraron la sesión después de al menos un rechazo	Sí	Anular el pedido o abrir una sesión nueva si el cliente quiere volver a intentar
EN_DUDA	El banco no confirmó a tiempo. El cobro pudo ocurrir	Se resuelve después	No entregar y no volver a cobrar. Esperar el segundo aviso
CANCELADA	El cliente o el comercio retiraron la sesión antes de intentar pagar	Sí	Anular el pedido
EXPIRADA	Venció el tiempo sin veredicto	Sí	Anular, u ofrecer una sesión nueva

Un rechazo no cierra la sesión

Si el banco rechaza un intento, por ejemplo por fondos insuficientes, la sesión sigue abierta en EN_CURSO. El cliente ve el motivo y puede intentar con otra tarjeta o con otro medio dentro de la misma sesión, mientras no venza. Cada intento queda numerado, así que nada se cobra dos veces.

Tu servidor recibe un aviso informativo por cada intento rechazado (checkout.intento.rechazado). No marques el pedido como fallido con ese aviso. El cierre llega siempre con el aviso checkout.sesion. Si el cliente se rinde y cancela después de uno o más rechazos, la sesión termina RECHAZADA con el código del último rechazo.

El cierre de una sesión rechazada, en el servidor simulado del SDK con un comercio ficticio.

✕

Por qué así

Cerrar la sesión en el primer rechazo obligaba a la tienda a abrir otra para que el cliente probara otra tarjeta. Con la sesión abierta, el cliente reintenta sin salir de la página y tu tienda recibe un solo cierre por pedido.

En duda no es rechazado

EN_DUDA aparece cuando FINORA envió el cobro al banco y no obtuvo una respuesta clara: el banco tardó demasiado o no registró la operación. El dinero pudo haber salido de la cuenta del cliente.

Por eso el checkout no ofrece reintentar y le dice al cliente «no vuelvas a pagar». Reintentar un cobro que pudo ocurrir es cobrar dos veces.

Lo que ve el cliente cuando el cobro queda en duda (servidor simulado del SDK).

✕

Después, FINORA consulta al banco por su cuenta. Cuando sabe qué pasó, la sesión pasa a APROBADA o RECHAZADA y tu servidor recibe un segundo aviso para la misma sesión. Trata siempre el último aviso como el definitivo.

El terminal que no responde

Con tarjeta, la orden viaja a un terminal físico. Si el terminal no la toma a tiempo, o el cajero la cancela en el equipo, la sesión vuelve a CREADA con el código TERMINAL_SIN_RESPUESTA o CANCELADA_EN_TERMINAL, y el cliente puede elegir otro medio. Mientras el terminal tiene la orden aceptada, el cliente no puede cancelar ni cambiar de medio: la tarjeta puede estar en el lector en ese momento.

Dónde sigue

• Códigos de error y de resultado: el código exacto de cada caso.
• Prueba cada veredicto en sandbox: provoca cada estado con el monto.
• Avisos (webhooks): los dos tipos de aviso y sus campos.