Open Banking Payments

Open Banking Payments: How Bank-API Payment Initiation Works for Merchants

A customer reaches checkout and clicks Pay by Bank.

The merchant does not need to build a separate connection to every customer's bank. In a typical open-banking payment implementation, a payment-initiation provider connects into participating banks, the customer gives the required consent, and the customer's bank authenticates them before the payment order is submitted.

Then something important happens:

the payment still has to travel somewhere.

In the UK, an open-banking payment may ultimately move across existing bank-payment infrastructure such as Faster Payments. The UK Open Banking Standard defines payment-initiation services through which a PISP can initiate a payment order, with the customer's explicit consent, from an online payment account and obtain payment-status information. Pay.UK, separately, operates the Faster Payment System used to move bank payments between participating institutions.

The same architectural distinction exists in SEPA. The European Payments Council's current SEPA Instant Credit Transfer rulebook explicitly provides for a credit transfer to be initiated either by the payer or indirectly by a payment-initiation service provider.

That is the most important thing an international merchant should understand about open banking:

Open banking can change how a customer and merchant connect to a bank account without creating the underlying payment rail that moves the money.

It is an initiation and connectivity model.

It can produce account-to-account payments.

It can use real-time payment infrastructure.

It can appear at checkout as Pay by Bank.

Those statements can all be true simultaneously without making the terms interchangeable.

Open banking is not another name for A2A, bank transfer, or instant payment

Payment terminology becomes confusing because several descriptions can apply to the same transaction.

Consider a UK ecommerce payment.

A customer might:

•choose Pay by Bank;

•interact with an open-banking payment provider;

•consent to a payment-initiation request;

•authenticate with their own bank;

•authorize the bank payment;

•have the transfer processed through Faster Payments;

•and return to the merchant.

That transaction can reasonably be described as:

•an open-banking payment;

•an account-to-account payment;

•a bank payment;

•and, depending on its execution, a fast bank payment.

But each term describes a different part of the system.

Account-to-account describes where the money moves

A2A describes movement between accounts without the transaction being carried over a conventional card-payment rail.

It does not tell the merchant how that payment was initiated.

Open banking describes connectivity and authorized access

In the UK model, payment initiation allows a regulated PISP to initiate a payment order at the request of the payment service user. The customer's account-servicing payment provider—the ASPSP—remains the institution servicing the customer's payment account. The FCA requires payment-initiation providers to be appropriately authorized and identifies customer consent and authentication as central to account access.

Faster Payments or SEPA Instant describes payment infrastructure or scheme

Pay.UK describes Faster Payments as its 24/7 interbank retail payment system. The European Payments Council separately operates the SCT Inst scheme for instant euro credit transfers in SEPA.

“Pay by Bank” usually describes the merchant-facing proposition

A merchant or provider can label the checkout experience in language customers understand without exposing the architecture underneath it.

That is commercially useful.

It is not a technical definition.

The merchant therefore needs to ask:

What exactly is doing what?

What open banking actually changes

Open banking creates standardized or regulated ways for authorized third parties to interact with eligible payment accounts.

For payments, the relevant capability is generally payment initiation.

This needs to be separated from account information.

Under PSD2 terminology, payment initiation services and account information services are distinct payment-service categories. The European Commission has described both as open-banking services, while PSD2 itself sets distinct rules for payment initiation and account information.

That gives merchants an immediate terminology rule:

A provider accessing bank-account information is not necessarily initiating payments.

And:

A merchant using open-banking payment initiation does not necessarily need or receive the customer's transaction history.

The integration should request and process only the services and data required for the merchant proposition.

PISP versus AISP

Under the PSD2-style terminology commonly encountered in Europe:

PISP — Payment Initiation Service Provider

Provides the regulated service that initiates a payment order at the customer's request in relation to an account held with another payment service provider.

AISP — Account Information Service Provider

Provides account-information functionality rather than payment initiation.

A firm may have permissions for more than one role, but merchants should not infer payment-initiation capability merely because a provider offers bank-account connectivity.

For international merchants, this terminology should also be treated as jurisdiction-specific.

The UK and European regulatory frameworks provide useful reference models, but “open banking” is not one globally identical licensing regime, API standard, bank-coverage model, or payment product.

The legal and technical arrangement must be verified market by market.

The customer gives consent before the bank authenticates the payment

Consent and authentication are related.

They are not the same event.

The latest UK Open Banking customer-experience guidance describes payment initiation as beginning with explicit customer consent to the PISP. The customer's ASPSP then performs the customer authentication required for the bank-side action.

This distinction matters for both UX and debugging.

Imagine a customer who:

•selects Pay by Bank;

•chooses their bank;

•approves the payment details shown by the initiation provider;

•reaches their banking app;

•but fails bank authentication.

The merchant should not report that as a successfully authorized bank payment.

The customer consented to the initiation journey.

The bank-side authorization did not complete.

Likewise, bank authentication does not necessarily prove that the merchant has received the final payment state required for fulfillment.

Each stage needs its own state.

How customer authentication works

In open-banking payment initiation, the merchant should generally not be collecting the customer's online-banking password.

Bank authentication occurs within the bank or account provider's controlled authentication environment.

The current UK Open Banking Standard supports redirection and decoupled authentication models. In an app-based redirection flow, for example, the customer can be sent directly into the account provider's application to authenticate there rather than entering bank credentials into the PISP's interface.

Depending on the bank, device and market, authentication can involve mechanisms such as:

•banking-app approval;

•biometrics;

•passcodes;

•multifactor or strong customer authentication;

•or other bank-supported authentication.

The important merchant distinction is responsibility:

The merchant initiates the commercial payment flow.

The initiation provider manages the relevant bank connectivity.

The customer's bank controls the bank-side authentication.

If authentication performance varies materially by bank, device or browser, blended checkout statistics can hide the problem.

The Open Banking Payment Stack

A useful merchant model contains seven layers.

•Merchant checkout

The merchant decides:

•whether Pay by Bank appears;

•which transaction is being paid;

•amount and currency;

•order reference;

•customer-return destination;

•and which payment state is required before fulfillment.

The merchant may render the payment button itself or rely on a provider-hosted interface.

•Initiation provider

The merchant or its PSP connects to an authorized payment-initiation capability.

The provider may handle:

•bank discovery;

•API connectivity;

•payment-request creation;

•consent orchestration;

•return URLs;

•payment-status retrieval;

•error mapping;

•and merchant callbacks.

The provider is not necessarily the payment rail.

•Customer consent

The customer receives sufficient information to understand the payment they are authorizing and gives the required consent for the initiation service.

In the UK Open Banking model, payment initiation explicitly relies on the PSU's consent.

Consent should be treated as a state of its own.

Consent ≠ authentication.

Consent ≠ transfer execution.

Consent ≠ completed merchant order.

•Customer bank authentication

The customer's account provider authenticates the customer using the bank's supported journey.

The merchant does not decide whether a particular bank asks for biometric approval, passcode entry, app confirmation or another permitted authentication mechanism.

•Underlying payment rail

After authorization and payment submission, the bank transfer proceeds through whatever underlying infrastructure applies to that payment.

In the UK, Faster Payments can provide the interbank payment layer beneath open-banking-initiated transactions. Pay.UK explicitly discusses open-banking transactions in connection with FPS and separately describes open-banking-initiated payments as a channel/product using its payment-system infrastructure.

In SEPA, an SCT Inst transfer can similarly be initiated through a PISP without making the PISP the SEPA Instant scheme itself.

•Payment status

The merchant needs an authoritative machine-readable answer to:

What happened to the payment?

The UK Open Banking Standard distinguishes multiple stages and supports status information after submission, including granular information during processing and confirmation when the transfer has reached the payee's bank.

That is substantially more useful than a customer-facing “Success” screen.

•Merchant reconciliation

Finally, the merchant must map:

Order

→ payment request

→ open-banking provider transaction

→ bank-payment status

→ funds/settlement record

→ refund if applicable

If those records cannot be joined reliably, the merchant has implemented bank connectivity without implementing dependable ecommerce payment operations.

Open banking versus a real-time payment rail

A particularly persistent misconception is:

Open banking payments are instant because open banking is an instant-payment network.

That reverses cause and effect.

An open-banking provider may initiate onto an underlying real-time or near-real-time payment system.

That rail—not the words “open banking”—determines much of the transfer timing.

For example, Pay.UK describes Faster Payments as continuously available and designed for real-time payments. The EPC describes SCT Inst as making funds available on the beneficiary account within the scheme's defined instant-payment timeframe.

But several clocks still need to be separated:

Customer interaction time

How long does bank selection and authentication take?

Payment execution time

How quickly does the underlying transfer process?

Merchant confirmation time

How quickly does the merchant or provider receive a sufficiently authoritative status?

Merchant funds-availability time

When are the funds accessible under the merchant's actual account/provider structure?

Provider payout time

If a provider receives funds and later pays out the merchant, when does that happen?

A real-time rail does not automatically imply that all five clocks are real time.

Merchant confirmation is where open banking becomes an ecommerce payment

For a merchant, payment initiation is not enough.

The customer may have authenticated.

The payment provider may have successfully submitted the order.

The payer's bank may have accepted it.

The receiving bank may eventually have received it.

These are distinct states.

The current UK Open Banking Standard includes payment-status information across initiation, processing and execution and can communicate a state indicating that settlement is completed to the creditor account.

That gives payment teams an important design rule:

Define the exact provider/rail status that authorizes fulfillment.

Do not use:

•customer redirect completed;

•bank authentication succeeded;

•consent accepted;

•payment request created;

•or payment submitted

as substitutes for an authoritative paid state unless the provider and rail documentation explicitly establish that state as sufficient for the merchant's use case.

For a low-risk digital product, the merchant's risk tolerance may differ from a high-value physical shipment.

But the decision should be deliberate.

Return-to-merchant success is a separate performance metric

Open-banking payments often move the customer away from the merchant's immediate interface.

On mobile, that can mean an app-to-app journey.

On desktop, it may mean browser-based bank authentication or another bank-controlled handoff.

A payment can succeed financially while the customer fails to return cleanly to the merchant.

That creates two separate questions:

Did the money move?

and:

Did the merchant checkout recover the customer and finish the order experience?

The payment system must resolve the order from server-side payment state even when the browser or app return is imperfect.

The customer-return event should improve UX.

It should not be the merchant's sole source of payment truth.

Refunds are not necessarily reversals of the original transaction

Card-oriented payment teams sometimes expect a refund to behave like a message attached to the original payment credential.

Open-banking bank-payment refunds may work differently.

The UK Open Banking Standard's refund guidance explicitly discusses obtaining the payer's account details for future refund purposes and describes refund fulfillment through a new payment instruction back to the payer. Its reverse-payment proposition similarly describes a refund as a new payment order related to the earlier payment rather than simply reversing the original transfer.

That has real operational consequences.

A merchant needs to know:

•whether the provider offers a refund API;

•whether payer account details required for refunds are available;

•whether customer consent is required to obtain those details;

•whether full and partial refunds are supported;

•how refunds are linked to the original order;

•what status indicates successful refund;

•whether the provider or merchant initiates the return payment;

•and how refund reconciliation appears in reporting.

Do not assume:

“Open banking payment supported” = “card-like refund lifecycle supported.”

Test the refund before production.

A single open-banking payment does not create a recurring mandate

A successful one-time payment proves that the customer authorized that payment.

It does not automatically authorize the merchant to debit the customer's account again next month.

Recurring bank payments require a separate mechanism.

In the UK, Variable Recurring Payments provide an open-banking mechanism under which customers can authorize payment providers to make payments within agreed parameters. The existing UK framework includes sweeping VRPs, while commercial VRP capability has been undergoing active expansion. In June 2026 the FCA described the launch of the UK Payments Initiative as a step toward broader commercial VRP competition and recurring-payment use cases.

That is important progress.

It does not justify a global statement that:

“Open banking supports subscriptions.”

Recurring capability remains dependent on:

•jurisdiction;

•bank participation;

•API capability;

•provider;

•commercial scheme;

•merchant use case;

•consent model;

•payment limits;

•and current production availability.

For SaaS or subscription merchants, recurring support should be a provider-selection requirement, not something inferred from successful one-time Pay by Bank checkout.

Open banking does not eliminate fraud or disputes

Bank authentication changes the fraud and authorization model.

It does not make fraud disappear.

Merchants and providers still need to consider risks such as:

•compromised customer accounts;

•social engineering;

•authorized push-payment fraud;

•merchant impersonation;

•manipulated payment instructions;

•false customer claims of payment;

•refund abuse;

•and account/payment mismatches.

The fact that the payment is not processed through conventional card rails does not mean there is no consumer-protection, recall, reimbursement, fraud-claim or dispute process.

Open Banking Limited continues to publish dedicated fraud analysis for open-banking payment journeys, including a June 2026 fraud monitor, which itself is evidence that authenticated open-banking payments still require fraud operations and monitoring.

The correct merchant question is not:

“Does this method have chargebacks?”

It is:

“Which fraud, liability, reimbursement, recall and dispute mechanisms apply to this payment in this jurisdiction?”

Geography matters more than the phrase “open banking”

There is no single universal open-banking merchant API.

The UK provides a particularly developed example involving FCA-regulated payment-initiation firms and the UK Open Banking Standard. The FCA states that firms providing payment-initiation services require authorization, and the Open Banking Standard defines the API and customer-experience framework used by participating providers.

The European Union's PSD2 framework also introduced payment-initiation services and access-to-account rules. The EU is now revising that regime through the proposed PSD3 and Payment Services Regulation package. As of August 2026, EUR-Lex still records the PSD3 legislative procedure as ongoing; Council and Parliament reached political agreement and final compromise texts have progressed, but merchants should not present the proposed framework as if it had already replaced all current PSD2 rules.

That creates an important editorial safeguard:

“PISP,” “open banking,” and “Pay by Bank” should not be projected unchanged onto every country.

For every target market verify:

•applicable regulation;

•provider authorization;

•participating banks;

•eligible account types;

•API or connectivity model;

•payment rail;

•currency;

•payment status;

•recurring capability;

•refunds;

•and merchant eligibility.

Merchant integration: you usually integrate the provider, not every bank

The practical value of an open-banking provider is aggregation of bank connectivity.

Instead of an international merchant independently implementing:

**Bank A API

•Bank B API

•Bank C API

•Bank D API**

the merchant integrates an initiation provider that maintains the relevant bank connections and exposes a merchant-facing API, SDK or hosted experience.

The provider may supply:

•bank lists;

•payment creation;

•consent handling;

•redirect/deep-link information;

•status APIs;

•callbacks/webhooks;

•error normalization;

•refund functionality;

•recurring capabilities;

•reconciliation data;

•and reporting.

That abstraction can be valuable.

It also makes provider quality strategically important.

Evaluate open-banking providers on bank coverage, not the word “open”

A provider should be evaluated on whether the banks your customers actually use are available and reliable.

Useful measures include:

Bank availability rate

Eligible checkout sessions in which the customer's relevant bank is operationally available

÷ eligible bank-payment checkout sessions

× 100

A provider claiming “national coverage” may still produce poor customer access if strategically important banks have weak availability or limited payment capabilities.

Evaluate the authentication journey

Measure:

Bank-selection completion

Customers progressing from bank-selection screen into the selected bank flow

÷ customers reaching bank selection

× 100

Bank authentication completion

Customers successfully completing the bank-controlled authentication stage

÷ customers reaching that stage

× 100

Segment this by:

•bank;

•device;

•operating system;

•browser;

•native app versus mobile web;

•and returning versus new customer.

A blended 90% result can hide one major bank performing at 65%.

Evaluate payment confirmation

Measure:

Payment confirmation rate

Payments reaching the merchant's defined authoritative successful state

÷ payments successfully submitted for bank execution

× 100

And:

Confirmation latency

Time from a precisely defined customer/payment event

to the authoritative merchant confirmation event.

Do not label the metric “instant” unless both endpoints are explicitly defined.

Evaluate the merchant return

Return-to-merchant success

Sessions returning successfully to the intended merchant order state

÷ customers completing the relevant bank journey

× 100

But always resolve final order state server side as well.

Evaluate completed orders

Ultimately:

Open-banking completed-order rate

Completed merchant orders paid through the method

÷ relevant eligible open-banking checkout sessions

× 100

That is commercially more important than:

•Pay by Bank impressions;

•clicks;

•consent starts;

•bank selections;

•or successful authentication.

The Open Banking Payment Stack

A merchant evaluating an implementation should be able to fill in every row.

Layer

Owner/question

Merchant failure if unclear

•Merchant checkout

Who creates amount, currency, beneficiary and order reference?

Wrong or untraceable payment request

•Initiation provider

Who maintains bank connectivity and payment-initiation permissions?

Bank unavailable or merchant cannot initiate

•Customer consent

What precisely is the customer agreeing to?

Invalid or confusing authorization journey

•Bank authentication

Which bank authenticates the customer, on which device/channel?

Authentication abandonment or failed handoff

•Underlying rail

What actually moves the money?

Wrong assumptions about speed, reach or finality

•Payment status

Which state is authoritative for fulfillment?

Goods delivered against pending/failed payment

•Merchant reconciliation

Which IDs connect order, provider, bank transfer and refund?

Unmatched funds and manual operations

The model exposes where provider marketing tends to compress several systems into one phrase.

A button labeled Pay by Bank may hide:

Merchant UX

→ PISP

→ customer bank

→ authentication

→ Faster Payments/SCT/SCT Inst/other rail

→ beneficiary bank

→ provider status

→ merchant ledger

Architecture teams should understand every layer they are relying on.

When open-banking payments fit well

Open-banking payment initiation deserves investigation when the merchant serves customers who have eligible bank accounts and for whom bank payment provides meaningful access or convenience.

Potentially strong situations include:

Customers without an appropriate card path

If an otherwise valuable customer can pay from an eligible bank account but cannot adequately use the merchant's current card checkout, open banking can create an access effect.

Customers who already use bank-based payments

Where bank-account payment is normal for the target customer and transaction type, a well-designed Pay by Bank journey can connect that existing behavior directly to ecommerce checkout.

Higher-value transactions

Bank-account payment can be worth evaluating where transaction size, card limits, customer behavior or merchant economics make bank payment attractive.

That is a hypothesis to test, not a universal rule.

Merchants with strong reconciliation requirements

Provider-generated payment references, explicit order associations and machine-readable payment statuses can make initiated bank payments substantially more operationally usable than customers manually transferring money to a displayed IBAN or account number.

When open banking may fit poorly

Open-banking payments deserve lower priority where:

•relevant customer banks are poorly covered;

•customers rarely use online/mobile banking;

•the authentication journey is weak on the merchant's dominant devices;

•provider status is too ambiguous for safe fulfillment;

•refunds are operationally cumbersome;

•subscription economics depend on recurring capability the provider cannot offer;

•bank-payment demand overlaps almost entirely with already-successful payment methods;

•or the ongoing integration/support burden exceeds incremental customer value.

The method should not receive strategic priority simply because “open banking” appears modern or because an underlying rail is fast.

Test incrementality, not just Pay by Bank volume

A merchant that processes $10 million through open banking has not necessarily created $10 million in additional sales.

Customers may have:

•been previously unable to pay;

•abandoned a failing card and recovered through bank payment;

•preferred Pay by Bank but could have paid by card;

•or simply substituted one successful method for another.

Those effects have different commercial value.

Where possible, compare eligible customer cohorts using controlled rollout or carefully designed pre/post analysis.

Measure:

•total completed-order rate;

•bank-payment completion;

•card-payment displacement;

•average order value;

•transaction economics;

•fraud losses;

•refund/support cost;

•reconciliation exceptions;

•and incremental completed orders.

The hypothesis should be falsifiable:

If adding open-banking payment initiation produces substantial Pay by Bank selection but does not increase completed orders, meaningful customer access, payment economics or operational performance—and creates significant authentication or refund burden—the merchant should reconsider its priority.

That provides a useful example of the article's broader argument.

A global payment provider can abstract:

•bank connectivity;

•checkout integration;

•customer handoff;

•payment-status handling;

•and method access

without becoming the underlying bank-payment rail.

•Which banks and countries are currently supported?

•Which merchant entities are eligible?

•What provider relationship sits behind the payment?

•What rail carries each payment?

•Which status is authoritative for fulfillment?

•How are refunds initiated?

•Does this implementation support recurring payments?

•How are bank transactions reconciled?

•When and how does the merchant receive settlement?

FAQ: Open banking payment terminology

Is open banking the same as account-to-account payment?

No.

A2A describes the movement of money between accounts without a conventional card rail in the transaction path.

Open banking describes an access/connectivity and initiation model.

An open-banking payment can produce an A2A transfer, but not every A2A payment uses open banking.

Is open banking a real-time payment system?

No.

An open-banking provider may initiate a payment that runs across a real-time payment system such as Faster Payments or SCT Inst, but the initiation layer and the rail are separate systems.

What does a PISP do?

Under PSD2-style terminology, a Payment Initiation Service Provider provides an online service that initiates a payment order at the request of the payment service user for an account held with another payment service provider.

Is a PISP the same as an AISP?

No.

Payment initiation and account information are distinct services. A provider can have permissions for both, but one capability does not imply the other.

Does the merchant receive the customer's bank password?

A properly structured open-banking flow does not require the merchant to collect the customer's bank password. In the UK Open Banking Standard, authentication is performed by the customer's account provider using supported bank authentication journeys.

Does successful bank authentication mean the merchant has been paid?

Not necessarily.

Authentication, payment submission, bank processing and final payment status are separate states. The merchant should use the provider/rail status defined as authoritative for fulfillment.

Can open-banking payments be refunded?

They can be in implementations that support refund functionality, but the mechanics may differ from card refunds. UK Open Banking guidance, for example, describes refunds that involve payment-account information and a separate payment instruction back to the customer.

Can merchants use open banking for subscriptions?

Do not assume so from a successful single payment.

Recurring bank-payment functionality requires an appropriate recurring mechanism. UK Variable Recurring Payments are one open-banking model, but capability and availability remain market-, provider- and use-case-specific.

Is Pay by Bank always an open-banking payment?

Not necessarily.

“Pay by Bank” is customer-facing commercial terminology and can refer to different bank-payment architectures depending on the provider and market. Merchants should inspect the actual connectivity, authorization and rail model behind the product.

Final recommendation

Open banking matters because it can turn an eligible customer's bank account into a usable ecommerce payment experience without requiring the merchant to build individual bank integrations.

But the words open banking tell the merchant surprisingly little about how the payment ultimately behaves.

They do not, by themselves, tell you:

•which banks are reachable;

•which accounts are eligible;

•how the customer authenticates;

•which rail moves the money;

•how fast the rail operates;

•when the payment becomes authoritative;

•how refunds work;

•whether later payments can be initiated;

•how disputes are handled;

•or when the merchant receives settlement.

Those questions belong to different layers.

So the merchant decision is not:

“Should we support open banking?”

It is:

“For these customers, in this market, can this initiation provider reliably connect the customer's bank account to an underlying payment rail, give us an authoritative and reconcilable payment state, support the refund and recurring model our business requires, and produce enough completed-order, customer-access, economic or operational value to justify the integration?”

That is how open banking should be evaluated:

not as a new global rail, but as a connectivity and initiation layer whose value depends on everything above and below it.

This article provides general information and does not constitute legal, regulatory, banking, tax, security, or compliance advice. Merchants should verify applicable requirements with qualified advisers, relevant payment providers, banks, scheme operators and authorities.

I treated the uploaded brief as the controlling document and kept this article narrowly focused on open banking as an initiation/connectivity layer, rather than letting it become another A2A, Faster Payments, or real-time-payments explainer.

Editorial interpretation

Field

Decision

Bank-payment decision owned

Whether open-banking payment initiation provides a useful, operable way to connect the merchant's customers to bank-account payments—and whether the provider, bank coverage, confirmation model, recurring support and underlying rail fit the merchant's use case.

Customer being enabled

A customer with an eligible online-accessible payment account who wants or needs to pay from that account rather than through conventional card checkout.

Initiation layer

Regulated or otherwise locally authorized payment-initiation connectivity between the customer, their account-servicing bank, and the merchant/provider.

Merchant-facing product

Usually presented commercially as Pay by Bank, bank payment, bank transfer, or similar, but the exact implementation and regulatory model varies by market.

Unique evidence anchor

The UK Open Banking Standard explicitly lets a PISP initiate a payment order with customer consent and retrieve its status, while Pay.UK separately operates Faster Payments. The EPC's SCT Inst rulebook likewise states that an instant credit transfer may be initiated indirectly by a PISP. Open banking can therefore initiate a payment that travels across a pre-existing rail.

Editorial position

Evaluate the complete bank-payment stack—not the “open banking” label.

Common assumption challenged

“Open banking is a new global payment rail.”

Most important technical distinction

Consent / connectivity / authentication / payment initiation / payment execution / merchant confirmation are separate states and responsibilities.

Selected format

Initiation-layer systems walkthrough.

Merchant decision

Prioritize open-banking payments when bank coverage, customer flow, authoritative payment status, refunds, recurring requirements and operating economics create a credible customer-access or checkout case.

Structural rationale

The article follows the payment instead of defining terms in isolation:

Merchant → initiation provider → customer consent → customer bank → bank authentication → existing payment rail → payment status → merchant reconciliation

That allows the reader to see exactly where “open banking” stops and the underlying bank-payment infrastructure begins.

Supporting visual: Open Banking Payment Stack

I would make this a layer diagram rather than a conventional flowchart:

MERCHANT CHECKOUT

Payment request + order reference

↓

OPEN-BANKING / INITIATION PROVIDER

Bank connectivity + payment request + status

↓

CUSTOMER CONSENT

↓

CUSTOMER BANK / ASPSP

Authentication + authorization

↓

UNDERLYING PAYMENT RAIL

Examples: Faster Payments | SCT | SCT Inst | market-specific rail

↓

PAYEE BANK / BENEFICIARY

↓

PAYMENT STATUS TO PROVIDER

↓

MERCHANT ORDER + RECONCILIATION

Across the diagram, place three callouts:

Open banking initiates

The rail moves

The merchant must confirm

That visual captures the article's intellectual territory immediately.

Suggested alt text: “Open banking payment stack showing merchant checkout, payment-initiation provider, customer consent, bank authentication, underlying payment rail, payment status and merchant reconciliation.”

SEO package

Element

Recommendation

Open Banking Payments: How Payment Initiation Works

H1

Open Banking Payments: How Bank-API Payment Initiation Works for Merchants

Meta description

Learn how open banking payments work for merchants, including PISPs, customer consent, bank authentication, A2A rails, payment confirmation, refunds and recurring payments.

URL slug

/bank-based-payments/open-banking-payments

open banking payments

Secondary keywords

open banking payment initiation; pay by bank open banking; PISP payments; open banking ecommerce; bank API payments; open banking checkout; account to account open banking; open banking merchant payments

Related entities

PISP, AISP, ASPSP, PSD2, PSD3, payment initiation, Pay by Bank, Faster Payments, SEPA Credit Transfer, SCT Inst, Variable Recurring Payments

Excerpt

Open banking can let a customer initiate payment from their bank account through regulated/API connectivity, but it is not itself the underlying payment rail. Merchants need to understand consent, bank authentication, execution, confirmation, refunds and recurring capability as separate layers.

Structured data

Article, BreadcrumbList; FAQPage only if the visible FAQ remains published and current search-engine eligibility requirements justify it

Primary merchant metric

Completed-order rate among customers eligible for the open-banking payment flow

Primary technical metric

Authoritative payment-confirmation rate

Original asset

Open Banking Payment Stack

Internal-link plan

Use A2A Payments immediately after clarifying that open banking can initiate an account-to-account transfer but does not define every A2A architecture.

Use Faster Payments in the UK from the underlying-rail discussion rather than explaining the complete FPS model here.

Use SEPA Instant Payments where SCT Inst is used as the example of a rail that can receive a PISP-initiated credit transfer.

Use Trustly for Merchants later as an example of a provider/service-layer article. That keeps this article from becoming a provider profile.

I would also link to Real-Time Payments Explained once, specifically from the section separating initiation speed, rail execution, merchant confirmation and settlement.

Authoritative source recommendations

The permanent evidence stack should be led by Open Banking Limited's current Payment Initiation Service and authentication standards, because those documents establish the separate roles of consent, PISP connectivity, ASPSP authentication and payment status.

Use the FCA for UK authorization and regulatory-role claims. It explicitly addresses PISPs, AISPs, ASPSPs and payment-initiation authorization.

Use Pay.UK when describing Faster Payments as underlying UK payment infrastructure rather than as an open-banking product.

Use the European Payments Council when demonstrating that SCT Inst is a payment scheme whose credit transfers may be initiated directly or through a PISP.

Use European Commission / EBA / EUR-Lex for PSD2 and the evolving PSD3/PSR framework. As of August 8, 2026, the PSD3 procedure is still recorded as ongoing, so editors should not prematurely describe PSD3/PSR as having fully replaced PSD2.

Proposed author and reviewers

Primary reviewers:

•Open-banking specialist

•Senior payment engineer

•Regulatory/compliance reviewer

•Treasury or reconciliation specialist

Publication fact-check matrix

Rail and scheme

Verify the exact underlying rail behind every branded open-banking product used as an example.

Do not assume that:

open banking → Faster Payments

outside the relevant UK product, or:

European open banking → SCT Inst

for every transaction.

Country and regulation

For every market, verify:

•current open-banking/payment-service regime;

•PISP-equivalent role;

•authorization requirements;

•eligible accounts;

•mandatory versus voluntary bank participation;

•payment-API standards.

For the EU specifically, recheck the PSD3/PSR legislative state at publication. It remained an ongoing legislative procedure in the latest official material reviewed here.

Merchant eligibility

Verify whether the merchant:

•contracts with a regulated initiation provider;

•can be boarded in the relevant country;

•requires a local entity;

•requires a local receiving account;

•is eligible for the transaction category;

•can use the provider's merchant model cross-border.

Confirmation and reconciliation

Confirm:

•provider status vocabulary;

•whether status is synchronous or asynchronous;

•webhook/callback behavior;

•polling/status API;

•authoritative successful state;

•beneficiary-bank confirmation;

•reference structure;

•order ID support;

•provider transaction ID;

•settlement reconciliation ID.

Do not map “customer authenticated” directly to “paid.”

Refunds

Confirm:

•whether an API refund exists;

•whether a refund is implemented as a new transfer;

•payer account-detail requirements;

•customer consent/data requirements;

•partial refunds;

•refund limits;

•settlement funding;

•return-payment status;

•reconciliation.

Recurring

Verify independently:

•VRP or equivalent;

•standing orders;

•mandate model;

•payer consent;

•variable/fixed amounts;

•payment limits;

•bank coverage;

•merchant use-case restrictions;

•provider production availability.

Never infer recurring capability from single-payment initiation.

Fraud and disputes

Confirm:

•unauthorized-payment process;

•APP-fraud exposure;

•customer reimbursement regime;

•provider liability;

•rail recalls/returns;

•mistaken-payment handling;

•merchant refund process.

Avoid the phrase “chargeback-free” unless a very narrow, explicitly defined comparison is intended.

Amber-flag claims

Do not publish the following without narrower evidence:

•“Open banking is instant.”

•“Open banking is cheaper than cards.”

•“Open banking payments cannot be reversed.”

•“Open banking eliminates chargebacks.”

•“Bank authentication guarantees payment.”

•“Every bank supports open banking.”

•“Open banking works throughout Europe.”

•“PSD3 is now the governing EU open-banking law.”

•“Open banking inherently improves conversion.”

•“Pay by Bank always means open banking.”

•“Open banking supports subscriptions.”

•“A real-time rail means instant merchant settlement.”

•“A payment initiated through open banking is final as soon as the customer approves it.”

Each collapses at least two separate layers of the payment stack.

•The current provider/partner model behind Bank Transfer Europe.

•Current supported countries.

•Current bank coverage by country.

•Whether GBP and other currencies are supported beyond the page's documented processing setup.

•Which underlying rails carry payments in each country.

•Exact authoritative confirmation state.

•Current average/status latency definitions.

•Full and partial refund mechanics.

•Whether a refund is provider-managed or merchant-funded as a new transfer.

•Current recurring/VRP capability.

•Merchant entity eligibility.

•Settlement and payout model.

•Reporting and reconciliation fields.

•App-to-app/mobile-bank behavior.

•Provider outage/fallback handling.

Provider-specific verification checklist

For any open-banking provider a merchant is evaluating, record:

Market → provider → regulatory permission → bank coverage → account coverage → authentication model → initiation API → underlying rail → status states → authoritative confirmation → webhooks → refund model → recurring model → settlement architecture → reconciliation IDs → SLA → outage handling → last verified date

That record prevents “open banking supported” from becoming a meaningless checkbox.

Cluster sameness-audit fields

Field

This article

Title

Open Banking Payments: How Bank-API Payment Initiation Works for Merchants

First-two-sentence device

Customer clicks Pay by Bank; the payment still needs an underlying rail

Opening device

Interface versus infrastructure

Primary geography

UK/EU examples, globally qualified

Payment rail

Deliberately variable; Faster Payments and SCT Inst are examples

Merchant-facing method

Open-banking payment initiation / Pay by Bank

Primary format

Initiation-layer systems walkthrough

Unique evidence anchor

PISP can initiate a transfer carried by a separately governed bank-payment rail

Editorial position

Evaluate the full stack, not the open-banking label

Merchant decision

Bank coverage + UX + status + refunds + recurring + economics

Original framework

Open Banking Payment Stack

Primary technical distinction

Consent/authentication/initiation/execution/confirmation are separate

Primary metric

Authoritative payment confirmation → completed order

Conclusion

Open banking changes access and initiation, not necessarily the rail underneath

CTA direction

Map provider → bank → rail → status before integrating

FAQ

Technical terminology and state distinctions

Distinctive visual

Seven-layer initiation-to-reconciliation stack

This keeps the article clearly separated from Account-to-Account Payments, which owns the funding/transaction model; Real-Time Payments Explained, which owns instant-payment infrastructure; and Faster Payments, which owns the UK rail itself.