How Account-to-Account (A2A) Payments Works
A2A payments use open banking APIs or domestic payment rails to move money directly from the payer's bank account to the payee's bank account. No card network, no intermediary processor standing between the two parties. The technical flow involves payment initiation, bank authentication, and fund movement — all orchestrated via API.
Merchant or platform initiates payment request
The merchant's checkout or platform calls a payment initiation API (either directly to a bank or via an aggregator). The request specifies amount, currency, payee account details, and a redirect or webhook URL for confirmation.
Customer authenticates with their bank
The customer is redirected — or deep-linked — to their banking app or online banking portal. Their bank applies Strong Customer Authentication (SCA), typically biometrics or a one-time passcode. This step happens inside the bank's trusted environment.
Payment instruction is submitted to the rail
Once the customer approves, the bank submits a credit transfer instruction to the relevant payment rail (e.g., Faster Payments, SEPA Instant, FedNow). The instruction is irrevocable at this point on most instant rails.
Funds settle in the payee account
On instant rails, settlement occurs in seconds. On batch rails (ACH, BACS), it may take one to three business days. The merchant receives a webhook or polling confirmation from the initiation API, triggering order fulfillment logic.
Reconciliation is matched automatically
Modern A2A implementations embed a unique payment reference in the transfer instruction. This reference flows through to the merchant's bank statement, enabling straight-through reconciliation without manual matching.
Why Account-to-Account (A2A) Payments Matters
A2A payments have moved from a niche bank-transfer option to a mainstream payment method in several major markets, driven by regulatory change and merchant demand for lower-cost alternatives to card schemes. Understanding the scale of this shift is essential for any merchant evaluating their payment strategy.
According to a 2024 report by ACI Worldwide, A2A payment volumes grew 16% globally year-on-year, with markets like Brazil (PIX), India (UPI), and the UK (Faster Payments) leading adoption. PIX alone processed over 42 billion transactions in 2023, surpassing card transaction volumes in Brazil within three years of launch.
For merchants, the cost advantage is significant. Card acceptance typically costs 1.5–3.5% of transaction value in interchange plus scheme fees. A2A payments on domestic rails cost a flat fee — often under £0.20 per transaction in the UK — representing savings of 50–80% at scale. A McKinsey analysis of European payment economics estimated that widespread A2A adoption could shift €2–4 billion annually from card scheme revenue to merchant margins.
Regulatory tailwind
PSD2 in Europe mandated bank API access for licensed payment initiation service providers (PISPs), creating the open banking infrastructure that modern A2A payments depend on. The UK's Open Banking Implementation Entity (OBIE) reported over 11.4 million active open banking users in 2024.
Account-to-Account (A2A) Payments vs. Card Payments
A2A and card payments serve the same core function — moving money from buyer to seller — but differ fundamentally in cost structure, risk model, and settlement mechanics. The right choice depends on merchant vertical, average order value, and customer base.
| Dimension | A2A Payments | Card Payments |
|---|---|---|
| Cost to merchant | Flat fee, typically $0.10–$0.30 | 1.5–3.5% + fixed fee |
| Settlement speed | Seconds (instant rails) to 3 days | T+1 to T+2 (net of reserves) |
| Chargeback risk | None (push payment, irrevocable) | High — up to 180-day dispute window |
| Fraud model | Bank SCA handles authentication | Merchant bears CNP fraud liability |
| Global acceptance | Fragmented by market/rail | Near-universal via Visa/Mastercard |
| Recurring payments | VRP (UK), direct debit elsewhere | Card-on-file, easy tokenisation |
| Consumer protection | Varies by jurisdiction | Strong (chargeback rights) |
| Checkout friction | Bank redirect/app switch | Card entry or saved card |
Types of Account-to-Account (A2A) Payments
Not all A2A payments work the same way. The category covers several distinct payment flows, each suited to different use cases.
Push payments (credit transfers) are the most common form. The payer instructs their bank to send funds to the payee. These are used in e-commerce checkout, bill payment, and P2P transfers. Because the payer initiates, there is no chargeback mechanism. Push payments form the backbone of instant payment schemes worldwide.
Pull payments (direct debits) allow the payee to initiate a debit from the payer's account, subject to a pre-agreed mandate. Traditional direct debit (SEPA Direct Debit, ACH debits) is not technically A2A in the modern sense, but variable recurring payments (VRP) — where an open banking consent governs automated pulls — represent a next-generation A2A pull mechanism.
Request to Pay (RtP) is a messaging layer over A2A rails. The payee sends a structured payment request to the payer, who then approves and triggers a push payment. It bridges the consumer experience of card-like checkout with the economics of A2A.
Bulk/batch A2A covers payroll, supplier disbursements, and insurance claim payouts — high-volume, lower-urgency transfers routed through ACH, BACS, or SEPA Credit Transfer batch windows.
Best Practices
Implementing A2A payments correctly requires different thinking for merchants focused on conversion and developers focused on reliability.
For Merchants
Offer A2A alongside cards rather than replacing them. Customers in markets with high open banking adoption (UK, Netherlands, Germany) are more likely to choose bank payment when offered; others will default to card. Surfacing A2A as "Pay by Bank" with a recognisable bank logo increases selection rates.
Set clear refund policies before launch. A2A payments are irrevocable — you cannot reverse a credit transfer. Refunds must be initiated as new outbound payments. Define your SLA and communicate it at checkout to manage customer expectations.
Use payment references systematically. Embed a unique, immutable order reference in every A2A instruction. This is the only reliable reconciliation anchor once funds arrive in your account.
Monitor settlement windows by rail. If you accept payments across geographies, map each rail's cut-off times and availability (some batch rails do not process on weekends or public holidays). Build this into your fulfillment logic.
For Developers
Implement idempotency on all payment initiation calls. Network timeouts can cause duplicate API calls; use idempotency keys to ensure at-most-once payment creation.
Design webhook handling before building the redirect flow. The redirect confirmation from the bank is unreliable — customers close browsers, apps crash. Webhooks from your payment initiation provider are the authoritative confirmation signal. Never fulfill an order based solely on redirect parameters.
Handle the pending state explicitly. Real-time payments settle in seconds, but some rails have processing windows. Your order state machine needs a pending_settlement state distinct from confirmed and failed.
Test bank authentication edge cases. Different banks implement SCA differently. Test with multiple bank sandboxes if your provider supports it. Expired consent, insufficient funds, and SCA timeout are the three most common failure modes.
Common Mistakes
Treating A2A like a card payment with lower fees. The risk model is inverted. You gain by eliminating chargebacks and fraud liability, but you lose consumer protection mechanisms. Adjust fraud screening and refund workflows accordingly — do not port card-era logic directly.
Ignoring rail fragmentation in multi-market rollouts. A2A in the UK runs over Faster Payments; in the EU it may be SEPA Instant or a national scheme; in the US it could be FedNow or RTP. Each has different limits, speeds, and API contracts. A multi-rail orchestration layer is almost always needed beyond a single domestic market.
Underestimating the open banking consent UX. The customer redirect to their bank is a high drop-off point if not designed carefully. Deep-linking directly into a banking app (where supported) and pre-filling the bank selection screen materially improves completion rates.
Skipping reconciliation infrastructure. Merchants who implement A2A without a structured payment reference and automated matching workflow quickly discover a large unreconciled cash pile in their bank account. Build reconciliation tooling in parallel with payment acceptance.
Conflating A2A with instant. A2A is a payment type; instant refers to settlement speed. Not all A2A payments are instant — ACH and BACS batch transfers are A2A but settle in days. Communicate accurate settlement expectations internally and to customers.
Account-to-Account (A2A) Payments and Tagada
Tagada's payment orchestration layer is designed to abstract the complexity of A2A payment rails across markets. Rather than integrating directly with each domestic scheme API, merchants connect once to Tagada and route A2A transactions to the appropriate rail based on customer geography, amount, and rail availability — with automatic fallback to card if the A2A flow fails.
Tagada supports alternative payment methods including A2A across Europe and the UK, with built-in reconciliation reference injection, webhook normalization across providers, and real-time settlement status tracking. Merchants can enable A2A at checkout with a single configuration change — no per-rail integration required.
For platforms running subscription or marketplace flows, Tagada's orchestration handles the VRP consent lifecycle alongside one-time A2A payments, giving a unified payment method object regardless of whether the underlying instrument is a push payment or a recurring bank debit.