Split payment in restaurants: cash and card on one bill, and the card at the table through the API
Half cash, half card: the API takes one payment method per document, so a mixed bill is the receipt plus an 8.4. How to send them, what happens when the bill is split across receipts, and how the card on the terminal works.
The table's bill is €44.20. One guest pays €20.00 in cash, the other €24.20 by card. For the waiter it is one move. For a restaurant ordering system it is the most frequent integration question: how to declare two payment methods on one receipt.
The API takes one payment method per document. A mixed bill is two documents: the receipt for the full amount, and a POS payment receipt for the card part only.
Cash and card: the receipt and the 8.4
Two calls, in this order:
| Call | Document | The fields that matter |
|---|---|---|
| 1 | 11.1 Retail receipt for the full amount | payment_, on credit, no terminal |
| 2 | 8.4 POS Payment Receipt for the card | pos_device_id, payment_, the receipt's ΜΑΡΚ in correlated_ |
The terminal charges only the 8.4's amount, and the 8.4 takes its ΜΑΡΚ once the payment is approved. The cash part needs no further document. If the receipt settles order notes, it carries their ΜΑΡΚ too, like any table receipt. Both complete bodies are in the JSON examples for mixed payment.
When the bill is split across receipts
If each guest wants their own receipt, you issue one receipt per part, each with its own payment method. When the table has order notes, the conservative implementation puts the note's ΜΑΡΚ on every receipt that settles it, because ΑΑΔΕ's text speaks in the plural of "the revenue documents concerning" the note.
Your system keeps track of what is left to pay on each part, because the table's total counts the notes not yet correlated, not the money still owed: the first receipt for part of the bill, carrying the note's ΜΑΡΚ, takes it to zero at once. Never read "0" as "paid in full". The table closes after the last receipt, with POST /catering_tables/:id/close, because it does not close by itself.
Card on the terminal
When the whole bill is paid by card, the receipt itself goes out with the terminal: pos_device_id and payment_method_type: 3. The response is pending, the receipt takes its ΜΑΡΚ once the payment is approved, and the result arrives by webhook: the issued receipt on success, and a failure or cancellation separately. The body is in the JSON examples for the card on the terminal.
- Over the cloud. Wrapp sends the amount to the terminal server to server. Nothing is installed in the venue and you never talk to the acquirer separately.
- Mandatory interconnection. Α.1155/2023 requires the card terminal to be interconnected with the system that issues the receipt. When you issue through the API, the terminal connects to Wrapp.
- Plan. A connected terminal from Wrapp Core up, on the Wrapp plans page.
- Staging. Only Viva demo terminals work on staging. Real terminals are registered on the production account, with their Merchant ID and Terminal ID.
If the receipt has to exist before the guest pays, for example for delivery with the card at the door, the flow is different and is explained in the guide to aade_preloaded.
Why it matters which document charged the card
A refund to the card always points at the document that charged the card. If the receipt charged it, the refund is an 11.4 credit note. If an 8.4 charged it, the refund is an 8.5, and the sale is reversed separately. Both flows are in the guide to refunds to the card.
How to start
Sign up free at wrapp.ai with your VAT number and press "Try the API": you get a login email and an API key for staging.wrapp.ai, with no tax effect. The picture of the whole shift is in the guide to restaurant ordering systems and myDATA.
Frequently asked questions
Can one receipt carry two payment methods?
Not through the API: it takes one payment method per document. A mixed bill is two documents, the 11.1 receipt for the full amount on credit and an 8.4 for the card amount only.
Does the cash part need a document?
No. The receipt is already issued for the full amount. Only the card part needs a document, the 8.4 that goes through the terminal.
How is the 8.4 linked to the receipt?
With the receipt's ΜΑΡΚ in the 8.4's correlated_invoices. The 8.4 is sent with pos_device_id and payment_method_type 3, the terminal charges its amount, and it takes its ΜΑΡΚ once the payment is approved.
The bill is split across several receipts. What about the order note?
The conservative implementation puts the note's ΜΑΡΚ on every receipt that settles it. The table closes after the last receipt, with POST /catering_tables/:id/close.
Does anything need installing in the venue for card payments?
No. Wrapp sends the amount to the terminal over the cloud, server to server, and the receipt takes its ΜΑΡΚ once the payment is approved. The terminal has to be connected to Wrapp, as Α.1155/2023 requires.
Need help?
If you have a question about this topic or want to make sure everything is set up correctly, contact us and we will look at it together.