Variable Recurring Payments (VRP) and A2A Payments in Open Banking

From a single transfer to an ongoing payment permission

Open banking started by making permissioned access to financial services easier to integrate. For merchants, one familiar result is a checkout where customers choose their bank and approve a transfer. That works for an individual purchase, but asking someone to repeat the same journey for every bill creates friction. Variable recurring payments address that problem by separating the initial payment permission from later payment collection requests.

The customer approves defined boundaries at their bank. A licensed provider can then initiate a payment within those boundaries without asking the customer to complete a fresh approval journey each time. The payment amount can change, but the permission remains limited. This makes the model relevant to businesses that need customers to pay regularly while retaining meaningful control over timing and expenditure.

This guide uses the UK open banking context, where the distinction between sweeping and commercial use is especially important. Availability depends on the bank, licensed provider, arrangement and intended purpose. An open banking demonstration does not establish that every customer can use the same flow in production.

How VRP differs from an ordinary bank transfer

Account-to-account payments move funds directly between bank accounts. VRP enables repeated initiation within this model; it is not a separate settlement rail. A standard open banking payment usually has one instruction and one approval journey. VRP introduces a payment consent that can support multiple payments over time. The payment consent identifies the permitted destination and relevant limits, while each later bank payment remains a separate payment transaction with its own amount, reference and outcome. The provider does not receive unrestricted control over the payer’s account.

The phrase open banking variable recurring payments describes this combination of open banking connectivity, bounded payment permission and repeated initiation of payments. It does not mean that the bank decides what the merchant should charge. Billing remains a business responsibility. The merchant calculates the amount due; the provider and bank enforce the applicable consent conditions when the request is submitted.

A standing order generally follows a payment amount and schedule chosen by the customer. VRP can accommodate variable payment amounts within the agreed payment boundaries. Direct Debit uses a different mandate and payment collection framework, with its own scheme protections and operational rules. Card subscriptions use stored card credentials or tokens. These methods can serve similar billing needs without sharing identical rights, acceptance or failure behaviour.

The consent limits that make VRP controllable

Before approving a VRP consent, the customer should understand who will receive funds, why payments are requested and how to stop those bank payments. The bank presents the authorisation journey and applies strong customer authentication where required. Your product should explain the proposal before that handover, using language that matches the terms the customer will see at their bank.

Limits may include a maximum amount per payment, a cumulative cap per period and a validity window. Supported fields and periods depend on the provider and bank implementation. A maximum of £60 per payment is not the same as £60 per month: several smaller requests could satisfy the first rule while exceeding the second. Store and display both limits clearly when both apply.

Do not treat VRP consent as permanent. It can expire, be revoked or become unusable because the underlying relationship changes. VRP software needs an explicit lifecycle: proposed, awaiting approval, active, revoked or expired, with provider-specific states mapped carefully. An old successful payment is not evidence that the current consent remains active.

The VRP customer should have a clear way to find their permission and revoke it through the supported channels. Explain what revocation changes and what it does not. Stopping future payments does not automatically cancel an outstanding invoice, a service agreement or a bank payment already accepted for execution. Those questions need separate product and support processes.

Sweeping and commercial payments are different

Sweeping VRP moves money between accounts belonging to the same person. A savings service might move surplus funds from a bank account into a savings account destination under a consent. The UK’s established sweeping framework is narrower than a general permission to collect merchant payments. Teams should use that distinction when evaluating claims about bank coverage.

Commercial, or non-sweeping, VRP concerns transfers to another party, such as a merchant. That introduces different questions about pricing, participant agreements, customer protections and supported purposes. Support for sweeping VRPs does not demonstrate support for commercial VRPs. Ask the provider to confirm the specific use case rather than accepting a generic feature label.

Open banking infrastructure also differs between markets. A UK capability should not be presented as a feature of every European bank. Assess each proposed rollout by jurisdiction, currency, provider and receiving account institution. For a merchant launch, obtain current production coverage and the relevant terms before offering the method to customers.

Industry announcements often describe pilots, phased access or an intended expansion. Distinguish those from a live service available to your business. This guide does not assume universal commercial availability or quote a coverage percentage that could become outdated. The useful question is whether your customers can use the intended flow today under your agreed arrangement.

A payment collection journey, from consent to confirmed funds

The first open banking VRP journey starts in your product. Explain the billing purpose, the recipient and the proposed limits. Send the consent request through the integrated provider, then direct the end user to their bank. After the user approves, keep the provider’s consent identifier and record the confirmed boundaries. Do not activate billing merely because the browser returns to your site.

When a payment is due, create an open banking payment request linked to that consent. Include a stable reference and an idempotency key, following the API contract. Check your own billing rules before sending it. A valid consent is permission to request an eligible bank payment, not a reason to collect an amount the customer does not owe.

The licensed open banking provider initiates the payment instruction and the end user’s account issuing bank decides whether it can execute it. The bank sends the funds if the instruction is accepted for execution. Status messages may arrive asynchronously. Your system must distinguish a submitted request, an authorised instruction, a failed attempt and evidence that the receiving account balance was actually credited.

Use read-only account credit confirmation on the merchant’s C2B account to establish arrival where that connectivity is available. Match the reference and amount, then apply your final-status rule. This is especially important when a subscription renewal, wallet top-up or release of goods depends on the money arriving rather than on the customer having approved a request.

Where variable recurring bank payments can help

A business with variable recurring bills has a natural reason to consider variable amounts. Customers might pay more in a busy month and less in a quiet one. A bounded consent can reduce repeated checkout steps while preserving a ceiling. The recurring payment interface still needs to show how the total was calculated and when payment collection is expected.

For example, a service may propose a £40 cap per payment and a £100 cap per month. A £32 invoice could fit both limits, but a fourth £32 payment in the same period would exceed the cumulative cap. The application should detect that situation before making a request and offer an appropriate alternative instead of attempting to bypass the limit.

Other potential applications include subscriptions with optional extras and customer-authorised bank top-ups. Their suitability depends on commercial VRP support, the provider’s acceptance criteria and the relevant customer protections. Do not assume that a recurring billing model is automatically eligible. A product that can use sweeping for personal savings may need a different arrangement to collect a merchant charge.

Keep an alternative way to pay for customers whose bank or consent does not support the intended payment collection. A one-off bank checkout or another accepted method can prevent a coverage gap from becoming a failed renewal. Explain the change before redirecting the customer, and reconcile the alternative against the same invoice to avoid duplicate payment.

VRP compared with other ways to pay

No payment method is a universal winner. Compare the complete service, including bank reach, successful payment collection rates, support effort and financial reconciliation. Open banking payments avoid card scheme rails, but that does not make every bank-based service cheaper or remove consumer rights. Evaluate the actual commercial terms and the rules governing the chosen method.

VRPs also require a different recovery process. A declined VRP payment request may reflect insufficient funds, an inactive consent, exceeded limits or a connectivity issue. Repeating the same request cannot resolve every cause. Decide which failures permit a retry, which need customer action and which should stop payment collection entirely.

Who does what in the payment chain

The merchant owns the recurring bill, the product experience and the decision to release goods or services. It should retain evidence of the commercial obligation and explain charges clearly. It also holds the relationship for its receiving C2B account with the relevant EMI or bank. That institution receives bank payments and provides the connectivity used to confirm incoming funds.

The licensed open banking provider performs regulated payment initiation within its authorisation. It also performs payment screening and transaction monitoring within its service scope. The end user’s bank captures payment consent, authenticates the user and sends the authorised bank payment. These are distinct responsibilities, even when one open banking customer journey makes them appear seamless.

viaBanking supplies the orchestration layer. A merchant signs an agreement with viaBanking to access integrated providers, without separate merchant contracts with each open banking provider. We handle any required provider onboarding for the merchant. Provider availability and approval still matter; a single agreement does not override an institution’s eligibility checks.

The open banking software routes requests, normalises statuses, delivers callbacks and performs read-only account credit confirmation. viaBanking does not hold customer funds or execute transfers. The read-only restriction describes its receiving-side check; it does not exclude initiation or the licensed providers’ checks from the services accessed through the arrangement. See our recurring payment collection integration overview for the open banking product context.

Build for asynchronous events and imperfect connections

Start by modelling a VRP consent separately from each VRP payment. A consent can remain active after one failed payment, while revocation can prevent future payments even after earlier payments succeeded. Store identifiers that let support trace the consent, invoice, provider request and received funds without confusing them with one another.

Use payment idempotency to prevent an uncertain response from becoming a duplicate charge. If a request times out, reconcile its existing state before submitting a new instruction. Follow the provider’s documented retention and retry semantics rather than assuming that every API uses the same rules. Network uncertainty is not evidence of failure.

VRP payment callbacks can be delayed, retried or delivered out of order. Verify their authenticity using the documented mechanism, deduplicate events and enforce valid state transitions. A late intermediate event should not overwrite a final confirmed result. Keep a query or reconciliation path for cases where notification delivery fails.

Test revoked and expired VRP consents, limits exceeded, bank payment downtime, insufficient funds and authorisation without observed credit. Include a customer paying through a fallback method while an earlier attempt remains unresolved. Your open banking integration should preserve one invoice outcome even when several technical events describe it.

Consent, customer data and browser privacy

Permission to initiate an open banking payment is not permission to collect an unrestricted financial profile. Keep the data needed for the service: identifiers, consent boundaries, payment amounts, references, statuses and appropriate payment audit records. Access to balances or transaction history is a separate question requiring an appropriate service and permission. Do not treat payment consent as general account information consent.

A cookie preference is also separate from open banking payment authorisation. Accepting analytics on a website does not create a VRP consent, and declining a marketing cookie should not be described as revoking one. A browser consent form can explain the proposed limits, but the user must complete the supported bank authorisation journey. Keep these interfaces and their wording distinct.

Avoid exposing sensitive data in browser URLs, analytics events or unrestricted logs. Apply retention and access controls that match the purpose of each record. Support staff need enough information to investigate a payment collection, not the end user’s online banking credentials. Those credentials remain with the bank during authentication.

Evaluate coverage, costs and customer support together

Ask prospective providers for evidence covering your actual use case. Which banks support it? Which customer types and currencies qualify? What limits can be configured? How are revocation, refunds, complaints and disputed payments handled? Request the current open banking terms and technical documentation, then test the relevant journeys before committing to a launch date.

Compare costs per successful payment collection rather than just a headline fee per request. Include failed attempts, platform charges, support work and reconciliation effort where applicable. A low payment initiation fee offers little value if customers cannot use the method or your team repeatedly investigates ambiguous outcomes.

Prepare VRP customer support before release. Agents should distinguish cancelling a service from revoking a consent, and an accepted instruction from received funds. Give them a clear escalation route to the appropriate provider or institution. For VRPs, a trustworthy experience comes from explainable limits and dependable records as much as from a shorter checkout.

A practical starting point

Before enabling variable recurring bank payments, agree a small set of operational measures. Track consent completion, payment acceptance, confirmed arrival and the time between those events. Separate unsupported bank journeys from customer cancellations and technical failures. For open banking teams, those distinctions explain where the service needs work. Review the figures with the provider using payment identifiers rather than unnecessary personal data. A useful launch report describes which VRPs succeeded, which needed intervention and which were never eligible to run.

Choose one well-defined payment collection scenario, confirm live coverage and write the VRP consent limits in plain language. Build against the sandbox, test failure paths and agree when your business will treat funds as received. Then expand only after the end-to-end records show that consent, billing, initiation and confirmation remain consistent.

Open banking can make repeat bank payments more convenient, but the strongest implementation keeps responsibility visible. The bank customer knows what they approved, the licensed provider performs initiation, the bank sends funds and the merchant acts on reliable confirmation. That is the foundation for a sustainable VRP service.

Further reading

For the underlying UK open banking framework and current developments, consult Open Banking Limited, the Competition and Markets Authority and the Financial Conduct Authority. Confirm implementation details against your licensed provider’s current documentation; general guidance does not establish your production coverage.