GOV.UK Pay rips out Stripe, drops in Adyen — and the abstraction held

5 min read 1 source clear_take
├── "The real story is the architectural abstraction, not the vendor swap"
│  ├── top10.dev editorial (top10.dev) → read below

The editorial argues the noteworthy achievement is that GDS swapped PSPs across 1,000+ public-sector services with zero integration changes downstream. This validates a deliberate 2020 bet to build a payments abstraction rather than a Stripe wrapper — most teams claim to build such abstractions but leak vendor-specific concepts everywhere.

│  └── Government Digital Service (GDS Blog) → read

GDS frames the migration as the payoff of an intentional architectural decision: they designed GOV.UK Pay as an internal API with the PSP as a swappable backend, anticipating they'd eventually want to change providers. Six years later they exercised that option transparently to consuming services.

└── "The vendor change itself is the story — Stripe lost a flagship UK government account to a European competitor"
  ├── The Register (The Register) → read

The Register's framing ('GOV.UK goes Dutch on payments as it dumps Stripe') treats this primarily as a commercial defeat for Stripe and a win for European payments infrastructure. The headline emphasizes the geopolitical and competitive angle rather than the engineering achievement.

  ├── Adyen (Adyen Press Release) → read

Adyen issued a press release the same week confirming the deal, positioning it as validation of their enterprise PSP capabilities and a flagship public-sector win. The commercial narrative frames Adyen as displacing an incumbent at a high-profile reference customer.

  └── @toomuchtodo (Hacker News, 386 pts) → view

The submitter chose the framing 'Gov.uk has replaced Stripe with Dutch provider Adyen,' foregrounding the vendor swap and the European provider angle rather than the underlying architecture. The 386-point score suggests this framing resonated with the HN audience as the headline takeaway.

What happened

On 2 June 2026, the Government Digital Service published a blog post titled *"Building for the future: making change simple on GOV.UK Pay"* announcing that the UK government's shared payments platform has migrated its underlying payment service provider from Stripe to Adyen. The Register picked it up two days later under the less diplomatic headline *"GOV.UK goes Dutch on payments as it dumps Stripe."* Adyen confirmed the deal in its own press release the same week.

GOV.UK Pay isn't a small surface. It handles card payments for more than 1,000 public-sector services across central government, the NHS, local councils, and the devolved administrations — everything from passport renewals to fishing licences to court fees. The platform has processed billions of pounds since it launched in 2016, originally on Worldpay, then on Stripe from around 2020.

The migration is notable less for the choice of Adyen than for the fact that it happened at all without a public incident, a parliamentary question, or a rewrite of the consuming services. GDS says the switchover was transparent to the 1,000+ services on the platform. No service team had to change their integration. No citizen-facing flow broke. That's the headline a senior engineer should read first.

Why it matters

The interesting story here is architectural, not commercial. GDS didn't build a Stripe wrapper in 2020. They built a payments *abstraction* — an internal API that consuming services integrate against, with the PSP sitting behind it as a swappable backend. The blog post is unusually candid about this being a deliberate bet: the team assumed they'd want to change providers eventually, designed for it, and six years later cashed the option.

Most teams claim to build this kind of abstraction and don't. They write a `PaymentsService` class with a `chargeCard()` method, then leak Stripe's `payment_intent_id`, Stripe's webhook signature scheme, Stripe's idempotency-key semantics, and Stripe's dispute-evidence model into every layer above. Two years in, the "abstraction" is a Stripe SDK with extra indirection, and a migration means rewriting every service that touches money. GDS appears to have actually held the line — webhooks normalised, identifiers re-issued from a Pay-owned namespace, dispute workflows owned by Pay rather than passed through.

There's a commercial subtext too. Adyen is a publicly traded Dutch processor that does roughly $1T in annual processed volume and is known for two things US developers tend to underweight: better international/SEPA coverage and an interchange-plus pricing model that scales more favourably than Stripe's blended pricing at high volume. For a government processing predictable, large-batch card volume across 1,000+ services, the unit economics almost certainly improve. GDS doesn't publish the contract value, but the procurement notice that preceded this in 2024 had a ceiling reported at over £100M across the term. That's the kind of envelope where a few basis points of interchange savings funds an entire engineering team.

The choice of a European processor over an American one in mid-2026 is also not nothing. The Procurement Act 2023 came fully into force in early 2025 and explicitly nudges UK public-sector buyers toward data-sovereignty considerations. Adyen processes in the EU and UK and is regulated by De Nederlandsche Bank as a credit institution; Stripe's UK operations route through Stripe Payments UK Ltd but the parent corporate gravity is in Dublin and South San Francisco. Read the migration with that lens and it stops looking like a pure technical decision.

Community reaction on Hacker News (386 points at the time of writing) split predictably. The senior-engineer cohort focused on the abstraction win — "this is what good public-sector engineering looks like" — while a separate thread debated whether Stripe's developer experience premium is still worth its pricing in 2026, with multiple commenters noting that Adyen's API has quietly become competitive in the last 18 months. A third, smaller thread asked the obvious question: if Pay is genuinely PSP-agnostic, why not run two providers in parallel for resilience? GDS hasn't answered that publicly, but the architecture clearly supports it.

What this means for your stack

If you've built anything with Stripe in the last five years, the honest exercise is this: open your codebase, grep for `stripe`, and count the import sites outside your payments module. If that number is greater than one, you don't have a payments abstraction — you have a Stripe SDK with a thin coat of paint. The GOV.UK Pay migration is the rare real-world proof that the boring architectural advice ("hide your vendor behind an interface") pays out, and that the cost of *not* doing it compounds silently for years.

The specific design moves worth stealing: own your own payment identifiers (don't pass `pi_...` IDs to upstream services), normalise webhook payloads at the edge so consumers don't care which PSP fired them, keep idempotency keys in your namespace rather than the PSP's, and treat dispute/refund workflows as first-class objects in your domain rather than thin pass-throughs. None of this is novel. All of it is rare. GDS's blog post is, in effect, a six-year retrospective on doing it correctly, and it should be required reading for anyone designing a payments layer in 2026.

The second-order takeaway is commercial leverage. A payments layer that can credibly run an RFP between Stripe, Adyen, Checkout.com, and Worldpay is a payments layer that pays a different price than one that can't. Stripe's pricing power comes from switching costs as much as product quality. Remove the switching cost and the negotiation changes. GDS's procurement was reportedly competitive across multiple PSPs precisely because Pay's architecture meant any of them could plug in.

Looking ahead

The next interesting question is whether Pay goes multi-PSP — routing transactions across Adyen and a secondary processor for resilience, geographic optimisation, or interchange arbitrage. The architecture supports it; the operational complexity is real. Watch the GDS blog over the next two quarters. If they ship multi-PSP routing, the playbook for public-sector and high-volume private-sector payments stacks will officially have a new reference implementation, and Stripe's competitive moat will look meaningfully narrower than it did in 2024.

Hacker News 558 pts 214 comments

Gov.uk has replaced Stripe with Dutch provider Adyen

<a href="https:&#x2F;&#x2F;gds.blog.gov.uk&#x2F;2026&#x2F;06&#x2F;02&#x2F;building-for-the-future-making-change-simple-on-gov-uk-pay&#x2F;" rel="nofollow">https:&#x2F;&#x2F;gds.blog.gov.uk&#x2F;2026&#

→ read on Hacker News
arjie · Hacker News

Surprisingly small contract. It&#x27;s interesting to see that a full government contract for a payment provider is a fraction of a US mid-size company&#x27;s cloud bill. I am constantly surprised by things like this. Here&#x27;s another: there are more foreigners in Taiwan (total pop. 25 m) than in

taffydavid · Hacker News

It hurts a little that stripe is an American company since it was founded by two Irish brothers. It could have been an EU company to begin with

siren2026 · Hacker News

I wish Adyen was as good at marketing and hype as Stripe was.Stripe is really good at making themselves look like a way bigger deal than they are.

xp84 · Hacker News

It seems to me like whole Western countries, especially Britain being outside the EU and Eurozone and with its own currency, ought to have at least one big domestically-based option for something this fundamental. It’s an odd thing to have to rely on foreign countries for.Is there a company that’s b

maelito · Hacker News

Adyen refuses small clients, under the million :&#x2F;

// share this

// get daily digest

Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.