2026-11-11 Author : ZCS
The difference between a POS void and a refund is the payment state at the moment the merchant tries to undo it. A void normally stops an authorized payment before capture or settlement. A refund returns all or part of a payment that has already moved beyond that point. The wider point of sale system guide explains how orders and tenders are recorded. This article follows what happens when a completed-looking checkout must be cancelled.
The words can be confusing because POS software, payment terminals and processors do not always use the same labels. One system may show “void,” another may show “cancel,” and another may offer a single “reverse” action that chooses between cancellation and refund after checking the payment status. Merchants should therefore follow the payment provider’s supported operation and final response instead of relying only on the button name.
A void attempts to cancel a payment before it becomes a captured financial transaction. A refund creates a new return-of-funds event against a payment that was already captured or completed.
| Question | POS void | POS refund |
|---|---|---|
| Typical payment state | Authorized but not captured or submitted for settlement | Captured, settled or otherwise completed under the provider’s rules |
| Main purpose | Stop an incorrect or unwanted payment before completion | Return money after a completed sale |
| Customer account effect | Release or remove the authorization hold | Post a credit or return through the original payment route |
| Merchant settlement effect | Normally keeps the cancelled amount out of captured sales | Reduces a later settlement, merchant balance or payout according to provider rules |
| Original sale record | Retained with a voided or cancelled state | Retained, with a separate linked refund record |
| Partial amount | Often unavailable for an ordinary void, though capture adjustment may be supported | Commonly supported when the payment method and provider allow partial refunds |
| Customer receipt | Void or cancellation evidence | Refund receipt showing amount and reference |
This table describes a common card-payment model, not a rule for every payment method. Some immediate-capture systems leave little or no usable void window. Some debit, QR, wallet, gift-card and account-to-account methods use their own cancellation and refund states. A merchant must check the exact provider, region, tender and integration.
Time is only a practical clue. The decisive question is whether the provider still treats the payment as authorized and uncaptured, or as captured and refundable. A cashier may notice an error ten seconds after approval, but an automatic-capture configuration may already have submitted the payment. Another merchant may use delayed capture and still be able to cancel several hours later.
Adyen’s payment-management documentation illustrates the state boundary clearly: its cancel action applies before capture, while its refund action applies after capture. That documentation describes Adyen’s system, but the general lesson applies more widely—read the authoritative transaction state before choosing the correction.
Useful states include:
The POS settlement process explains why authorization, capture, settlement and bank payout are separate events. A void belongs near the authorization and capture boundary. A refund belongs after a completed payment and can affect a later merchant settlement or payout.
A successful void asks the payment chain to release the approved amount instead of capturing it. The customer may never see a completed debit, but they can still see a pending authorization for a period of time.
Suppose a customer approves an $80 card payment and the cashier immediately discovers that the wrong order was selected. If the payment remains uncaptured, the merchant can request a void. The processor records the cancellation, and the issuer can release the $80 authorization hold.
The available balance may not update at the same moment as the POS screen. The merchant controls the cancellation request, but the issuer controls how and when the pending authorization disappears from the customer’s account view. The cashier should not promise that the hold will vanish instantly or by one universal deadline.
A useful void receipt or support record should show:
If the void request remains pending or fails, staff should not tell the customer that the payment has been cancelled. They should check the processor’s final status and follow the provider’s escalation route.
A refund returns money through a new financial event linked to the original payment. The original sale does not disappear. The customer can see the original debit and, later, a separate credit or returned amount.
Using the same $80 example, assume the payment was captured and the customer returns a $20 item the next day. The POS locates the original transaction and sends a $20 refund. The merchant retains the $80 sale, adds a linked $20 refund record and reports a net retained amount of $60 before any fees or other adjustments.
The customer’s available balance may not increase immediately. The provider, payment network and issuer must process the refund. Some providers can report that a refund request was accepted before the customer’s bank has posted the credit, and a later failure can still require merchant action.
Adyen’s refund documentation provides one provider-specific example: a captured payment can be partially refunded, multiple partial refunds cannot exceed the remaining payment balance, and a refund request can later fail or be reversed in defined cases. Merchants should use their own provider’s final statuses rather than treating “refund submitted” as “customer credited.”
Neither a void nor a refund should erase the original transaction. A reliable audit trail keeps the order, payment attempt, correction, employee, reason and final payment status connected.
The POS can have two related but different records:
Voiding an unpaid item before tender is not the same as voiding an approved card payment. Similarly, cancelling an entire order does not prove that the payment terminal successfully cancelled its authorization. Integrated systems should exchange the final result so the order and tender do not drift apart.
| Event | Order record | Payment record | Customer document |
|---|---|---|---|
| Item removed before payment | Item voided or removed under store policy | No payment change | Updated order or no receipt |
| Authorized payment voided | Order cancelled, reopened or marked unpaid | Original authorization plus confirmed cancellation | Void or cancellation receipt |
| Full refund after sale | Original sale retained and marked fully refunded | Original payment plus full refund | Refund receipt |
| Partial refund | Original sale retained with returned lines or amount | Original payment plus partial refund | Refund receipt showing returned amount |
| Failed void or refund | Order remains under exception handling | Request and failure reason retained | No success receipt; staff escalation record |
A linked-transaction refund workflow shows why the connection to the original sale matters. Staff should be able to locate the prior transaction, choose returned items and retain refund details such as the reason, amount, time and cashier. Exact screens differ by POS, but those fields form a useful minimum audit trail.
Partial refunds are common, while an ordinary void often cancels the full authorization. A merchant that needs to collect less than the authorized amount may use partial capture, authorization adjustment or another provider-supported action instead of a partial void.
The correct operation depends on the payment design:
Clover’s void and refund FAQ provides a useful example of provider-specific rules. It states that its void applies before settlement submission, refunds apply after settlement begins, and a partial sale amount cannot be voided through that void operation. The same page also describes a specific timing rule for Clover. That timing must not be copied into a general POS policy for another provider.
The practical rule is simple: do not invent a partial-void workflow. Query the payment status and use the exact adjustment, capture, cancellation or refund operation supported by the provider.
A successful void normally prevents the cancelled amount from becoming captured sales, while a refund creates a later deduction or funding requirement. The exact payout treatment depends on the provider’s balance, fee and settlement model.
Consider three versions of the $80 sale:
| Outcome | Processor activity | Possible merchant payout effect |
|---|---|---|
| $80 authorization voided before capture | Authorization and cancellation, no completed $80 capture | $80 should not enter captured gross sales |
| $80 captured, then fully refunded before payout | $80 sale plus $80 refund | Provider may net the refund in the same or a later settlement |
| $80 captured and paid out, then $20 refunded | $80 original sale plus later $20 refund | Provider may deduct $20 from merchant balance, future payout or linked funding source |
Fees require provider-specific treatment. Some providers return some fees, some retain them, and some apply separate refund charges. The POS should not calculate a universal refund cost from the original sale amount.
The POS reconciliation workflow should therefore compare gross sales, voided authorizations, captured payments, refunds, processor adjustments and bank payouts as separate categories. Combining voids and refunds into one negative-sales total hides whether money ever entered settlement.
Not always. “Reversal” can describe a network or processor message used to release an authorization after a failed or uncertain transaction. A cashier-initiated void is a deliberate correction to a known payment. A technical reversal can be the recovery action after a timeout, communication failure or incomplete service.
The difference matters when the POS shows no final result. If staff assume the payment failed and create a new sale, the customer could be charged twice. The system should preserve the original reference, check the authoritative status and let the processor or host apply the supported reversal when necessary.
Visa’s Kernel in the Cloud release notes describe one specific implementation in which a reversal is triggered for timed-out authorizations when the PSP or acquirer selected reversal support. This is evidence that timeout recovery can use a technical reversal; it is not a promise that every POS, payment rail or timeout follows the same process.
The related guide to agent banking timeout reversals covers this uncertain-state problem in withdrawals and deposits. That scenario is deliberately separate from the merchant return covered here: the agent is resolving an unknown financial result, not accepting a normal product return after a completed sale.
Staff should confirm the transaction, payment status, amount and permitted operation before changing any financial record. A simple operating checklist reduces duplicate credits and mismatched orders.
For an unknown result, staff should stop and investigate instead of choosing the button that seems most likely to move the customer’s balance.
Removing the order from the POS does not guarantee that the payment provider cancelled the authorization. The integration must confirm both results.
A successful void can leave a temporary pending hold, and a successful refund request can take time to reach the customer’s account. Staff should use provider-approved wording.
The provider may reject a refund before capture or automatically choose a cancellation instead. Query the state rather than guessing.
A lost response does not prove that the void or refund failed. Check the original request before submitting another financial event.
Deletion breaks the connection among the receipt, inventory movement, payment reference, staff action and settlement record. Use linked statuses and correction records.
A financial refund and an inventory return are separate decisions. A damaged, consumed or missing item may be refunded without returning to sellable stock.
Returning funds through an unrelated tender can weaken the payment trail and create fraud or compliance risk. Follow the original-payment and provider rules unless an approved exception applies.
A successful void normally prevents capture, but the customer may still see a temporary authorization hold. The issuer determines when that pending amount disappears from the account display.
No. The original sale should remain, and the refund should appear as a separate linked event. This preserves receipts, inventory decisions, staff accountability and settlement reconciliation.
Often, but not always. Partial refund support depends on the provider and payment method. The total of all refunds should not exceed the refundable balance under the provider’s rules.
An ordinary void often cancels the full authorization. When the final amount is lower, the provider may support partial capture or authorization adjustment instead. Staff should use the documented operation.
The merchant’s cancellation confirmation and the issuer’s account display do not always update at the same time. A pending hold can remain temporarily even though capture was cancelled.
No. A reversal commonly releases or corrects an authorization or incomplete financial event. A refund returns money after a completed payment. Provider terminology can vary, so the transaction state and financial effect matter more than the label.
Not until they check the original request. The first operation may have succeeded even if the POS lost the response. Repeating it can create duplicate or conflicting records.
Explain the account effect. A void releases an authorization before completion; a refund sends a credit after completion. Avoid promising a universal posting time because the payment provider and issuer control later processing.
POS void vs refund is a transaction-state decision, not simply a choice between two buttons. Void the supported uncaptured authorization. Refund the supported captured payment. Preserve the original order and payment references in both cases.
The customer-facing difference is equally important. A void can leave a pending hold while the issuer updates the account, whereas a refund creates a separate credit after the original debit. Clear receipts, staff permissions, final-status checks and separate reconciliation categories keep those outcomes understandable for the customer and traceable for the merchant.
Home 
What Japanese Merchants Must Check Before Processing Biometric Data? 
