Choose payment when guests order if you want each order paid before staff prepare it and your guests are comfortable paying again for later additions. Choose payment after service if guests commonly add items and prefer one bill, and you have a reliable way to track open checks and collect payment before they leave.
The key difference is timing, not whether payment happens at the table or counter. With either model, ask what happens when a guest orders another drink, a payment fails, or staff need to correct a bill. The right answer depends on your service pattern and the workflow the software actually supports.
Map the two paths through a meal
In a prepaid flow, a guest scans the table code, chooses food and pays before the order goes forward for preparation. Staff need to see the order, its table and its payment state. If the guest wants another item, the restaurant must decide whether that item starts a separate paid order or can be added another way.
In a postpaid flow, the guest scans and orders, staff serve the meal, and payment is collected later. The restaurant needs a clear open check for the correct table or guest party. Staff also need to know when a check is ready to close and whether payment has actually succeeded.
Neither path removes staff work. Prepayment can shift work toward helping guests who cannot pay or need a refund. Postpayment can shift work toward watching open checks, resolving split bills and following up on unpaid balances. A table may also be reused during a shift, so ask how an old check is kept separate from a new party at the same physical table.
Fleksa's QR ordering lets guests scan, order and pay at the table in a browser without downloading an app. A QR menu alone is not necessarily an ordering or payment system. For either payment timing, ask the vendor to show the exact order-to-payment flow you intend to use. The QR ordering FAQ is a useful starting point for product questions.
Keep a non-phone option in the service plan. Decide who takes an order for a guest without a suitable phone, how that order reaches the kitchen, and how staff record its payment. The fallback should be understandable during a busy shift, not just when a manager is nearby.
Use a decision worksheet for your service
The following is a hypothetical comparison for one service period. It is a way to organize assumptions, not a forecast or a software quote. The restaurant expects 40 guest parties. For this exercise, a party is a group sharing a check; it is not a physical table or a measure of seating capacity.
Assume staff time costs $20 per hour for this comparison. Prepayment is assumed to require 24 minutes of staff attention for payment help and corrections. Postpayment is assumed to require 45 minutes for check collection and corrections. The operator also assumes $0 in unpaid balances for prepaid orders and $8 in unpaid balances for postpaid orders. Those assumptions need checking against the restaurant's own experience.
| Service-period input | Pay when ordering | Pay after service |
|---|---|---|
| Staff attention | 24 minutes = $8 | 45 minutes = $15 |
| Assumed unpaid balances | $0 | $8 |
| Included operating impact | $8 + $0 = $8 | $15 + $8 = $23 |
| Difference in this scenario | $15 lower | $15 higher |
On these assumptions, prepayment has $15 less included operating impact for the period. That result supports trying prepayment if the restaurant can handle extra orders and refunds without unacceptable friction. It does not show total operating cost or prove that prepayment will save money.
The worksheet includes the assumed variable staff time and the specified unpaid-balance exception. It excludes fixed software and equipment costs, processing fees, refund charges, other exceptions and any change in sales. Processing fees are payment costs; unpaid balances are amounts not collected; sales are revenue. Do not combine them as if they measure the same thing.
Replace the inputs with your own estimates. Count the minutes spent helping guests pay, closing checks and correcting mistakes; estimate unpaid balances separately. Then obtain written quotes for software, equipment and payment processing. Ask whether later additions create separate transactions and whether refunds or adjustments carry charges. A quoted processing fee alone is not the all-in cost of running the workflow.
If postpayment reduces friction for a restaurant where most parties add several items, the extra collection work may be worthwhile. If guests usually place one order and leave quickly, prepayment may fit better. Change the worksheet assumptions before making the choice; a different service pattern can change the result.
Compare unpaid orders, additions and refunds
Prepayment limits exposure to an order going unpaid when the system only sends it for preparation after successful payment. Confirm that sequence in a demonstration. Ask what staff see if a payment is declined, interrupted or still processing. An order appearing on a screen is not, by itself, proof that money was collected.
Postpayment lets the restaurant serve before collecting the balance, so an open check needs an owner. Decide which role watches open checks, who can correct them and what happens when a party leaves without paying. A server should be able to distinguish an open bill from a payment attempt and a completed payment without guessing from a table number alone.
Later additions are the counterweight. A single postpaid check may be convenient if the system can attach new items to the correct party. With prepayment, another item may require another payment. Ask whether the guest must scan again, whether staff can assist, and how the kitchen sees the new item. Do not assume either model supports combining or splitting checks in the way your restaurant needs.
Refunds deserve their own walkthrough. Suppose a paid item is unavailable. Ask who can remove or cancel it, whether a partial refund is possible, what the guest sees, and how the order and payment records show the correction. For postpayment, ask how a removed item changes the open balance. Also ask how long payment adjustments take to appear and whether any fees remain. Set staff permissions and a manager escalation path before service.
Trace one extra drink from table to kitchen
Use this separate hypothetical scenario: two guests have ordered meals and one guest wants a $5 drink after the food arrives. The initial meal amount is irrelevant to the comparison below. The $5 is the drink's menu price, not a processing fee, refund or unpaid balance.
If the first order was prepaid
- The guest opens the ordering page or asks a staff member for help. Confirm whether the existing table context is still available.
- The guest selects the $5 drink. Ask whether it becomes a new order and whether the guest must complete a separate payment before staff receive it.
- Staff identify the correct table and see that the drink is an addition, not a duplicate meal order. They prepare and serve it.
- If the drink is unavailable, staff follow the agreed cancellation and refund process rather than leaving the guest to discover an unresolved charge.
For this path, the key question is not merely whether a second order can be placed. Ask how many steps the guest takes, what payment status staff see and whether a separate transaction has a separate processing cost.
If the meal is paid after service
- The guest or staff member adds the $5 drink to the correct open check, if the workflow supports it.
- Staff see the new item and its destination, then prepare and serve it.
- At the end of the meal, the check should show the earlier items plus the $5 drink. Staff or guests review the balance before payment.
- After the payment attempt, staff confirm its final status before treating the check as closed.
Ask what happens if the guests want separate checks, one person leaves early, or the drink lands on the wrong party's bill. If the demonstration cannot show a workable correction, include the manual steps in your decision. For more on matching QR ordering to your style of service, read the table-service buying guide.
Check order and payment states with staff
Before choosing a timing model, have a server, a kitchen representative and a manager walk through the same scenarios with the vendor. Ask each person to identify what needs action and who owns it. The useful states include an order awaiting payment, a failed payment, an order ready for preparation, an open check, a completed payment and a correction or refund. Ask which of those states the product actually displays and where.
Start with a simulation in a sandbox or other vendor-provided practice setup. Use fictitious orders and table identifiers. The simulation must not charge a real card, send a message to a guest or dispatch a courier. If the setup cannot prevent those actions, ask the vendor to demonstrate the states without submitting a real transaction.
For each scenario, check the handoff: Can front-of-house staff tell the kitchen what to prepare? Can the kitchen distinguish a new drink from the original order? Can a manager find the payment record and explain its status? Include a failed payment, an unavailable item, a wrong-table correction and a guest who needs staff assistance.
A live service pilot is different from a simulation: it involves real guests and real orders. If you proceed, start with a limited service period, brief the team, and keep your normal fallback available. Record staff questions, corrections and collection work. Do not assume a practice run guarantees the same result during a rush.
Next, write down your preferred payment timing, your fallback and the exceptions staff must handle. Compare those requirements with Fleksa and ask for a demonstration of the relevant workflow, including the extra drink and a payment correction.
Frequently asked questions
Does a QR menu mean guests can pay at the table?
No. A QR menu may only display items. Ask whether guests can place an order and pay, and whether payment occurs before preparation or after service.
Is prepayment always cheaper for a restaurant?
No. It may reduce exposure to unpaid orders, but separate payments, processing charges, staff assistance and refunds can affect the comparison. Use your own service assumptions and written quotes.
Can guests add items to a postpaid QR check?
That depends on the workflow. Ask the vendor to show how an addition reaches the correct party's open check, how staff see it and how the final balance is confirmed.
