Variable recurring payments (VRP)
What is variable recurring payments (VRP)?
Variable recurring payments (VRP) are an open banking payment method that let a customer authorize a single mandate covering a series of future account-to-account payments, where each payment's amount can differ from the last. The customer sets the boundaries once, a maximum amount, a frequency, and an expiry date, and payments within those limits go through without repeat authentication.
VRP runs on infrastructure rather than card networks. A payment initiation service provider (PISP) submits the payment instruction directly to the customer's bank, which moves funds straight from the customer's account to the recipient. This makes VRP a form of : the recipient side initiates the request, but only within limits the customer has already approved.
Key facts
- Also known as: VRP, variable recurring payment mandate
- Built on: open banking payment initiation (PIS) APIs, not card rails
- Two common types: sweeping VRP, which moves money between accounts the same customer owns (for example, topping up a savings account), and non-sweeping (commercial) VRP, used for third-party payments such as subscriptions or usage-based bills
- Depends on: the customer's bank and the PISP both supporting VRP, so coverage varies by market and by bank
How it works
- Customer sets up the mandate. During checkout or account setup, the customer authenticates with their bank through the PISP's flow and approves a mandate that defines the maximum payment amount, how often payments can occur, and when the mandate expires.
- The bank stores the consent. The customer's bank keeps the mandate on file and checks every future payment request against its limits before allowing it.
- The PISP initiates payments as they come due. Within the mandate's limits, the PISP sends a payment instruction to the bank without asking the customer to re-authenticate for that individual payment.
- The bank validates and moves the funds. If the request fits the mandate, the bank executes an to the recipient. If it doesn't, the amount exceeds the cap, or the mandate has expired, the bank declines it.
- The customer can revoke the mandate directly with their bank at any time, which stops all future payments without going through the merchant.
Key participants: the customer, the customer's bank (which holds the account and the mandate), the PISP that initiates payments, and the merchant or recipient collecting them.
Why it matters
VRP lets a merchant collect that change in amount, a usage-based subscription, a variable utility bill, a top-up, without storing card credentials or triggering a new authentication for every charge. Because the payment moves account-to-account, it also sidesteps card-specific failure points like an expired card number or a blocked flag, replacing them with a single mandate check at the bank.
For customers, VRP replaces a common pattern in card-based billing, screen-scraping or storing card details with a third party just to enable variable charges, with one bank-authenticated consent that they can see and revoke from their own banking app.
Common issues
- Insufficient funds at the moment of collection. Unlike some card retry flows, a VRP payment either executes against the account balance at that moment or is declined, there's no issuer-side retry logic built into the mandate itself.
- Mandate limits set too low. If a customer's spending grows past the maximum amount or frequency in the original mandate, the payment is blocked until the customer approves a new or updated mandate.
- Uneven bank support. VRP depends on both the customer's bank and the PISP supporting the same open banking APIs, so it isn't available to every customer in every market yet, which is why most merchants still run it alongside -based card billing rather than in place of it.
- Different dispute path. Because there's no card scheme involved, a customer disputing a VRP charge works it out with the merchant directly rather than filing a card-network chargeback.
