Key topics
Related public pages
If you need the product, API or operations page rather than only the article, start with these VPOS.am sections.
Payment should be connected with table and POS check
If payment arrives as amount without table id, order id and check id, cashier and manager reconcile it manually.
In restaurant, cafe, food court or bar, payment flow often starts from table, QR menu, waiter, cash desk, delivery order or pre-order form. If payment is not connected with table id, POS check id, order lines and channel, team later cannot know which check to close.
Practical flow creates payment request from POS or backend: table/order id, check id, amount, currency, channel, expiration and service context are fixed before payment. POS receives paid status only after trusted webhook or server-side status lookup.
- store table id, order id and POS check id;
- separate dine-in, takeaway and delivery channel;
- do not close check from return URL or screenshot;
- sync cashier, kitchen and CRM/POS after verified payment.
Split bill, tips and service fee should be separate lines
Bill split, tips and service fee have different rules, recipients and reporting.
Split bill can create several payment attempts for one POS check. Tips can belong to waiter, shift, team or venue. Service fee can depend on venue rules. If all of this is merged into one amount, payouts, refunds and reports become wrong.
Backend should store line type, recipient, shift, consent/status fields and refund path. Do not add tip or fee automatically without clear rule and visible confirmation in interface. Partial order refund should not delete original payment and tip history.
- connect split bill with one POS check id;
- store tips separately from food/order amount;
- service fee needs rule and guest visibility;
- partial refund should not break payout report.
Daily reconciliation should see cash desk, delivery and provider report
Restaurant should close day by POS, delivery orders, verified payments, refunds, tips and provider references.
For restaurant, provider amount is not enough. Team needs to see which checks are closed in POS, which delivery orders are paid, where partial refund happened, where tips entered payout report, and which payments wait for manual review.
Reconciliation compares POS checks, shifts, delivery channels, verified payments, refunds, tips ledger, provider report and accounting export. Manager sees real exceptions instead of searching payments in messenger and bank cabinet.
- reconcile POS checks and provider references;
- see void, refund, partial refund and duplicate attempts;
- close shift after tips and orders reconciliation;
- do not store unnecessary guest personal data in payment log.
FAQ
Can restaurant check close immediately after return URL?
Prefer closing check after server-side verification or trusted webhook. Return URL can open before final payment status.
How should online tips be recorded?
Store tips as separate line with recipient or shift reference, payment id, refund path and payout status.
What if guests split the bill?
Create several payment attempts connected with one POS check id and close the check only when split bill rules are satisfied.
