Ciclo de vida de la sesión

Una sesión de pago recorre estados bien definidos. Conocerlos te dice cuándo confirmar y qué esperar.

Ciclo de vida de la sesión

Los estados

            ┌─────────► failed     (rechazado · solo Botón)
 pending ───┼─────────► expired    (venció sin pagarse)
            └─────────► paid       (pagado)  ──►  [acreditación: leg 2, por webhook]

Estado	Qué significa	Cómo se llega
pending	Sesión creada, esperando pago	al crear la sesión
paid	El débito salió bien (leg 1)	la persona paga
failed	El pago fue rechazado (solo Botón)	intento fallido
expired	La sesión venció sin pagarse	pasa el TTL o se expira

La acreditación no es un estado

Tras paid, la acreditación (leg 2) ocurre, pero el status se queda en paid. Solo te enteras por el webhook payment_session.accredited. → Transacción a dos tiempos.

Notas importantes

• failed aplica solo al Botón. Una Solicitud no se marca failed: o se paga (paid) o vence (expired).
• expired se refleja en GET status. Al expirar, el status pasa a expired de verdad (no se queda en pending).

Compruébalo en el simulador

Puedes forzar cada desenlace y verlo reflejado en el status:

# paid | failed | expired
curl -X POST https://sim-productos.abiertolab.com/control/sessions/<id>/outcome \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"leg":1,"outcome":"expired"}'

curl https://sim-productos.abiertolab.com/api/v1/ext/payment-sessions/status/<id> \
  -H "Authorization: Bearer <token>"     # -> { "data": { "status": "expired" } }

→ Usar el simulador · Manejar notificaciones