Imagine a customer returns a £40 item and accepts store credit. A few minutes later, they ask for the refund to go back to their card instead.
The cashier finds a refund option. The customer sees a confirmation. Everyone believes the job is finished.
But what happened to the £40 credit already issued?
That is an illustrative example, not a customer case. It is also the sort of question a useful POS demonstration should answer before a busy Saturday makes it urgent.
A good refund workflow leaves the customer, the till and the shop's records telling the same story. A button labelled refund is only one part of that.
One return can change four different records
Start by separating four decisions that often get folded into one conversation at the counter.
The return decision: What has the shop agreed to accept, and what outcome is appropriate for this case? Follow the applicable requirements and your authorised policy; this guide is about checking the workflow, not deciding a customer's legal entitlement.
The stock decision: Has the item physically come back? Is it ready to sell, damaged, awaiting inspection or somewhere else? The payment outcome should not quietly decide its physical condition. Our guide to stock having more than two states explains that distinction.
The payment decision: Which original payment is involved, what action is permitted now, and what status shows the outcome? A sale, a correction and a refund should remain traceable rather than being reconstructed from the drawer total later.
The customer-credit decision: Does an account credit or gift-card balance exist before the new action? What should remain afterwards?
The customer needs a clear explanation. Staff need a supported sequence. The owner needs enough history to understand the result without asking everyone to remember the shift.
A split sale does not answer the refund question
In a Shopify merchant discussion about split-tender refunds, the question was whether the merchant could "customize the distribution of funds" when returning part of an order paid through several methods.
That question came from a historical discussion, not a current statement of product limitations. It remains a useful requirement to take into an evaluation: can the shop perform its intended return, through an authorised route, against those actual original payments?
Do not confuse splitting a fully paid sale with collecting an outstanding balance. Shopify's current multiple-payment guidance treats both situations separately. It also warns that certain refunds, exchanges or edits on an order being paid in multiple payments prevent collecting further payments on that order.
That is a provider-specific example, not a rule for every POS. Ask about the exact order state instead of accepting "we support split payments" as the whole answer.
Use a seven-case refund acceptance sheet
Run the following exercise in a demonstration or other provider-supported non-production environment. Use sample orders and representative payment scenarios. Do not send real money or expose customers' details to prove a point.
For each case, write down the supported action and the expected result before the demonstration. Then record what actually happened.
| Case | Question to resolve | Record or reference | Approval owner | Expected next state |
|---|---|---|---|---|
| Cash purchase | Which cash-return action is supported? | Original receipt and refund record | Named authorised role | Cash and sale history explain the same return |
| Original card | Which original payment can be refunded? | Sale/payment and refund references | Named authorised role | The refund has a known status; staff explain what is confirmed |
| Partial or split payment | How is the permitted amount distributed? Is a balance still outstanding? | Each original tender and returned line | Named exception owner | No method is over-refunded and the remaining order state is clear |
| Gift card | Was the card bought, used as tender, or selected as the refund destination? | Original transaction and relevant balance history | Role authorised for that specific action | The correct payment and card balance are accounted for |
| Existing store credit | Was credit already issued, spent or adjusted? | Order and customer-credit history | Authorised credit/refund role | No unexplained duplicate value remains |
| Wrong tender or correction | What is the payment's current state, and which correction is supported? | Original entry and attempted-action history | Named manager or provider support | One traceable correction, not several speculative reversals |
| Pending or unclear outcome | How is the existing attempt checked before a retry? | Existing refund reference and current status | Named escalation owner | The case stays open until the outcome is verified |
Add one further field to every row: what can the cashier truthfully tell the customer now?
For example, "the refund request has been recorded and this is its reference" is different from promising that funds have arrived. Obtain the provider's current status definitions and timing guidance rather than inventing a standard waiting period.
The approval column matters as much as the payment column. If only the owner can resolve an exception, what happens when the owner is not in the shop? Define a supported escalation route, not a shared owner password. Our staff-permissions guide helps frame that handover.
Work through the £40 example without creating a second promise
Return to the opening example. Assume, purely for this exercise, that £40 credit has been issued and none has been spent. The customer then requests a change to the original card.
The test should establish:
- Where the original sale, issued credit and current credit balance can be verified.
- Whether the requested change is permitted in that setup, and who can authorise it.
- What the supported process does to the existing credit and the new payment outcome.
- Which records show the final position and what staff should explain to the customer.
Shopify's store-credit documentation makes a material distinction: refunding to the original payment method after a store-credit refund does not reverse the credit already issued. It also specifies permission requirements.
That does not mean staff should manually improvise a balance adjustment or pay the customer outside the system. It means the existing value and the authorised provider procedure must be understood before proceeding.
In this simplified example, leaving £40 of usable credit while also completing a £40 card refund would leave £80 of value against an intended £40 return. That arithmetic is not a measured merchant loss; it shows why the acceptance test must inspect both records.
Gift cards need their own line in the test
"We refund gift cards" is too vague for an operating procedure. Ask which of these is meant:
- Refunding the payment used to purchase or fund a gift card.
- Returning goods originally paid for using a gift card.
- Putting the value of a return onto a gift card.
Square's UK gift-card refund guidance distinguishes a card used as payment from the payment used to buy the card. It also documents restrictions for refunds onto gift cards, including split-tender transactions.
Those are Square UK conditions, not universal limits or a comparison score. Check your own provider, country, device and permissions. Inspect the resulting balance as well as the receipt.
Give the next person a case they can understand
An unresolved refund should not become "someone tried something earlier" at the next shift change.
Keep an access-controlled case record with the original order reference, relevant payment type, amount, current status, existing refund reference, earlier actions, responsible person and next check. Refer to customer or payment records through approved internal references. Do not paste full card numbers, credentials or unnecessary personal information into a shared worksheet or support message.
Where the outcome is unclear, verify the existing attempt through the provider's supported route before another action. If support is needed, the history should show what is known and what is still unknown.
Later, the shop may also need to reconcile the payment outcome with settlement records. That is a separate check from the counter decision. The POS sales-to-bank reconciliation guide covers that next stage.
Bring your exceptions to the checkout evaluation
A normal sale shows how the system behaves when everything goes as expected. Returns reveal who owns the exceptions and whether the records stay understandable.
When considering EzyCarto POS, bring your actual payment methods, devices and the return cases staff need to handle. Its public mobile POS scope covers supported selling, configured payments, shared stock context and sale/receipt synchronisation. It is not a promise of every refund, gift-card or credit workflow in this worksheet.
Take your seven cases into the discussion and ask the team to confirm the supported scope before committing. A useful answer includes the limits, the person responsible when a case falls outside them, and what the customer will be told.
That is the standard to test: one return with an outcome everyone can explain.