Account-to-Account Payments

Account-to-Account Payments: How A2A Works for Online Merchants

Three customers pay merchants directly from bank accounts.

The first customer receives bank details at checkout, opens a banking app and manually sends a transfer.

The second chooses Pay by Bank, is handed to a bank-authentication experience, approves a payment initiated through an open-banking provider, and returns to the merchant.

The third previously gave a merchant a valid direct-debit mandate. On the next billing date, the merchant initiates collection from the customer's account.

All three involve money moving from one account to another.

They are not the same payment product.

That is the most useful way for merchants to understand account-to-account payments, or A2A.

A2A primarily describes the movement of money between accounts without a card payment rail carrying the transaction. It does not, by itself, tell the merchant:

•who initiates payment;

•whether payment is push or pull;

•whether the customer uses an API, QR code, bank app or manual transfer;

•whether the underlying rail is instant;

•when the merchant receives authoritative confirmation;

•whether subsequent merchant-initiated payments are possible;

•how refunds work; or

•how the transaction should be reconciled.

The UK's Payment Systems Regulator uses essentially this movement-based definition, describing A2A payments as money moving directly from a payer's bank account to a payee's bank account rather than through credit- or debit-card systems. The same regulator explicitly distinguishes A2A from open banking by describing open banking as one way of delivering A2A payments.

For merchants, that distinction is not academic.

It determines what must actually be integrated and operated.

What does account-to-account payment mean?

At the simplest level:

Payer account → payment infrastructure → payee account

No card credential needs to be the instrument carrying the transaction.

That distinguishes A2A from a conventional card payment:

Cardholder account or credit line → issuer → card network → acquirer → merchant

But the simplicity of the first diagram hides several layers.

An A2A transaction still requires financial institutions, rules, messaging and payment infrastructure. “Direct” should therefore not be interpreted as “no banks, PSPs or intermediaries exist.”

The strategically useful distinction is:

A2A avoids the card rail; it does not avoid the payment system.

A merchant-facing A2A experience can consequently be built in many different ways.

A2A is not one payment method

This is the source of most terminology problems.

“A2A” is comparable to saying that a vehicle is electric.

That tells you something fundamental about how it is powered.

It does not tell you whether the product is:

•a delivery van;

•a sports car;

•a bus;

•a motorcycle.

Similarly, A2A tells the merchant something fundamental about how funds move.

It does not completely define the merchant product.

An A2A payment might be:

•a manually initiated bank transfer;

•an open-banking payment;

•an instant domestic transfer;

•an ecommerce bank redirect;

•a QR-initiated bank payment;

•a direct debit;

•a standing order;

•a payment initiated through a bank-payment provider.

The PSR itself points out that account-to-account payments are not new, citing direct debit as a longstanding form of A2A while discussing open banking as a mechanism for developing newer retail A2A experiences.

The merchant therefore needs to identify the layers underneath the label.

A2A versus bank transfer

The two terms overlap heavily, but they answer slightly different questions.

Account-to-account describes the funding and movement model.

Bank transfer generally describes a transfer of funds between bank accounts, often using a credit-transfer mechanism.

Many bank transfers are therefore A2A payments.

But A2A is potentially broader because account-based merchant payments can also include pull mechanisms such as direct debit.

The ECB's SEPA terminology makes the distinction concrete:

•a credit transfer moves money from payer to payee and is initiated by the payer;

•a direct debit moves money from payer to payee but is initiated by the payee based on the payer's prior consent through a mandate.

Both are account-based.

Operationally, they are very different.

A2A versus open banking

A2A and open banking should not be used as synonyms.

Open banking can provide the initiation and account-access layer for an A2A payment.

The FCA defines a payment-initiation service as an online service that initiates a payment order, with the user's consent and authentication, from an account held at another payment service provider.

The current UK Open Banking Standard similarly says a Payment Initiation Service Provider can initiate a payment order, with explicit customer consent, from the customer's online payment account and retrieve the status of that payment order.

That describes how the customer and payment provider interact.

The money still needs an underlying payment mechanism to move.

This is particularly easy to see in the UK, where Open Banking documentation describes payment-initiation journeys that can ultimately result in payments processed through Faster Payments.

The layers are therefore:

Open-banking interface and consent

→ payment instruction

→ underlying payment scheme/rail

→ destination account

Open banking can enable A2A.

It is not the definition of A2A.

A2A versus real-time payment

“Real-time” describes another dimension entirely:

speed.

A payment can be:

•account-to-account and instant;

•account-to-account and non-instant;

•initiated through open banking and instant;

•initiated through open banking but processed through another timing model.

In Europe, for example, the ECB defines instant payments as credit transfers that make funds available in the payee's account within ten seconds of the payment order, with the SEPA Instant Credit Transfer scheme supporting the relevant euro transfers.

The fact that an A2A payment uses an instant rail therefore tells the merchant something important about execution.

It still does not define the entire checkout product.

A merchant should separate at least four clocks

•Customer authorization time

•Bank/payment-rail execution time

•Merchant confirmation time

•Merchant settlement or PSP payout time

Those events may occur close together.

They are not conceptually identical.

A transaction reaching a beneficiary account quickly does not automatically mean an international merchant's PSP payout also happens at that instant.

Push versus pull: the most important A2A operating distinction

A useful first classification is whether money is pushed by the payer or pulled under merchant authority.

Push A2A payment

The customer authorizes funds to be sent.

Examples can include:

•manual credit transfer;

•Pay by Bank payment;

•open-banking-initiated credit transfer;

•QR-initiated account payment;

•instant bank payment.

The customer generally participates in each payment authorization unless a separate recurring mechanism has been established.

Pull A2A payment

The payee or merchant initiates collection under previously granted authority.

Direct debit is the clearest conventional example.

Under SEPA terminology, the payee initiates the direct debit based on the customer's consent through a mandate.

This distinction matters enormously for subscriptions.

A one-time push payment proves that the customer successfully paid once.

It does not prove that the merchant can charge the account again next month.

Payment initiation is its own layer

Once the merchant knows whether the product uses push or pull, ask:

How does the payment instruction get created?

Possible initiation methods include:

•customer manually entering bank details;

•bank selection and redirect;

•bank app handoff;

•open-banking API;

•QR code;

•payment alias;

•account identifier;

•provider-hosted checkout;

•standing order;

•direct-debit mandate;

•recurring API consent.

Consider two push payments.

Manual transfer

The merchant displays:

•bank account;

•amount;

•reference.

The customer leaves checkout, opens online banking and manually creates the payment.

Provider-initiated A2A checkout

The merchant creates a payment request.

The provider supplies payee and payment information.

The customer selects a bank, authenticates and approves a prepared payment.

Both can ultimately create an account-to-account credit transfer.

The ecommerce experiences are radically different.

The second model can eliminate manual entry, improve payment references and create much stronger transaction-state visibility.

That value comes from the initiation and acceptance layer, not from the phrase “A2A” alone.

Authentication is another independent layer

How the customer proves authority over the account depends on the bank, jurisdiction and product.

Authentication may include:

•banking-app login;

•device authentication;

•biometrics;

•OTP;

•bank credentials;

•strong customer authentication;

•PIN;

•QR approval;

•another bank-defined procedure.

In an open-banking payment-initiation model, authentication ultimately occurs with the customer's account provider rather than being invented by the merchant. FCA guidance specifically describes payment-initiation services as operating with the user's consent and authentication.

The merchant controls whether and where it offers the method.

The bank controls significant portions of bank-side customer authentication.

Do not attribute bank-authentication failure automatically to the merchant or PSP.

The rail determines how the instruction travels

After initiation and authorization, the payment needs infrastructure that can execute the transfer.

That rail may be:

•a standard credit-transfer scheme;

•an instant-payment scheme;

•a domestic fast-payment system;

•another bank-payment infrastructure.

Payment systems themselves are sets of rules and procedures supporting transfers between people, businesses and financial institutions, typically operated through dedicated infrastructure and participating financial institutions.

This is why the merchant-facing brand should not be confused with the underlying rail.

A provider may create the checkout interface while a national payment system actually moves the funds.

An open-banking API can create the instruction while an existing bank-payment rail executes it.

The rail, initiation layer and merchant product may have different owners.

The A2A Payment Model

Before integrating any account-based product, map five layers.

Layer

Merchant question

Examples of what belongs here

•Funding accounts

Which account supplies and receives the funds?

Customer current/payment account → merchant/PSP account

•Initiation

Who creates the payment instruction, and how?

Manual transfer, open-banking PISP, QR, bank redirect, merchant under mandate

•Payment rail

What actually transports and processes the instruction?

Standard credit-transfer scheme, instant-payment system, domestic bank rail

•Merchant acceptance & confirmation

How does checkout create, identify and authoritatively confirm the payment?

PSP API, payment ID, webhook, status API, reference matching

•Post-payment operations

What happens after success?

Refund, return, dispute, recurring payment, reconciliation, reporting, settlement

Do not approve an A2A implementation based on Layer 3 alone.

A fast rail paired with poor Layer 4 confirmation can still produce a poor ecommerce product.

A polished initiation experience paired with inadequate refund operations can still be unsuitable for the business.

A strong one-time payment method with no suitable Layer 5 recurring model can still be wrong for subscriptions.

Merchant confirmation matters as much as payment speed

One of the most important merchant questions is:

When do we know the order is actually paid?

A bank-payment journey can expose multiple states:

payment request created

→ customer sent to bank

→ customer authenticated

→ payment authorized

→ payment submitted

→ payment accepted by infrastructure

→ provider reports completed state

→ merchant records paid order.

Do not collapse those events.

A customer-facing “success” page is especially dangerous as the only fulfillment signal.

The customer can close a browser.

A redirect can fail.

The return URL can be interrupted.

An asynchronous update can arrive later.

A merchant should establish which server-side or otherwise authoritative provider state is appropriate for fulfillment under the specific product.

The Open Banking Standard itself distinguishes payment initiation from the later retrieval of payment-order status, reinforcing that initiation and status are separate parts of the flow.

For valuable or irreversible goods, this should be an explicit integration requirement.

Confirmation is not settlement

Another terminology trap:

payment confirmed

does not necessarily mean:

merchant has received its PSP payout.

There can be several economic layers:

•customer account debited;

•beneficiary/payment account credited;

•interbank settlement completed;

•PSP merchant balance updated;

•merchant payout created;

•funds arrive in merchant treasury account.

The exact model varies.

Even where an underlying payment scheme operates in seconds, merchant payout can follow the merchant's separate provider settlement schedule.

Therefore do not sell an A2A implementation internally as “instant settlement” unless the statement defines exactly which settlement event is instant.

Real-time rails do not automatically create real-time ecommerce

Imagine a market has a highly capable instant payment system.

That solves infrastructure latency.

It does not automatically solve:

•customer bank selection;

•merchant identification;

•transaction references;

•payment-request generation;

•QR or app experience;

•authentication;

•payment status;

•order matching;

•refunds.

The ECB itself has historically described instant payments through a layered model separating end-user solutions from underlying payment and clearing/settlement infrastructure.

This is one of the strongest reasons merchants should think in layers.

Infrastructure capability is necessary for some experiences. It is not the customer experience itself.

Recurring A2A is not one capability

The phrase “supports A2A” says almost nothing about recurring billing.

There are several possible models.

Customer repeats a push payment

The customer actively authorizes each payment.

This is repeat purchasing.

It is not merchant-initiated recurring billing.

Standing order

The customer can establish a recurring schedule from their account.

UK Open Banking standards, for example, contain payment-initiation journeys for standing orders with frequency and schedule information.

The customer or payment setup determines the schedule rather than allowing arbitrary merchant charging.

Direct debit mandate

The merchant/payee initiates collections based on prior customer consent and the scheme's mandate rules.

That is a pull model.

Variable Recurring Payment

Open-banking systems can also develop API-based recurring models.

In the UK, Variable Recurring Payments allow customers to give a PISP longer-lived consent to initiate a series of payments within defined parameters. Commercial VRP development remains an evolving area, so merchants should verify the current scope rather than assuming every open-banking payment can automatically become recurring.

These mechanisms are fundamentally different.

For SaaS and subscription merchants, “Does it support A2A?” should immediately be followed by:

“Which recurring model, under which rail and provider implementation?”

Refunds also live above the A2A definition

A2A tells the merchant how the original payment moved.

It does not specify a universal refund process.

Depending on the method and provider, a refund could involve:

•an API-linked refund;

•a provider-created outbound transfer;

•another payment instruction;

•manual collection of customer account details;

•partial-refund support;

•no standardized same-path refund at all.

The merchant must verify:

•full refunds;

•partial refunds;

•API availability;

•original-transaction linkage;

•supported currencies;

•refund timing;

•reconciliation;

•failed-refund handling.

This is why a bank-payment product can be excellent for one-time digital goods and operationally weak for a business with frequent partial returns.

A2A does not mean “no disputes”

The absence of a card rail does not mean the absence of fraud, claims or payment recovery mechanisms.

Bank-based systems can face:

•account takeover;

•authorized push-payment fraud;

•social engineering;

•impersonation;

•mistaken transfers;

•unauthorized-payment claims;

•scheme returns or recalls;

•merchant refund disputes.

The precise customer rights and recovery process depend on the rail, jurisdiction and transaction type.

Merchants should avoid the expression “chargeback-free” unless they are making a narrow statement about the absence of the card-network chargeback process and simultaneously explaining what dispute or recovery mechanisms can still exist.

A2A changes the dispute model.

It does not make disputes disappear.

Reconciliation is where a basic bank transfer becomes an ecommerce payment product

If a merchant tells a customer:

Send €157.42 to this IBAN and place order 928431 in the reference.

the payment may be completely valid.

But several operational failures can follow:

•reference omitted;

•reference mistyped;

•amount incorrect;

•duplicate transfer;

•payment sent days later;

•payment sent after order expiry;

•several orders combined;

•settlement contains insufficient metadata.

The transfer worked.

The commerce system did not.

A mature A2A implementation should link:

Order

→ payment request

→ customer instruction

→ bank transaction

→ provider confirmation

→ merchant payment record

→ settlement record

→ refund/return where applicable.

Useful identifiers can include:

•merchant order ID;

•PSP payment ID;

•payment reference;

•end-to-end identifier;

•bank transaction reference;

•virtual-account identifier;

•QR-associated identifier.

The exact fields depend on the method.

The objective does not:

the merchant should be able to identify which bank transaction paid which commercial obligation automatically.

Unmatched payment rate is an A2A metric worth owning

One operational metric deserves more attention:

Unmatched payment rate

Received account-based payments not automatically linked to a valid payment/order record

÷ received account-based payments

× 100

A method can have excellent customer payment completion and still create expensive merchant operations if substantial payment volume enters manual reconciliation.

For B2B, education, travel and high-ticket commerce, this metric can be as important as checkout conversion.

A2A versus cards: compare products, not slogans

A2A discussions often begin with claims such as:

•fewer intermediaries;

•lower fees;

•faster funds;

•lower fraud;

•no chargebacks.

None should be treated as universal.

A merchant comparison should instead examine:

Question

Card

Specific A2A product

Customer eligible?

Verify

Verify

Customer has required instrument/account?

Card

Eligible bank account

Customer initiation

Card form/wallet/etc.

Product-specific

Authentication

Issuer/network dependent

Bank/provider dependent

Confirmation

Authorization/capture model

Product-specific

Payment timing

Network/process dependent

Rail dependent

Refunds

Established card process

Method-specific

Recurring

Stored-credential frameworks

Mandate/VRP/standing order/etc.

Disputes

Card-network processes

Scheme/legal/product-specific

Reconciliation

Processor/acquirer data

Provider/reference model

Cost

Merchant-specific

Merchant-specific

The right question is therefore not:

“Is A2A better than cards?”

It is:

“Does this specific A2A product improve customer access, payment completion, economics or operations for this merchant cohort?”

When A2A can create meaningful customer access

A2A is especially worth evaluating when the customer:

•has funds in a bank account but lacks an appropriate card;

•cannot successfully use an international card;

•expects to pay through familiar domestic banking infrastructure;

•prefers account-funded payment;

•is making a transaction where direct bank payment fits the market;

•already uses a relevant local bank-payment mechanism.

The Payment Systems Regulator's work on retail A2A is built partly around the idea that A2A can provide an additional retail payment option alongside card systems.

But customer access must be measured market by market.

Bank-account ownership alone does not prove customers expect A2A at ecommerce checkout.

Ecommerce retail

Retail merchants should prioritize:

•customer initiation quality;

•mobile bank handoff;

•authoritative payment confirmation;

•refunds;

•partial refunds;

•reconciliation.

A rail can be technically excellent while the merchant-facing experience still underperforms.

Digital goods and gaming

Fast confirmation can be particularly valuable where goods are delivered immediately.

But the merchant should establish the exact authoritative success state before granting irreversible digital value.

Bank-side authorization and return-to-merchant behavior should be measured separately.

Travel

A2A may be relevant for high-value transactions and customers comfortable paying directly from bank accounts.

Travel also makes post-payment operations especially important:

•cancellation;

•partial refund;

•rescheduling;

•delayed fulfillment;

•reconciliation.

The merchant should not optimize only the initial payment.

Education

Account-based payments can fit higher-value tuition, enrollment and course-payment scenarios.

The merchant should prioritize structured references and automatic reconciliation.

A manual bank transfer with excellent payment economics can still be expensive if staff repeatedly investigate unmatched tuition payments.

B2B

This can be one of the most natural A2A environments because businesses already use bank transfers heavily.

The merchant value may come less from checkout speed and more from:

•payment references;

•invoice matching;

•automated confirmation;

•bank connectivity;

•reconciliation;

•high-value suitability.

SaaS and subscriptions

Proceed only after solving the recurring question.

A strong one-time Pay-by-Bank experience does not automatically provide a reusable billing instrument.

Determine whether the implementation uses:

•direct debit;

•standing order;

•variable recurring payment;

•another mandate-based mechanism;

•customer reauthorization for every payment.

This can determine whether the method fits the business model at all.

That classification is operationally useful.

But merchants should not infer uniform behavior from the category.

The takeaway is not that one is better.

It is that:

“Bank transfer supported” is too high-level a statement for merchant decision-making.

For every method, a merchant still needs the five-layer map.

How merchants should integrate A2A

Possible models include:

•direct method/scheme integration where available;

•bank-payment provider;

•PSP;

•gateway;

•hosted checkout;

•redirect;

•API;

•QR flow;

•open-banking provider;

•orchestration layer.

The relevant control questions are:

Who creates the payment request?

Who connects to the banks?

Who owns customer initiation?

Who reports authoritative status?

Who provides transaction references?

Who manages refunds?

Who reports settlement?

Who supports incidents?

A provider abstraction can reduce the number of direct integrations the merchant maintains.

It does not make the underlying methods technically identical.

How to measure an A2A product

Do not stop at A2A payment volume.

Use a full merchant funnel.

Customer eligible

→ A2A method visible

→ method selected

→ bank flow launched

→ bank/account identified

→ authentication completed

→ payment authorized or initiated

→ authoritative confirmation received

→ merchant order completed

Customer eligibility rate

Customers eligible to use the A2A product

÷ relevant checkout population

× 100

Define eligibility by:

•country;

•participating bank;

•currency;

•account type;

•device where applicable.

Bank-flow initiation completion

Customers successfully reaching the bank/payment authorization flow

÷ customers starting A2A payment

× 100

Useful for identifying handoff failures.

Authentication completion

Customers completing bank authentication

÷ customers reaching bank authentication

× 100

Useful for bank- or device-specific analysis.

A2A payment completion

Successfully completed payments

÷ eligible initiated A2A payments

× 100

Completed-order rate

Completed merchant orders

÷ comparable A2A-eligible checkout sessions

× 100

This is the metric required to determine whether A2A availability improves commercial completion.

Confirmation latency

Elapsed time between a precisely defined payment event and authoritative merchant confirmation.

Do not simply label the metric “payment speed.”

Name both timestamps.

Unmatched payment rate

Unmatched received payments

÷ received A2A payments

× 100

Refund success

Successful refunds

÷ eligible initiated refunds

× 100

Track partial refunds separately if operationally important.

Do not treat A2A volume as incremental revenue

Like wallets and other local methods, A2A can create:

Access effect: the customer could not adequately pay before.

Convenience effect: the customer could pay by card but finds bank payment easier.

Preference effect: the customer prefers bank payment.

Substitution effect: the customer would have completed by card anyway.

Only appropriate experiment or cohort analysis can determine the net commercial effect.

Ask:

Did making this A2A product available increase completed orders among comparable eligible customers?

A payment-method dashboard alone cannot answer that counterfactual.

Merchant economics need the complete operating model

Do not assume account-to-account payments are inherently cheaper than cards.

Merchant cost can include:

•provider pricing;

•scheme or bank cost;

•settlement;

•FX;

•refund operations;

•fraud;

•support;

•integration;

•reconciliation;

•manual exceptions.

A useful metric is:

Cost per completed order

Relevant payment and operational cost

÷ completed paid orders

A nominally low transaction fee can be offset by poor completion or significant manual reconciliation.

Conversely, a higher headline payment fee can still make commercial sense if the method gives a profitable customer segment genuinely new payment access.

The merchant A2A decision

Before approving an account-to-account product, complete the five-layer map.

Layer 1 — Funding accounts

•Which account funds payment?

•Which account ultimately receives the transaction?

•Which customers are eligible?

Layer 2 — Initiation

•Push or pull?

•Manual or provider initiated?

•Redirect, app, QR or API?

•Does the customer authorize every payment?

Layer 3 — Rail

•Which scheme or payment infrastructure executes the transaction?

•Standard or instant?

•Domestic or cross-border?

•What timing actually applies?

Layer 4 — Merchant acceptance and confirmation

•Who creates payment state?

•What identifier links payment to order?

•Which event is authoritative?

•What happens if the browser never returns?

•How quickly does confirmation arrive?

Layer 5 — Post-payment operations

•Full refunds?

•Partial refunds?

•Disputes?

•Recurring?

•Reconciliation?

•Settlement?

•Support?

If a vendor cannot explain all five layers, “A2A support” is not yet enough information for a production decision.

Final recommendation

Account-to-account payment is a useful concept precisely because it is broad.

It identifies a fundamental alternative to card-based payment:

money moves from payer account to payee account without the card rail carrying the transaction.

But merchants should stop using that definition as though it describes one homogeneous checkout product.

One A2A experience can involve:

customer-created push transfer

→ standard bank rail

→ asynchronous merchant matching.

Another can involve:

open-banking API

→ bank authentication

→ instant-payment rail

→ provider confirmation.

Another can involve:

customer mandate

→ merchant-initiated pull

→ recurring account collection.

All are account-based.

Their customer experience, confirmation, recurring capability, refund operations, fraud model and merchant economics can be completely different.

So when a provider proposes “A2A,” do not ask only:

Do you support account-to-account payments?

Ask:

Which accounts fund the payment, who initiates it, which rail moves the money, how does the customer authenticate, what event tells us the order is paid, and how do refunds, recurring payments and reconciliation work afterwards?

Then evaluate the outcome that matters:

Does this specific A2A implementation give meaningful customers a reliable way to pay—and does the resulting improvement in customer access, completed orders, economics or operations justify the complexity?

That is the merchant decision.

Not whether “A2A” is the future.

Account-to-account payments FAQ

Are A2A payments the same as bank transfers?

They overlap, but A2A is the broader movement concept. Credit transfers are a common A2A form, while direct debits can also move funds directly between accounts using a pull model. The ECB distinguishes payer-initiated credit transfers from payee-initiated direct debits.

Are all A2A payments open-banking payments?

No. Open banking is one possible initiation and account-access model for A2A. The UK PSR explicitly describes open banking as one way of enabling account-to-account retail payments.

Are A2A payments always instant?

No. A2A describes account-to-account movement; instant describes timing. Some A2A payments use instant rails while others use standard transfer or collection mechanisms. The ECB, for example, separately defines standard credit transfers, instant credit transfers and direct debits.

Are A2A payments always push payments?

No. Credit transfers are commonly push payments initiated by the payer. Direct debit is a pull model initiated by the payee under prior customer consent.

Can A2A payments support subscriptions?

Some can. Direct debit, standing orders and newer API-based recurring models can support recurring use in different ways. A successful one-time A2A payment does not establish recurring capability. UK Open Banking standards, for example, separately define standing-order and Variable Recurring Payment mechanisms.

Are A2A payments chargeback-free?

Do not use that as a generic claim. An A2A payment may not use the card-network chargeback system, but unauthorized-payment claims, authorized push-payment fraud, recalls, returns, refunds and other dispute mechanisms can still exist depending on the scheme and jurisdiction.

Is Pay by Bank the same thing as A2A?

Pay by Bank is commonly a merchant-facing A2A payment proposition. A2A is the broader funding/movement model; Pay by Bank describes a particular customer checkout experience layered over account connectivity and payment infrastructure.

What matters most when evaluating an A2A provider?

Ask for the complete five-layer model: funding accounts, initiation, rail, merchant confirmation, and post-payment operations. A provider that explains only payment speed or bank coverage has not yet described the whole merchant product.

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 specification. This article owns the A2A model itself: it separates where money moves from how payment is initiated, how quickly the rail executes, how the customer authenticates, how the merchant confirms payment, and what happens after payment.

Editorial interpretation

Decision

Direction

Bank-payment decision this article owns

How should a merchant decompose an “A2A payment” before deciding whether a specific product fits checkout and operations?

Customer enabled

A customer with funds in a usable bank account who can or prefers to pay directly from that account rather than through a card credential.

Unique evidence anchor

A2A describes where money moves—not necessarily how the customer starts the payment.

Editorial position

Merchants should evaluate the rail, initiation layer, customer journey, confirmation model and post-payment operations separately.

Assumption challenged

“A2A payments all work like open banking.”

Most important technical distinction

Movement model ≠ initiation model ≠ payment rail ≠ merchant-facing product.

Format

Payment-model framework

Primary merchant decision

Determine whether the specific A2A implementation—not “A2A” generically—fits the market, transaction model and merchant operating requirements.

Primary metric

Completed-order rate among eligible customers, accompanied by initiation completion, authoritative confirmation, reconciliation and refund performance.

The terminology is supported unusually well by official sources. The UK's Payment Systems Regulator defines A2A as payments moving money directly from a payer's bank account to a payee's bank account without using card rails, while separately describing open banking as one way to facilitate A2A. The ECB distinguishes payer-initiated credit transfers from payee-initiated direct debits.

Proposed architecture

•Three A2A payments that are not the same product

•What account-to-account actually means

•A2A versus bank transfer

•A2A versus open banking

•A2A versus real-time payments

•Push versus pull

•The initiation layer

•The underlying rail

•Authentication and merchant confirmation

•The A2A Payment Model

•Refunds, disputes and recurring payments

•Reconciliation and settlement

•Merchant use cases

•Measurement and economics

•Final recommendation

•Terminology and use-case FAQ

Original framework: The A2A Payment Model

The article's five-layer framework should be the primary reusable asset:

•Funding accounts

↓

•Initiation

↓

•Payment rail

↓

•Merchant acceptance & confirmation

↓

•Post-payment operations

The important design choice is to avoid drawing “Open Banking,” “Faster Payments,” “Pay by Bank,” and “A2A” as peers.

Instead, show examples in their appropriate layers:

•A2A — the overall movement model

•Open banking/PISP/QR/manual instruction — initiation

•Faster Payments/SCT/SCT Inst/domestic systems — rail

•PSP checkout/status API/payment reference — merchant acceptance

•Refund/recurring/reconciliation — post-payment operations

That visual would solve the terminology problem in seconds.

Suggested alt text: “Five-layer A2A Payment Model showing payer and payee funding accounts, payment initiation, underlying bank-payment rail, merchant confirmation, and post-payment operations including refunds, recurring payments and reconciliation.”

SEO metadata

Field

Recommendation

Account-to-Account Payments: How A2A Works

H1

Account-to-Account Payments: How A2A Works for Online Merchants

Meta description

Learn how account-to-account payments work, including A2A vs open banking, push vs pull, instant vs standard rails, merchant confirmation, refunds, recurring payments and reconciliation.

URL slug

/account-to-account-payments

account-to-account payments

Secondary keywords

A2A payments; account to account payment; bank to bank payments; direct account payments; A2A ecommerce; pay by bank; account based payments; bank account checkout

Related entities

Payment Initiation Service Provider; open banking; bank transfer; direct debit; credit transfer; instant payment; Faster Payments; SEPA; payment rail; Pay by Bank

Excerpt

A2A describes how money moves from payer account to payee account—not how the payment is initiated. This merchant guide separates initiation, rail, authentication, confirmation, recurring payments, refunds and reconciliation.

Structured data

Article + FAQPage if the terminology FAQ is retained

Internal-link plan

Anchor/context

Target

online bank transfers

Bank Transfers as an Online Payment Method

instant payment infrastructure

Real-Time Payments Explained

open-banking payment initiation

Open Banking Payments

merchant relevance of UPI

UPI for International Merchants

standard euro credit transfers

SEPA Credit Transfer

instant euro transfers

SEPA Instant Payments

how local methods fit the overall portfolio

Local Payment Methods cluster

Authoritative source recommendations

The Payment Systems Regulator is the strongest source for the core A2A definition and for the specific proposition that open banking is one possible mechanism for retail A2A rather than a synonym for it.

The European Central Bank is particularly useful for the push/pull distinction because it explicitly defines credit transfers as payer-initiated and direct debits as payee-initiated under consent. Its instant-payment materials also provide a clean demonstration that “instant” is a timing/scheme characteristic rather than the definition of A2A.

The FCA should support the regulatory meaning of payment initiation: an authorized service initiates a payment from an account at another PSP with the user's consent and authentication.

The current Open Banking Standard is the strongest source for payment-initiation status, standing orders, and the evolving VRP layer. Its latest API specification is version 4.0.1, published March 18, 2026.

Proposed author and reviewers

Recommended accountable reviewers:

•[Named bank-payments specialist]

•[Named payment product manager]

•[Named treasury/reconciliation specialist]

Add the names only after those people have actually reviewed the piece. A last-reviewed date should likewise reflect the real review.

Publication fact-check matrix

Area

Verify immediately before publication

A2A terminology

Confirm the chosen definition still aligns with regulator/rail usage in referenced jurisdictions

Rail/scheme

Scheme name, operator, execution model, current rules, participation and timing

Open banking

Current regulatory roles, API standard and scope

Push/pull

Who legally/operationally initiates the specific method

Customer initiation

Redirect, app, QR, manual transfer, alias or provider flow

Merchant eligibility

Entity, country, bank coverage, merchant category, provider route

Confirmation

Which provider state is authoritative for fulfillment

Reconciliation

Available IDs, references, virtual accounts, reports and exception handling

Refunds

Full/partial support, API support, customer information, original-transaction linkage

Recurring

Direct debit, standing order, VRP or other mandate; fixed vs variable; merchant initiation

Disputes

Unauthorized claims, APP fraud, recalls/returns and provider-specific processes

Settlement

Rail settlement versus PSP/merchant payout

Economics

Total cost per completed order rather than unsupported card-vs-A2A generalizations

Amber-flag claims

Use explicit qualification for:

•“A2A is direct.” Say direct account-to-account movement without a card rail; do not imply banks/PSPs disappear.

•“Instant.” Define bank execution, merchant confirmation or merchant payout separately.

•“Open banking payment.” Do not make it synonymous with A2A.

•“Bank transfer.” Clarify whether credit transfer, bank redirect or another product is meant.

•“Recurring A2A.” Name the actual mandate/standing-order/VRP model.

•“Irreversible.” Scheme- and jurisdiction-specific.

•“Chargeback-free.” Avoid unless narrowly defining the absence of a card chargeback while explaining other claims/returns.

•“Cheaper than cards.” Requires merchant-specific total economics.

•“Higher converting.” Requires comparable eligible-customer evidence.

•“Real-time settlement.” Identify exactly which accounts are settled.

Second, verify every method's current:

•authoritative confirmation event;

•refund and partial-refund behavior;

•recurring capability;

•onboarding requirement;

•payment-model availability;

•merchant eligibility;

•settlement/reconciliation process.

That is exactly the type of documentation discrepancy this cluster's fact-check discipline is intended to catch.

Provider-specific verification checklist

For any A2A product named in the final published version, verify:

•What accounts actually fund and receive the payment?

•Is the transaction push or pull?

•Who initiates it?

•What customer consent is required?

•How does the customer authenticate?

•Which scheme or rail carries it?

•Is execution standard or instant?

•What status can the provider observe?

•What status is authoritative for merchant fulfillment?

•How does payment map to the order?

•Are unmatched payments possible?

•Are full refunds supported?

•Are partial refunds supported?

•What dispute/return processes exist?

•Can it support recurring payments?

•Which recurring mechanism is used?

•How does rail settlement differ from merchant payout?

•Which merchant entities and customer accounts are eligible?

Cluster sameness-audit record

Field

Article 3

Title

Account-to-Account Payments: How A2A Works for Online Merchants

Opening

Three account-based transactions with different initiation models

Opening device

Terminology paradox

Primary geography

Global framework with UK/EU official examples

Payment rail

None owned; rail is a separate framework layer

Merchant-facing method

Generic A2A

Primary format

Payment-model framework

Unique evidence anchor

Movement does not determine initiation

Editorial position

Never evaluate “A2A” as one product

Merchant decision

Map all five layers before selecting an implementation

Original framework

The A2A Payment Model

Primary metric

Completed-order rate plus confirmation/reconciliation performance

Conclusion

Ask what moves money, what initiates it, what rail executes it and how operations work afterward

Closing element

Terminology/use-case FAQ

CTA direction

Evaluate specific A2A implementations using the five-layer model

Cannibalization safeguard

Does not own generic bank transfers, real-time infrastructure, open-banking mechanics, or any named domestic scheme

This gives the article a clean position in the fourteen-piece cluster: Article 1 owns bank transfers, Article 2 owns speed/infrastructure, Article 4 owns open-banking initiation, while Article 3 owns the model that explains how those concepts can fit together without being treated as synonyms.