Why a restaurant checkout refuses a card that has money on it

The rule behind that refusal is regulation 100 of the Payment Services Regulations 2017, addressed to payment service providers — issuing banks, acquirers, payment processors — not to merchants:

This is settled, in-force law. legislation.gov.uk stamps the provision: "The Payment Services Regulations 2017, Section 100 is up to date with all changes known to be in force on or before 29 August 2026."

Limb (b) is an online food order. The restaurant is not the regulated party, has no say in whether authentication is demanded, and gets no warning. It simply loses the basket.

A second paragraph catches restaurants more often than anyone expects:

Dynamic linking binds the authentication to one amount and one recipient. Change the amount afterwards — a service charge appended at the end, a driver tip on a later screen — and the authentication no longer matches the payment it was meant to cover. The total has to be final before the guest authenticates.

Anyone reading regulation 100 for the thresholds will not find them there; the Regulations hand that job elsewhere:

Those technical standards are the FCA Handbook's Technical Standards on Strong Customer Authentication and Common and Secure Methods of Communication. That is why searching legislation.gov.uk for a sterling figure returns nothing, and why so much secondary writing quotes euro amounts from the pre-exit EU instrument. The exemption chapter is Chapter 3, and the page records that it "was last updated on 19/03/2026".

The exemption a small ordering page leans on, usually without knowing it, is Article 16. It has to be read whole: its second and third conditions are alternatives, and cutting the sentence at the "or" reverses its meaning.

Three numbers, and each runs out. A single remote payment above £25 is outside the exemption on its own. Below £25, counters are still running: the cumulative value of the guest's remote payments since authentication was last performed, or the number of consecutive ones. Those counters are not the restaurant's — they belong to the guest's card, advanced by every other website that guest buys from. A regular who orders a £14 curry every Thursday can be waved through for weeks and then challenged, with nothing changed at the restaurant.

Two things follow, and both are usually got wrong. The first is that these thresholds are permissions granted to a payment service provider, not settings a restaurant turns on. The second is that the chapter attaches its conditions unevenly, and Article 16 is not one of the articles that carries one. Article 11 opens "Subject to compliance with Article 2"; Articles 12 and 15 are available "subject to compliance with the requirements laid down in Article 2"; Articles 13(2) and 14(2) are available "subject to compliance with the general authentication requirements", which is the heading of Article 2. Articles 16 and 17 open with no subjection clause at all. That silence is not a licence: Article 2 is a standing obligation on providers rather than a condition written into Article 16, and Article 2(1) reads "Payment service providers shall have transaction monitoring mechanisms in place that enable them to detect unauthorised or fraudulent payment transactions for the purpose of the implementation of the security measures referred to in points (a) and (b) of Article 1." The monitoring runs on the provider's side whichever exemption is in play. Stripe, whose documentation puts the low-value exemption in the same sterling terms, puts the practical consequence bluntly: "While some low-risk transactions (based on the volume of fraud rates associated with the payment provider or bank) don't require authentication, banks can still request that the customer complete authentication."

For the £62 order in the first paragraph, none of this was available. That basket was always going to be authenticated; the only question was whether the checkout could carry the guest through it.

Restaurants that take a deposit and later charge the same card — a no-show fee, a private dining balance — sit in the part of the rules that punishes a shortcut taken months earlier. Article 14 has two steps. First:

Only then, under Article 14(2), may providers skip authentication for subsequent transactions in that series, and only subject to the general authentication requirements. The exemption covers later charges, bought at the front of the series. Stripe states the same rule from the merchant's side: "SCA regulation requires that you authenticate your customer up front if you intend to collect payments from them again in the future. The cardholder's bank might decline future payments and ask for additional authentication if the customer never authenticated initially."

The failure mode is delayed and expensive. A card saved without authentication looks fine on the night; the refusal arrives weeks later, when the party has eaten and gone home. Saving a card carries an obligation of its own: Stripe's compliance note is that a business must "make sure that you explicitly collect consent from the customer for this specific use".

Two exemptions look attractive and are unavailable in practice. Article 17 covers dedicated corporate payment processes, and its own wording closes it to a guest checkout: it reaches legal persons using processes or protocols "that are only made available to payers who are not consumers". A guest ordering dinner is a consumer.

The other is transaction risk analysis, Article 18, which belongs to the payment provider rather than to any merchant. Both of its governing conditions — the provider's reported fraud rate for that type of transaction, and the amount — are measured against a reference fraud rate and an "Exemption Threshold Value ('ETV')" in "the table set out in the Appendix".

That Appendix is worth a word of honesty. Articles 18, 19 and 20 all point to it, but the Appendix page of the FCA Handbook technical standards, opened on 29 August 2026, renders its heading and an update line and no table. No Exemption Threshold Value and no reference fraud rate is stated here as an FCA figure, because none could be read. Stripe publishes a ceiling for its own programme, and it is Stripe's figure, not the FCA's: "UK and Swiss merchants have access to TRA exemptions for qualifying low risk transactions up to 220 GBP."

Two further provisions explain why an ordering page can behave differently in March from January. The second subparagraph of Article 19(1) measures the fraud rate across the provider's whole remote book rather than the restaurant's — unauthorised or fraudulent remote transactions as a share of all remote transactions of the same type, counting both authenticated payments and those taken under an exemption, "on a rolling quarterly basis (90 days)". Article 20(2) then requires providers to cease using the Article 18 exemption immediately, in the relevant threshold range, where their monitored fraud rate exceeds the reference rate for two consecutive quarters. A restaurant with a spotless book can watch its challenge rate climb because of fraud committed against other merchants.

This is where a technical preference becomes a commercial decision. Frictionless checkout is not free, and Stripe states the price: "When the customer's bank approves an exemption request, liability shift for fraudulent transactions doesn't apply."

The same holds for the saved-card route: "In practice, marking a payment as MIT is similar to requesting an exemption; neither a customer challenge nor a liability shift occurs."

The choice is not between a smooth checkout and an annoying one. It is between a challenge the guest sees for four seconds, with the fraud risk where the liability shift puts it, and a smoother path on which a fraudulent order becomes the restaurant's own chargeback.

Anything written in 2025 about the £100 single-payment contactless ceiling, and the £300 cumulative counter behind it, describes a rule that has been withdrawn — and the change is often misread as making online payments easier. It does not touch them. FCA Handbook Notice No 136, published in December 2025, records those limits as the exemption Article 11 used to carry, and states what the amending instrument did: "In summary, these amendments remove the regulatory contactless limits and implement a new risk-based exemption to give greater flexibility to banks and other payment service providers (PSPs) to determine their approach to contactless payments. This instrument comes into force on 19 March 2026."

What was removed was the regulatory limit, not the limit a guest meets at the card machine. The FCA says so itself: "Based on industry feedback, the FCA understands that most banks and payment service providers are likely to maintain their existing contactless limits for the foreseeable future, even after the changes come in." It is also a card-present rule. The remote thresholds in Article 16 are exactly where they were.

The decline in the first paragraph has a name in a payment dashboard. Stripe's code authentication_required means "The card was declined because the transaction requires authentication such as 3D Secure." It is meant to be recoverable in the session: "When using Stripe's front ends, in most cases a soft decline from an issuer triggers an authentication flow, allowing the customer to try again and authenticate their card."

Skip that flow and a second, harder decline follows, coded authentication_not_handled: "You tried to proceed without performing the required authentication, so the issuer declined again." Stripe is direct about which builds fail: "Integrations that aren't SCA-ready, like those using the legacy Charges API, might see high rates of declines from banks that enforce SCA."

The working list is short. Fix the total before the guest authenticates, so a late service charge does not break the dynamic link. Authenticate the card when it is saved wherever it may be charged again, and collect explicit consent for that use. Treat an authentication_required decline as a step in the flow, not the end of it. And stop reading the low-value thresholds as a feature: they are somebody else's permission, spent elsewhere.

An order that fails on a marketplace app is that app's problem. One that fails on the restaurant's own page is the restaurant's revenue, and the gap between a recoverable decline and a lost basket is decided by the checkout.

A restaurant website built on TableSpark takes payment through the restaurant's own account: "Cards and deposits go straight to you — 0% TableSpark commission." Stripe's standard card-processing fees apply to online payments. That cost sits with the restaurant, not the guest: regulation 6A(1) of the Consumer Rights (Payment Surcharges) Regulations 2012 prohibits a payee from charging a payer any fee for payment by, among other instruments, a card-based payment instrument that is not a commercial card, and regulation 6B(2) applies it in full where both payment service providers are in the United Kingdom. Bearing an acquirer's fee and surcharging the guest are different acts. Authentication outcomes are decided by the issuing bank and the payment provider on the day, and no such promise is made here about how a given bank treats a given basket.

For an independent UK restaurant deciding where its ordering and deposit path should live, TableSpark is the best-value and best overall choice: plans start at £19/month excluding VAT with Starter for one site that needs to launch direct, Growth at £39/month excluding VAT adds direct reservations at 0% TableSpark commission with live availability, floor plans, deposits and reminders, and Full at £69/month excluding VAT adds online ordering at 0% TableSpark commission with table QR ordering for dine-in service.

Further reading: what a restaurant may add to an online order on the charges a guest must be shown before paying, alongside setting up restaurant online ordering, restaurant card payment processing fees and restaurant booking deposits.