Customer returns and refunds
Handle returns quickly without losing control of the original sale.
Give authorized managers the original transaction, remaining eligibility, supported refund scope, payment outcome, inventory decision, and receipt recovery context they need to help the customer.
A better return experience
Turn a difficult return into a controlled customer experience.
LiftedPOS keeps the return tied to the original sale so an authorized manager can see what remains eligible, choose the supported scope, preserve the reason, and follow the money, inventory, and receipt result. During scoped setup, we help align roles, payment paths, restock rules, and manager procedure.
Start from the sale
Find the original items, tender, customer, employee, and remaining refundable value before taking action.
Choose the right scope
Use the supported full, item, or amount path without turning a return into an unconnected adjustment.
Keep the record together
Retain the manager, reason, payment outcome, inventory decision, and receipt recovery context.
Use the seeded product to explore the operating path, then bring us the locations, roles, devices, records, and exceptions that matter to your business.
The control rule
Do not begin with a dollar field. Begin with the original transaction.
A defensible refund procedure reads what the sale says is still eligible, lets the authorized operator choose only a valid scope, records why the return happened, and keeps the resulting money, stock, and receipt evidence connected.
Refund decision tree
Seven control points from sale to recovery.
Each step names the authoritative record. The workflow stops when permission, eligibility, or payment evidence is missing.
- 01LocateAuthority · recorded sale
Open the original transaction.
Confirm the sale, location, employee, customer, items, tender, total, receipt, and prior refund history before choosing an action.
- 02ReadAuthority · refund eligibility
Use the server's remaining refundable value.
LiftedPOS exposes cumulative refunds, refund history, and the amount still eligible. The browser does not invent a new balance.
- 03ChooseAuthority · sale and tender rules
Select full refund, selected item quantities, or an exact amount.
Use only the modes the sale and tender support. Rewards-wallet tenders are full-refund-only in the reviewed product state.
- 04ExplainAuthority · operator audit
The reason is required.
The refund reason is retained with the operator name, amount, item detail, and time so the return can be reviewed later.
- 05Submit onceAuthority · server transaction
Keep one idempotency identity.
A repeated click or retry reuses the same identity. A replay reports that nothing was refunded twice instead of creating another refund.
- 06VerifyAuthority · refund and inventory records
Inspect the money and stock result.
Confirm the new remaining refundable balance, refund history, returned item quantities, and the restock effect represented by the refund.
- 07RecoverAuthority · receipt outcome
Reprint or resend the receipt.
From completed-sale history, reprint the receipt or use configured delivery to email or text a confirmed destination.
Eligibility
The server decides what remains refundable.
LiftedPOS reads cumulative refund history and a server-owned remaining refundable value for the original transaction. A partially refunded sale can remain completed and still carry an eligible balance. Every available quantity is the quantity sold minus what has already been refunded on that sale line.
This prevents a stale browser from authorizing its own return. The interface can stop an obviously invalid request early, but the server rechecks the cap, the permission, and the transaction state inside the refund operation.
Swipe to inspect the full product screen, or open the full-resolution proof.
Swipe to inspect the full product screen, or open the full-resolution proof.
Scope
Choose the smallest correct return.
A full refund returns the remaining eligible value and the un-refunded item quantities represented by the sale. A selected item refund lets the operator choose a quantity no greater than what remains refundable for each line. An exact amount refund handles an allowed value adjustment without pretending it identifies a returned product.
Return the remaining sale
Use when the entire eligible remainder should be reversed and its un-refunded item quantities restocked.
Return selected item quantities
Use the per-line maximum and running total when specific merchandise comes back.
Return an exact amount
Use only when partial refunds are supported and the requested value does not exceed the remaining balance.
Rewards-wallet sales are full-refund-only in the reviewed source. The UI says so instead of offering partial controls the server will reject.
Audit and inventory
The return should leave more evidence than the original request.
The reason is required before submission. Refund history shows the amount, cumulative amount, selected lines and quantities where present, reason, operator, and time. The completed transaction retains the thread instead of replacing the original sale with a disconnected adjustment.
For item and full refunds, verify the corresponding restock result at the location. A refund amount and an inventory movement answer different questions: one explains value returned; the other explains sellable quantity restored.
Exception and receipt recovery
The POS governs the record. The capturing rail governs the return.
Cash, rewards wallet, open-batch card void, settled card return, and card-absent refund paths are not interchangeable. The configured processor, gateway, MID, terminal, batch state, original references, merchant settings, and rollout determine how money can be returned. If a card payment requires action on the terminal or gateway, LiftedPOS leaves the sale completed rather than recording a reversal it cannot verify.
LiftedConnect can preserve card-safe result fields and, for supported credit sales when enabled, optional processor-issued token metadata that creates a path for qualified future refunds or card-on-file use. Those workflows require confirmed processor, MID, merchant, and rollout support. For receipt recovery, reprint locally or confirm the destination before email or text; a success state appears only after the configured delivery request succeeds.
Before you go live
Make sure every return path ends with the right result.
Run these cases in the actual merchant configuration before a manager signs off on the procedure.
| Scenario | Expected POS record | Inventory check | Payment and receipt evidence |
|---|---|---|---|
| Full eligible sale | Reason, operator, amount, time, zero remaining | Un-refunded item quantities restocked | Configured tender outcome and replacement receipt |
| Selected item quantity | Line, quantity, running total, remaining balance | Only returned quantities restored | Qualified return result; receipt reflects the record |
| Exact amount | Requested and server-completed amount | No invented item return | Qualified tender outcome retained |
| Double click or lost response | One idempotent refund; replay disclosed | One stock effect | No blind second return |
| Full-refund-only tender | No partial controls or partial record | Full path only when completed | Tender-specific outcome |
| Card reversal unavailable | Sale remains completed; required action disclosed | No premature stock change | Terminal/gateway escalation and reconciliation |
| Receipt resend failure | No false sent state | No stock effect | Server error shown; destination can be corrected |
Manager shift runbook
Train the decision, not just the button.
- 01 · LocateOpen the original transaction and read its prior refund history.
- 02 · QualifyConfirm permission, remaining refundable value, tender, and the allowed scope.
- 03 · RecordSelect full, item quantity, or exact amount and enter the required reason.
- 04 · SubmitWait for the server result; do not create a fresh request after an ambiguous response.
- 05 · VerifyCompare refund history, remaining value, restock, payment-rail evidence, and receipt.
- 06 · EscalateStop when the rail requires terminal/gateway action or the evidence does not reconcile.
Complete commercial picture
Know what is included before you launch.
LiftedPOS software is $100/month for the first station and $50/month for each additional station. A standard station is $499.99 to buy or $39.99/month to lease. Cancel anytime—there is no long-term software contract. Leased equipment must be returned after cancellation or billed at full purchase price.
Payment terminals, processing, and separately scoped rollout work are separate. Tenant access uses {company-prefix}.liftedpos.com/login.