Payments and refunds
Understand captured payments, refund requests and completed outcomes.
On this page
Read the payment record
Review the payment’s status and captured amount alongside the order. An order may have more than one payment record, so check the whole payment history.
Customer payments, food value, tips and fees describe different amounts. Use the measure that matches the question rather than treating them as interchangeable totals.
Refund requests and outcomes
A refund request records that a refund was requested. Its request time does not establish when the payment provider completed it.
Check the refund’s current status and related payment before describing it as complete. A manually recorded refund and a provider-processed refund are separate records.
Partial refunds
A partial refund reduces the payment by the refunded amount. The amount alone does not identify which individual items were returned or refunded.
When reviewing a historical period, remember that a payment’s cumulative refunded amount can include refunds made after the original purchase date.
Make changes in the payment workflow
Use the supported payment and refund controls for the actual action. Gordon can help inspect the records and explain their state; a report is not a refund instruction.
A receipt-printing problem does not mean a payment failed. Check the payment record before asking a customer to pay again.
Captured payments and net customer payments
Received-payment reports include successful payments and payments later partially or fully refunded. Net customer payments subtract recorded refunds from the captured amount, up to the amount originally captured.
Merchant net is different: it also accounts for lost disputes and merchant fees. Missing fee information is unknown, not a known zero. An order total, customer payment, settlement balance and payout are separate measures.
Refund requests, refunds and dates
A saved or reserved refund request is not proof the provider completed it. Air POS refund requests are not a complete provider refund-event history. A request date is not the completion date.
Cumulative refunds attached to a payment describe its current refunded amount; they are not all refund events that happened within the payment's date range. Provider refund-event reporting uses the refund creation date and current status. Do not add cumulative payment refunds to refund-event totals, which would double count them.
Provider refund reports cover Stripe refunds rather than manual cash refunds. Count succeeded refunds separately from pending and failed refunds, keep currencies separate and check whether the report includes all results. Refunds that cannot be linked to a location can leave that location’s total incomplete.
Eligibility and amount remaining
Already reserved or completed refunds reduce the remaining refundable amount. Active disputes and access rules can restrict a refund. Check the payment, currency, amount and existing request status before retrying, so you do not request a second refund by mistake.
Paid-sales rankings exclude fully refunded activity. A partial refund does not identify which products were returned, so the refund amount alone cannot tell you how many items to subtract.
Use payment controls for financial actions
Gordon’s financial reporting is read-only. Explaining a refund, reading a request or showing a status does not execute a refund or payout. Catalogue Undo does not reverse payments, refunds, disputes, fees or payouts.