Payments
Tax
Multiple rates, inclusive pricing, and the one figure you are allowed to display.
Tax is a specification, not a detail. A buyer who cannot find on your site what the receipt in their hand states will ask about it, and "our website does not show that" is not an answer a business wants to give. Show it on the cart, at checkout and on your confirmation page.
The configuration
Everything you need comes back in the tax block from the restaurant settings endpoint, or from your customer's tax settings under Settings then Organization then Tax.
{
"enabled": true,
"label": "BTW",
"prices_include_tax": true,
"rates": [
{ "id": "8f1c...", "name": "Laag (eten)", "rate": 9, "is_default": true },
{ "id": "b2d7...", "name": "Hoog", "rate": 21, "is_default": false }
]
}| Field | What it decides |
|---|---|
enabled | false means this business does not charge tax. Show nothing at all. Not a zero, nothing. |
label | What to call it: BTW, MwSt, TVA, VAT. Use it verbatim. A German receipt saying "VAT" reads as foreign software. |
prices_include_tax | Whether the listed price is already the final price. |
rates | Every rate this business is registered for, each with an id, a name and a percentage. One is the default. |
Inclusive or added
| `prices_include_tax` | Means | Show |
|---|---|---|
true | The listed price is what the buyer pays. | The tax contained in the total. The total does not change. |
false | Tax is added at checkout. | That the buyer pays more than the menu showed, and say it before the payment screen rather than after. |
Why there is more than one rate
A menu spanning food and alcohol has more than one rate. In the Netherlands food is 9 percent and alcohol 21, so a single average would be wrong for any order mixing them.
A catalog item carries its own rate in the field your customer mapped. Anything without one falls back to the rate flagged is_default. You do not have to resolve this yourself: it matters because it explains why the breakdown has several lines.
The figure that counts
The cart does not have to estimate. Quote the basket and the same breakdown comes back before anyone commits, computed by the same function the checkout uses — see Online Ordering. The checkout returns it again on the order itself. Both are the server's arithmetic; the only figure that is a guess is one you worked out yourself.
"vat": {
"total": 4.10,
"inclusive": true,
"lines": [
{ "rate_id": "8f1c...", "rate_name": "Laag (eten)", "rate": 9,
"base": 24.20, "amount": 2.00 },
{ "rate_id": "b2d7...", "rate_name": "Hoog", "rate": 21,
"base": 12.10, "amount": 2.10 }
]
}Use it on your confirmation page rather than your own arithmetic. The server applies discounts to the taxable base, taxes fees at their own rate, and rounds once per rate group. Recompute that yourself and the two figures will eventually disagree by a cent in front of a buyer.
Print rate_name. "Incl. Laag 9%" tells someone more than "Incl. 9%", and it is what your customer called it in their own books.
Where it goes on the page
One layout rule, everywhere the totals appear: the total is the last line.
Subtotal 36.30
Delivery 3.50
Happy hour -5.50
------------------------
Total 34.30
incl. Laag 9% 2.00
incl. Hoog 21% 2.10Subtotal, then fees, then discounts, then the total, with the tax breakdown below it and quieter. With inclusive pricing the tax is already inside the total, so listing it above reads as another charge being added and people add it up twice.