Payments and payment methods
What this is for
Every way a customer can pay, and what each one means for your records.
At the till
The methods offered when a cashier takes payment:
| Method | What it records |
|---|---|
| Cash | Amount tendered, with change calculated. |
| Card | A card payment. The money moves through your own terminal unless a gateway is connected. |
| UPI | Where you accept it. |
| Bank Transfer | For account and invoiced customers. |
| Other | Anything else you've configured. |
The step-by-step is on Taking payment. This page is about how they're set up and what they mean.
Card payments are recorded, not processed
Unless you've connected a payment gateway, Restodesk records that a payment was made by card. The approval happens on your card terminal.
That's a real operational rule, not a technicality: take the payment on the terminal first, then record it. A declined card recorded as paid is a bill nobody will ever chase.
A Transaction ID can be stored against the payment. Do it — it's what turns end-of-day card reconciliation from guesswork into matching two lists.
Online payments
Guests ordering through your customer site can pay at checkout where you've connected a gateway. Those orders arrive already paid.
Restodesk supports a range of gateways — Stripe, Razorpay, PayPal, PayFast, Paystack, Mollie, Flutterwave, Xendit, Tap and others. Which are available to you depends on your plan and your region.
Setting one up needs credentials from that provider and is done under Settings › Payments. It's worth doing carefully once with whoever handles your banking.
Offline payment methods
Separate from the gateways, and separate again from POS offline mode.
An offline payment method lets a customer pay outside the system — a bank transfer, most often — and upload a receipt as proof.
The order then sits at Payment Verification until someone checks it, and a manager either:
- Confirm Payment — the money arrived.
- Report Unpaid — it didn't.
Check your bank before confirming. That status exists precisely because an uploaded screenshot isn't proof of anything.
"Offline payment" and "the POS working offline" are unrelated. One is a way to pay; the other is what happens when your internet drops. See When the internet drops.
Part payment and money owed
An order can be settled in stages. What's left shows as Remaining, and the order carries Payment Due until it clears.
Pay Later leaves an order deliberately unpaid — account customers, staff meals, a table settling at the end of the week. See Due payments.
Tips
Added at payment, as a suggested percentage or a custom amount, with the old and new totals both shown before confirming.
Order totals elsewhere are reported excluding tip, so your food revenue stays separate from gratuity. See Discounts, taxes and charges.
Refunds
Money going back out. Full, partial, or a waste write-off where nothing returns to a customer at all — see Refunds and cancellations.
Refunding is a permission. Restrict it.
Reconciling a day
A routine that works:
- Cash — count the drawer against recorded cash payments. With the cash register add-on this is structured for you: Cash register and shift handover.
- Card — match your terminal's batch total against recorded card payments.
- Online — match your gateway's settlement against paid online orders.
- COD — settle what drivers collected: Cash on delivery and settlements.
- Due — check nothing has quietly aged: Due payments.
Do it daily. A discrepancy found the same evening is a question someone can still answer.
Good to know
- Cancelling an order deletes its payments. If money genuinely changed hands, refund instead.
- Split payments each take their own method — cash from one guest, card from another. See Split, merge and hold.
- Split payments and online methods can't be completed while the POS is offline.
- Show Payments and Refund Payments are separate permissions. Plenty of staff should see payments; few should reverse them.