UK Commercial VRP Went Live in June. Subscription Billing Isn't on the List Until Wave 2.

On 2 June 2026, the UK got its first new payment scheme since Faster Payments launched in 2008. Thirty-one firms — including every major UK retail bank — went live with commercial Variable Recurring Payments under a shared rulebook called UKPI, the UK Payments Initiative. If you bill subscriptions to UK customers, this is the kind of infrastructure news that's easy to skim past. It shouldn't be. It's also, right now, not something you can actually use.

That's the tension worth understanding before you do anything about it. VRP is real, it's growing, and it fixes a specific set of problems that cards and Direct Debit both have. It also isn't open to subscription billing yet, and the gap between "this exists" and "you can turn it on" is exactly where a lot of billing teams waste time building against infrastructure that isn't ready for their use case.

What a VRP mandate actually is

A Variable Recurring Payment isn't a card, and it isn't quite a Direct Debit either, even though it gets compared to both. The customer sets up a mandate directly with their own bank — not with you, and not through a card network — specifying a maximum amount that can be taken over a given period (per day, week, month, or year) and an end date for the whole arrangement. Once that's in place, you can pull payments against it without asking again, as long as each one respects the agreed cap.

Three things make the mandate model different from what you're already running:

• The cap is enforced by the bank, not by you. There's no card limit to raise, no risk team to negotiate with — the customer's own bank simply won't let a payment through that exceeds what was agreed.
• The mandate is visible in the customer's banking app at all times. Not a line on a statement after the fact — an active, named permission they can inspect whenever they open their banking app.
• Cancellation doesn't route through you. A customer can amend or kill a VRP mandate from their bank app, right up to the point a specific payment becomes irrevocable, with no advance notice to you required — a meaningfully lower-friction exit than a card decline or a Direct Debit cancellation typically involves.

That last point cuts both ways, and it's the one worth sitting with. It's good news for the failure modes VRP eliminates outright: there's no card number to expire, no reissue-after-fraud-block cycle, no CVV to re-enter. It's less good news for visibility, because a mandate cancellation doesn't generate the kind of decline event your dunning stack is built to catch. It looks a lot more like what we've written about with bank-initiated cancellations — a customer exiting through their bank instead of your product, leaving you to reconstruct what happened after the fact instead of watching it happen in real time.

Why the June launch isn't what most billing teams think it is

UKPI's actual achievement in June wasn't turning VRP on for the first time — commercial VRP has existed in pilot form for a few years, gated behind bilateral agreements each merchant's bank had to negotiate separately with each customer's bank. What UKPI did was replace that with a single shared rulebook that all 31 participating firms operate under, so a merchant's bank doesn't need a private deal with every other bank in the country before commercial VRP works for its customers. That's genuinely the more important part of the news — it's the interoperability layer that makes VRP scalable at all, not a specific product launch.

What went live under that rulebook on 2 June, called Wave 1, covers a narrow set of sectors:

Notice what's missing from that Wave 1 list: general retail and software subscriptions. The sectors that got in first are the ones regulators consider lower-risk or already tightly supervised — a utility company or a regulated e-money institution has existing compliance obligations that make a new payment rail an easier extension. A SaaS company selling monthly seats has none of that scaffolding, which is part of why it's queued for the second wave rather than the first.

Even inside Pay by Bank — itself still a minority of UK payment volume next to cards — VRP is the smaller slice of a smaller category. That's not a criticism of the technology, it's just an honest read of where the infrastructure actually sits. Building a subscription billing roadmap around VRP today would mean building against Wave 2 timing you don't control, on a scheme with zero live subscription volume to point to yet.

What Stripe does and doesn't give you here

If your billing already runs on Stripe, the honest answer is: nothing changes for you today. Stripe has published guidance explaining VRP to merchants, but VRP isn't on Stripe's list of supported payment methods, and there's no public roadmap committing to it. That's a meaningful gap if you're comparing this to how Stripe handled SEPA Direct Debit or ACH — both of those, Stripe supports natively, with its own retry logic layered on top of the scheme rules. VRP, for now, would mean a separate integration with a dedicated open banking provider running alongside your existing Stripe subscriptions, not a checkbox inside Billing settings.

That's worth knowing now specifically because it changes the planning question. It's not "when do we turn VRP on in Stripe" — it's "if Wave 2 lands this year, do we want a second payment integration running in parallel with Stripe for UK customers, and is the failure-rate improvement worth that operational cost." For most SaaS businesses billing a modest UK customer base, the answer today is probably not yet. For anyone processing meaningful UK subscription volume, it's worth having someone own that evaluation before Wave 2 actually ships, rather than scrambling once it does.

The mandate comparison that actually matters for churn

That last row is the one to plan around before Wave 2 arrives, not after. Every payment rail we've covered — SEPA's 8-week reversal window, ACH's unauthorized-return codes, a card's hard decline — gives your billing system some kind of signal when a customer is on their way out through a side door instead of your cancel flow. A VRP mandate cancellation, as currently specified, doesn't generate a payment failure at all. It just stops. If you're not explicitly monitoring for a mandate that goes quiet, you'll misclassify it as "not using it enough" the same way silent churn from other rails gets misclassified today, and you'll lose the chance to route that customer through an actual cancellation flow that might have saved them.

What to actually do with this now

Nothing urgent, and that's the useful takeaway. There's no VRP integration to ship this quarter — Wave 2 isn't live, and Stripe doesn't support it yet even where it is. What's worth doing now is narrower: if UK revenue is material to your business, put someone on watching for Wave 2's actual go-live date rather than a targeted quarter, and decide in advance whether a mandate cancellation needs its own webhook-equivalent monitoring the moment you do integrate. Getting that decision made before the scheme is live beats retrofitting your churn reporting after a few hundred UK subscribers have quietly walked out through a mandate you never saw close.

In the meantime, the actual lever available to you hasn't moved: whatever rail a UK customer pays through, the highest-leverage moment to save them is still the one where they're actively trying to leave, not the one where a payment silently stops. Run your current involuntary and voluntary churn split through our churn calculator, and if UK Direct Debit or card declines are already a meaningful share of it, that's worth fixing with CancelFlow today — regardless of what a new payment rail does or doesn't change a year from now.

Frequently asked questions

Stop losing subscribers today

One script tag. One function call. A live cancellation flow in under 10 minutes.