On 23 June, as England played Ghana, some pubs, shops and supermarkets ran into the sort of payment problem that no customer wants explained in technical language: their cards would not work.
Some venues switched to cash. Queues formed at cash machines. Worldpay said a third-party power disruption was causing intermittent transaction-authorisation problems on some of its platforms. The outage was eventually fixed, but the timing made the cost of a payment failure unusually visible. A busy bar can lose more than a transaction when the terminal stops. It can lose the queue.
This week, the Financial Conduct Authority returned to the same underlying problem from the regulator's side. Banks, payment firms and other financial businesses increasingly rely on a relatively small number of technology, data and operational suppliers. If one important supplier fails, the effect can spread through many firms at once.
The FCA's figures make that dependency concrete. In 2025, 27% of incidents reported to it were attributed to a third-party issue. Of those incidents, 37% were cyber-related.
Since 13 July, the Bank of England, Prudential Regulation Authority and FCA have directly overseen the critical financial services supplied by four designated technology companies: Amazon Web Services EMEA, Google Cloud EMEA, Microsoft Ireland Operations and Oracle UK.
That sounds remote from a café, salon, tradesperson or independent shop. It is not. A payment that feels like a tap between a customer and a terminal can depend on the shop's connection, the terminal, a gateway or processor, an acquiring bank, card networks and several background technology services. The merchant sees one green tick. The transaction may have crossed a long chain to produce it.
The new regime is useful, but it is not an outage shield. The FCA says explicitly that it cannot end all disruption. It also does not take responsibility away from regulated financial firms, which must still manage their suppliers and contingency plans.
The same principle applies at a much smaller scale to merchants. Your provider is responsible for its service. You are responsible for what happens in your business while that service is unavailable.
Start by asking a deceptively simple question: what would fail together?
A spare terminal is helpful if the first device breaks. It is much less helpful if both devices use the same connection, processor and acquiring route. A payment link or QR code can be a genuine alternative, but not if it travels through the same failed provider. Cash can keep some businesses trading, but only if there is change, a way to record the sale and a safe process for handling it.
The aim is not to buy one of everything. It is to find one fallback that fails differently from your main route.
Ask your payment provider what happens during an internet outage, a terminal fault and a wider processing failure. If the terminal has an offline mode, ask whether it is enabled, which transactions it can accept and what happens when they are submitted later. Do not discover the limits during a queue.
Then make the plan usable by a person who did not write it. Decide who checks the provider's status page, who puts up the sign, what staff say to customers, when they stop retrying the same card and how alternative sales are recorded for later reconciliation. Keep the instructions where the work happens, not in an owner's inbox.
There is a customer-experience point here too. "Cash only" is clear, even when it is inconvenient. "The machine is being weird, maybe try again" is neither. A confident explanation and one workable alternative will protect more goodwill than repeated taps and a growing queue.
Regulators can make the financial system more visible, better tested and quicker to coordinate when things go wrong. That matters. But no national framework can choose your till-side response.
The best payment backup is not the one with the most logos. It is the one your team can use, your records can reconcile and your customers can understand before the second person in the queue walks away.
