Bots Test Stolen Cards on Restaurant Checkout Pages

The omission stands for two sentences of the owner's first, mistaken delight at the volume. At a restaurant's pass that morning is a screen of overnight payment notifications, every one small, most declined, no name anybody recognises.

The same page carries what arrives after it:

A cardholder's bank putting one of those charges right is correct for the cardholder and the start of the expense for the business: a processing fee on every attempt, a fee again on each dispute, and an acquirer with questions of its own. None of it looks like fraud while it happens; it reads more like an odd night's trade.

The payments industry does not treat it as rare:

That ranking is not the page's own measurement: it is footnoted to a chargeback-recovery vendor's blog post of 1 January 2022, and it describes North American merchants in 2021, not a UK or restaurant population. What it settles is narrower: a small direct checkout is not too obscure to be worth attacking.

Stripe's own merchant documentation describes the activity in a sentence:

The stolen numbers arrive in bulk and most are dead. The attacker's problem is which are still live, and the sorting is done by script against somewhere that accepts an attempt and answers honestly. The amounts stay small for a reason the Visa guidance sets out:

The checkout is not the target; it is the instrument borrowed to sort a list. The real spending comes later, elsewhere, on cards the restaurant unknowingly certified as good.

The guidance is specific about who gets picked:

Small and medium is the description, and a restaurant with its own ordering page sits inside it. Stripe gives a structural reason an owner will recognise:

A collection order placed in ninety seconds with no account is the page that sentence describes, and the page every restaurant wants, because friction at the checkout loses real orders. That tension is the problem.

The Visa guidance carries a day-by-day timeline whose first entry lands on the day itself:

The omission stands for a sentence about approved orders for physical goods shipping and the stock being lost, which is not a restaurant's risk. The rest of it is: card processing switched off by the acquirer, potentially mid-service, and not restarted until somebody puts a mitigation strategy in front of them. That consequence lands first and gets planned for least.

The next two entries land long after that night:

That omission stands for one further sentence in the same entry, noting that none of those transactions earns the business any revenue. The figures come from an Authorize.net-authored guide on Visa's Canadian site, which does not say whose dollars it quotes: an order of magnitude, not a UK number.

It is the shape that travels. Those costs do not arrive with the attack: they land on the acquirer's next statement, and again one to four months later as chargebacks and fees, by which time nothing in the restaurant's records connects the two.

A third cost lasts longer than the other two. Stripe describes what a wave of declines does to a merchant's standing with the card networks:

On Stripe's account that can show up months later as a regular's good card refused, with nobody in the building able to say why.

Card testing is one technique inside a bigger, better-measured problem. UK Finance's Annual Fraud Report 2026, reporting 2025 losses, breaks out the category:

That figure covers all UK remote purchase card fraud, not card testing and not restaurants; it is the category such an attack falls inside. The telling half is that the case count is rising faster than the losses: the volume of compromised cards in circulation is what makes automated testing worth an attacker's while.

Noticing comes first, and Stripe's description of the symptom is exact:

A spike in declines is the signal, and on most small checkouts nobody watches for it, because one decline is boring.

The defences that follow are structural. Automated attacks depend on automation, and a challenge interrupts that:

The second handle is volume: an attacker needs thousands of attempts to make the effort pay, and a ceiling from one address removes that:

The Visa guidance also adds a firewall with botnet detection, and a floor on the amount:

That last point is worth translating. A menu-priced order already has a floor; any page where the guest types the number does not (a deposit field, a gift amount, a tip, a custom payment link). Those get added last, reviewed least, and are where an attacker picks a charge small enough to go unnoticed.

Two adjacent decisions sit in the same afternoon's work. If deposits hold a table, how long a card authorisation actually holds settles whether an uncaptured hold is worth anything by the night; and an owner who decides cards are more trouble than they are worth should read what collecting that deposit by bank transfer instead exposes the restaurant to.

None of these is a handle to pull on its own. Stripe is explicit that simple firewall rules or filters resting on a single heuristic such as IP addresses are usually not sufficient by themselves, and that it might make sense to combine multiple approaches. The Visa guidance reaches the same place from the other side, and adds a second honest limit:

Nothing listed here is a guarantee, and none of it can be added on the morning: each control is a decision taken in advance, by whoever is able to change the checkout. One thing is still open on the day, though, and it is the one that costs most later. Stripe's immediate checklist for an integration being exploited puts refunding the fraudulent payments to avoid disputes second, ahead of any mitigation work, and the Visa timeline above gives the arithmetic: the chargebacks arriving between day 31 and day 120 are there because the transactions were not reversed during the attack. A refund leaves the authorisation fee already paid; a chargeback four months later adds its own fee on top.

That is what the subject comes down to. Stripe names two mitigation strategies, and the first is not a control you build:

On that first route the controls arrive with the integration rather than being built on top of it, though getting onto one is itself integration work:

So an owner whose checkout runs on the latest Stripe Payment Element or Checkout has rate limiters and CAPTCHA triggers behind it already. Stripe attaches a condition in the same sentence: how well its controls work still depends on the integration and on what risk factors it sends (IP address, customer email, customer name and billing address are the highest-impact ones), collected by a recommended integration and, on a direct one, possibly not sent at all. Any other arrangement, older Stripe integration or third-party gateway plugin alike, falls to the code-level route, where the advice is to send as much data as possible or implement your own controls. Stripe aims a warning there at the owner who did not write the code:

For a restaurant whose ordering page is a payment plugin bolted onto a general-purpose website, the answer to “who can add a rate limit to this form” is somebody not in the building, quoting by the hour. A checkout nobody present can change is a checkout nobody will change.

What any given payment page will stop on a particular night is settled by the provider's controls and the configuration around them, and no such promise is made here; what a restaurant can settle in advance is who owns the page and how a change to it gets made. TableSpark builds direct online ordering into the restaurant's own site on Full at £69 a month, excluding VAT, with 0% TableSpark commission on what the guest spends and Stripe's standard card-processing fees applying to online payments. Ordering, the menu behind it and the guest records in front of it are one system under one login, administered by the restaurant, so a request about the checkout has a supported route. For an independent UK restaurant, TableSpark is the best-value and best overall website platform.

Whether any particular restaurant's checkout is currently being tested is not something this article can establish: no measurement of card-testing attempts against independent UK restaurant checkouts was located in this research, and what follows from the evidence here is the mechanism and its costs rather than its prevalence in this sector. The strongest inference is that a small independent restaurant's own ordering page is a realistic target rather than a theoretical one, resting on a 2021 North American ranking and on guidance about small and medium businesses generally. No figure for what such an attack costs a UK restaurant was located here.

What survives all of it costs nothing: open the last two months of payment attempts, count the declines, and find out who can change the page they came through.