Last Updated: 11 June 2026
Reading Time: 10 minutes
Author: Inquid Editorial Team
Open banking APIs have fundamentally changed how merchants connect to banking infrastructure. In 2026, payment initiation through open banking APIs is no longer a future ambition — it is a live, scalable payment rail being used by Forex brokers, iGaming operators, and subscription platforms across the UK, Europe, and beyond. This guide explains how open banking APIs work for merchants, what integration looks like in practice, and why high-risk businesses stand to benefit the most.
What Is an Open Banking API?
An open banking API is a standardised programming interface that allows a licensed third-party payment provider to communicate with a customer bank on their behalf — with the customer’s explicit consent. There are two principal types relevant to merchants:
Payment Initiation Service Provider (PISP) API — Enables a merchant or their payment provider to initiate a bank transfer directly from the customer’s bank account to the merchant’s designated account. This is the core mechanism behind open banking payments at checkout.
Account Information Service Provider (AISP) API — Enables a merchant or service provider to read a customer’s bank account data (transaction history, balance, account details) with consent. This is used for affordability checks, Know Your Customer (KYC) enrichment, and fraud scoring.
For most merchants, the PISP API is the primary integration point. The AISP API is increasingly relevant for regulated industries — particularly UK Gambling Commission-regulated operators required to conduct open banking-based affordability assessments from 2026.
The Regulatory Foundation: PSD2, FCA, and Global Equivalents
European Union: PSD2 and PSD3
In the EU and EEA, the Revised Payment Services Directive (PSD2) mandates that banks provide API access to licensed third parties. The follow-on PSD3 framework, scheduled for progressive implementation from 2026 onwards, strengthens API standardisation and performance requirements, reducing the technical inconsistency that has historically created friction in open banking integrations.
United Kingdom: FCA PISP Regime
The UK’s departure from the EU did not diminish its open banking framework — in many respects, the UK leads globally. The Financial Conduct Authority (FCA) licenses PISPs and AISPs independently of the EU framework. The Open Banking Implementation Entity (OBIE) developed the UK Open Banking Standard, which all nine largest UK banks are required to implement.
By mid-2025, the UK had over 13 million active open banking users with monthly payment volumes continuing to grow at roughly 40% year-on-year. The upcoming transition to the Future of Payments regulatory framework signals further expansion of PISP capabilities, including Variable Recurring Payments (VRP) beyond the current sweeping use cases.
USA: Consumer Financial Protection Bureau (CFPB)
In the US, the CFPB’s Section 1033 rule establishes consumer rights to share financial data with third parties. While US open banking remains market-led rather than mandated, the Financial Data Exchange (FDX) standard now covers over 114 million customer accounts and is the de facto API standard for US open banking.
How Merchants Integrate an Open Banking API
There are three primary integration models, each suited to different merchant technical capabilities and use cases.
1. Hosted Checkout Integration (No-Code / Low-Code)
The simplest route to accepting open banking payments. The merchant embeds a payment button or redirect link that takes the customer to a hosted payment page managed by the open banking gateway provider. The merchant receives a webhook notification on payment confirmation. This approach requires minimal technical work — typically a few hours of development — and is suitable for eCommerce merchants using WooCommerce, Magento, Shopify, or similar platforms.
2. API Integration (Direct)
The merchant integrates directly with the gateway provider’s PISP API, building open banking payment initiation natively into their checkout flow. This approach offers the highest level of customisation — the payment experience remains fully within the merchant’s environment — but requires developer resources. Integration typically takes one to three weeks for a competent development team. REST API documentation, sandbox environments, and test bank credentials are standard from reputable providers.
3. SDK and Plugin Integration
Payment SDK libraries (typically available in JavaScript, PHP, Python, and Node.js) wrap the underlying API calls and simplify integration. CMS plugins for WooCommerce, OpenCart, and Magento are increasingly common. For merchants on supported platforms, this is the fastest route to production.
Open Banking API Use Cases for High-Risk Merchants
Forex and CFD Brokers
For trading platforms, open banking APIs solve two critical problems. First, they provide instant deposit initiation — a customer can fund their trading account from their bank in seconds, improving conversion rates at the crucial deposit stage. Second, they enable instant withdrawals: the broker initiates a payment from the platform account directly to the trader’s bank account via the PISP API, eliminating the multi-day card withdrawal window.
In a highly competitive retail trading market, same-day withdrawals are increasingly a standard customer expectation rather than a premium feature.
iGaming and Online Casino Operators
UK Gambling Commission (UKGC) regulations from 2024 onwards require operators to use open banking data for player affordability assessments — confirming that a player’s spending on gambling is proportionate to their income and financial situation. This requires AISP API integration to pull account data for risk-scored customers.
On the payment side, open banking deposit initiation reduces decline rates (a persistent problem for gaming merchants on card rails) and eliminates card network prohibitions. Malta-licensed (MGA) and Curaçao-licensed operators are increasingly implementing open banking as a primary European payment method.
Subscription and Recurring Billing Platforms
Variable Recurring Payments (VRP) — an open banking payment type that allows pre-authorised, variable-amount recurring transfers — is being piloted across UK banks and represents the most significant development in open banking for subscription merchants since the original PSD2 mandate. Unlike direct debits, VRP payments include real-time consumer controls and cannot be disputed through the same chargeback mechanism.
High-Risk eCommerce Merchants
Merchants in high-chargeback categories — digital goods, nutraceuticals, adult content, gaming credits — find open banking APIs particularly valuable because they sidestep card network rules entirely. There are no MCC codes to manage, no card brand rules restricting what can be sold, and no chargeback mechanism for disputes to exploit.
Technical Considerations for Open Banking API Integration
Bank Coverage — Not all banks in every market support all open banking payment types. Before selecting a provider, confirm which banks are supported in your primary geographic markets. In the UK, the nine major banks (Barclays, HSBC, Lloyds, NatWest, Santander, and others) provide full PISP coverage. In Europe, coverage varies by country and is improving as PSD3 implementation progresses.
Consent and Authentication UX — The customer authentication step (redirecting to their bank) adds one step to the checkout flow compared to entering card details. Optimising the redirect flow — pre-selecting likely banks, using app-to-app redirection on mobile, minimising load times — is important for maximising checkout conversion.
Webhook Reliability — Open banking payments require robust webhook infrastructure to handle asynchronous payment confirmation. Merchants should implement retry logic and idempotency keys to prevent duplicate order fulfilment on webhook retries.
Refund Handling — Open banking payments cannot be reversed through the payment initiation channel. Refunds require a separate outbound payment from the merchant. This is operationally straightforward but must be accounted for in the merchant’s order management workflow.
Open Banking API Security and Compliance
Open banking APIs operate under strict security requirements. All data in transit must be encrypted using TLS 1.2 or higher. Qualified website authentication certificates (QWACs) are required for PSD2 compliance in the EU. API authentication uses OAuth 2.0 and strong customer authentication (SCA) is a mandatory component of every payment initiation.
For merchants handling open banking data, the GDPR (EU/UK) and equivalent data protection regulations govern how account information data accessed via AISP APIs can be stored and used. Consent must be explicit, purpose-limited, and revocable.
Frequently Asked Questions
1. Do I need my own PISP licence to use an open banking API?
No. Merchants access open banking payment initiation through a licensed PISP — a regulated payment provider that holds the necessary authorisation from the FCA (UK), relevant national competent authority (EU), or equivalent regulator. Inquid and similar providers hold these licences; merchants access the capability via the provider’s API without needing their own regulatory authorisation.
2. How long does it take to integrate an open banking API?
Integration time depends on the approach. A hosted checkout redirect can be live in hours. A full REST API integration typically takes one to three weeks for a developer-resourced team. SDK and plugin integrations for supported platforms (WooCommerce, Magento) can be completed in one to two days.
3. Which banks are supported by open banking APIs in the UK and Europe?
In the UK, all nine major current account banks are required to support open banking APIs under the CMA Order. Coverage includes Barclays, HSBC, Lloyds, NatWest, Santander, Nationwide, Danske Bank, Bank of Ireland, and Allied Irish Bank. In Europe, coverage varies by country — Germany, the Netherlands, and the Nordics have the highest coverage rates as of 2026.
4. Can open banking APIs be used for recurring payments and subscriptions?
Yes, through Variable Recurring Payments (VRP). VRP is a specific open banking payment type that allows pre-authorised, variable-amount recurring transfers — designed precisely for subscription billing, top-up services, and automated sweeping. VRP is currently in expanded rollout in the UK; EU equivalents are progressing under PSD3.
5. Is open banking API integration available for Forex and iGaming businesses in offshore-licensed jurisdictions?
Open banking payment initiation is available to merchants regardless of their licensing jurisdiction, as the regulatory obligation sits with the PISP (the payment provider), not the merchant. A Curaçao or Malta-licensed iGaming operator can accept UK or EU customer payments via open banking, provided the PISP conducting the initiation is appropriately licensed for those markets.
Inquid offers open banking API integration for high-risk merchants across the UK, EU, and global markets. Our PISP capabilities cover Faster Payments (UK), SEPA Instant (EU), and emerging markets. Contact us to discuss integration options.