Switching payment processors is a security event

Opening Claim

Gov.uk has replaced Stripe with Adyen as its payment provider. That is the confirmed fact. Everything else circulating around this change requires verification before it carries operational weight.

The change is not a vendor swap. It is a re-anchoring of the trust boundary that sits between citizen payment data and a government platform processing transactions at national scale. The party holding the keys, the jurisdiction governing them, and the operational controls enforcing them have all moved. Whether the change improved or degraded the security posture is not confirmed.

What is confirmed is that the trust relationship has been re-established with a different entity, under a different regulator, on different infrastructure. Each of those is a control surface. Each of those carries failure modes. This post is not about whether Adyen is competent. It is about what changes when a sovereign service relocates its payment trust boundary, and what that relocation means for the people whose data passes through it. The boundary moved. The accountability did not.

The Original Assumption

The original assumption with Stripe was the same assumption every organisation makes when it offloads card data to a processor. The processor owns the regulated data. The merchant owns the integration. The boundary between them is enforced by tokenisation and PCI scope reduction. Whether that assumption held in practice on gov.uk is not confirmed.

That model places trust in three things. First, that the processor environment is secure and continuously audited. Second, that the merchant integration does not leak data outside the processor domain. Third, that identity and access into both environments is governed, monitored, and revoked when relationships change. None of these are properties of code. All of them are properties of operational discipline. None of them are visible from outside the system unless they fail.

The assumption that “we use Stripe, therefore we are secure” was never a control. It was a delegation of risk. Delegation reduces operational scope. It does not remove accountability. Gov.uk remained responsible for the keys it held, the staff with administrative access, the audit logs it ingested, and the response capability if something failed inside the processor. Whether any of those controls existed in a defined state, and whether they were carried over, replaced, or rebuilt for the new provider, is not confirmed.

What Changed

The processor changed. Stripe is a US-headquartered company. Adyen is Dutch. That alone changes the regulatory regime governing the data, the supervisory authority responsible for breach notification timelines, and the legal basis under which cross-border transfers operate. The technical integration may be similar. The legal and identity surface is not. Whether the procurement decision accounted for that surface, or treated the change as a commercial substitution, is not confirmed.

When a payment processor is replaced, every identity that touched the old environment must be removed from it, and every identity required in the new environment must be provisioned with the minimum access needed to operate. Whether that has occurred cleanly on either side is not confirmed. Legacy API keys, webhook endpoints, dashboard accounts, support team access, and incident response credentials all require explicit decommissioning. Absence of evidence is not evidence of decommissioning. Old credentials that remain valid after a transition are not dormant. They are live access paths waiting for someone to find them.

The trust relationship has also moved. Stripe’s risk engine, fraud signals, and tokenisation vault are no longer the systems making decisions on gov.uk transactions going forward. Adyen’s are. Any operational playbook, alerting rule, reconciliation process, or fraud control built against Stripe behaviour and data shape is now operating against a different source. Whether the migration included rebuilding those controls against the new provider, or whether the existing controls were pointed at a new endpoint and assumed to work, is not confirmed. A control that has not been validated against the system it is meant to govern is not a control. It is an assumption with a dashboard.

Mechanism of Failure or Drift

The mechanism is identity boundary relocation under operational continuity pressure. When a payment processor is replaced, the work that is visible is the integration. New endpoints, new credentials, new SDKs, new reconciliation formats. The work that is invisible is the identity decommissioning on the legacy side and the identity provisioning on the new side. Visible work gets attention because it breaks if it is wrong. Invisible work does not break. It leaves access alive. Whether either side of that work was completed cleanly on the gov.uk transition is not confirmed.

The drift comes from the asymmetry between provisioning and decommissioning. Provisioning has a deadline. The new processor must work by go-live. Decommissioning has no deadline. The old processor still works whether anyone removes access or not. That asymmetry is structural to vendor changes. It is the reason legacy credentials, dashboard accounts, webhook subscriptions, and API keys persist beyond cutover dates inside organisations that have completed the visible work of integration. Whether gov.uk maintained a tracked credential inventory across both providers, with explicit revocation gating, is not confirmed.

Control drift compounds it. Detection rules, fraud signals, anomaly thresholds, reconciliation logic, alerting pipelines, and incident response runbooks are built against the behaviour of a specific provider. Threshold values, field shapes, identifier formats, and timing characteristics carry vendor fingerprints. Pointing those controls at a new provider without rebuilding them against the new behaviour produces controls that fire late, fire wrong, or do not fire at all. Whether gov.uk rebuilt those controls or repointed them is not confirmed. If they were repointed, they are operating outside the conditions they were validated under. A control operating outside its validated conditions is not a control. It is a metric.

Expansion into Parallel Pattern

The same mechanism appears in identity provider migrations. When an organisation moves from one IdP to another, the integration work gets the focus. SSO endpoints, SAML assertions, group mappings, conditional access rules. The legacy IdP often remains active for fallback. Service accounts in the legacy environment are rarely audited after cutover because no one is using them by design. They are still valid. They are still trusted by the systems they originally federated with. They are unattended. The mechanism is the same. Provisioning gates the migration. Decommissioning does not.

The same mechanism appears in secrets management transitions. When an environment moves from one secrets store to another, the new store gets populated with the credentials needed for the new workload. The old store keeps the credentials that were already there. Rotation policy applies to what is loaded into the new store. The old store falls outside the rotation policy because operationally it is considered retired. Retired is a description. It is not a control. Whether anything in the gov.uk payment migration sits in that condition is not confirmed. The pattern recurs across industries because the cost of confirming a clean cutover is higher than the cost of assuming one.

The mechanism is consistent because attention follows function. If a credential, account, endpoint, or control is not part of the new working system, it falls outside the attention surface. Falling outside attention is not the same as being removed. Systems remain trusted until trust is explicitly revoked. Revocation is an action, not a default. Anywhere revocation is treated as a passive consequence of replacement, access persists. The Adyen migration sits inside this pattern by structure. Where exactly it sits on the pattern is not confirmed, and absence of public detail is not evidence of clean handling.

Hard Closing Truth

Identity is the boundary. The processor changed. The boundary changed. Anything not explicitly revoked on the Stripe side remains a live trust relationship with a system that no longer carries operational ownership inside gov.uk. Anything not explicitly provisioned with minimum scope on the Adyen side is overprovisioned by default. Both conditions can hold simultaneously. Both are silent until they are exploited. The state of either is not confirmed.

Controls must be validated against the system they govern. Monitoring built against Stripe behaviour does not govern Adyen behaviour by repointing. Reconciliation built against Stripe payloads does not validate Adyen payloads by configuration change. Incident response built against Stripe escalation paths does not reach Adyen by assumption. Each of these controls requires rebuild and revalidation against the new provider. Whether that has happened is not confirmed. Until it is confirmed, the control surface is in an undefined state. Undefined is not safe. It is unknown, and unknown is the condition attackers operate in.

Accountability did not move with the processor. Adyen processes the data. Adyen is regulated under a different supervisory authority. Adyen carries its own controls. None of that transfers gov.uk’s accountability to the citizens whose payment data passes through the platform. The platform owner is responsible for the trust boundary, the access governance, the audit posture, the control validation, and the incident response capability spanning both providers during and after transition. Vendor selection is a decision. It is not a control. The processor changed. The accountability did not. What must now be true is that every identity, credential, integration, and control tied to the old boundary has been explicitly handled and every equivalent on the new side has been explicitly scoped. Until that is confirmed, the migration is not complete. It is in progress without a finish line.

See also: NordVPN for tunneled traffic when operating outside controlled networks.

---

#ad Contains an affiliate link.