Recurring Pay by Bank (VRP)

Recurring Pay by Bank payments use Variable Recurring Payments (VRP), an Open Banking capability that lets you collect multiple payments from a customer under a single, pre-authorised mandate. The customer authorises once; every payment after that is initiated by you.

VRP types

The type of VRP you use will influence which banks are available to your customers.

If you are unsure which VRP type applies to your use case, contact us and we can advise.

cVRP eligibility

cVRP eligibility is based on UKPI's approved use cases. Eligible sectors include the following:

• Utilities, telecoms and rail — variable energy, water, broadband and mobile bills, and rail season tickets and travel accounts.
• Regulated financial services — payments into FSCS-eligible products (savings and deposits, insurance, investments and pensions) and FCA-regulated mortgage payments.
• E-money institutions — topping up e-money wallets, prepaid and deposit accounts, including auto-top-ups.
• Government — council tax, business rates, licence and permit fees, fines, and court and statutory fees, across central, local, devolved and TfL.
• Registered charities — recurring donations to a registered charity, with donor-set limits.

How it works

Recurring payments follow two stages: mandate setup, which happens once and involves the customer, then payment collection, which repeats without them.

Stage 1: Mandate setup

A mandate can be set up in two ways. Both end the same way: the customer authorises at their bank, you receive a mandate_active webhook, and the mandate is ready to collect against.

Option A: Hosted Checkout

1. Create the payment link. Submit a POST request to Create payment links with a configuration.variable_recurring_payment object defining the mandate limits. The response returns a link_id.
2. Redirect the customer. Send them to the Hosted Checkout page for that link_id. Acquired displays the supported banks and redirects the customer to the one they select.
3. Customer authorises. The customer reviews the limits in their banking app and approves. This is the only point at which the customer is involved.
4. Mandate active. You receive a mandate_active webhook and the customer returns to your redirect_url.

For the full field list and an example request, see Pay by Bank in Hosted Checkout.

Option B: Direct API

1. Retrieve the supported banks. Call List supported banks to build your own bank selection UI.
2. Create the mandate. Submit a POST request to Create a mandate with the customer's chosen bank_id, the debtor.customer_id, the mandate limits, and the VRP type. The response returns a mandate_id and an auth_url.
3. Redirect the customer. Send them to the auth_url to authorise the mandate at their bank. This is the only point at which the customer is involved.
4. Mandate active. You receive a mandate_active webhook.

For the device-specific authentication experience, see Customer authentication.

Mandate limits

The following limits are set when creating a mandate. For both Sweeping and Commercial VRP, these are the limits the customer reviews and approves at their bank.

The field names below are those of Create a mandate, used in Option B. In Option A the same limits are nested under configuration.variable_recurring_payment in the Create payment links request, and bank_id is not sent — the customer selects their bank on the Hosted Checkout page.

Note: Customers can view and cancel their mandate directly from their banking app at any time. Your integration must also support a mandate cancellation flow (see Cancel a Mandate).

Stage 2: Payment collection

Once a mandate is in place, you can collect payments without any further customer interaction, as long as each payment falls within the agreed limits.

1. Initiate a payment. Your server submits a POST request to Initiate a variable recurring payment, referencing the active mandate ID and specifying the amount for that payment.
2. Payment processed. The payment is executed immediately over Faster Payments. No customer redirect is required.
3. Receive confirmation. A webhook notifies you of the payment outcome. See Statuses for how a payment progresses.
4. Funds settle. The payment reaches executed once the bank has sent it over Faster Payments, and settled once the funds land in your Acquired ledger. You receive a separate status_update webhook for each; match them on transaction_id. Acquired then batch settles to your external bank account each working day. If your account settles externally rather than into an Acquired ledger, the status stops at executed and no settled webhook is sent.

Note: If a requested payment exceeds the mandate limits, it will be declined. Validate your payment amounts against the mandate before submission.

Recurring Pay by Bank payments are well suited for subscription billing, savings contributions, top-ups, and any use case requiring flexible, variable-amount collections.

Checking funds before you collect

Before initiating a payment, you can check whether the amount is available on the account behind an active mandate, using Initiate a confirmation of funds check against a mandate.

This is a suggested step rather than a required one. A collection can be made without it, but a funds check lets you avoid a payment you can already tell will fail.

POST /open-banking/mandates/{mandate_id}/confirm-funds

The response contains a funds_available field indicating whether the amount is available.

Note: funds_available is returned as a string, not a boolean. Handle it accordingly.

A funds check reports availability only. It does not reserve, hold, or move any money, and the result is a point-in-time answer — funds can leave the account between the check and your payment request.

It also tells you nothing about the mandate's own limits. A payment must satisfy both conditions to succeed: sufficient funds in the account, and an amount within the mandate limits. A payment that exceeds the mandate limits is declined regardless of the customer's balance.

If funds are not available, defer the collection and retry later rather than submitting a payment you expect to fail.

Retrieving mandates

To read the current state of a mandate without waiting for a webhook, use Retrieve an open banking mandate with the mandate_id. To list the mandates on your account, use List mandates.

Retrieving a mandate is the reliable fallback when a webhook is delayed or missed. See Statuses for the mandate states you may see.

cVRP disputes

cVRP disputes are handled under the UK Payments Initiative's dispute and arbitration process. This is separate from card chargebacks and from Direct Debit indemnity claims: card scheme chargebacks do not apply to Pay by Bank, but Commercial VRP payments are not dispute-free.

How a dispute progresses

1. The customer contacts their bank, which triages the claim. Disputes covered by an existing industry framework, such as Authorised Push Payment fraud, follow that framework instead of UKPI.
2. The customer is refunded immediately if the claim is eligible. The bank then has 21 days to raise a formal case or write the claim off.
3. Acquired notifies you when a case is raised, and works with you to agree a response.
4. A response is due within 15 days, accepting or contesting liability. Missing that deadline triggers an automatic default against the case.
5. Unresolved cases escalate to UKPI for final arbitration.

There is no limit on how old a disputed transaction can be, or on how many disputes can be raised.

Testing

Create mandates with type: sweeping when testing, including where your live integration will use Commercial VRP. The request and response structures, webhooks and statuses are identical for both types, so a Sweeping mandate exercises the same integration path end to end.

Set type: commercial when you move to production.

Cancelling a mandate, statuses and webhooks

To cancel a mandate, see Cancel a Mandate. For the possible statuses and how a payment progresses, see Statuses. For the mandate and payment webhooks you will receive, see Webhook Notifications.