Ciclo de vida del pago

Los estados por los que pasa un pago y las reglas que evitan que un pago retroceda.

Cada pago que registra Vecnet, en línea o presencial, se resuelve en un solo status en su fila de transactions. Es el mismo vocabulario para los dos rieles, así que integras una sola vez.

Estados

Estado	Significado
`pending`	Recibido y en proceso. Incluye autorizado pero no capturado.
`approved`	El pago fue aprobado y los fondos se capturaron.
`declined`	La tarjeta o el método fue rechazado.
`failed`	Un error impidió completar el pago.
`expired`	La sesión o la liga expiró antes de completarse.
`cancelled`	El pago fue cancelado o anulado.
`refunded`	El pago fue reembolsado por completo.
`chargeback`	El pago fue disputado / tuvo un contracargo.
`duplicate`	Un intento repetido de un pago ya procesado.

Una autorización no es un cobro cumplido. Los pagos autorizados pero no capturados se reportan como pending. Actúa solo con approved, que significa que los fondos se capturaron.

Ciclo típico

pending

approved

Más adelante

reembolsodisputa

refunded

chargeback

Un pago en línea con tarjeta sano se mueve así:

pending  →  approved  →  (después, opcionalmente)  refunded  o  chargeback

Un intento fallido termina en declined o failed. Un checkout abandonado termina en expired. Esos estados son finales para ese intento.

Reglas de estado

Dos reglas mantienen confiables los estados:

El estado del pago manda. Si el estado de un intento y el del pago no coinciden, el del pago es el autoritativo. (Esto importa en los pagos en efectivo, donde un intento puede verse "exitoso" mientras el pago sigue sin realizarse.)
Un pago nunca retrocede. Una vez que un pago está approved, una lectura posterior incompleta o fuera de orden nunca puede regresarlo a pending. Los movimientos hacia adelante, a refunded o chargeback, sí se permiten; los movimientos hacia atrás, no.

Leer el estado

En línea: consulta la sesión de checkout o la liga de pago, o suscríbete a webhooks.
Presencial: lee la fila de transactions (consulta Conciliación) o suscríbete a webhooks.

Un reembolso total mueve un pago approved a refunded. Los reembolsos están disponibles para pagos con tarjeta exitosos mediante POST /api/transactions/:id/refund; la transacción reembolsada conserva su correlation_id original, así que el reembolso y la captura original se concilian juntos. Mientras se procesa, la transacción expone refund_status (processing, succeeded, failed). El webhook payment.refunded se dispara cuando el reembolso se confirma.

Disputas y contracargos

Un pago disputado aparece como chargeback y dispara un webhook payment.chargeback. Las disputas también se exponen como recurso de tu comercio en /api/disputes para darles seguimiento y resolverlas.