Pay by Bank in Hosted Checkout
Learn how to offer open banking-powered payments in Hosted Checkout.
Use this for: one-off or recurring Open Banking payments via Pay by Bank.
Hosted Checkout supports two types of Pay by Bank transactions:
- Single Immediate Payments (SIPs): one-off payments authorised by the customer in real time.
- Variable Recurring Payments (VRPs): ongoing payments made under a pre-approved mandate with configurable limits. This applies to both Sweeping and Commercial VRP.
Note: Pay by Bank is only supported when using GBP as the currency.
The Pay by Bank type depends on the checkout scenario you configure:
| Scenario | Pay by Bank Type |
|---|---|
| One-off payment | Single Immediate Payment (SIP) |
| Store credentials only | Variable Recurring Payment (VRP) |
| Charge + store credentials | Variable Recurring Payment (VRP) |
One-off Payment (SIP)
Use this for: taking a single Open Banking payment from a customer.
For Pay by Bank (SIP), no additional fields are required beyond the standard transaction fields. The request structure is identical to one-off payments made with cards or wallets, created with Create payment links. See the One-off Payments page for full details.
Response
A successful request returns a link_id. Redirect the customer to the Hosted Checkout page for that link to complete the payment. The same response is returned for VRP mandate setup.
{
"status": "success",
"link_id": "01HZ6XKQR4NJTV8S2BWMCEGP7Y"
}How it Works
- The customer selects Pay by Bank at checkout.
- They are redirected to their banking app or online banking portal.
- The customer reviews and authorises the transaction.
- The bank processes the payment instantly via Faster Payments.
- Hosted Checkout confirms the outcome via
status_updatewebhook and form POST. See Handling Hosted Checkout Responses for the payload, and Statuses for the values a payment can return. - Funds settle into your Acquired ledger and are batch settled to your external bank account each working day. See Settlement and the
settledstatus.
Funds are transferred in real time, and no credentials are stored for future use.
Variable Recurring Payments (VRPs)
VRPs allow you to set up a mandate that authorises future payments within defined limits (amounts and frequency).
Unlike SIPs, which are single transactions, VRPs follow a two-step flow:
-
Mandate Setup via Hosted Checkout.
You set the mandate details in the Create payment links request:- Maximum per-payment amount
- Periodic limits (e.g. £100 per month)
- The mandate's validity window, if you need one
The customer is then redirected through their bank's Open Banking flow to authorise the mandate, selecting the account it will be taken from.
Once authorised, a
mandate_activewebhook confirms the mandate is live. See Webhook Notifications for the payload.You can retrieve the full mandate at any point with Retrieve an open banking mandate. The response returns the limits you set, plus the details added during authorisation: the
debtoraccount the customer selected, thecreditoraccount payments are made to, the mandatestatus,termandreference.To create and manage mandates yourself rather than through Hosted Checkout, see Stage 1: Mandate setup on the Recurring Pay by Bank page.
-
Payment Initiation (outside Hosted Checkout).
Future payments are initiated by you with Initiate a variable recurring payment. No customer interaction is required, as long as payments remain within the agreed mandate parameters.
Note: Hosted Checkout only supports the mandate setup portion of VRPs. All VRP payments, including the first payment in a Charge + Store scenario, must be initiated separately with Initiate a variable recurring payment.
VRP Scenarios
VRPs in Hosted Checkout use the same baseline fields as when storing credentials for cards and digital wallets, plus VRP mandate details. For those baseline fields, see Store credentials only and Charge + store credentials.
The following fields are required in addition to those baseline fields:
| Field | Type | Required | Description |
|---|---|---|---|
recurring.term | object | No | Defines the active date range for a recurring payment schedule or VRP mandate. |
payment.reference | string | No | Sets the reference that will appear on the customer's bank statement for payments made under this mandate. |
configuration.variable_recurring_payment | object | Yes | Defines recurring payment limits and mandate parameters. |
configuration.variable_recurring_payment.type | string | Yes | Defines the type of VRP: sweeping or commercial. |
configuration.variable_recurring_payment.periodic_limit | object | Yes | Container for all mandate limits. Must include per_payment, plus at least one period limit (e.g. day, week, month) with maximum_amount and alignment. |
configuration.variable_recurring_payment.periodic_limit.per_payment | object | Yes | Defines the maximum allowed amount for a single payment under the mandate, via maximum_amount. Nested inside periodic_limit, not alongside it. |
Note:
transaction.currencymust be set togbpto offer VRPs via Pay by Bank. Other payment types support additional currencies.
VRP Mandate Requirements
To successfully offer VRPs via Hosted Checkout, within the configuration.variable_recurring_payment you must include:
type: the type of variable recurring payment (sweepingorcommercial)periodic_limit.per_payment.maximum_amount: the cap per payment- At least one period limit within
periodic_limit(e.g. day, week, month) containing:maximum_amount: cap for that periodalignment:calendarorconsent(not required for the fortnight periodic limit; this defaults toconsent)
These parameters define the scope of the customer's authorisation and must be honoured in every payment request under the mandate. If any of these fields are missing or malformed, the Create payment links request will fail.
Monzo does not support the
day,week,fortnightorhalf_yearperiodic limits. They also do not support thecalendaroption foralignment. If these values are included in your request, Monzo will be removed from the list of banks available for customers to select. See Supported Banks for full coverage by bank and VRP type.
Store Credentials Only vs. Charge + Store Credentials
The distinction between Store Credentials Only and Charge + Store Credentials depends on a combination of transaction.capture and transaction.amount:
| Scenario | transaction.capture | transaction.amount | Pay by Bank (VRP) behaviour at checkout |
|---|---|---|---|
| Store Credentials Only | false | Any value (incl. 0) | Creates the mandate only. No payment is taken. You trigger payments later with Initiate a variable recurring payment. |
| Charge + Store Credentials | true | > 0 | Creates the mandate only. No payment is taken automatically. You must initiate the first payment with Initiate a variable recurring payment. |
Important: For Pay by Bank, Hosted Checkout never takes a payment during mandate setup. All payments, including the first one in a Charge + Store flow, must be created with Initiate a variable recurring payment.
Example Request
The payload below shows the baseline VRP structure. Toggle transaction.capture to switch between Store Credentials Only and Charge + Store Credentials scenarios:
{
"transaction": {
"order_id": "vrp-001",
"currency": "gbp",
"amount": 10.00,
"capture": false
},
"is_recurring": true,
"payment": {
"reference": "Monthly Plan"
},
"configuration": {
"variable_recurring_payment": {
"type": "sweeping",
"periodic_limit": {
"per_payment": {
"maximum_amount": 100
},
"month": {
"maximum_amount": 300,
"alignment": "calendar"
}
}
}
},
"recurring": {
"term": {
"start_date": "2025-09-01",
"end_date": "2026-09-01"
}
}
}As with a SIP, a successful request returns a link_id to redirect the customer to. Set transaction.capture to true for the Charge + Store Credentials scenario. The payment.reference field is optional and defaults to your company name if omitted. The recurring.term object is optional; omit it if you do not need a validity window.
VRP Mandate Cancellations
VRP mandates can be cancelled by the customer either via their banking app or through the hosted Acquired revocation flow. Once cancelled, no further payments can be initiated under that mandate, even if the mandate limits have not been reached. For the revocation URL parameters, the redirect response and hash validation, see Cancel a Mandate.
VRP Mandate Cancellation at Bank
Customers can revoke consent directly from their bank at any time.
When this happens:
- The bank cancels the VRP mandate
- Acquired will send a
mandate_cancelledwebhook notification — see Webhook Notifications for the payload - You should update your internal customer billing state accordingly
We recommend monitoring cancellation webhooks in real time and pausing any scheduled billing immediately. This ensures a seamless customer experience and helps avoid failed payment attempts.
VRP Mandate Cancellation via Hosted Flow
In addition to cancellation through the bank, merchants must provide customers with the option to cancel a VRP mandate through a hosted Acquired journey.
To do this, redirect the customer to the VRP revocation URL for your environment:
| Environment | Revocation URL Format |
|---|---|
| QA | https://test-pay.acquired.com/v1/open-banking/vrp/{mandate_id}/revoke |
| Production | https://pay.acquired.com/v1/open-banking/vrp/{mandate_id}/revoke |
The hosted revocation flow:
- Displays mandate and payee details
- Allows the customer to confirm cancellation
- Cancels the mandate via Acquired's internal VRP cancellation API
- Sends a
mandate_cancelledwebhook - Redirects the customer back to your application
VRP mandates cannot be cancelled via the merchant API. They must be cancelled by the customer, through their bank or the hosted Acquired revocation page. See Cancel a Mandate.
Updated 19 days ago