How Variable Recurring Payment Works
Variable Recurring Payments operate on top of the open-banking API layer, using the Payment Initiation Service to move money directly from a customer's bank account to a merchant or service provider. The process begins with a single consent journey and then executes automatically for subsequent payments within those agreed parameters.
Customer completes a one-time consent journey
The customer is redirected to their bank's authorisation interface, where they review and approve the VRP mandate. They set the maximum amount per payment, an optional per-period cap, and an expiry date for the consent. This consent replaces the need to re-authenticate for every future charge.
PISP stores the consent token
The Payment Initiation Service Provider — typically a fintech or payment platform — receives and stores the consent token returned by the bank. This token authorises future payment initiations within the agreed limits without requiring further customer involvement.
Merchant triggers a payment
When a charge is due — at the end of a billing cycle, when a usage threshold is hit, or on a scheduled date — the merchant's system instructs the PISP to initiate the payment. The PISP sends a signed payment request to the bank API referencing the stored consent.
Bank validates against consent limits in real time
The bank checks the payment request against the customer's consent parameters before executing anything. If the amount is within the agreed cap, the mandate is still active, and the account has sufficient funds, the transfer is executed immediately. If any condition fails, the payment is rejected and the merchant is notified instantly.
Funds settle and reconciliation closes automatically
Funds move account-to-account, typically settling within seconds via Faster Payments in the UK. The merchant receives a payment confirmation with a unique reference, enabling automated reconciliation without waiting for overnight batch clearing cycles.
Why Variable Recurring Payment Matters
VRPs address a structural gap in the recurring payment landscape where billing amounts are not fixed month to month. Traditional instruments — cards and direct debits — were designed for predictable amounts and introduce friction, delays, or risk when charges need to vary.
According to Open Banking Limited, the UK reached over 13 million active Open Banking users by mid-2024, with payment initiations growing at 25% year-on-year. That growth reflects genuine commercial demand for bank-led payment flows that give both merchants and customers more control.
A 2023 report from the Payment Systems Regulator found that failed direct debit collections cost UK businesses an estimated £1.1 billion annually in retry costs, late-payment fees, and customer churn attributable to failed collections. VRPs reduce collection failures substantially because payment limits are pre-validated at consent time — a merchant initiates only payments they know are within the customer's agreed parameters. Industry benchmarks also show that involuntary churn from expired or declined cards affects up to 9% of subscription revenue annually; VRPs eliminate card expiry as a failure mode entirely.
For merchants on consumption-based pricing models, VRPs remove the need to store card details or maintain card tokenisation infrastructure, reducing PCI DSS scope and lowering per-transaction costs — bank transfer fees typically sit well below card interchange rates.
Sweeping vs. Commercial VRPs
The first VRP use case mandated in the UK was sweeping — automatically moving surplus funds between a customer's own accounts, such as from a current account to a savings pot. Commercial VRPs (cVRPs), which enable payments to third-party merchants, are a separate product being rolled out on a voluntary basis by UK banks. Both use the same underlying Open Banking API, but cVRPs require a bilateral commercial agreement between the bank and the PISP.
Variable Recurring Payment vs. Direct Debit
VRPs and direct-debit are often compared because both enable recurring collections without requiring the customer to act on each payment. They differ fundamentally in payment direction, risk allocation, settlement speed, and the granularity of customer control.
| Feature | Variable Recurring Payment | Direct Debit |
|---|---|---|
| Payment direction | Push (bank-initiated on customer's instruction) | Pull (merchant instructs bank to collect) |
| Amount flexibility | Variable per payment, within consent limits | Fixed or variable, but no real-time limit enforcement |
| Settlement speed | Seconds (Faster Payments) | 1–3 business days (Bacs cycle) |
| Consent mechanism | Digital, real-time, bank-authenticated with granular limits | Paper or digital mandate, limited granularity |
| Customer revocation | Instant via banking app | Must notify merchant, then await bank action |
| Chargeback risk | Minimal — bank enforces consent limits pre-execution | Higher — indemnity claims possible up to 8 years post-payment |
| PCI DSS scope | None — no card data involved | None — but Bacs compliance required |
| Geographic availability | UK mature; EU and other markets emerging | Global, deeply established infrastructure |
| Integration complexity | Requires PISP relationship and Open Banking API work | Lower barrier, long-established bank relationships |
| Failure notification | Instant rejection with specific reason code | Silent failure; 3-day Bacs notification cycle |
Types of Variable Recurring Payment
VRPs are not a single product — different variants serve distinct use cases, and the regulatory status of each category varies by market. Understanding the landscape prevents merchants from building to an assumption that does not match their actual commercial situation.
Sweeping VRPs are the original mandated use case in the UK. They allow customers to automate the movement of surplus funds between their own accounts — for example, from a current account to an ISA or mortgage offset account. The CMA mandated the nine largest UK banks to support sweeping VRPs by January 2022 at no charge to PISPs, establishing the foundational API infrastructure that commercial VRPs now build on.
Commercial VRPs (cVRPs) extend the model to third-party merchant payments. A utility company, SaaS platform, or marketplace can collect variable amounts from a customer's account under a standing consent, without requiring the customer's involvement at charge time. cVRPs require banks to enter bilateral agreements with PISPs and typically carry a fee structure — the commercial model is still evolving across UK banks.
Lending repayment VRPs are a specific application where the repayment amount varies with the outstanding loan balance or an agreed flexible repayment schedule. This is particularly relevant for BNPL providers and credit facilities where over-payment or partial payment in a given period needs to be handled programmatically.
Premium API VRPs are an emerging commercial tier where banks offer enhanced VRP services — including richer transaction data, higher per-payment limits, guaranteed API SLAs, and dedicated settlement windows — on a fee basis to PISPs building high-volume or high-value recurring payment products.
Best Practices
Getting VRP implementation right requires different considerations depending on whether you are the merchant consuming the capability or the developer building the integration. Mistakes made at either layer tend to surface as silent billing failures or customer trust issues.
For Merchants
Set consent limits that reflect realistic billing ranges, not theoretical maximums. Customers who see a £2,000 monthly cap presented during a £30 subscription sign-up are more likely to abandon the consent flow. Calibrate your per-payment maximum to 110–120% of your highest expected charge to give operational flexibility without alarming users.
Communicate clearly what the VRP mandate covers before the customer reaches the bank authorisation screen. Unlike direct debit, which most consumers understand culturally, VRPs are unfamiliar. Plain-language explanations of maximum amounts, payment frequency, and cancellation rights reduce drop-off and support contacts.
Build a consent revocation detection workflow. Customers can cancel a VRP mandate at their bank without notifying you. Your system should poll consent status periodically via the PISP API and handle revoked mandates by prompting re-consent rather than retrying failed payment initiations repeatedly.
Plan your fallback payment method for customers or markets where VRPs are unavailable. Do not design a subscription-billing system that assumes universal VRP coverage — have a card or direct debit path ready and route intelligently.
For Developers
Implement idempotency keys on every payment initiation request. VRP APIs can return ambiguous states during network failures — an idempotent request ensures a timeout-triggered retry does not produce a duplicate charge.
Store the full consent object returned by the bank, not just the consent ID. Consent parameters — limits, expiry date, linked account details — are required for validation logic, customer support, and audit trails. Losing this data creates operational problems that are difficult to recover from without customer re-consent.
Handle webhook events for payment status updates rather than building a polling-based reconciliation system. Most Open Banking VRP APIs emit real-time webhooks for payment execution, failure, and consent revocation events. Polling misses revocation events and creates payment retry incidents.
Use the payment-initiation-service sandbox environments provided by individual UK banks for end-to-end integration testing before going live. Each bank's implementation of the VRP specification has subtle differences in consent parameter validation, error response formats, and webhook payload structure.
Common Mistakes
Merchants and developers new to VRPs often carry assumptions from card or direct debit integrations that do not apply. These are the most common errors that cause production billing failures or customer complaints.
Setting consent limits too wide. Merchants sometimes set the maximum per-payment amount at an arbitrary high figure to avoid ever encountering a limit rejection. This erodes customer trust at the point of consent and increases drop-off rates. Limits should be derived from actual billing logic, not set defensively.
Ignoring consent expiry. VRP mandates include an expiry date agreed at consent time. Systems that do not track expiry will attempt payment initiations against expired consents, receive hard rejections, and have no automated re-consent flow in place — creating silent churn that is difficult to attribute correctly in analytics.
Treating VRP failures like card declines. Developers sometimes build retry logic modelled on card decline handling — retry in 24 hours, retry again in 3 days. VRP failures carry specific reason codes: limit exceeded, consent revoked, insufficient funds, mandate expired. Each requires a distinct response. A limit-exceeded failure should trigger a business logic review, not a time-delayed retry against the same limit.
Assuming uniform bank behaviour. Each major UK bank implements the VRP API specification with variations in error codes, consent validation rules, and webhook payload structures. Testing against one bank's sandbox and assuming universal behaviour causes production incidents when customers authenticate through a different bank.
Not surfacing VRP consent status in customer support tooling. When a customer calls to query a charge or explain why their service was suspended, support agents need instant visibility into consent status, payment history, limit configuration, and recent failure reasons. Systems that silo this data away from CRM tools produce poor support experiences and unnecessary escalations.
Variable Recurring Payment and Tagada
Tagada's payment orchestration layer is directly relevant to merchants building VRP-powered billing workflows. Rather than integrating individually with each bank's Open Banking API — each carrying its own quirks, commercial agreements, and error-handling requirements — merchants can route recurring-payments through Tagada's unified API, which abstracts the PISP layer and normalises consent management, webhook processing, and payment status events across providers.
For merchants migrating from card-based billing to account-to-account-payment flows, Tagada can run both instruments in parallel during the transition — routing new customers to VRP while honouring existing card mandates — without requiring changes to the upstream billing logic layer. This is particularly useful for SaaS and utility merchants moving large existing customer bases without forcing a re-consent event on everyone simultaneously.
When building a VRP integration through Tagada, use the orchestration layer's consent lifecycle hooks to automate re-consent prompts before mandate expiry. Set a trigger at 14 days before expiry to surface an in-product prompt — this recovers the majority of customers who would otherwise experience a silent payment failure at the mandate boundary.