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
- 6
- Available on
- All plans
Product managers implementing direct API transfers face fragmented banking infrastructure and complex authentication redirects. Relying on legacy card rails incurs high interchange fees and network costs, while integrating individual banking APIs requires significant engineering resources to maintain strict compliance and handle inconsistent token protocols across diverse financial institutions.
Cardflo orchestrates PSD2 payment initiation through a unified technical integration, routing open banking payments directly to the optimal banking endpoint. The platform handles the complexity of app-to-app redirection and biometric authentication data, allowing engineering teams to bypass card networks and significantly lower transaction processing fees without building proprietary banking connections.
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
Integrating multiple PISP payment gateways requires orchestrating API calls across hundreds of disparate banking endpoints. Cardflo provides the technical layer for open banking checkout integration, translating merchant payment requests into the exact JSON payloads required by specific banking institutions.
The platform handles the full lifecycle of API based bank transfers, from generating the initial authorisation URL to capturing the final settlement confirmation via webhooks.
This technical infrastructure deals specifically with the underlying PSD2 API mechanics, rather than consumer interface optimisation covered in pay by bank, standard wire clearing described in account-to-account payments, or proprietary guaranteed network layers found in trustly-style bank payments.
Product teams use this architecture to maintain persistent connections with banking providers, ensuring stable uptime for payment initiation while avoiding the technical debt of tracking API maintenance schedules for every supported financial institution.
How open banking payments works
Initiating the banking request
The merchant checkout generates a payment intent through the Cardflo gateway, specifying the transaction amount, currency and destination institution. The orchestration platform dynamically constructs a PSD2 compliant payment initiation payload, applying the correct security certificates and mutually authenticated TLS protocols required by the specific bank's developer portal before transmitting the initiation request to the bank.
Managing the authentication redirect
Upon receiving a successful initiation response, Cardflo extracts the bank-generated authorisation URL and facilitates the device handover. The system routes the session to the mobile banking application or web portal, allowing the financial institution to perform strong customer authentication using biometrics or secure credentials without exposing sensitive login data to the merchant's core orchestration platform.
Processing the webhook confirmation
Following successful banking authentication, the financial institution executes the transfer and posts a status update back to the Cardflo listener endpoints. The gateway instantly parses this webhook data, verifies the cryptographic signature to prevent spoofing, and standardises the response format before pushing a definitive success state to the merchant's underlying order management system for final fulfilment.
Why open banking payments matters
Reducing transaction processing costs
Bypassing traditional card networks removes interchange fees, scheme fees and acquirer markups from the transaction lifecycle. Product managers deploying open banking payments can drastically reduce the cost of overall payment acceptance. This proves particularly valuable for high-value transactions where percentage-based card fees erode commercial margins, replacing those variable costs with highly predictable flat API access costs.
Eliminating fraudulent chargeback liabilities
Direct bank API transfers require biometric or hardware-backed strong customer authentication for every initiated transaction. This explicit cryptographic authorisation shifts the liability entirely to the issuing bank and eliminates the operational burden of managing card-based chargebacks. Finance teams benefit from absolute payment finality, preventing post-transaction revenue reversals and simplifying complex reconciliation processes across the enterprise.
Regulatory notes for open banking payments
PSD2 regulatory technical standards
The European Banking Authority enforces strict Regulatory Technical Standards for open banking communications. Platforms must utilise eIDAS certificates for mutual authentication when connecting to an Account Servicing Payment Service Provider.
These cryptographic certificates verify the identity of the initiating entity, ensuring that only regulated third parties can transmit payment instructions to the financial institution.
Compliance requires constant adaptation to differing API implementations across national regulatory environments. The orchestration platform manages the specific header requirements, payload structures and security signatures mandated by regional open banking frameworks like the Berlin Group standard or Open Banking UK.
This technical abstraction keeps merchant platforms compliant without requiring continuous internal engineering updates.
Bank-led authentication and dynamic linking
Open banking regulations mandate explicit multi-factor authentication for the initiation of any electronic payment transaction. The framework requires the customer's banking application to execute the security challenge, completely removing the merchant's checkout environment from the authentication scope.
This separation of concerns ensures that sensitive credential data remains securely isolated within the regulated banking perimeter.
Financial institutions implement dynamic linking requirements to bind the authentication token precisely to the transaction amount and the specific merchant payee. If any parameter alters between the initiation request and the final bank execution, the authentication token immediately invalidates.
The orchestration layer guarantees that the initial request payload matches the final execution command perfectly.
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
This range reflects typical industry observations when comparing A2A fees to the total cost of card acceptance including interchange and scheme fees.
Industry benchmarks for successfully authenticated open banking payments often exceed card-not-present rates due to real-time fund checks and biometric security.
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.
Related terms
Talk to our team about a live rollout across our acquirer partners' rails.
What you get with Open banking payments
- Standardised API connections translate merchant requests into institution-specific payloads for automated payment initiation.
- App-to-app redirection routing hands over the authentication session directly to the customer's native banking application.
- Webhook listener infrastructure captures real-time bank confirmation payloads to update merchant order systems instantly.
- Unified token management standardises authentication credentials across various European banking interfaces and regional open banking hubs.
- Automated failover logic detects banking API timeouts and re-routes the initiation request to alternative aggregator connections.
- Sandbox testing environments simulate strong customer authentication flows for rigorous product checkout integration testing.
A short scoping call, then a written plan for your MIDs.
Questions about Open banking payments
How do PISP gateways handle bank authentication timeouts?
When an authentication session exceeds the bank's predefined time-to-live threshold, the financial institution automatically invalidates the specific token. The Cardflo gateway detects this timeout via status polling or delayed webhook responses.
The platform updates the internal transaction state to expired and signals the merchant's front end to present a renewed checkout session.
This prevents orphan transactions where the customer might attempt to authorise a stale request, ensuring that the merchant's order management system maintains exact synchronisation with the underlying bank's active payment intent ledger.
What is the difference between AISP and PISP licences?
Account Information Service Providers (AISP) only possess the regulatory permission to read banking data, such as transaction history and current balances, typically used for credit scoring or financial dashboards.
Payment Initiation Service Providers (PISP) hold the specific regulatory authority to instruct the bank to move funds on the customer's behalf.
Orchestrating open banking checkouts requires active PISP capabilities to generate the payment intent, construct the transfer payload and transmit the execution command directly to the relevant Account Servicing Payment Service Provider (ASPSP).
How are refunds processed for open banking payments?
Refunding an API based bank transfer fundamentally differs from reversing a card transaction. Because open banking rails operate as push payments, the original transaction cannot simply be voided or reversed through the scheme network.
To issue a refund, the merchant must initiate a completely new outbound transfer back to the customer's original International Bank Account Number (IBAN).
Cardflo captures and encrypts the source IBAN during the initial payment payload, allowing finance teams to trigger automated outbound return transfers through compatible payout orchestration routes.
Do open banking APIs support recurring payment mandates?
While initial PSD2 frameworks focused heavily on single immediate payments, Variable Recurring Payments (VRP) now enable ongoing automated collections through open banking rails.
Establishing a VRP requires the customer to authenticate a long-lived consent mandate with their bank, defining specific parameters like maximum amounts and frequency.
Once this cryptographic consent token is established, the Cardflo orchestration layer can trigger subsequent API calls to initiate future transfers automatically, entirely bypassing the need for customers to re-authenticate via their banking application for every subsequent billing cycle.
Related features.
Related guides.
See how Cardflo compares.
From the blog
A merchant acquirer is a licensed bank that holds your account, takes liability for transactions, and settles funds. The payment processor is the technology layer routing data between the checkout, card networks, and issuing banks. Every card payment requires both components to manage technical encryption and financial liability. They are often separate entities with distinct fee structures.
Read articleA merchant acquirer is a financial institution that processes card transactions and verifies funds. The payment gateway acts as the technological bridge, encrypting sensitive data between the website and the acquirer. Merchants need both components to ensure that electronic payments are accepted, authorised, and settled. Together, they create a seamless and secure payment experience for customers.
Read articleA merchant account is a specialised business account used to accept electronic payments like Apple Pay and Google Pay. It acts as a bridge between the business and the customer bank. Funds are held here for verification and compliance before being transferred to a main bank account. This process ensures that all transactions are secure and reduces the risk of fraud for the merchant and the customer.
Read articleReady 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.