Before relying on QR payment for split checks, test how the system handles equal shares, selected items and custom amounts. Then check what happens when a payment fails, a guest adds a tip, or one person pays while another is still deciding. The key question is whether staff can see exactly what remains due.
Choose the split methods your restaurant actually needs. A counter-service restaurant may be comfortable with equal shares and a staff-assisted fallback. A full-service restaurant serving groups may need item selection and a clear way to assign shared dishes. Ask each vendor to demonstrate your required cases before you commit.
Choose the split methods to test
Start with a normal table check, then agree on the expected result before anyone scans a code. A QR menu alone does not necessarily let guests order or pay. Fleksa's QR ordering lets guests scan, order and pay at the table in a browser without downloading an app. Ask for a demonstration of the specific split-payment workflow you need; do not assume that every split method is available.
Equal split: Can guests divide the current check equally? Ask how the system handles a total that cannot be divided into equal whole cents, and whether a guest can pay only their share while the others remain unpaid. Also ask whether a guest can change the number of shares after a payment has started.
Item split: Can each guest select their own items? Ask how shared appetizers, modifications and items added after the first payment are handled. If two people select the same item at nearly the same time, what prevents both from paying for it? If a shared item cannot be divided, decide whether staff will assign it to one guest or use another method.
Custom split: Can a guest enter a dollar amount instead of selecting items? Ask whether the system prevents an amount above the remaining balance and whether the next guest sees the updated balance. Decide whether an arbitrary contribution is acceptable for your service or whether staff need an item-by-item record.
Include a non-phone option in the decision. A guest may not want to scan, may have a dead battery or may need help reading the screen. Ask staff how they would take that person's payment without losing track of the portion already paid by QR.
Use a two-guest settlement worksheet
The following is a hypothetical example, not a product demonstration. Assume the restaurant accepts custom amounts, the check is assigned to the correct physical table, and both guests agree on their portions. The bill is $60.00 before tips. Guest A chooses $36.00 and Guest B chooses $24.00. Guest A adds a $4.00 tip; Guest B adds a $3.00 tip.
The table below separates the bill from tips. The expected customer payment total is $67.00: $60.00 toward the bill plus $7.00 in tips. These are gross payment amounts, not the restaurant's net proceeds. Fixed costs, variable payment-processing fees and exception costs are excluded; any tax or other charge is assumed to be included in the $60.00 bill. Confirm how your own system displays those components.
| Step | Expected bill payment | Tip | Bill remaining |
|---|---|---|---|
| Before payment | $0.00 | $0.00 | $60.00 |
| Guest A pays | $36.00 | $4.00 | $24.00 |
| Guest B pays | $24.00 | $3.00 | $0.00 |
| Completed check | $60.00 | $7.00 | $0.00 |
Run the sequence one step at a time. After Guest A's payment is confirmed, the bill should still show $24.00 due under these assumptions. The $4.00 tip should be recorded separately rather than reducing Guest B's share. After Guest B pays, check that both payments are associated with the same check and that the bill balance is zero.
Now change the sequence. Have Guest B open the bill before Guest A finishes, then attempt to continue after Guest A pays. Does Guest B see a refreshed balance before confirming? Ask what happens if both guests submit amounts at nearly the same time. The answer matters most when guests have an old screen open or are using different phones.
Finally, add a late item before Guest B pays. Agree first whether the item belongs to Guest B, should be shared, or requires staff assistance. Confirm that the displayed balance changes and that Guest A's completed payment is not silently altered. If the vendor cannot demonstrate the desired handling, write down the staff workaround and decide whether it is practical during a busy shift.
Challenge rounding, tips and failed payments
For a separate hypothetical rounding case, divide a $50.00 bill among three guests. Three payments of $16.67 would total $50.01, so an acceptable allocation is $16.67, $16.67 and $16.66. Ask the vendor to show where the one-cent difference goes and what each guest sees before paying. This bill includes any tax or other charge; tips, fixed costs, variable processing fees and exception costs are excluded.
Test tips as their own line of inquiry. Can each guest add a tip to their own payment? Can staff distinguish the tip from the amount that settled the bill? Ask what happens when a guest leaves no tip or changes a tip before confirming. Do not treat a tip as payment of another guest's unpaid share.
For payment failure, agree on the expected rule: an unsuccessful attempt must not be counted as a completed contribution to the bill. In a vendor-authorized simulation, cause an attempt to be declined or interrupted using the available test controls. Check the guest view, staff view and payment record. The amount should remain due until a successful payment is recorded.
Then simulate a retry. Ask how staff can tell a failed attempt from a successful payment that is still updating, and what they should do before asking the guest to try again. A useful workflow makes the status clear enough to avoid charging twice or allowing the table to leave with an unpaid balance. If the status is uncertain, have a staff escalation route rather than guessing.
Also ask about a partial payment followed by a cancellation, correction or refund. Does the check reopen, does the balance change, and who can make the correction? Those actions may involve different screens or permissions. Your acceptance rule should say what staff must see before they consider the check settled.
Reconcile the check before live service
Arrange an authorized test environment with the vendor. Practice scenarios must not create a real card payment, guest message or courier dispatch. Use simulated payment outcomes and a designated test table or check. Confirm that the test data is separated from real service records and that staff know how to end or reset the exercise.
For each scenario, compare four things: the original check, the portions shown to guests, the payment statuses and the staff-facing remaining balance. Then compare the completed check with the transaction or settlement records the vendor provides. In the two-guest example, the check should account for $60.00 in bill payments and $7.00 in tips, with no bill balance remaining. Payment processing fees, if shown, should be separate from those gross amounts.
Ask when a payment status is final and where staff should look if screens disagree. A guest seeing a confirmation is useful, but it does not by itself explain an unresolved table balance. Likewise, a zero balance should be supported by payment records, not merely by a screen that has been closed.
Keep a simple pass-or-fix list. Record the scenario, expected result, observed result and person responsible for resolving any difference. Include access needs: can a server find the check quickly, identify the physical table and see which portion still needs attention? Can a manager investigate an exception without interrupting another table?
After the simulated checks pass, consider a limited live-service pilot only if you are ready to handle actual guest transactions. Brief the staff involved, select a manageable service period and define who monitors unpaid balances. Have a conventional payment fallback and a way to review discrepancies at the end of the shift. A pilot reduces the scope of a problem; it does not guarantee uninterrupted service or prevent every missed payment.
Make the rollout decision
Set your acceptance criteria around the service you intend to run. For example, if item selection is essential for large parties, a custom-amount workaround may create too much staff explanation. If most guests pay one bill and splits are rare, a reliable staff-assisted fallback may be enough. Either way, require a clear remaining balance and a way to investigate uncertain payments.
Compare operating costs separately from the bill-settlement exercise. Ask for a written quote covering fixed charges, variable processing fees and likely exception costs, such as chargeback or refund fees where applicable. A quoted processing rate alone is not an all-in operating cost. Fleksa states that table QR orders have no Fleksa commission; payment processing and applicable tax still apply. See Fleksa plans for current pricing; pricing information was checked in November 2026.
For the wider service decision, consider where scanning fits alongside servers and other payment options in this table-service buying guide. The QR ordering FAQ can also help you prepare general setup questions.
Next, bring your required split scenarios and acceptance criteria to Fleksa and ask for a demonstration of the relevant workflow, including the staff fallback and payment-status views.
Frequently asked questions
Should every restaurant offer itemized QR splits?
No. Choose the methods that fit your guests and staffing. If itemized splits are important, ask to see shared items, modifications and late additions handled before making them part of service.
Does a guest's QR confirmation mean the whole table has paid?
Not necessarily. One guest may have paid only a portion. Staff should check the remaining balance and payment records before treating the check as settled.
Can we practice failed payments without charging a card?
Ask the vendor for an authorized test environment and simulated decline controls. Practice must not create a real payment, guest message or courier dispatch.
