We’ve introduced a new Pay at Table feature that enhances the in-app payment experience by allowing customers to use their loyalty profile directly from the PAT solution - even before the check is officially closed at the POS. This update provides more flexibility for both customers and staff, especially in busy environments.

What is Pay at Table?

This feature allows members to complete their payment in advance, while the check is still open at the POS. Each customer can pay individually from their phone.
This is especially useful in group scenarios, where each diner wants to pay separately and avoid waiting for service.

How It Works: Pay at Table supports two key flows:

• Get Benefits (discount redemption)
• Submit Purchase (completing the transaction)

Under the hood, each of these flows is handled in a two-stage structure:

1. Child requests sent from individual users via the app
2. Parent request triggered when the check is finally closed at the POS

Key Challenges:

Challenge 1: Duplicate Submit Purchase Calls

What is the problem?
In Pay at Table scenarios, two SubmitPurchase (SP) requests may be triggered — one from the POS and one from the app. When both include customer identification, this can lead to data duplication and inconsistencies in reporting or loyalty logic.

What is the solution?
The system is designed to recognize and merge these requests, ensuring only one consolidated SP is processed. This prevents duplication and maintains clean transaction data.

Challenge 2: Filtered Purchases with Benefit Redemption

What is the problem?
When using a filtered purchase setup (where only certain items are eligible for benefits), and gifts or discounts are redeemed both in the app and at the POS, the same benefit might be applied twice or not burned at all. This can cause redemption errors and inaccurate tracking.

What is the solution?
The system defers benefit redemption until the final POS transaction is processed. At that point, all benefit data is merged and calculated in a single step, ensuring proper usage and accurate tracking across platforms.

 

Get Benefits Flow

Each customer can identify and use their loyalty form their PAT solution.The system saves all these individual requests (child requests) of the table members, and when the POS performs the benefits check, it merges all customers’ benefits together and calculates the final total.

This design avoids locking - meaning benefits remain available to each user until the final checkout.

Submit Purchase Flow

Each customer who makes a transaction  via the app is identified as a club member, which the system saves and marks as “Inherited” (pending).

When the POS closes the bill, all these payments are merged into one final transaction that is processed and confirmed.

This ensures that all individual payments are accounted for and reflected in a single, consolidated transaction at the end.

Real-life Example

Imagine three friends sitting together at the same table in a restaurant:

• Alice and Bob each send requests from the app to check/apply benefits and make their payments. These requests are saved in the system as “Inherited” (pending) and are not processed immediately.
• When Carol pays the final bill at the POS, the system merges Alice’s and Bob’s benefits and payments with Carol’s payment.
• Only then is the full transaction processed, combining all customers’ payments and benefits into one final bill.

This approach lets each customer pay separately and redeem benefits without conflicts, making things much easier for the staff on the floor.

Key Takeaways

• Faster checkout for customers, especially in groups
• Safe benefit redemption across multiple users, no conflicts
  No need to split checks manually
• Everything is merged into one final, clean POS transaction
  
   

Technical Requirements for Pay at Table Integrations

To ensure a smooth and reliable Pay at Table experience, all PAT providers must follow several integration requirements. These requirements guarantee correct member identification, accurate benefit usage, and proper consolidation of payments when the POS closes the bill.
 

Header Requirements

Every Pay at Table call must include these headers:

Transaction Linking Requirements

To merge multiple requests into a single final transaction, the PAT system must link its calls to the POS order.

Mandatory rules

1. Every PAT submission for the same table must reuse the same relatedTransactionId This creates a clean parent child flow that Como can merge later. 
2. When the POS closes the bill The POS must send a final SubmitPurchase using the real transactionId from PAT. This final call triggers the system to merge all the saved PAT child requests. 
3. If PAT sends SubmitPurchase before POS closes the bill Como will store the data but will not finalize it until the POS final request is received.

Behavior of Member Identification and Benefit Usage

Because multiple diners may identify or redeem benefits from different devices, the system performs all loyalty logic only after the POS finalizes the bill.

Key rules:

1. Duplicate identification: 
   If a member identifies in both POS and PAT, the system merges the data and avoids duplication. 
2. Multi member tables:
   1.  Deals apply to the first identified member 
   2. Gifts can be redeemed by any member 
   3. Points on payments are split evenly across members 
   4. All requests must share the same relatedTransactionId 
3. Redemption accuracy:
   1. Benefit redemptions applied through PAT are not burned immediately. They are burned only after all data is merged at the final POS checkout. This prevents double usage and benefit conflicts.

Payment Handling Requirements

PAT may submit payments before the POS. These requirements ensure the final transaction is correct:

1. Payments from PAT are saved as pending They are merged only when the POS closes the bill. 
2. Split payments 
   1. Each diner can pay a separate amount. 
   2. All payments are combined into the final consolidated POS transaction. 
3. Payment cancellations 
   1. Cancellations coming from PAT before the POS closes the bill are accepted. 
   2. Cancellations sent after the POS closes the bill are ignored.