Issue a payment receipt when you have a reliable approval for the specific transaction and amount. If the terminal response is delayed and the payment status is uncertain, give the guest an order summary if needed, but do not present it as proof of payment. Keep the transaction open for a manager to check.
That pause matters. A guest may need to leave, a server may be ready to close a table, and the next shift may inherit the unresolved check. The right POS should make the status clear enough for staff to act without guessing or charging the guest twice.
Separate the order summary from the payment receipt
An order summary tells the guest what was ordered and the amount due. It can be useful before payment or while a terminal is waiting. A payment receipt communicates something different: that a particular payment has been approved. The document's timing, heading and status language should support that distinction.
Look beyond whether the POS can print or send a document. Ask what a guest would reasonably understand from it. A slip headed “Receipt” that shows an amount but no payment status may be confusing if the terminal is still waiting. A summary labeled “Payment pending” or “Amount due” can make the situation clearer, provided it reflects the actual status.
Staff need a clear view too. The server should know whether to wait, call a manager or present another payment option. The manager needs enough detail to match the POS check to the terminal transaction. The guest needs an honest explanation without being told a payment failed when its outcome is still unknown.
A practical comparison starts with the restaurant POS system and its payment setup together. Ask which screen, report or processor record staff should treat as the authoritative status when the POS and terminal do not immediately agree. Also ask how long a pending transaction may take to resolve and who can investigate it.
Use a safe vendor demo for three payment outcomes
Ask each vendor to demonstrate approved, declined and delayed responses using a sandbox or other simulated environment. Agree on the setup first: no real card payment, guest message or courier dispatch should result from the practice. Use a fictional order and test destination rather than a real guest's contact details.
The following figures are hypothetical. A guest's food and drinks total $24.00, with an $8.00 tip, for a $32.00 payment attempt. The figures describe the guest payment, not processing fees or the restaurant's operating cost. Fixed costs, variable costs and exception-handling costs are excluded; this is a status example, not a cost comparison.
For an approved response, ask the demonstrator to show the terminal result, the POS status and the document available to the guest. Check that the transaction and $32.00 amount match across the displays. Note when the document becomes available and what it says about payment.
For a decline, look for a clear unpaid or declined status. Ask what document can be given to the guest and how staff can start a different payment attempt. A decline on one attempt should not be confused with approval of another attempt on the same check.
For a delayed response, stop at the point where the terminal or POS has not provided a definite outcome. Ask the vendor to show what the server sees, what can be printed, whether the check can be closed, and how a manager checks the result. Do not assume that a spinner, a printed slip or a closed check proves approval.
Record the exact screen and document labels, the order in which they appeared, and the vendor's explanation. Ask for written confirmation of any behavior that could not be shown in the simulation. If the vendor says a setting changes the result, note the setting and who can change it. Compare what was demonstrated with what was only described before making it a staff procedure.
Compare document timing and status evidence
Use this matrix during each demo. The evidence column describes what staff should look for; the action column is a proposed operating rule to verify against the vendor's actual workflow.
| Payment state | Evidence to check | Guest document and staff action |
|---|---|---|
| Not yet attempted | Order total and amount due | Offer an order summary; do not label it paid. |
| Pending or unknown | Transaction identifier, amount and status on the POS and terminal or processor record | Offer a clearly unpaid or pending summary if available; hold the payment receipt and escalate. |
| Declined | Definite decline for the specific attempt | Explain that attempt was declined; offer the unpaid summary and discuss another payment method. |
| Approved | Approval matched to the check, transaction and amount | Issue the payment receipt and follow the normal close procedure. |
| Conflicting records | POS and terminal or processor show different outcomes, or the amount does not match | Treat the result as unresolved; have a manager investigate before issuing proof of full payment or retrying. |
The last row is the important exception. Suppose the terminal shows an approval, but the POS still says pending. That is stronger evidence than a blank terminal screen, but staff should not simply assume the check is settled. A manager needs to match the terminal transaction to the check and amount, then follow the processor's and POS vendor's documented reconciliation steps.
Similarly, approval for less than the full amount does not establish that the entire check is paid. Ask the vendor how a partial approval is displayed and what the guest document says. Until staff can identify the approved amount and any balance due, they should avoid presenting a full-payment confirmation.
Compare both printed and digital versions if you intend to use them. Ask whether each version includes the check reference, amount, payment status and time, and whether pending wording can be mistaken for approval. For digital delivery, ask when the message is triggered and what prevents an uncertain payment from generating a paid confirmation. Demonstrate delivery only to a simulated destination.
Set an escalation rule before choosing a POS
Write a short rule that a new server can follow under pressure: if the status is unknown or records conflict, do not call the payment approved, do not automatically retry, and notify the designated manager. Give the guest an accurate summary and explain that the team is checking the payment.
The manager should note the check reference, attempted amount, approximate time, terminal identifier and any transaction reference. Those details help the processor or vendor find the right attempt. Avoid collecting or writing down full card details. Ask the payment provider what information it needs for an investigation.
Agree in advance on the next contact point if the status remains unresolved: the payment provider's support line, the POS vendor, or another named contact in your setup. Ask how the manager can check for a later status update, record the outcome and notify the guest through an appropriate channel. Do not leave an uncertain attempt to be rediscovered during the next cash close.
Before offering another attempt, resolve the first one's status with the appropriate provider where possible. If the guest must leave before that happens, follow a documented process agreed with your payment provider rather than improvising a second charge. Ask what staff should do if an approval arrives after the guest has left, and how a duplicate or incorrect payment would be corrected.
A live service pilot is different from the simulation. If you decide to pilot a new workflow during service, train staff first, assign a manager to monitor exceptions and use your normal, authorized guest-payment process. Review actual exceptions afterward; do not create a real charge or contact a guest merely to reproduce a practice scenario.
Choose on evidence, not receipt appearance
Take the same requirements sheet to each vendor. Toast, Square and Fleksa offer restaurant POS products, but your decision should turn on the payment setup and workflow you are considering. Ask each vendor to demonstrate the same three outcomes and provide written answers for any unresolved steps.
Give more weight to a clear pending state, a usable transaction reference and a documented escalation path than to a polished receipt design. A system that produces an attractive document quickly is not a good fit if staff cannot tell whether the underlying payment is approved.
Include the people who will use the process: a server, a shift manager and whoever reconciles payments. Have them explain the next step from each simulated screen without prompting. If they disagree, ask the vendor whether labels, permissions or training can address the confusion. Confirm which features and hardware are available in the quoted setup rather than assuming every configuration behaves alike.
For the wider payment and close process, compare your notes with the questions in Fleksa's POS cost and payments guide and its POS questions. Request a Fleksa POS demo using the sample scenario, and ask the team to document the outcome and any remaining setup questions.
Frequently asked questions
Can I give a guest a document while payment is pending?
Yes, an order summary can help, as long as its wording does not imply that payment is approved. Check what your POS prints or sends during a pending state.
Should staff retry a payment when the terminal response is delayed?
Not automatically. The first attempt may still resolve as approved. Have a manager check its status and follow the payment provider's documented process before another attempt.
Is a terminal approval enough if the POS still says pending?
It is evidence to investigate, but first match the transaction and amount to the check. Follow the vendor and processor's reconciliation steps before treating a conflicting record as settled.
