Recurring Pay by Bank: UK Variable Billing on Bank Rails
Billing teams lose margin when every renewal runs on a card that expires, and they lose days of cash visibility when Direct Debit returns land late. Recurring pay by bank fixes both patterns for eligible UK merchants: the customer approves your business once in their banking app, you pull each bill within agreed caps, and successful collections settle on Faster Payments — often the same day. GoCardless made Recurring Pay by Bank production-ready in July 2026 under the UK Payments Initiative (UKPI) scheme, and other providers offer similar bank on file flows. This guide covers when recurring pay by bank fits your billing model, how the consent journey works, Wave 1 sector gates, Wave 2 readiness, and what to validate before you switch rails.

Recurring pay by bank: Collecting repeat charges from a customer's bank account after a single approval in their mobile or online banking app — each payment can vary in amount within limits the customer set, without storing a card number or sending a new checkout link every cycle.
When should billing teams adopt recurring pay by bank?
Adopt recurring pay by bank when your UK customers pay you on a cycle, invoice amounts change month to month, and card interchange or Direct Debit settlement lag is hurting cash flow or margin.
Strong fits include:
- Energy, utilities, and telecoms — usage-based bills where the monthly total shifts with consumption
- Insurance and financial services — premiums or contributions that adjust with risk or balance
- Housing associations and regulated lenders — rent or loan repayments where faster confirmation reduces arrears admin
- Charities and public-sector billers — recurring donations or instalment plans under UKPI Wave 1 sectors
Hold off or keep cards as fallback when:
- Your merchant category sits outside UKPI Wave 1 — general e-commerce, SaaS, and streaming subscriptions wait for Wave 2 (expected later in 2026)
- Your customers are euro-area only — recurring pay by bank in this article means the UK cVRP path; EU teams typically stack open banking subscription billing on SEPA Direct Debit after verification
- You cannot run parallel rails during pilot — enrollment rates vary; do not cut card renewals until bank consent conversion is proven in your top segments
According to GoCardless product updates for July 2026, Recurring Pay by Bank is now live for businesses with flexible or variable billing models — a signal that UK providers are moving from scheme testing to production collections.
How does recurring pay by bank work for the customer?
The customer selects pay-by-bank at signup or in a billing portal, authenticates in their banking app, sets per-payment and monthly caps plus an expiry date, and your provider stores that consent for future pulls.
The journey in six steps:
- Customer initiates — from your website, app, or billing portal ("Set up bank payments").
- Bank selection — payer picks their institution from a UK coverage list (UKPI Wave 1 targets roughly 75% of current accounts).
- Consent screen in bank channel — payer sees your business name, maximum single payment, monthly limit, and permission duration.
- Approval — strong customer authentication completes in the banking app, not on your domain.
- First collection — your billing engine requests the amount when the first bill is due, within agreed caps.
- Repeat pulls — each cycle, your provider requests the variable amount; webhooks confirm success, failure, or cancellation.
This is the operational face of commercial variable recurring payments (cVRP) — permission lives at the bank, not as a card token. For the technical distinction between sweeping (own-account) and commercial collection, see variable recurring payments explained.

What the customer controls
- Maximum amount per individual pull
- Monthly aggregate cap
- Permission expiry — they can revoke in the banking app at any time
- Which business they authorised — no shared card number across merchants
Trade-off to plan for: consent UX is bank-app dependent. Mobile banking users convert well; desktop-only payers may need guidance. Run A/B tests against your existing Direct Debit mandate flow before you promise a switch date.
What changes for finance compared to Direct Debit and card-on-file?
Recurring pay by bank typically settles faster than Bacs Direct Debit, costs less variable margin than many card-on-file renewals, and gives finance IBAN-level references — but dispute paths and sector eligibility differ from both legacy rails.
| Dimension | Recurring pay by bank (UK cVRP) | Direct Debit | Card on file |
|---|---|---|---|
| Setup | One bank-app consent | Mandate + Bacs timeline | Card entry or wallet token |
| Variable amounts | Designed for changing bills within caps | Supported with amendment notices | Native but with interchange |
| Settlement | Faster Payments (often same day) | Bacs (2–3 working days typical) | Acquirer batch schedules |
| Failure visibility | Can check balance before pull (provider-dependent) | Returns often days later | Declines at point of charge |
| Disputes | Bank/scheme model under UKPI | Direct Debit guarantee rules | Chargebacks |
| Sector gates | UKPI Wave 1 categories today | Broad | Broad |
GoCardless completed the first recurring open banking transaction during industry live testing in March 2026 for Jellyfish Energy, before the UKPI scheme went live on 2 June 2026. That sequencing matters for finance planning: the rail works, but your sector and provider coverage determine whether you can use it this quarter.
Reconciliation habits
- Match on creditor reference and payer IBAN — not last-four card digits
- Treat webhook final status as source of truth; browser return is unreliable on mobile
- Segment reporting by rail during hybrid rollout so you can compare involuntary churn and cost per successful collection
Teams evaluating providers for recurring flows should also read best open banking providers for recurring transactions for coverage dimensions — then use the provider-matching form to compare live institution lists against your customer bank mix.
Which UKPI rules affect who can use recurring pay by bank today?
UKPI Wave 1 limits recurring pay by bank to regulated and trusted sectors — utilities, telecoms, financial services, e-money institutions, government, and charities — with Wave 2 expected to open general e-commerce later in 2026.
Wave 1 sectors (live since June 2026):
- Energy, water, gas, broadband, and mobile
- Regulated financial services (insurance, investments, lending where permitted)
- E-money institutions within scope
- Local and central government
- Registered charities
Wave 2 (anticipated second half of 2026) targets broader retail — SaaS subscriptions, streaming, membership clubs, and general e-commerce where card-on-file dominates today. The Payments Association notes UK Finance is developing the Wave 2 commercial model, including proposed ad valorem fee structures to compete with card pricing — a shift from the fixed pence-per-transaction design discussed for Wave 1.
Practical checklist before you announce bank-pay renewals
- Confirm your merchant category with your provider against current UKPI eligibility lists
- If you are Wave 2, build technical integration now using one-off pay by bank so checkout rails are ready when recurring opens
- Train support on consent revocation — customers manage permissions in their banking app
- Document hybrid billing: which customer segments stay on Direct Debit or cards during pilot
- Align dunning logic — retry windows differ from card networks and Bacs return codes
If you operate in both the UK and EU, pair this UK guide with open banking UK vs EU for market-specific rollout sequencing.

How do you implement recurring pay by bank without breaking renewals?
Pilot on a single segment, keep legacy rails live, and validate webhooks, cap logic, and dunning before you migrate your full billing book.
Phase 1 — Prove consent conversion (2–4 weeks)
- Offer recurring pay by bank alongside Direct Debit or card at signup for one product line
- Measure consent completion rate, time-to-first-successful-pull, and support tickets
- Fail paths to test: payer cancels in bank app, insufficient funds, consent expiry mid-cycle
Phase 2 — Finance and ops alignment
- Map webhook events to your billing engine (success, failure, revoked consent)
- Set cap validation rules so pulls above customer limits fail gracefully with clear payer messaging
- Define when finance releases service on pending vs confirmed status
Phase 3 — Scale and hybrid strategy
- Move eligible cohorts in tranches; retain cards for Wave 2 sectors until UKPI expands
- Compare cost per successful collection and involuntary churn against your card baseline
- Revisit provider contracts for UKPI pricing — commercial models evolve between Wave 1 and Wave 2
Provider shortlist criteria specific to recurring pay by bank:
| Criterion | Question to ask |
|---|---|
| UKPI scheme participation | Is the provider a UKPI participant with production cVRP, not sandbox-only? |
| Balance check support | Can you avoid blind pulls when funds are insufficient? |
| Cap enforcement | How are per-payment and monthly limits validated before initiation? |
| Webhook reliability | Do you receive final status without polling? |
| Hybrid billing | Can one customer mix recurring bank pulls with one-off pay-by-bank invoices? |
| Wave 2 roadmap | What is the provider timeline for general e-commerce eligibility? |
Run sandbox tests with production-shaped amounts — variable bills, cap breaches, and consent expiry — before marketing the method to customers.
Frequently Asked Questions
What is recurring pay by bank?
Recurring pay by bank is a UK collection method where a customer authorises your business once in their banking app to pull repeat payments from their account. Each charge can be a different amount, as long as it stays within per-payment and monthly caps the customer agreed. You do not store a card number, and successful payments typically settle on Faster Payments the same day.
How is recurring pay by bank different from Direct Debit?
Direct Debit runs on Bacs with mandate setup and settlement often two to three working days after a successful collection. Recurring pay by bank uses open banking consent in the banking app and Faster Payments settlement, which is usually same-day. Direct Debit has broader sector eligibility today; recurring pay by bank under UKPI currently follows Wave 1 sector rules with Wave 2 expanding to general e-commerce.
How is recurring pay by bank different from card-on-file?
Card-on-file stores a card token and charges through card networks, with interchange on each successful payment and failures driven by expiry or issuer declines. Recurring pay by bank pulls account-to-account after bank-app consent — no card expiry, different dispute economics, and typically lower variable cost on many flows. Card-on-file remains available to all merchant categories; UKPI sector gates apply to recurring pay by bank today.
Which businesses can use recurring pay by bank in 2026?
UKPI Wave 1 covers energy and utilities, telecoms, regulated financial services, e-money institutions, government bodies, and registered charities. General e-commerce, SaaS, streaming, and most retail subscriptions are expected in Wave 2 later in 2026. Confirm eligibility with your payment provider before launching customer-facing copy.
Can recurring pay by bank handle variable invoice amounts?
Yes — variable amounts are the core use case. The customer sets maximum per-payment and monthly caps during consent; your billing engine requests each bill's actual amount within those limits. Amounts above the cap are blocked unless the customer updates their consent in the banking app.
Do I need a different provider for recurring pay by bank vs one-off pay by bank?
Many UK open banking providers offer both one-off payment initiation and recurring cVRP under UKPI, but capabilities differ. Verify production cVRP support, not just sandbox payment initiation, and test webhook payloads for repeat pulls separately from single checkout flows.
How do I choose a provider for recurring pay by bank?
Compare UKPI scheme participation, Wave 1 sector support, institution coverage for your customer bank mix, balance-check features, webhook reliability, and Wave 2 roadmap. Run sandbox tests with variable amounts and cap breaches, then match requirements to live provider coverage through a structured comparison process.
Conclusion
Recurring pay by bank gives eligible UK billers a path to collect variable repeat charges with one bank-app consent, faster settlement than many Direct Debit flows, and lower variable cost than card-on-file on several use cases. Wave 1 sector gates mean not every subscription business qualifies today — but energy, utilities, financial services, government, and charity billers can pilot now, while Wave 2 merchants should integrate one-off pay by bank first and prepare consent UX for later in 2026. Pilot on one segment, keep legacy rails live, and validate provider webhooks and cap logic before you migrate your full billing book.
Related articles
- Open Banking Subscription Billing: UK & EU Bank-Rail Renewals
Subscription revenue bleeds when renewals depend on cards that expire, chargebacks that eat margin, or mandates that cannot match a variable invoice. Open bank…
- cVRP Explained: Commercial Variable Recurring Payments
cVRP stands for Commercial Variable Recurring Payments — a UK way to collect repeat payments straight from a customer’s bank account after they approve once in…
- Bank on File vs Card on File: EU & UK Recurring Billing
Recurring revenue depends on a stored funding method you can charge again without asking the customer to re-enter details every cycle. Card on file is the defa…