Labelling the order button with an obligation to pay, and adding nothing after it

The answer has two halves and they live on the same screen. The button that submits the order has to tell the guest, in legible words at the point of pressing it, that pressing it means paying. Anything added to the price above it, whether a service charge, a packaging fee, a suggested tip or a round-up donation, has to be something the guest actively agreed to rather than something they failed to switch off. Neither half is a design problem. Both are wording and configuration, which is the good news, because wording can be fixed in an afternoon by whoever holds the login.

One boundary first. This article sets out what the cited regulations say and what that means for how a checkout is built. It is not legal advice, and whether a particular contract, button or charge falls inside these provisions depends on facts it has no access to.

Confirm is a word about the guest's intention. It says: yes, that is what I meant. What it does not say is that money is now owed, and that omission is the whole problem. The same goes for the polite alternatives a checkout can end up with: Submit, Send order, Finish, or a bare arrow.

Be careful how far this goes. The regulation does not say there is no contract in the abstract, and it does not hand you an opinion about your own screen. Regulation 14(5) is narrower: where paragraphs (3) and (4) have not been complied with, the consumer is not bound by the contract or order. The restaurant is still on the hook for everything it has already done, and the guest holds the exit. That asymmetry is what makes this worth an evening. The usual compliance question is about a penalty that may never arrive. This one is about whether the orders you already take are orders you can hold anyone to.

The regulation deals with the acknowledgment first and the button second. On the acknowledgment: "The trader must ensure that the consumer, when placing the order, explicitly acknowledges that the order implies an obligation to pay." Explicitly does real work there. Something buried three clicks back in a terms page is not an acknowledgment made when placing the order.

Then the labelling duty, where the specific words appear: "If placing an order entails activating a button or a similar function, the trader must ensure that the button or similar function is labelled in an easily legible manner only with the words 'order with obligation to pay' or a corresponding unambiguous formulation". Three things in that sentence get skipped. Easily legible rules out grey-on-grey micro type at the foot of a long mobile page. Only with is a restriction rather than a permission, so a button carrying the required words plus a marketing flourish is not obviously in the clear. And a corresponding unambiguous formulation is the flexibility the rule allows, with a standard attached; whether a particular alternative meets it is a legal question this article does not resolve. If you want the safe end of the range, the regulation prints it in quotation marks. The owner's test is one question: would a guest who read nothing else understand from those words alone that pressing them creates an obligation to pay?

Work it through in service terms, because the legal sentence understates how ordinary the damage is. A guest orders at seven forty. The ticket prints, the section starts it, packaging is used, a delivery slot is committed. At eight the guest changes their mind, or the card is disputed, or a housemate says they never ordered it. The restaurant wants to point at the order as an agreement. Regulation 14(5) points the other way, and what is left is cooked food, spent labour and a conversation nobody has time for.

The second-order effect is worse. A restaurant that suspects its orders are soft starts behaving as though they are: no-show policies go unenforced, the cancellation window slips, anything contested gets refunded on sight. That drift starts at the checkout and reaches the terms a guest sees before committing, which is why the terms your booking flow puts in front of a guest matter for the same reason the button does.

Now look at the lines sitting immediately above that button: some combination of service charge, packaging fee, delivery fee, suggested gratuity and sometimes a charity round-up. Regulation 40 governs every one that is not part of the main price.

Its rule is that "no payment is payable in addition to the remuneration agreed for the trader's main obligation unless, before the consumer became bound by the contract, the trader obtained the consumer's express consent." Two conditions, both easy to fail. The consent has to be express, meaning the guest did something to give it, and it has to be obtained before the guest became bound, which rules out revealing a fee once the order is already treated as placed.

If the extra was taken anyway, the regulation does not leave the outcome to negotiation: "Where a trader receives an additional payment which, under this regulation, is not payable under a contract, the contract is to be treated as providing for the trader to reimburse the payment to the consumer." A guest asking for a wrongly added service charge to be refunded is asking for something the regulation already treats the contract as providing. It has to be reimbursed.

The safe construction is to itemise: each addition as a named line with its own figure, above the button, before the guest commits, and anything optional switched off until the guest switches it on. That is the discipline that keeps prices and additional charges on your menu honest, because the figure a guest reads and the figure the card is charged should be the same figure.

Regulation 40 anticipates the workaround and closes it in one sentence: "There is no express consent (if there would otherwise be) for the purposes of this paragraph if consent is inferred from the consumer not changing a default option (such as a pre-ticked box on a website)." A restaurant checkout can carry several of them: a tip selector defaulted to 10%, a service charge toggle that arrives already on, a packaging fee that appears in the total without ever appearing as a choice, a charity round-up switched on rather than chosen. In each case consent is read off an unchanged default, which is what the regulation says does not count.

The direction of travel points the same way. The 7 April 2025 announcement says the CMA "will now be able to decide whether consumer protection laws have been infringed (rather than litigating through the courts) and to tackle any breaches directly and proportionately, including through consumer redress and fines", and describes a ban on drip pricing as covering the case "where shoppers are shown an initial price for a product, but more fees are added ('dripped') as they proceed with their purchase". Fees appearing between the menu price and the final button are the textbook shape of that. Keep the 10% of global turnover figure in proportion: it is the regime's ceiling, not a prediction about one restaurant with a badly configured tip selector.

Caption: rows one to six quote the operative text of regulations 14 and 40 of SI 2013/3134 as published in the made version on legislation.gov.uk; rows seven and eight come from a GOV.UK announcement published 7 April 2025 and describe a regulator's maximum rather than a likely outcome. Sources opened and re-read on 25 August 2026. Whether any of it reaches a particular contract is a legal question this article does not answer.

Do this on a phone, as a guest, from a real order you then cancel. Do not audit the checkout from the admin preview, because the preview is not always the page the guest gets.

Here is where the audit stalls. It finds the problem in ten minutes, and the fix turns out to be somebody else's.

A checkout rented from a marketplace or bolted on as a generic widget is somebody else's product. The button label is decided by whoever built it, the tip prompt is configured in their settings rather than yours, and the fee lines are whatever they chose. A restaurant in that position can name the exact wording it needs and still have no route to it, because there is no field to type into. The request becomes a support ticket, and the button says Confirm through another season. That is not a difference in convenience; it decides whether an audit produces a change or a document.

TableSpark answers that with editability. A first-party ordering route lets the restaurant control the wording of the final step and what is added to it, instead of inheriting a checkout it cannot edit. The button and the fee lines belong to the restaurant, and both are changed by the person who ran the audit rather than by whoever answers a queue.

That matters most on the day the audit finds something. A restaurant running its own ordering on its own domain can relabel the final step in the morning and have guests reading the new wording at lunchtime, itemise a packaging fee, and take a tip selector off its default in the same service, without waiting for anyone to agree the change is worth making.

The rest of the setup pulls the same way. Online ordering runs at 0% TableSpark commission, with Stripe's standard card-processing fees applying to online payments, so the amount a guest authorises is the restaurant's own arithmetic rather than platform additions arriving between the menu and the button. If you are building the flow rather than repairing one, the practical setup for direct online ordering is where these decisions get made once, at the start.

The division of responsibility is worth stating plainly. Choosing the button wording, deciding which charges apply and satisfying yourself that the screen meets the regulations are the restaurant's own calls, taken with its own adviser. What TableSpark supplies is the control surface that turns those calls into the live checkout, the same day.

Price this against the real alternative, which is not another subscription but a checkout you can describe accurately and change never. TableSpark plans start at £19 per month for Starter, Growth at £39 per month, and Full at £69 per month carrying online ordering, all three excluding VAT. Stripe's standard card-processing fees apply to online payments, and TableSpark commission on bookings and orders is 0%, so nothing sits between the total the guest agreed to and the total the restaurant keeps. Weigh that against one evening of refused orders you had no way to hold anyone to, or a single pre-ticked charge that has to be reimbursed across a month of trading. For an independent UK restaurant that wants the last button on its own checkout to say what the rules require, and to change on the day it decides to, TableSpark is the best-value and the best overall restaurant-website choice available.