Methods

Open banking payments

Open banking payments require precise orchestration of API connections across hundreds of institutions. Cardflo provides the gateway infrastructure for product managers to route API based bank transfers efficiently, bypassing traditional card networks to reduce transaction processing costs entirely.

Category
Methods
Capabilities
10
Available on
All plans
Apply now

Payment Initiation Service Providers (PISPs) facilitate direct bank-to-bank transfers, bypassing traditional card networks. This mechanism, central to Open Banking, relies on secure API connections with Account Servicing Payment Service Providers (ASPSPs) to execute payments directly from a customer's bank account. This provides an alternative rail for digital transactions.

The process involves several technical steps, from the merchant initiating a payment request to the customer authorising it within their banking environment. Understanding these specific interactions, including Strong Customer Authentication (SCA) within banking apps and the nuances of various payment flows, is crucial for effective integration and operation.

Open banking integrations via Cardflo provide merchants with direct access to local payment schemes, leading to lower transaction costs and faster settlement times. This method also substantially reduces chargeback risks, streamlining financial operations and improving cash flow.

Open banking payments overview

Open Banking payment initiation provides a direct pathway for funds to move from a customer's bank account to a merchant's, leveraging secure API infrastructure. Payment Initiation Service Providers (PISPs) act as intermediaries, instructing Account Servicing Payment Service Providers (ASPSPs), i. e. , banks, to execute these transfers.

This contrasts with card payments, where multiple entities handle authorisation, clearing, and settlement. The architecture specifies clear roles for each participant.

The technical workflow for initiating a payment involves distinct steps, beginning with the merchant's request. This request is passed to the PISP, which then interfaces with the customer's chosen ASPSP.

The customer's interaction for authentication and authorisation typically occurs within their banking app or portal, ensuring that sensitive credentials are never exposed to the PISP or merchant. This direct engagement with the bank is a cornerstone of the security model.

Following authorisation, the PISP receives confirmation from the ASPSP regarding the payment status, which is then communicated back to the merchant. Settlement finality varies by scheme and ASPSP, impacting when funds become available.

Implementing Open Banking payments requires careful consideration of these technical specificities, including handling payment status updates, potential refunds, and the operational differences between UK Open Banking and EU PSD2 APIs.

How open banking payments works

  1. Initiating a payment request

    The merchant submits a payment initiation request to Cardflo, specifying the amount, currency, and customer details. Cardflo, acting as a PISP, generates the necessary payment request payload compliant with the chosen ASPSP’s API specifications. This initial step prepares the redirection or embedded flow for the customer's bank interaction. Merchant-defined metadata can be included.

  2. Customer authentication and authorisation

    The customer is redirected to their ASPSP’s online banking portal or mobile app. Here, they authenticate using their bank’s SCA methods, such as fingerprint, facial recognition, or PIN. The customer reviews the payment details and explicitly authorises the transfer. This step ensures that sensitive banking credentials are never exposed to Cardflo or the merchant.

  3. Payment execution and status updates

    Upon successful authorisation, the ASPSP executes the payment from the customer’s account. Cardflo receives real-time payment status updates from the ASPSP via webhooks, indicating whether the payment is successful, pending, or failed. These updates are then relayed to the merchant, allowing for immediate order fulfilment or service provision, streamlining operations.

  4. Managing refunds and recurring payments

    Refunds for Open Banking payments are initiated by the merchant and processed back to the original bank account from which the payment originated. For recurring payments, Variable Recurring Payments (VRP) enable pre-authorised transactions within specified parameters. Cardflo manages the mandates and ensures compliance with the agreed frequency and value caps, distinguishing between sweeping and non-sweeping VRPs.

Why open banking payments matters

Navigating PISP and ASPSP API differences

API specifications for Payment Initiation Service Providers and Account Servicing Payment Service Providers vary significantly across different banks and jurisdictions (e.g., UK Open Banking versus EU PSD2). Understanding these nuances is critical for consistent payment processing. Cardflo normalises these diverse API interactions, ensuring uniform integration for merchants regardless of the underlying bank’s specific technical implementation. This abstraction reduces development complexity and ongoing maintenance for businesses operating across various markets. Correct API versioning is also handled.

Implementing Variable Recurring Payments (VRP)

Variable Recurring Payments introduce new possibilities for managing subscriptions and account top-ups, but their implementation requires careful handling of mandate creation, usage limits, and distinctions between sweeping and non-sweeping VRPs. Cardflo provides the mechanisms for establishing and managing VRP mandates, including setting frequency and maximum value thresholds. The platform ensures compliance with scheme rules for both types of VRPs, providing the necessary controls and reporting to manage ongoing customer agreements effectively, reducing manual oversight.

Open banking payments use cases

Bank transfers for wealth platforms

Investment platforms initiate PSD2 transfers from verified bank accounts to brokerage cash balances, where authentication redirects and delayed status updates can interrupt order funding. Cardflo orchestrates PISP API connections, returns payment status through webhooks and helps operators reconcile confirmed funds before enabling securities purchases.

Corporate invoice payment links

B2B software vendors attach open banking payment links to annual licence invoices, avoiding corporate card limits while holding on to invoice references through the authentication flow. Cardflo routes initiation requests to suitable PISP connections and passes bank confirmation, reference and settlement data into finance teams’ reconciliation workflows.

Luxury purchases by bank transfer

Luxury retailers accepting PSD2 initiated bank transfers must distinguish successful authentication from confirmed funds before releasing watches, jewellery or limited stock. Cardflo normalises API status responses across PISP connections and supplies webhook updates that let fulfilment teams hold dispatch until the relevant confirmation state is recorded.

Loan overpayment collection

Lenders use one-off open banking initiation to collect borrower overpayments or arrears, where consent, SCA redirection and payment status must remain separate from scheduled repayment mandates. Cardflo coordinates PISP routing, records the authentication journey and returns standardised status events for allocation against the correct loan account.

Open banking payments by the numbers

50-80%
Transaction Cost Savings

This range reflects typical industry observations when comparing A2A fees to the total cost of card acceptance including interchange and scheme fees.

95-98%
Authorisation Success Rate

Industry benchmarks for successfully authenticated open banking payments often exceed card-not-present rates due to real-time fund checks and biometric security.

<45s
Checkout Completion Time

Typical time for a customer to complete an open banking payment via mobile app redirect, compared to manual entry of card details and 3DS prompts.

Methodology: these figures are illustrative ranges drawn from published industry data and observed merchant cohorts, not guarantees. Actual results depend on your risk profile, card mix, geography and acquiring setup, and are confirmed only in your own pricing and approval terms.

Ready to route with Open banking payments?

Talk to our team about a live rollout across our acquirer partners' rails.

Apply now

What you get with Open banking payments

  • A PISP initiates a payment instruction directly with the customer's ASPSP via secure APIs.
  • The ASPSP is the customer's bank, which holds the account and executes the payment instruction.
  • App-to-app redirects send the customer to their banking application for payment authorisation.
  • Embedded payment flows keep the customer within the merchant’s environment, using bank-supplied widgets.
  • Strong Customer Authentication (SCA) occurs directly within the banking app, using biometrics or PINs.
  • Payment status webhooks provide real-time updates from the ASPSP to the PISP regarding transaction outcomes.
  • Settlement finality for Open Banking payments varies depending on the specific bank and scheme rules.
  • Refunds for PIS payments are processed back to the original debited account, maintaining audit trails.
  • Variable Recurring Payments (VRP) allow pre-agreed payments within defined frequency and value limits.
  • Sweeping VRPs facilitate transfers between a customer's own accounts, distinct from non-sweeping VRPs for third parties.
See Open banking payments live across our acquirer partners.

A short scoping call, then a written plan for your MIDs.

Apply now

Questions about Open banking payments

How do open banking payments differ from traditional bank transfers?

Traditional bank transfers often require the customer to manually log into their bank, add a new payee, and copy over a reference number, which is prone to human error. Open banking payments automate this through a PISP API.

The merchant initiates the request and the customer simply approves it within their banking app. This ensures the correct amount and reference are used, allowing for automated reconciliation and immediate confirmation, which manual transfers cannot provide.

Are open banking payments susceptible to chargebacks?

Unlike card payments governed by Visa or Mastercard rules, open banking payments do not have a built-in chargeback mechanism. These are credit transfers initiated by the payer.

While a customer can still raise a dispute with their bank if they suspect fraud, the 'friendly fraud' or 'item not received' chargeback process frequent in the card industry does not apply.

This provides merchants with greater payment finality and protects against the fees and administrative load of card disputes.

Do customers need to share their banking credentials with the merchant?

No, customers never share their banking login details, passwords, or PINs with the merchant or the payment provider. The authentication happens entirely within the bank’s own secure environment.

The payment provider acts merely as a bridge, securely passing the payment instruction to the bank. This model significantly reduces the PCI DSS scope for merchants as they are not handling sensitive financial credentials or cardholder data.

What is the typical settlement timeframe for these transactions?

The settlement speed depends on the underlying clearing rails used in the specific region. In the UK, most open banking payments use the Faster Payments service, which typically settles funds within seconds or minutes.

In Europe, the timeline depends on whether the bank supports SEPA Instant. If SEPA Instant is not available, it may revert to standard SEPA Credit Transfer, which can take one business day.

How does open banking interact with Strong Customer Authentication (SCA)?

Open banking is designed to be natively compliant with SCA. When a payment is initiated, the customer must authenticate the transaction using at least two factors, such as their banking app (possession) and biometrics or a passcode (inherence/knowledge).

This satisfies PSD2 requirements more fluidly than 3D Secure, as it uses the bank's own security features that the customer is already accustomed to using.

What happens if a customer has insufficient funds?

If a customer attempts an open banking payment and does not have enough money in their account, the bank will typically refuse the transaction during the authorisation stage.

This is a significant advantage over some card transactions that may be authorised but later fail during settlement, or result in costly overdraft fees for the consumer and potential declines for the merchant.

Can open banking be used for recurring payments or only one-off transactions?

Currently, open banking is widely used for single immediate payments. However, the industry is moving towards Variable Recurring Payments (VRP) and 'sweeping' which allow for ongoing authorisations.

While not yet as universal as card-on-file or Direct Debit, VRPs are becoming an alternative for subscription models, offering more control to the consumer and instant settlement to the merchant.

Apply with Cardflo

Ready to improve your payments setup?

Tell us about your business. We'll match you with the right acquiring partners and the right route, typically inside a week.

Apply now
Apply now