How can a payment platform prepare its merchants for VRP?

By running recurring billing on infrastructure that can add new rails without rebuilding the schedule. A subscription engine keeps offers, rebills and retries in one place, and account-to-account rails can be added where VRP schemes go live.

What VRP changes

Variable recurring payments let a customer authorize a series of bank transfers once, with limits on amount and frequency, instead of approving each payment. For merchants, it is a card-on-file experience on account-to-account rails: no card expiry, no interchange, instant settlement. Commercial VRP is live in the UK and planned in the euro area, so the question for a platform is timing, not whether.

The preparation

• Run recurring billing from one engine that holds the offer, the schedule, the retries and the mandate, whatever the rail.
• Model the VRP consent as a mandate with limits, next to card tokens and SEPA mandates.
• Connect the first VRP provider as a payment rail, enabled per merchant and per market.

What merchants will ask

Whether their subscriptions can move from cards to VRP without re-enrolling customers, and whether failed collections retry the same way. The answer depends on the billing engine, not on the rail. A platform that already separates the schedule from the payment method can add VRP as one more method, and let merchants offer it where it lowers cost or failure rates.