Gov.uk dumped Stripe for Adyen. The reason isn't price.

What happened

On June 2, the Government Digital Service quietly published a blog post titled *"Building for the future: making change simple on GOV.UK Pay."* Two days later, Adyen issued a press release confirming what the GDS post had buried under three paragraphs of platform-speak: Gov.uk Pay, the payments platform that sits behind more than 1,000 UK public-sector services and processed roughly £2.4 billion in citizen transactions last year, has migrated off Stripe and onto Dutch processor Adyen.

The migration was not announced as a procurement win. GDS framed it as architectural — a need to "reduce coupling" between the Pay platform and any single payment service provider, and to make it easier to add acquirers, switch routing, and onboard new central-government and local-authority tenants without bespoke per-PSP engineering. Stripe was the incumbent from the original 2016 build of Gov.uk Pay. Adyen takes over as the primary card acquirer, with GDS retaining the abstraction layer that lets it swap providers in the future.

Neither party has disclosed contract value. Public procurement records for the predecessor framework put GDS's annual PSP spend in the low tens of millions of pounds, with a typical UK government framework running 3–5 years. Stripe declined to comment beyond confirming the contract end.

Why it matters

The surface read — *"government switches vendor"* — is the boring read. The interesting read is what GDS chose to optimize for, and what that says about where Stripe's product gaps now show up.

Stripe's pitch since 2011 has been a beautiful abstraction: one API, one dashboard, one reconciliation surface, and Stripe handles the acquirer relationships, scheme fees, and 3DS dance underneath. That abstraction is exactly the right trade for a SaaS company doing $50M/year. It becomes a constraint when you're a £2.4B/year platform that needs to: route by BIN to minimize interchange, settle to sub-merchants in 400+ separate council bank accounts, produce reconciliation files that map to HM Treasury's chart of accounts, and prove to the National Audit Office that every penny took a deterministic path.

Adyen's architecture is the opposite trade. It exposes the acquirer layer as a primitive. You can declare which acquirer handles which BIN range, swap them mid-flow on decline, and route the same transaction through different scheme rails depending on cost. The GDS blog post specifically calls out "multi-acquirer routing" and "sub-merchant settlement" as capabilities they wanted to bring in-house under their own abstraction — both things Stripe Connect can do, but in a way that assumes the platform looks like Shopify, not like a federation of 400 councils and 50 central departments.

The community read on Hacker News (524 points, top of front page for six hours) was sharper. The top comment, from someone who claims to have run integrations at a UK challenger bank: *"Stripe is the best PSP in the world if you're building a startup. It's the worst PSP in the world if you need to see the BIN-level decline reason at 3 a.m. to argue with your acquirer."* The second-most-upvoted thread pointed out that Adyen's gross margin is ~60% on a flat per-transaction fee that drops to under 15bps at scale, while Stripe's blended take rate on enterprise volume is closer to 80-110bps — at £2.4B/year that delta is £15-20M.

What this means for your stack

If you're a startup founder reading this, nothing has changed. Stripe is still the right answer. The integration is two hours, the docs are unmatched, the dashboard is the gold standard, and the per-transaction premium is invisible until you're doing nine figures.

If you're at a scale-up crossing roughly £200-500M in annual processing volume, this is the second major migration in eighteen months — eBay moved most of its EU acquiring to Adyen in late 2024, and now Gov.uk — and it's the inflection point where the build vs. buy math on payment routing flips. The pattern is consistent: companies hit a wall where Stripe's opinionated abstractions can no longer express their reconciliation, routing, or settlement requirements, and they migrate down a layer.

The practical implication for engineering leads: if your roadmap includes any of (a) multi-region acquiring, (b) marketplace-style sub-merchant settlement, (c) BIN-level routing for interchange optimization, or (d) regulatory reporting that requires deterministic transaction paths, start the Adyen evaluation now, not when finance asks for it. The migration itself is not trivial — Gov.uk's took roughly 14 months from signed contract to first transaction — and you want to own the abstraction layer between your code and whoever processes the cards, not let either vendor own it for you. The GDS post is unusually candid about this: their first lesson is that they should have built the abstraction layer earlier, when they were still on Stripe, so the migration would have been a backend swap instead of a frontend rewrite.

There's also a procurement angle worth naming. The Cabinet Office is increasingly explicit that critical national infrastructure should not be sole-sourced to US firms. Adyen is Dutch and EU-regulated; that's not the headline reason for the swap, but it isn't zero either, and you'll see the same logic surface in other European public-sector RFPs over the next 18 months.

Looking ahead

The interesting question isn't whether Stripe loses more government accounts — it will, on the same architecture argument — but whether Stripe ships a credible answer to the multi-acquirer use case before the next tier of platforms hits the same wall. Stripe Issuing and Stripe Treasury showed the company can build down-stack when it wants to. Multi-acquirer routing is a harder political problem than a technical one: it requires Stripe to admit that for some customers, its own acquiring isn't always the cheapest path. Watch the next Stripe Sessions keynote. If "intelligent acquirer routing" is in the deck, they're playing defense. If it isn't, Adyen's enterprise pipeline just got another tailwind.