Voids & Refunds
Reverse a charge made through a Payment Link. The mechanism differs depending on whether the transaction has already settled.
Revert vs. refund
| Transaction state | Mechanism | What it does |
|---|---|---|
| Authorised / pre-settlement | Revert (void) | Cancels the charge before funds settle. No money moves. |
| Captured / settled | Refund | Returns settled funds to the cardholder. Partial amounts are supported. |
| In-flight async request (e.g. Zigi) | Cancel | Stops a payment request that is still pending. |
Partial refunds are supported by processors whose refund method accepts an amount; the transaction's accumulated refunded total grows as refunds are applied.
Per-processor support
Not every processor supports both operations:
- Refund supported:
fac,fac-2,openpay,visa-cybersource,visa-epay,paypal,mercadoPago,paymentez,adyen,serfinsa,ridivi-v2,zigi,t1pagos,azul, and the Apple/Google Pay variants (applePayFac,applePayT1,applePayCyber,googlePayCyber). - Revert only (no refund):
globalPay,epay— these support voiding a pre-settlement charge but not a post-settlement refund.
Refund and revert limits are enforced by the thresholds configured for your merchant account and by the processor's own response.
How to request a void or refund
Voids and refunds are not exposed as a public self-serve endpoint on the integration API today. Coordinate them through your Migo operations channel / account manager, referencing the transaction uid you received when the link was created.
Receiving the outcome
Refund and void outcomes are delivered to your backend only if a callback is configured for your account — see Merchant generic callback. Reconcile by correlating with the transaction uid. There is no fixed refund.* / chargeback.* event catalog on this path.