How do I set up and run Order & Pay?

Switch on at-table ordering — customers scan their table's QR code, order and pay from their phone, and orders ring on your live Orders screen.

Order & Pay comes with the Complete plan, or on its own as the standalone Order & Pay product (from £29 a month — Plus at the table; Pro, £39 a month, adds collection and delivery): customers scan their table's QR code, browse your live menu, order and pay from their phone, and the paid order rings on your Orders screen for your team to deliver. ResoFlow charges a flat 15p platform fee per paid table order, deducted from the payout — it's never added to the customer's bill, and tips are never touched (customers pay through your own Stripe account, so Stripe's standard card-processing fees also apply as with any card payment). Collection and delivery ordering — Order & Pay Pro, or the Complete plan — carries its own fee of 50p + 1% per collection or delivery order, with a per-channel choice to add it to the customer's total instead (never to tips); see Collection and delivery.

Switching it on

The master switch lives on Orders → Settings. Switching ON is checked server-side and will be refused until your venue is genuinely ready:

If either is missing, the page shows a checklist of exactly what to fix, with links.

Optional setup guide. On Orders → Settings, choose Open setup guide for six steps: Add your dishes to the Menu page · Switch on at-table ordering · Put the QR codes on the tables · Set up your printer or the Orders screen · Do a test order yourself · Brief the team on the board. Previous step and Next step move through the guidance; they do not save settings or mark tasks complete. ResoFlow confirms only facts it can observe, such as dishes existing or ordering being on. Printed codes, a test order and the team briefing still need your review. Close or reopen the guide whenever you need it, including after ordering is running. Your normal settings and Save changes/Discard changes remain available. Changing venue closes the guide.

Separately — and never as a block — the page warns you if you'd be going live with nothing to order: no dishes on your menu, or no tables added (so there are no table codes to scan). You can still switch on; it's simply telling you that a customer scanning right now would find nothing. Both notes carry a link straight to the page that fixes them, and they disappear once there's something there.

Switching off is always allowed, instantly — new orders stop at once, and paid orders already on the board stay there until your team handles them (nothing is auto-refunded).

For a short breather mid-service, there's also a separate temporary pause: the Orders screen's Pause new orders button (the pause icon in the board's top bar) stops new orders in one tap without touching the master switch — and when collection or delivery is switched on too, it first asks which orders to pause: everything, at-table only, collection only or delivery only. Customers see "Ordering is paused — back shortly" on the menu, checkout refuses politely, and an amber strip on the board carries the one-tap Resume orders button. Orders already on the board are untouched — the pause only stops new ones. It stops them properly, too: a customer who was on the payment screen at the moment you paused can't slip an order through, and if their card was taken in that instant they're told plainly on screen and refunded automatically, so nothing lands on the board that your kitchen hasn't agreed to make. Pausing is always allowed; the master switch stays exactly as it was.

Strongly advised before going live (not enforced — it's your venue's legal responsibility): fill in each dish's allergen checklist and "Contains alcohol" flag on the Menu page. If you brought your menu in with the menu import, its review screen pre-ticks "Contains alcohol" for dishes that read as alcoholic drinks and lets you mark a whole drinks section in one go — check those ticks rather than starting from nothing. Customers ordering remotely must be able to see allergen information in writing.

Your printed QR codes just work. The per-table menu QR codes you've already printed start taking orders the moment Order & Pay is on — no reprinting needed. With it on, the QR codes page's per-table cards read "Scan to order and pay" instead of "Scan to view our menu".

How customers start an order

There is one way in. The Menu tab on your customer pages is for browsing only — no Add buttons, nothing to tap into. The Order tab (it sits in the same navigation as Home, Menu and Book) is the single door to ordering, and it appears as soon as any way of ordering is on — at the table, collection or delivery — including venues that only take orders at the table by QR code.

Tapping Order opens a small chooser that slides up over the menu with up to three big buttons — Order to your table, Order for collection and Order for delivery — showing only the ways you have switched on, each with one line underneath in your own words: the current collection wait ("Ready in about 20 minutes"), the delivery area and fee ("Within 3 miles · Delivery £2.50 — free over £25.00"), or that the channel is closed or paused right now. If only one way of ordering is on there is no chooser: the customer goes straight in.

To hide the Order tab, the venue-page card and the menu-page pointer together, switch off Show the Order tab and card on your venue page on Orders → Settings — it sits beside Flexible table entry whenever ordering is on, and also under Collection & delivery while collection or delivery is on (one setting, two places). Ordering still works from your table QR codes, your website's Order online link and any direct ordering link — the switch only hides the entry points.

Flexible table entry

The Flexible table entry switch on Orders → Settings is on by default and decides what Order to your table does for a customer who hasn't scanned a table code — switch it off and ordering becomes strict: a customer can only start an order by scanning their own table's QR code. With it on:

With the switch off, the Order tab, card and pointer still show (ordering is on, after all) but Order to your table — and a previously printed general code — leads to an honest "To order here, please scan the QR code on your table — or ask a member of the team" note above the browse menu, never a typed table and never a silent dead end (the per-table codes themselves are unaffected). Separately, whenever a customer scans a table QR (or the general code) while Order & Pay is switched off — or nothing is currently orderable — they now see a friendly "Ordering at the table isn't available right now — please order with our team" notice above the browse menu instead of nothing at all.

Serving times and category switches

Every menu category can be switched on or off for ordering, and scoped to serving windows — set days and times:

Outside a category's serving windows, its dishes show on the menu as browse-only and can't be added to an order — and the times are re-checked at payment, so a window closing mid-browse still holds. The category itself is never hidden: customers see it with its serving times shown against its name ("Served Mon–Fri 12:00–15:00"), so tonight's dinner menu is still there to read at breakfast. The same windows also hold for pre-orders: a booked party can't pre-order dishes from a category that won't be served at their booking's time, and the picker says why (see pre-ordering).

Tip suggestion

The customer checkout always offers No tip, 5%, 10%, 15% or Other (their own amount) — tips are voluntary and go to the venue. On Orders → Settings → Tip suggestion you can choose to preselect one of the percentages (5%, 10% or 15%) so it's highlighted when the checkout opens; the default is Off, meaning the checkout starts on "No tip". Customers can always remove the suggestion in one tap or type their own amount, and once they've chosen, their choice is never overridden.

Set menus & deals

Build set menus and bundles on the Menu page's Set menus & deals view — existing dishes grouped into slots with one bundle price and optional per-dish supplements, scoped to their own day and time windows (see How do I build my menu?). When at least one deal is available right now, customers see a highlighted Set menus & deals section at the top of the ordering menu — or, for a deal you've placed inside one of your categories, its card inside that section with a compact deal chip (name and price) just under the category heading; a deal placed At the top AND in its category shows its card in both places — and pick their dishes step by step; with ordering off, the browse menu lists live deals read-only with their times shown. Every visible deal's Apply automatically switch (on by default) means a basket that fills the deal gets the deal price even when the customer never tapped the card — see How do I build my menu? for how the automatic apply always favours the customer.

On the Orders screen a deal arrives as one line — the deal's name and price with each chosen dish listed beneath it (including any choice-step picks and supplements), so the kitchen sees exactly what to make. Deal orders behave like any other: they count in sales figures, earn loyalty for signed-in members on the money paid (where your venue runs loyalty), and appear itemised on the customer's receipt with the bundle price split across the chosen dishes' VAT rates where you've set them. Automatic promotions never discount a deal — on a mixed order they apply only to the individually priced dishes. A promo code the customer types can also come off deal prices while the Promo codes can be used on deal prices toggle (Orders → Settings, on by default) is on; codes limited to certain items never touch deals either way — see How do promotions, deals, rewards and gift cards work together?. The Promo code box is always on the order checkout, whatever promotions you're running, so a customer holding a code from a poster always has somewhere to type it — and a code that's wrong, paused, used up, not started yet or meant for a different kind of order gets a plain one-line message under the box saying so. Customers with a code find it easily: whenever you have a live promo code that works on table orders, a Have a code? link sits under the basket's Go to checkout button and opens the checkout on the box.

The Orders screen — one screen, three layouts

Open Orders (in Front of house) on the dashboard or the staff portal. There is ONE orders screen; each device picks how it shows it from the footer picker This screen is:

The Wall screens page also has an Orders (kitchen and bar) card whose Open on this device sets that device to the Wall layout, and a Signed-in screens list showing which device is showing what (see wall screens).

New paid orders appear the moment they're paid — where a customer took the same option several times on one dish (a choice step that allows repeats), the card shows it once with a count, "Hash brown ×3", never three identical lines — and by default a Counter or Pass screen rings continuously until someone acknowledges the order (a Wall screen chimes once per new order instead — it cannot acknowledge, so a ring there would never stop). Each card carries one big button that moves the order on, and it follows the order's channel on every layout: Start preparing on a new order (this is what acknowledges it — it records who started it and when), then Delivered for a table order, Ready to collect then Collected for a collection order, Ready then Out for delivery then Delivered for a delivery order. Where your team ticks items off on the Pass layout, the Counter and Wall show each item's live progress read-only ("Made" — or "2 of 3 made" where identical items are listed one per line), and an order whose making is finished moves into Ready until someone finishes it. Every other staff screen also gets a centred pop-up, a bell entry and a ding for each new order (each account can switch its own alerts off in notification preferences).

Pre-orders on the same screen

Where a venue has switched on Show pre-orders on the kitchen screens (Settings → Pre-orders), each of today's submitted or paid pre-orders appears on this screen as its own ticket beside the orders — headed Pre-order, with the table, the customer's name, the party size and the booking time, every dish and who it's for, and the allergy or notes text typed on that booking. It goes live (and rings like a new order) Start cooking before the booking minutes before the booking, or the moment the party is seated; Start preparing acknowledges it, each station marks its part done (or one Done where you don't split stations), and it leaves the screen once every station has. Nothing is charged or refunded from a ticket — the money stays on the booking. A venue with pre-orders but no Order & Pay gets this screen for those tickets alone, with the Order & Pay controls hidden. See How does pre-ordering work for large bookings?.

Ticking items off

Tick items off as they're made (the Screens section of Orders → Settings, on unless you switch it off) makes each item on the Pass layout a tick target: tap it as it's plated and the tick shows live on every screen — the Counter and the Wall mark the item "Made" moments later. Ticking a station's last item marks that station's part done (any Pass screen can do it, including one showing Everything), and where you don't split kitchen from bar, ticking the last item marks the whole order prepared — it moves to Ready. Switch it off and cards carry buttons only; nothing is ticked. Group identical items (on by default) shows two of the same dish as one line with a count; off, each is listed separately so your team tick them off one at a time. The Wall layout never ticks — it has no taps.

Orders placed for a later time

A collection or delivery order booked for a later time waits in Upcoming and drops onto the live lane — ringing like a brand-new order — at its start-cooking moment: the promised time minus that channel's wait (the "about N minutes" figure). Each upcoming card says when it starts cooking and how long until then, and the kitchen printer prints its docket then, not when the order was placed — the printer collects it from our server itself, so it prints with every screen off. The Pass and Wall layouts show one line with the countdown ("Upcoming · 3 — next starts cooking 18:15, in 12 min"); on the Counter the strip opens to the cards, each with Start now (staff with the orders permission — it drops onto the board and prints at once) and Print now — a heads-up copy to your kitchen printer, split by station like the drop docket and headed HEADS-UP COPY — COOKS AT with the start-cooking time; the cooking docket still prints at the drop, so the kitchen never loses its cue. With no printer paired, the button opens the docket in your browser instead. Changing a channel's wait on the board's Wait control moves when today's scheduled orders start — a longer wait starts them earlier — and the dialog says so.

How long is each screen signed in?

Printing never depends on any screen. Beyond that: a Counter or Pass screen on a dashboard sign-in stays signed in for 24 hours from sign-in (checked when the page loads or the tab comes back into view) and its taps work for 24 hours — past that a red strip says "Session expired — sign in again"; on a staff-portal sign-in (a PIN) the screen stays signed in for 12 hours and its taps keep working for up to 7 days, with a PIN to get back in. A Wall screen, on either kind of sign-in, is never signed out for age — it cannot act, so there is nothing a stale session could do; it reconnects and carries on when the iPad wakes, and says "Board offline" if the connection drops rather than looking healthy. "Keep service screens signed in" (Settings → Security policy, on by default) keeps every layout free of the idle sign-out. The same table sits under How long is each screen signed in? in the Screens section.

Sounds

The bell button on the board's top bar opens Sound on this screen — each physical screen chooses how new orders sound there: Repeat (ring every few seconds until seen), Once (a single ring per new order) or Off, plus a Ready alerts switch (one ping when an order becomes ready, and one reminder ring if nobody has collected it after a set delay). The venue-wide defaults every screen starts from live in the Sounds section on Orders → Settings: the new-order sound, whether wall pass screens chime once per new order, whether ready alerts are on, and the Remind after delay (1–30 minutes, 2 by default). A screen's own choice always wins on that screen.

Splitting orders between the bar and the kitchen

If drinks are made at the bar and food in the kitchen, turn on Split orders by station (the Screens section of Orders → Settings, off by default — with it off, nothing changes anywhere). Each menu category then goes to one screen — set its Station on the category's form on the Menu page (categories start on the kitchen screen), with a per-dish Station override for the odd exception like a dessert wine. An order with both shows as two tickets, one per screen, each listing only its own items, and each screen marks its own part done — once every screen has finished, the order shows as Ready everywhere (the Counter's Ready lane and the Pass and Wall layouts' Ready column) and waits for someone to finish it with the channel's own button; a part-done order says so honestly on the combined view ("Bar done · Kitchen preparing").

Give a device its screen with the This screen is picker in the Orders screen's footer — Everything, Kitchen or Bar, beside the Counter · Pass · Wall layout choice. It's a per-device choice you set deliberately: a device with no screen set shows every order exactly as before, and a bar device only rings when an order carries bar items. A screen showing Everything can mark a collection order Ready to collect — or a delivery order Ready, before Out for delivery — itself even when orders are split by station — one tap marks every station's part done, so the customer's order page shows it ready. The waiting timer on every ticket runs from the moment the customer paid, whichever screen is slower. If station splitting is later switched off, a device still set to one screen shows a loud notice (and every order) rather than quietly hiding half your tickets.

Tap the card itself to open the order's panel (a full-screen view on a phone) — the full order with everything else your team can do:

Orders containing alcohol require the customer to confirm they're 18+ before paying, and your team checks photo ID at the table — choose what happens if they can't show ID in Orders → Settings → Receipts and age checks: pick a ready-made policy ("No refund on alcohol if ID can't be shown", "Alcohol refunded — the rest of the order stands" or "Please ask our team") or write your own wording (customers see it before they pay).

Collection and delivery on the same board

With collection and delivery switched on (see Collection and delivery for the full setup), remote orders join the same Orders screen — no second screen:

Taking an order over the phone

The board's New order button opens New collection or delivery order — staff pick the Order type, when it's for (As soon as possible or Pick a time), the customer's name and phone, and the dishes — search the menu as you type (dish names and descriptions both count) or tap a category chip to narrow the list; Add puts a dish in the basket and a −/+ stepper on the row changes the quantity (a dish with choices shows Choose… and opens its options first). The basket's item count and running total stay pinned at the bottom next to the place-order button, and Review opens the lines to adjust them. Then choose How the customer pays: Cash on collection / Cash on delivery (Place order — cash at hand-over), Card — send a payment link (Create order + payment link — the customer pays on their own phone and the order goes live the moment they do), or Card taken at the venue where you've switched that on (see below). Staff orders go through exactly the same checks and pricing as customer orders. The picker shows the menu exactly as customers see it on collection and delivery: a dish that has sold out for the day is greyed with a Sold out tag, a live special shows its special price, and a section that is switched off or outside its serving times is greyed with the reason.

Finding a customer you already know. The phone-order form has the same Find customer search the booking forms have — type an email address, a phone number or a name and pick the match. Their name, phone and email fill themselves in (each marked From profile), any delivery addresses they've saved appear as buttons you can tap to fill the address in one go, and anything on their profile about allergies or dietary needs shows as an amber note right above the allergy tick — it's what they told you last time, so still ask. Customers are always filed under their email address, so searching by phone finds them and fills their email in from the profile; there is no separate phone-only record. If you change an email that came from a profile, a one-tap prompt asks whether to use the new address (a different person) or keep the one on file, so a typo can't quietly create a second record. Customer search needs Alacarte and above.

No email? Take the order anyway. An email is never required — the order goes through without one. It's worth asking for, because it's the only way the customer gets a receipt or the payment link by email, and it's how the order joins their customer record for loyalty and offers. The form says so under the fields rather than blocking you.

Checking a delivery address before you take the order. On a delivery order the address box is the same address search customers get. The moment a postcode is in, the form answers straight away — You deliver here — £2.50 delivery with the free-over threshold where you have one, or Outside your delivery area, or That address couldn't be found. You see it before a single dish is keyed in rather than at the end. If the check can't be reached the form says so and lets you carry on: the address is checked again for real when you place the order. Under the address, Ask the customer first: save this address to their account for next time? saves it to their record (it needs their email, since that's what the record is kept under) and files it as **Added by your name**, so the customer can see who put it there.

Card taken at the venue

If you take cards on your own machine, switch Card taken at the venue on for collection or delivery in Settings → Order & Pay → Collection & delivery. It's a separate switch from Accept cash and starts off, so a cash-only venue never sees a card button. With it on, the phone-order form offers it as a third payment option: the order goes straight onto the board and the amount shows as Card to take on the board, the docket and the customer's receipt, instead of Cash to take. No card details are ever entered into ResoFlow and no money moves through us — it just records the truth so nobody has to press Cash and hope. In your figures it's counted on its own: the daily sales email and the Orders analytics show Card at the venue separately from cash and from card, and past-orders CSV exports carry a Paid by card at the venue (£) column, so your cash count and your Stripe payout both still add up. It carries exactly the same 50p + 1% platform fee a cash order does, billed monthly the same way.

Refunding a cash or card-at-venue order

Repayment for these orders happens outside ResoFlow. Return the money in cash or through your own card machine, then open the order and choose Record a cash refund… — enter the amount (it defaults to everything still paid) and an optional note, and approve it with a manager's PIN or an owner/admin password, exactly like a card refund. Nothing is charged or moved by ResoFlow. The refund shows in the order's detail, as a Refunds line in the daily sales email and the Orders analytics, and on the Payments page; the customer is emailed a confirmation worded for cash (or for your card machine); and the order's share of the monthly 50p + 1% platform fee is reduced in proportion — refund half the order and half its fee comes off the pot, refund it all and the whole fee comes off. The order itself stays delivered; only the money record changes. If you try Refund an amount… on a cash order instead, the screen tells you plainly to use Record a cash refund….

Checking cash-order platform fees

Account → Billing → Cash order fees shows fees not yet invoiced, available fee credits, invoice checks in progress and verified unpaid invoices. Refresh loads the recorded statement and its last update time. Invoice status reflects the last recorded check. Invoice history loads in pages; Show more invoices loads the next page. Earlier months with unverified balances have their own history. If a history page cannot be loaded, Retry history keeps the statement totals and earlier pages visible. If the statement is being reconstructed or needs reconciliation, it explains that instead of showing an assumed zero balance.

A recorded cash or card-at-venue refund reduces the original order's platform fee proportionally. The full fee credit is retained, including when the earlier month's invoice was already billed or there are fewer new fees available to offset it. Credits apply to cash-order platform fees; they are not a cash repayment or general account credit. Editing a cash order records its fee adjustment with the order update. These fees are normally invoiced separately on the 2nd of each month. Net fees under £1 roll over.

A finalised unpaid invoice stays visible with View invoice. If Stripe carries a small remainder to its customer balance, the statement names that carried amount separately. A later invoice may include it; ResoFlow keeps the original remainder tracked until its exact application is verified and avoids counting it again as new fees. Earlier balances need verification means historical counters are not yet a confirmed amount due. An invoice being checked is not confirmation of payment; ask support to reconcile it before arranging another payment.

Editing a live order

Any live order's panel offers Edit order — add dishes, remove them, or change quantities. Existing dishes keep their original prices and saved allergen information; newly added dishes use the current prices for that order's channel and save the menu's declared allergens. If the new total is higher, the screen creates a Top-up payment link to send the customer for the difference (on a cash order, the cash total to take simply updates); if it's lower, the difference is refunded — behind the same manager approval as any refund. The kitchen's tickets reprint with the changes, and the customer's receipt and order page stay honest. An order paid partly with a gift card or carrying an offer or loyalty reward can't be edited this way yet, and a set menu can't be added mid-edit — the screen explains these limits.

If the customer loses the top-up link or it expires (payment links last 72 hours), the order's panel offers Re-send payment link — a fresh link for the amount still owed goes out by email or text, and the old link stops accepting new payments. If a payment was already processing on a replaced link, it is recorded for the payment-link refund process. Only a payment matching the current unpaid amendment settles the order's balance.

Past orders

The board only shows live orders — the moment one is delivered or rejected it moves to Past orders (the clock icon on the board's top bar, or /dashboard/orders/history). There you can look back over every order the venue has ever taken: pick a date range, filter by table or status, search by customer or dish, and open any order for the same detail the board showed — the items and choices, kitchen notes, tip, gift-card and card split, any promotion, the VAT summary and any loyalty points earned. A Download CSV button exports the filtered list (Plus plan and above or a paid Gift Cards, Loyalty, Tickets or Order & Pay product — the Order & Pay product includes it — like every CSV in ResoFlow). The CSV's VAT column is headed "VAT (£, before refunds)" — refunded money isn't netted out of it — and it's blank for a venue with no VAT number on file, matching the rule every other surface follows: unregistered venues never show VAT anywhere.

Refunding a past order. From an order's detail, staff with the refund permission can refund two ways — both behind the same manager PIN (or owner/admin password) as the board's reject button. Refund items… ticks the exact item(s) to return — and where the customer ordered more than one of something, how many of them (one of two colas, say — set menus and deals included, each one refunding as a whole bundle at the price the customer paid for it, including any supplements or upgrades): the price the customer paid for them goes back to their card — if the order carried a promotion or a loyalty reward, that's the discounted price they actually paid, never the full menu price; fully refunded items show struck through in the order's detail, part-refunded ones carry a "1 of 2 refunded" note. Refund an amount… returns any part (or all) of the card payment — for a goodwill gesture or a disputed bill — either as a fixed amount (£) or a percentage (%): a percentage is worked out on the order total excluding the tip unless you switch on Include the tip, is rounded down to the penny, and never exceeds what's left of the card payment (if the percentage comes to more, you refund what's left and the dialog says so). Either way the order itself stays delivered; only the money moves, and every refund shows in the order's detail, on the Payments page and in the Activity Log (item refunds name what was refunded; percentage refunds show the percentage used). Partial refunds return card money only. Completing the card refund also re-credits any gift-card cover and returns a redeemed loyalty reward, as a rejection does. A cash or card-at-venue order has no card payment to send back, so its detail offers Record a cash refund… instead — see Refunding a cash or card-at-venue order above.

Fees when money comes back. The ResoFlow platform fee — the flat 15p on a table order, or the 50p + 1% on a collection or delivery order — isn't returned when you reject or refund a paid order, in full or in part (the one exception: if a payment ever completes while your ordering is switched off, the automatic refund returns everything — the platform fee included). Stripe does not return its own card-processing fees when a payment is refunded. Those fees are charged by Stripe under your Stripe agreement and are paid to Stripe directly — ResoFlow never receives or holds any part of them.

Receipts, VAT and loyalty

Every customer gets an itemised receipt email — each dish with its choices, any tip, promotion or gift-card cover, and the total. If you've entered your VAT number (Settings → Payouts and Stripe), the receipt also breaks down the VAT included, using each dish's VAT rate from the Menu page (new dishes can pick their rate up automatically from a category or venue-wide VAT default — see the menu guide), and closes with a "Tax invoice provided on behalf of…" line naming your business. The Registered business name field next to the VAT number (Settings → Payouts and Stripe) is the legal name behind your venue — a limited company name, for example — and it's what that line shows; leave it blank and your venue's trading name is used instead, with your venue address added when it's set. The same line appears on every money receipt at a VAT-registered venue — event-ticket confirmations, paid-in-full booking confirmations, customer pre-order receipts and the daily Order & Pay sales email. Where your venue also runs our loyalty scheme (Pro and above, or the standalone Loyalty product — Order & Pay alone doesn't include it), loyalty members earn on orders automatically when they sign in at the checkout (an emailed code the first time; the device stays signed in for 30 days) — their receipt quietly says what they earned and how far the next reward is. A customer who skips signing in still orders normally but doesn't earn. Non-members see a one-line invitation to join.

Members can also spend a reward at the checkout where you've switched on Let members use rewards when ordering in the loyalty scheme set-up (on the Rewards step; off by default) and given a reward a Checkout value (£) or linked it to a dish or category — with that toggle on, every live reward needs one or the other, and the Loyalty page flags any that lacks it. Three switches under the toggle (Rewards at the table, Rewards on collection orders, Rewards on delivery orders — all on unless you turn one off) say which kinds of order can use a reward. One reward per order: it applies after any promotion and never touches the tip, and any value beyond the order isn't carried over — no change is given, and the checkout tells the customer so before they pay. With the scheme set-up's Rewards can be used on deal prices toggle on (the default) the reward's value can come off set menu & deal money too, so a deal-only order can still use a reward; switch it off and rewards only cover individually priced dishes. A reward that covers the whole order skips the card step entirely. The reward shows as its own line on the customer's receipt, on the Orders screen and in Past orders (with its own Loyalty reward (£) column in the CSV), and your scheme's limits — the daily redemption cap and one-per-member rewards — are enforced exactly as they are on the Scanner. Rejecting the order returns the reward to the member's balance automatically, and the rejection email tells them so. On a per-£-spent scheme the reward's value comes off what the member earns on, exactly as a promotion does — earning follows the food and drink money actually paid.

Customers are also emailed automatically when money comes back: rejecting an order sends a refunded-in-full email, and a manual refund (partial, full, or by item — from Past orders or the Orders screen) sends a refund confirmation showing what came back and what's still paid; an item refund names exactly which items were refunded.

Sales figures

One more thing the order status page can carry: where your venue has customer reviews switched on, a delivered order's status page offers a "Leave a review" card — the customer's rating joins your venue page with a Dined in badge (collection and delivery orders get their own badges). See How do customer reviews work?.

Related: How do customers order and pay at the table? · How do I create and print QR codes for my venue? · How do I build my menu? · How do customer reviews work? · How do I connect Stripe?

Financial follow-up and order changes

If a refund or order edit needs another check, the order shows Financial update in progress or Financial update needs a check. Open Financial follow-up on the Orders screen or Past orders to see affected orders across all dates. The list shows the requested amount, confirmed refunds and payment/refund references. Refresh updates the list; Retry saved update is available to staff with refund permission and the usual manager-PIN or password confirmation. It retries the saved amount and items, without changing them.

A refund can span the original card payment and paid amendment top-ups. Each payment contributes only its own remaining refundable amount. Confirmed portions appear in the refund record while an unfinished portion remains in follow-up. Recovery checks run automatically every five minutes, with a wait when another check is already running. A provider processing delay, changed payment balance, or failed gift-card credit stays visible for review. Do not make a separate replacement refund while an update is pending. Order edits and completion pause while the money update is unfinished. Once it is recorded, fulfilment can continue; further financial changes wait until any follow-up work is resolved.

Editing an order respects the venue's stock settings. When tracking is on, added quantities reserve available stock for the order's promised service day. Removed counted quantities return to stock when the edit completes. This applies to swaps too, including a cheaper replacement that needs a refund. There is no stock override in the amendment dialog; correct an inaccurate stock count in the stock tools before trying again. Turning tracking off keeps the existing behaviour without a stock limit.

Venue-initiated rejects and refunds retain the ResoFlow platform fee. A system-failure refund returns the fee. A refund record is a retained financial record: customer erasure removes identifying guest fields and staged guest notes while keeping amounts, stock facts and payment references.

A bank may later report that one refund failed. The successful portions keep their own amounts, and the failed reference remains visible in Financial follow-up. Payment-history totals count only confirmed portions; any tax allocation that cannot be established remains unattributed. A failed bank refund requires a payment review; retrying a saved update does not automatically issue a replacement or mark it paid.

Resolving a card refund that has failed

Financial follow-up on the Orders board and Order history keeps a failed refund open until its outcome is known. The owner can use Resolve repayment. Other team members need the explicit Resolve failed refunds (record completed repayments) permission; ordinary Admin or Manager access does not include it. A downgraded plan does not remove care for an existing paid order.

Arrange any alternative repayment with the customer outside ResoFlow first. Then record the exact completed bank transfer or cash repayment with its date, unique transaction or receipt reference and reason. Do not enter bank details, card numbers or customer contact details in those fields. Alternatively, link a replacement refund already created in Stripe on the same original payment. This action does not create a Stripe refund or send a bank payment.

Review the details, then confirm with a fresh password or an authorised manager PIN. ResoFlow checks the failed refund, returned-funds evidence, original payment, dispute state and complete refund history again. An uncertain or pending original refund cannot be marked as repaid. A pending replacement stays open until Stripe confirms its outcome. A partial repayment leaves the exact unpaid remainder visible.

The original failed refund remains in the history. Stripe-confirmed refunds, venue-recorded bank repayments and venue-recorded cash repayments are shown separately. Saved order updates and their follow-up checks resume when all required repayment amounts are resolved; retrying does not create another copy of a recorded repayment. If a later provider outcome could duplicate money already repaid, the queue stays open for payment review. This flow does not automatically recover an overpayment or provide a generic “mark paid” override.

Outstanding gift value and linked replacements

If an order refund cannot return all gift value to the original card, Financial follow-up → Review outstanding gift value checks the original spend, linked earlier returns, original expiry and any purchase refund. Staff need Manage orders and Refund gift cards, plus fresh password or manager-PIN confirmation and a reason. It works for care of an existing paid order after a plan downgrade. The amount is calculated by the server; staff cannot increase it or convert it to cash.

A verified residual can be issued on one linked replacement gift card. This creates no new sale or payment. Its original expiry is preserved, including an expiry date that has passed. Use the existing explicit Extend expiry action if the venue decides to honour an expired card; replacement issuance never extends it automatically. Missing original terms, unlinked manual adjustments or unverified purchase refunds stay open for review. Do not issue another ordinary gift card to bypass that review.

The new code is shown once for printing or handover; this action does not send an email. Save it and give it to the customer. If the response or code is lost, open the order’s details and choose Replacement gift-card access. An explicitly confirmed access-code change invalidates the previous code while preserving the existing card, remaining balance and expiry. Retrying an issue or code-change request never silently rotates a code or issues more value. A fully spent or void replacement cannot have its code changed through this flow.

The queue clears only after the gift ledger covers the obligation and independent order follow-ups finish. Card refunds, original-card returns and linked replacement value are shown separately in the order and reports. A replacement records gift value issued; it does not claim the customer has received an email or a cash repayment.