Void
A void is the cancellation of an authorised card payment before it has been captured — the merchant drops the transaction, a reversal goes to the issuer, the hold is released, and no money ever moves. It costs nothing beyond the authorisation fee already paid; a refund returns money that was captured and settled, takes days, and costs fees on both legs. A merchant that voids instead of refunding saves money and complaints.
- Also known as
- Voided transaction, Authorisation void, Cancel before capture
- Used at
- order cancellations before dispatch, out-of-stock orders, checkout errors, terminal mistakes corrected before the batch closes, and any authorisation the merchant will not capture
- Binding
- the schemes' rules require merchants to reverse authorisations they will not use (misuse fees apply otherwise); a void is possible only before capture, or before the day's batch has been submitted at a terminal; after that, the operation is a refund
- Typical effect
- the reversal reaches the issuer and the hold is released — within hours at most issuers, longer at some, especially on debit cards — and the cardholder's available balance recovers; nothing appears on the statement
- Typical failure
- merchants that capture everything at order and refund cancellations, paying refund fees and interchange they do not recover, and leaving customers waiting days for money that a void would never have taken
- Parties
- the merchant and its gateway or terminal (which void), the acquirer and network (which carry the reversal), the issuer (which releases), and the cardholder who sees a pending amount disappear
How a void works in practice
A customer orders a €90 item; the merchant authorises €90 and holds the order for dispatch. The item is out of stock. The merchant's system voids the authorisation: the gateway sends a reversal, the issuer releases the €90 hold, the customer's balance recovers, and nothing was charged. Compare the alternative: the merchant had captured €90 at order, the €90 cleared and settled, and now it must refund €90 — a credit that takes four days to reach the customer, on which the merchant pays a fee and loses the interchange it paid on the sale. The void cost the merchant the authorisation fee it had already spent; the refund would have cost that plus the refund fee plus the interchange plus four days of customer patience.
The rule is timing. A void works until the transaction is captured — at an online merchant with delayed capture, until dispatch; at a terminal with daily batches, until the batch is submitted. After capture the only way back is a refund. So merchants that want to void must delay capture, and PSPs that capture automatically at authorisation (the small-merchant default) make voids impossible and refunds the only tool. The scheme rules push the same way from the other side: authorisations left neither captured nor voided attract misuse fees.
For a merchant's payments team the void rate is a health metric — high if the order flow is cancelling before dispatch, which is a stock or a checkout problem — and the refund rate on same-day cancellations is a sign that the integration captures too early.
Example
An online electronics retailer captures at order and refunds cancellations: 6% of orders are cancelled before dispatch — 18,000 a year, €2.7m — each captured, settled, then refunded. Costs: €0.25 per refund in fees, unrecovered interchange averaging 0.3% (€8,100), float on €2.7m for a week, and 900 support tickets from customers waiting for their money. It moves to authorise at order and capture at dispatch, voiding cancellations: refunds on pre-dispatch cancellations fall to zero; the annual cost of the change is the delayed-capture logic and a re-authorisation flow for orders held past seven days. The customer-service team's "where is my refund" queue halves, most of what remains being genuine returns.
Common mistakes
- Capturing at order for goods that ship later, so every cancellation is a refund. - Voiding through the merchant's system after the batch has gone, and assuming it worked. - Leaving authorisations to expire instead of voiding them, and paying misuse fees. - Telling the customer a void will show on their statement; it will not, and the pending amount may take a day or more to clear. - Confusing void (before capture) and refund (after) in the integration's API calls.