Payment control stays with the platform.
FCA-authorised PIS and VRP infrastructure for EPOS, billing, and payroll platforms.
Merchant initiated transactions put payment control in the platform’s hands.
Standard Open Banking payments require the user to complete every step. They select their bank. They authenticate. They approve the specific amount. The payment only moves when the user says so.
That model works for one-off checkout payments. It breaks for billing platforms that need to collect on a schedule, payroll platforms that disburse on a fixed date, and EPOS systems that need reliable payment execution without user friction at each cycle.
At Finexer, I work with EPOS, utility billing, and invoicing platforms that need the payment to happen without bringing the user back into the flow every time. The open banking payment flow has to work on the platform’s terms, not the user’s.
TL;DR
Merchant initiated transactions in Open Banking allow platforms to trigger payments within a pre-agreed consent framework – without requiring the user to re-authenticate each time. Standard Pay by Bank requires full user authentication per payment. Variable Recurring Payments (VRP) enable merchant-controlled payment execution within consented parameters. Finexer’s FCA-authorised PIS with VRP capability gives EPOS, billing, and payroll platforms the payment flow control they need for automated, scheduled, and recurring disbursements.
Key Takeaways
What are merchant initiated transactions in Open Banking?
Merchant initiated transactions are payments triggered by the platform within a pre-authorised consent framework – without requiring the user to authenticate each individual payment. In Open Banking, this capability is delivered through Variable Recurring Payments (VRP), which allow merchants to initiate payments within consented parameters.
Why do standard payment flows break for merchant-triggered use cases?
Standard Open Banking payment flows require full user authentication per payment. For billing, payroll, and recurring collection use cases, this creates unacceptable friction – users who do not complete the authentication journey result in failed payments that require manual recovery.
What is the control problem in Open Banking payment flows?
The control problem is that standard Pay by Bank places payment execution control with the user. The platform initiates the request but cannot complete the payment without the user’s active participation. Merchant initiated transactions invert this – the platform executes within pre-agreed consent without per-payment user action.
How does VRP + PIS enable merchant payment control for platforms?
VRP allows platforms to initiate variable payments within a consented parameter set without per-payment user authentication. Combined with PIS for payment initiation and AIS for transaction verification, platforms can build automated payment flows where the merchant controls timing, amount, and execution.
What Is the Standard Open Banking Payment Flow?
How Does a Typical Pay by Bank Payment Work?
A standard open banking payment flow runs through five stages that all require user participation:
- User selects Pay by Bank at checkout
- User selects their bank from the provider list
- User is redirected to their bank app
- User authenticates with their bank credentials
- User approves the specific payment amount
Each stage requires active user participation. If the user drops out at any stage, the payment fails. For one-off purchases, this is acceptable. For recurring billing, scheduled disbursements, or automated payroll – it is not.
How the Open Banking payment flow works for platform systems covers the technical architecture of standard Pay by Bank payment flows and where they fit in platform payment design.
“At Finexer, the EPOS and billing platforms I work with all hit the same point in their payment flow design. The standard Pay by Bank model is excellent for checkout. The moment they need to trigger a payment automatically – on a schedule, on an event, on a threshold – they need a different approach.” – Ravi, Finexer
What Is the Business Impact of No Payment Flow Control?
Why Does User-Controlled Payment Flow Break Platform Operations?
For platforms that depend on payment certainty, user-controlled flows create three operational problems:
Failed recurring collections – utility billing and invoicing platforms that use Pay by Bank for recurring collection cannot guarantee payment. Each collection cycle requires the user to re-authenticate. Users who miss the authentication step result in failed collections that require manual follow-up.
Payroll disbursement risk – payroll platforms that initiate salary payments need certainty that funds will reach employee accounts on the designated date. A payment flow that depends on user action introduces timing uncertainty that is unacceptable in payroll.
EPOS reconciliation gaps – EPOS platforms processing high transaction volumes need payment confirmation at the point of sale. A payment flow that can fail due to user drop-off creates reconciliation gaps that require manual resolution per transaction.
| Payment Use Case | Standard Pay by Bank | Problem | Merchant-Controlled Flow |
|---|---|---|---|
| Recurring billing | User authenticates each collection cycle | User drop-off = failed collection, manual recovery | VRP executes within consented parameters without re-authentication |
| Payroll disbursement | Requires user action to trigger | Timing uncertainty, cannot guarantee pay date | Bulk Payout via PIS initiates on platform schedule |
| Utility collection | User re-authenticates per billing cycle | Non-completion creates arrears management overhead | VRP collects within consented amount range on billing date |
| EPOS payment | User completes full flow per transaction | Drop-off at authentication breaks point-of-sale flow | Payment Links or QR initiate and confirm without redirect friction |
What Does Reliable Merchant Payment Flow Actually Require?
Why VRP Is the Foundation of Merchant Initiated Transactions in Open Banking?
Variable Recurring Payments are the Open Banking mechanism that enables merchant initiated transactions within a regulated consent framework.
Under VRP, the user grants consent once – defining the merchant, the maximum payment amount, and the payment frequency. Within those parameters, the merchant can initiate payments without bringing the user back for per-payment authentication.
This is not a workaround. VRP is a defined Open Banking capability, regulated by the FCA and built into the payment infrastructure that FCA-authorised Payment Initiation Service Providers operate. The user’s consent is explicit and revocable at any time.
Complete guide to Open Banking payments for platforms covers how PIS and VRP fit within the broader Open Banking payment architecture for platform payment design.
How Does Finexer Enable Merchant Initiated Transactions?
What Does Finexer’s PIS and VRP Provide for Platform Payment Flows?
The problem: standard Pay by Bank requires full user authentication per payment – making it unsuitable for automated, scheduled, or recurring merchant-triggered payment flows. Finexer’s FCA-authorised PIS with VRP capability solves this by enabling merchant-controlled payment initiation within pre-agreed consent.
- VRP – Variable Recurring Payments enabling merchant-initiated collections within consented parameters
- Pay by Bank via Faster Payments – zero chargebacks, instant settlement, no interchange fees
- Payment Links – shareable payment initiation links for invoice and billing use cases
- QR code payments – point-of-sale payment initiation without redirect friction
- Bulk Payout – multiple simultaneous disbursements via single API call (payroll, supplier payments)
- Payout – single outbound payment initiation for platform-controlled disbursement
- Webhook confirmation per payment – real-time settlement status, no batch reporting
- Covers almost all major UK banks – high street, challenger, and business banking providers
- Usage-based pricing, 3-5 weeks onboarding support
Transaction enrichment and payment data for platform systems covers how AIS transaction data complements PIS payment initiation – providing confirmation and reconciliation data alongside payment execution.
“Merchant initiated transactions in Open Banking require two things: a consent framework that holds, and a payment infrastructure that executes reliably within it. Finexer’s VRP and PIS give platforms both – the consent is set once, the payments run on the platform’s schedule.” – Ravi, Finexer
What I Feel
The payment control question is the one that determines whether an Open Banking integration actually works for a platform’s use case – or just looks good in a demo.
Checkout payments are easy. The user is present, motivated, and ready to pay.
Recurring billing, payroll, and automated collections are harder. The user is not present. The platform needs the payment to happen anyway.
VRP exists precisely for this. It just needs to be part of the platform’s payment flow design from the start, not an afterthought.
Common Use Cases
EPOS Platforms
Standard Pay by Bank requires user completion of the full authentication flow at point of sale. Finexer’s Payment Links and QR-initiated payments reduce friction at the point of payment initiation, while webhook confirmation delivers real-time payment status without polling or batch reconciliation.
Utility Billing Platforms
Recurring utility collection via standard Pay by Bank fails when users do not complete re-authentication each cycle. Finexer’s VRP enables merchant-controlled collection within pre-consented parameters – the platform triggers on the billing date without user re-involvement.
Payroll & Invoicing Platforms
Payroll disbursements and supplier payments require platform-controlled timing and batch execution. Finexer’s Bulk Payout initiates multiple payments simultaneously via a single API call – on the platform’s schedule, with webhook confirmation per payment.
What are merchant initiated transactions and when are they used?
Merchant initiated transactions are payments triggered by the platform within a pre-authorised consent framework – without requiring user re-authentication per payment. In UK Open Banking, this is enabled through VRP. They are used for recurring billing, utility collection, payroll disbursement, and subscription use cases where the merchant controls payment timing.
How does an Open Banking payment flow work?
A standard Open Banking payment flow involves the user selecting Pay by Bank, authenticating with their bank, and approving the payment amount. Payment Initiation Service Providers use FCA-authorised APIs to connect the merchant to the user’s bank. Settlement occurs via Faster Payments – typically within seconds.
What is the difference between customer-initiated and merchant-initiated Open Banking payments?
Customer-initiated payments require the user to authenticate and approve each individual transaction. Merchant-initiated payments – enabled by VRP – allow the platform to trigger payments within a pre-agreed consent framework without per-payment user action. VRP is designed for recurring billing, subscriptions, and automated collection use cases.
Build reliable merchant payment flows on FCA-authorised PIS and VRP infrastructure
About the Author
Ravi Ranjan
Ravi Ranjan is Co founder & CEO of Finexer