Estados que entiende el webhook de confirmación

El valor se toma de status (o status_detail, transaction.status) y de type si viene. Se compara sin distinguir mayúsculas.

Acción	Valores reconocidos	Efecto en el pago	Efecto en el link	Evento al comercio
Aprobar	APPROVED, SUCCESS, payment.purchase.processed, payment.authorization.processed, cualquiera que termine en .approved o .succeeded	paid	paid	payment.approved
Rechazar	DECLINED, REJECTED, FAILED, payment.purchase.rejected, payment.purchase.failed, payment.cancel.processed, terminados en .rejected o .failed	failed	failed	payment.rejected
Reembolso	payment.refund.processed	refunded	refunded	payment.refunded
Contracargo	cualquier valor que contenga chargeback	in_review	in_review	payment.chargeback
En revisión	cualquier otro valor (por ejemplo PENDING) o ausente	in_review	in_review (cuando su estado lo permite; nunca si ya está paid)	payment.in_review

Hoy no se distingue el motivo

Un rechazo por el banco, por fondos insuficientes o por expiración llegan igual como rechazar; el motivo solo se guarda como texto (failure_reason). No hay una pantalla de resultado propia para estos medios (la app del proveedor informa al pagador). El vocabulario real de estados y motivos está por acordar; ver decisiones abiertas.

Orden y estados terminales

• Un pending que llega después de paid no degrada el pago ni el link.
• Un contracargo sobre un pago paid sí lo lleva a in_review.
• Un evento repetido (mismo identificador) no cambia nada.