To test a restaurant kiosk transaction when one gift card cannot cover the total, ask the vendor to run a simulated order with two cards, each holding less than the order amount. Watch the balance after each card, then repeat the test and cancel after the first card. Compare what the guest sees with the receipt or cancellation record and the staff payment record.
A kiosk that accepts gift cards may not accept more than one per order. It may instead allow a gift card plus another payment method, or require staff help. Decide which outcome your restaurant can live with before the demonstration. A clear fallback can be workable, but it is different from letting a guest finish independently.
Set up a realistic test order
Use the same kiosk, payment configuration, gift card program, and staff-facing system you expect to use at the restaurant. Ask the vendor to identify any differences in the demonstration setup. For example, a test environment may simulate a card balance rather than read a physical card. That can show the payment logic, but you should also ask how physical card entry would work in your intended setup.
Hypothetical example: A guest orders food and drinks totaling $24. The first gift card has $9 available, and the second has $15. These amounts are assumptions chosen for the demonstration, not claims about a particular system. The $24 is the final amount presented for payment; no additional charge is added during the example.
Before applying either card, have the demonstrator show the order total and the two test balances. Record where each number appears: the kiosk screen, a test balance lookup, or the vendor's demonstration instructions. A number entered by the demonstrator is an input to the test; it is not proof that the kiosk independently checked the balance.
The expected arithmetic is simple: $24 minus $9 leaves $15; applying the second card's $15 leaves $0. The question is whether the proposed setup can carry that sequence through to a completed order and record both payments accurately.
Use simulated gift cards and simulated payment processing throughout the practice. Do not use a real card payment, send a real guest message, or dispatch a courier. If the kiosk can send orders to a kitchen or print tickets, arrange a safe test destination or disable those outputs for the demonstration.
Compare the payment paths
The worksheet below uses the hypothetical $24 order and the same two balances. It separates the desired two-card result from a fallback that may still suit some restaurants. The vendor should demonstrate the path rather than simply describe it.
| Step | Two-card completion | Alternate-tender fallback |
|---|---|---|
| Starting amount | $24 due | $24 due |
| First gift card | $9 applied; $15 remains | $9 applied; $15 remains |
| Next payment | Second gift card applies $15 | Second gift card is unavailable; another supported simulated tender pays $15 |
| Result to check | $0 due; both gift cards recorded | $0 due; gift card and alternate tender recorded |
| Buying implication | Meets a two-gift-card requirement if records and cancellation also pass | Usable only if guests and staff can handle the alternate tender |
The fallback is not a pass for a requirement that specifically calls for two gift cards. It may be acceptable if the restaurant mainly wants to let guests use a small gift card balance and pay the rest another way. Ask which alternate tenders are supported in the proposed setup and whether the guest can complete that path at the kiosk without staff intervention.
A third result is possible: the kiosk will not apply a card unless it covers the full amount. In that case, the $9 card should not appear to have paid part of the order. Ask what the guest sees and where staff should direct the guest. If the answer is to move the transaction to a counter, include that handoff in your decision.
Look beyond the payment buttons. Can the guest tell how much remains due? Is there an obvious way to cancel or ask for help? Does the interface make clear whether the first card has been applied? A technically correct balance is less useful if a guest cannot understand the next step.
The kiosk cart management workflow is also worth reviewing when you map the steps before payment. Keep cart changes separate from the gift card test: if an item is added after the first card is applied, ask the vendor to demonstrate how the new amount due is calculated.
Cancel after the first card
Run the same $24 scenario again in the simulation. Apply the first $9 card, confirm that the screen shows $15 due, and then cancel before using the second card. This is the failure case most likely to expose a confusing handoff: the guest leaves without an order, but the first card may appear to have been used.
Ask the demonstrator to show what happens to the first card. Is the $9 application voided, released, or reversed? When does the simulated balance become available again? The answer may depend on the payment and gift card setup, so do not assume the displayed cancellation alone restores the balance.
Assign a shift manager to detect the issue in the demonstration. The manager should check the simulated card balance and staff-facing transaction record against the canceled order. If either still shows an unresolved $9 application, the manager should flag the result as an exception rather than treating a canceled screen as proof of a clean reversal.
The manager should also ask what staff would do in a real incident: where to find the transaction, who can investigate it, and what information should be recorded for follow-up. The practice itself must stay simulated. If the vendor cannot show the final balance state during the demo, record the cancellation result as unresolved, not passed.
Repeat the cancellation at other points if they matter to your operation: before any card is applied, after an unsuccessful second-card attempt, and after the guest asks for staff help. These checks do not require a live service pilot. They establish whether the basic transaction states are understandable before guests encounter them.
Set acceptance criteria before the demo
Put the following criteria in the vendor demonstration request. Name the shift manager as the owner of exceptions and give that person access to the records needed for the check. Use a second person to act as the guest so the manager can observe the staff side without prompting the guest through every screen.
- Guest display: The kiosk shows $24 due, then $15 after the first simulated card, then $0 after the second. The guest can identify the next action without an unexplained balance.
- Completed transaction: The receipt or its simulated preview and the staff record show a $24 order paid with $9 and $15 from two gift cards. There is no remaining amount due or duplicate payment entry.
- Cancellation: After canceling with only the first card applied, the kiosk and staff record identify the order as canceled, and the simulated $9 is available again. Any pending or unresolved state is visible and assigned to the shift manager.
- Fallback: If two cards are not supported, the vendor demonstrates the agreed alternative, including the amount still due, the staff handoff if needed, and a clear way to abandon the transaction.
- Exception ownership: The shift manager can locate the order and payment details and knows whom to contact when the balance and transaction record disagree.
Pass for the two-card requirement: Both cards complete the simulated order with matching display and records, and the cancellation check shows the first card's $9 available again. If any required item fails or remains unresolved, mark the requirement as not met until the vendor demonstrates a correction. An alternate-tender path can pass only if you explicitly accepted it as your requirement.
Ask to see the staff view in the proposed restaurant POS system, not just the kiosk screen. Record the configuration used and any steps the vendor performed on the staff side. That makes it easier to compare demonstrations and prevents a staff-assisted transaction from being mistaken for a self-service one.
Choose the workflow your team can support
If two-card completion passes, check whether the rest of the kiosk experience fits your operation: item entry, accessibility, kitchen capacity, hardware, and a staffed fallback all matter. If it fails but alternate tender passes, decide whether that compromise is acceptable for guests who arrive with only gift cards. If neither path is workable, ask for another configuration or keep the transaction at the counter.
Request a written quote for the proposed hardware, software, installation, payment setup, and ongoing support. Ask which charges are fixed, which vary with transactions, and whether exceptions or changes create additional costs. The kiosk break-even guide can help frame the wider cost decision; a payment demonstration alone does not establish the total cost of ownership.
Bring the worksheet and your pass criteria to a Fleksa restaurant kiosk discussion. Compare your requirements with the proposed setup and confirm current support for multiple gift cards and your preferred fallback before choosing a workflow.
Frequently asked questions
Does accepting gift cards mean a kiosk accepts two on one order?
No. Ask the vendor to demonstrate two separate gift cards in the same transaction, including the remaining balance after each one and the completed staff record.
What if the second gift card is declined?
In a simulation, check that the first payment and remaining amount are clear, then test the offered fallback or cancellation. Ask the shift manager to verify the card and transaction records before treating the attempt as resolved.
Should we test with real guests during a demonstration?
No. Start with simulated balances and payments, without sending guest messages or dispatching couriers. Consider a separate live service pilot only after the simulated checks pass and you have agreed on staff procedures and safeguards.
