Open-banking payment initiation: one-off bank payments without card details

A payment initiation service lets a customer instruct a payment directly from an online bank account through an authorised third-party provider. For merchants, it can create an account-to-account checkout alternative to cards. For business users, the important controls are provider authorisation, explicit consent, bank authentication and a clean record of the final payment status.

A payment initiation service starts a bank payment at the user's request

The FCA defines payment initiation as an online service that initiates a payment order, at the request of the payment-service user, from an account held with another payment-service provider. In practical terms, a merchant or payment provider can present a "pay by bank" journey without collecting card details.

The third-party provider is known as a payment initiation service provider, or PISP. It does not simply log in as the customer. The service operates under the Payment Services Regulations and open-banking technical framework, with the user's bank acting as the account-servicing payment service provider.

The PISP needs the payer's explicit consent for the payment

FCA guidance says payment initiation services can only act with the user's explicit consent and authentication. The provider should make the transaction understandable before the user confirms it, including who is being paid and the amount or other relevant payment information.

For a merchant, this means the checkout should not hide the payment inside a general account-linking permission. A one-off £780 invoice payment should be presented as that payment. Keep the payment order, consent timestamp and provider reference so customer support can later see what the payer actually approved.

The customer's bank authenticates the payer before the instruction is completed

Open Banking's March 2026 customer-experience standard shows one-off domestic payment journeys in which the user gives consent to the PISP and is then authenticated by the bank. Once the bank has authenticated the user and processed the required information, the user is returned to the PISP or merchant journey.

This reduces the merchant's need to handle online-banking credentials. The user authenticates with the bank, not by handing their password to the merchant. Before integrating a provider, check that the PISP is authorised or registered for the relevant activity on the FCA Financial Services Register.

A successful checkout screen is not the same thing as reconciled cash

The Open Banking Standard allows a PISP to retrieve the status of the payment order. Merchants should use that capability rather than marking every order paid simply because the customer completed bank authentication. Payment initiation, bank acceptance and final receipt should be connected in the merchant's reconciliation process.

Use a unique payment reference that links the bank transaction to the customer order. If the payer closes the flow, the bank rejects the payment or the status remains uncertain, do not fulfil high-value goods merely because the checkout session reached its final webpage. Settlement evidence should drive fulfilment policy.

Future-dated, CHAPS, Bacs and bulk payment functionality depends on what the account provider supports

Open Banking standards cover more than immediate Faster Payments, but the available payment types depend on the payer's account provider and its own online functionality. The standards say payment providers are not required to expose a payment type through a PISP where they do not support that type through their own online channel.

The March 2026 standard also covers future-dated domestic payments. It notes that amendment or cancellation of those future-dated payments is not currently supported through the PISP standard itself and may need to be handled through the payer's own bank channel where supported. Do not promise customers universal scheduling features unless the connected banks actually provide them.

Treat pay-by-bank as its own payment rail for refunds, exceptions and reconciliation

Define how refunds will be made before launch. A merchant may need to send a separate bank payment back to the verified payer account or use a provider-supported refund flow, depending on the service. Customer support should know that the process is not identical to card refunds or Direct Debit indemnity handling.

Track conversion rate, payment success, settlement time, failed authentication and reconciliation workload. Open banking can reduce card dependence and offer direct account-to-account payments, but the commercial value should be measured from real operational results. A new payment button is useful only if finance can identify the money and customers can resolve exceptions cleanly.