On 2 June Adyen announced it had been appointed as the new payment services provider for Gov.uk Pay, replacing Stripe. The numbers are useful for scale. Gov.uk Pay serves more than 1,700 services across 600 organisations, has processed £9 billion through 135 million transactions since 2016, and is migrating around 1,000 of those services to Adyen, covering local authorities, the armed forces, and police forces. The announcement was full of the usual procurement language about "modern infrastructure" and "no disruption or loss of functionality for paying users".
The story is not that Stripe lost. It is that the Government Digital Service could plausibly move that much volume to another provider at all. Most SMEs cannot. Most SMEs cannot even seriously consider it. That gap is the interesting thing.
What Gov.uk Pay actually does
Gov.uk Pay is a wholesale wrapper around card payments. Public-sector services do not integrate directly with a card processor; they integrate with Gov.uk Pay, which then routes the payment to whichever processor the contract is with at the time. That layer is the bit that makes the swap possible. Stripe was the processor underneath; the services on top do not have Stripe's API hard-coded into them, they have Gov.uk Pay's.
This is a design decision, not an accident. The Government Digital Service knew when it built Gov.uk Pay that no processor contract lasts forever, and that the cost of being trapped with a provider is the price you pay later as a captive customer. So they built the abstraction first, then competed the contract underneath.
Nicole Olbe, Adyen's UK and Ireland MD, said Adyen's "architecture removes complexity associated with fragmented payment systems, enabling more secure and efficient operations". That is the marketing line. The actual mechanism is that the abstraction was already there and Adyen plugged in behind it. Without the abstraction, there would have been no realistic procurement competition; the cost of moving 1,000 services off Stripe's direct integration would have made the comparison a formality.
Why this matters to an SME that is not Gov.uk
Most SMEs integrate with their payment provider directly. The Stripe API is in the codebase. The webhooks are routed to Stripe-specific URLs. The reconciliation runs against Stripe's reports. The same is true for Worldpay, GoCardless, SumUp, Square, and whichever provider the business chose three years ago because it was the easiest one to set up that afternoon.
That choice is fine in good weather. The cost of it shows up in three places.
Price. Once you are integrated, the provider knows what it would cost you to leave. Annual price rises in the run-up to a renegotiation are common. There is no realistic threat of moving if moving costs three months of engineering work.
Outage. When the provider has a bad day, your shop has a bad day. If that recurs, you have no plan B you can flip to inside a working week. We have written before about when your payment processor cannot send email; the lesson there is the same shape.
Risk concentration. A regulator, an insurer, or a bigger customer asking "what is your fall-back if your payment provider fails" is a question that needs a real answer, not "we'd cope". For most SMEs there is no real answer.
The lesson from Gov.uk Pay is not "build an abstraction layer over your payments". For most small businesses that is over-engineering. The lesson is to know in advance what the route out looks like and to leave the door open.
What to actually do
Three things turn a captive integration into a survivable one. None of them require new software this quarter.
Read the exit clause in the contract you already have. Find it, read it, and write down in two lines what it actually allows. Notice period, data export rights, what happens to recurring subscriptions, what happens to disputes mid-flight. The clause is usually shorter than the marketing material and tells you what you can actually do. If it is not in the contract, that is itself an answer worth knowing.
Keep your domain logic separate from the provider's API. This is the developer half of the lesson and it is cheap if done from the start. Anywhere your code calls Stripe directly, wrap it in a thin internal function. The cost is small; the benefit is that swapping providers later becomes a finite project rather than a re-architecture. For non-technical owners: ask your developer or agency whether this is the case. The honest answer is usually no, and "we'd like to make this easier to swap, what would that cost" is a useful conversation to start having now while you are not under pressure.
Have a second provider you have used, even if rarely. A backup account with a second processor, used for a small slice of traffic or even just kept warm, removes the worst-case panic. If the primary provider has a bad week, the second one is not new to you. This is also the answer to the customer or insurer asking about fall-back.
Know what data the provider holds for you and how to get it out. Card-on-file tokens, subscription records, payment history, the lot. Most providers can export the lot on request. Knowing the process before you need it makes the exit shorter.
Why this filing exists
Government rarely gives smaller businesses a useful worked example of how to handle vendor risk. This is one. Gov.uk Pay is a service that started small, planned for the cost of being captured by a vendor, and built the layer that makes a procurement competition possible. The substitution itself is unglamorous and the announcement was thin. The thing to copy is the planning that made it routine.
Stripe will be fine. Adyen will be fine. The interesting party to this story is the team that built the bit in the middle.
How Steelwise can help
Reading the exit clauses in your current vendor contracts, mapping the lock-in points, and writing a short fall-back plan for the providers you cannot afford to lose for a week is something we do with clients. Get in touch.