PayMyDineCard / digital payments
Show the card or digital methods available for the configured provider and keep the selected method attached to the bill status.
Payments & Guest Ordering
Take a table from QR scan to confirmed payment without restarting the journey.
Cover 8 guest and payment moments: card or digital payment, pay-at-table, split equally, split by item, split by shares, table QR, mobile menu and guest checkout.
PayMyDinePayments & Guest Ordering
Pay at table
Open the correct bill from the table context and keep payment status visible to the service team.
Split equally
Divide the total evenly across the selected number of payers.
Split by item
Assign ordered items to individual payers while keeping the remaining balance visible.
Guest ordering & payment
Four guest actions stay in one mobile path.
Scan, browse, order and pay remain attached to the table and feed the responsible restaurant role at each step.
See the 5-step operating flow
Guest ordering & payment
One bill supports three split methods.
Guests can pay as one party or split equally, by ordered item or by shares while the unpaid balance remains visible.
See the 5-step operating flowGuest ordering and payment scope
Eight guest and checkout moments include three practical ways to split a bill.
The exact payment methods and settlement data depend on the provider and integration available in the deployment.
journey moments
Card or digital payment, pay at table, three split methods, table QR, mobile menu and guest checkout form the current scope.
bill-split methods
Guests can split equally, assign ordered items or divide the total by shares.
role perspectives
Guest, service staff, management and finance each need a different view of the same checkout.
connected journey
Menu access, ordering, service context and payment should not restart as separate experiences.
From table QR to settled status
How a guest action becomes a completed and visible payment event.
The table should understand the next step while the restaurant retains order and settlement context.
Open the table journey
A guest scans the table QR or enters the configured mobile menu and ordering experience.
Build or review the order
Items, notes and the table context remain connected as the guest or team prepares for checkout.
Start checkout
The guest reviews the bill and selects the payment path available in the restaurant setup.
Choose a payer or split method
One payer can settle the table, or the group can split equally, by ordered item or by shares.
Confirm status to the restaurant
Completed, partial or unresolved payment context returns to the team and reporting workflow where supported.
What each role sees
Guests need clarity; the restaurant needs settlement context and a clean handoff.
A simple guest interface should still provide the operational and reporting information required by the team.
Guest
Browses, orders, requests service and pays through the configured table journey without learning the restaurant's internal systems.
Service staff
Sees bill status, payment progress and whether the table still requires service or settlement attention.
Manager
Monitors incomplete payments, exceptions and the effect of checkout timing on table availability.
Finance and reporting
Reviews payment activity, method mix and reconciliation context available from the provider or POS connection.
Measure the workflow
Measure checkout completion and the time required to release the table.
Metrics must use provider and restaurant events that are actually captured in the deployment.
Bill-request-to-payment time
Measure the interval between the guest or team starting checkout and confirmed completion.
Digital checkout completion
Track completed checkout journeys against started journeys where the required events are available.
Split-method mix
Understand how often guests use equal, item-based or share-based splitting during comparable periods.
Payment and exception mix
Review payment methods, incomplete attempts and unresolved settlement states available from connected systems.
Configuration and data requirements
Payment configuration requires provider, table and reconciliation decisions.
The guest journey and back-office status need the same definitions before launch.
Supported payment provider and available status fieldsTable and QR mapping for each guest journeyEqual, item and share split rulesPartial, completed and failed payment status handlingPOS or finance reconciliation responsibilitiesRole permissions for viewing and resolving payment exceptions
Practical questions
What to clarify before choosing the scope.
The exact answer can depend on the restaurant setup, selected modules and connected systems.
Which split methods are supported?
The current product scope includes equal splits, assignment by ordered item and division by shares.
Must every restaurant use guest ordering?
No. Guest ordering, pay-at-table and payment modules can be selected according to the restaurant setup.
Does every payment provider expose the same data?
No. Payment methods, status detail, settlement fields and refresh behaviour depend on the provider and integration.
Can the team see when a table has paid?
Yes, where payment status is available to the configured operating workflow and permissions allow the role to see it.
8 ordering and payment moments
Keep the table, order, bill and payment status attached from scan to confirmation.
Guests can scan, browse, order, request service and pay while the restaurant keeps the table and order context visible.
Card / digital paymentsPay at tableSplit equallySplit by itemSplit by sharesTable QRMobile menuGuest checkout
Map the real operation
Want to explore Payments & Guest Ordering?
Book a demo and we’ll focus on table QR, mobile menus, guest checkout, pay-at-table and split-bill flows.