A2A Merchant Acceptance Architecture: What to Build, What Carries Over

Pix, UPI, PayNow, PromptPay, and SEPA Instant all get filed under the same mental shortcut — "bank payments" — and a merchant's second A2A integration usually gets scoped as a smaller version of the first: same idea, mostly reusable code. It isn't. What actually carries over is a set of operating assumptions — most of this is push, pending is not failed, there's no chargeback safety net, refunds are new payments. What has to be rebuilt every time is the mechanics underneath those assumptions: how the payment is initiated, how confirmation arrives, what a timeout means, and what identifier the payer's bank actually hands you for reconciliation.

Scope note. This article is about acceptance architecture — what a merchant's integration has to do differently across account-to-account (A2A) rails, and what's genuinely portable. It does not compare rail economics, governance, or cross-border readiness; that ground belongs to the Real-Time Payment Rails Comparison Matrix and the Pix vs UPI vs SPEI vs PromptPay economics comparison. Recurring and subscription mechanics are covered in full in the subscription rails comparison; this piece touches mandates only where they change the merchant's initiation and status-handling model, not the billing logic on top.

Five rails appear below — Pix, UPI, PayNow, PromptPay, and SEPA Instant — each chosen because primary scheme or regulator documentation was directly retrievable: Banco Central do Brasil's Pix specifications and API repository, Reserve Bank of India circulars, NPCI's technical error-code documentation, the Association of Banks in Singapore, Bank of Thailand's QR policy guideline, and the European Payments Council's SCT Inst, Verification of Payee, and Request-to-Pay rulebooks. Where a rail's behaviour wasn't sourceable from a primary document — PromptPay's refund and dispute mechanics, which Bank of Thailand's own 2019 standard frames as a future API extension, not a settled feature — it is left out rather than inferred by analogy to a different rail.

Push vs Pull: The Split That Drives Everything

Card acceptance is built around pull. The merchant, or its PSP, initiates the charge as a merchant-initiated transaction against a stored credential, and the cardholder is passive after the initial authorization. Most A2A rails invert that. PayNow is payer-initiated only — the Association of Banks in Singapore describes FAST, the rail PayNow rides on, as a transfer system with no pull mechanism at all — so a Singapore merchant collecting via PayNow cannot reach into a customer's account on demand; it can only display an identifier and wait. Pix in its default, non-mandate form works the same way: a payment is a credit the payer's bank sends, not a debit the merchant's bank pulls.

UPI is the partial exception. UPI Collect lets a merchant issue a request to the customer's VPA that surfaces in the customer's banking app — pull-shaped in that the merchant initiates it, but the merchant still has no authority to debit without the customer's live approval of that specific request. It's a request for a push, not a pull. (Worth building around, not just knowing: NPCI directed banks and PSPs to discontinue UPI Collect for P2M/merchant transactions on mobile from 28 February 2026, mandating UPI Intent and UPI QR as the replacement for general checkout — Collect now survives only for a narrow set of exceptions, including IPO and secondary-market merchant categories, UPI mandate execution, and iOS. The "request, not a pull" architecture described here still holds for Intent; a new integration just shouldn't be built on Collect itself.) The merchant is still, structurally, waiting.

This inversion is the biggest mindset shift from card acceptance, and it's the one piece genuinely portable across every rail below: the integration has to be built around "a payment might arrive" rather than "I am charging this account." Status polling, webhook handling, and timeout logic all have to live on the receiving side — nothing happening is a legitimate, common outcome the integration has to handle explicitly, not an edge case.

Initiation: QR, Alias, Deep Link, or API

Four initiation mechanisms recur across these rails, and the choice of which one a given transaction uses changes what data the merchant gets back.

Merchant-presented QR is the dominant checkout pattern for Pix, PromptPay, and PayNow. Bank of Thailand's Thai QR Code Payment Standard distinguishes static from dynamic explicitly: a static QR's image "will be unchanged" and can be printed on paper or a sticker, while a dynamic QR "will regenerate a new QR code every time a payment or funds transfer transaction is made." Pix's specification draws the same line with more precision: a static QR is mandatorily configured with only the payee's DICT key — a transaction reference and fixed amount are both optional, and if the reference (txid) is omitted, the spec requires the literal placeholder *** in its place. A dynamic QR, by contrast, encodes a URL rather than payment data itself; the payer's app resolves that URL at scan time to fetch the actual charge payload, which is where the merchant's own reconciliation reference, amount, and an expiry (defaulting to 24 hours if unset) actually live.

That's the direct, sourced answer to the reconciliation question this comparison always raises: a static QR cannot self-identify an order unless the merchant fixes the amount to one SKU per code — which doesn't scale to a variable cart — or upgrades to a dynamic QR generated per transaction. A printed table-tent QR is a defensible static use case. A checkout page is not.

Alias entry — the payer typing or looking up an identifier rather than scanning anything — is UPI's and PayNow's other primary path. A UPI QR or deep link encodes a VPA (name@bank); PayNow encodes a business's UEN, or a phone number/NRIC for P2P. Deep links open the payer's own banking or wallet app directly, pre-populated — PayNow Corporate documentation describes a paynow:// scheme that does this on mobile, and UPI's Intent flow works the same way, opening whichever TPAP (PhonePe, Google Pay) the customer has installed. API-initiated flows sit underneath both: a merchant's own backend calling a bank's corporate API (DBS RAPID, OCBC Velocity, UOB API Services) or an aggregator's unified API to generate the request programmatically rather than rendering a static asset.

SEPA Instant doesn't fit this taxonomy cleanly — none of the EPC documents retrieved for this piece define a scheme-mandated consumer-facing QR standard the way BCB and BOT do. Acceptance is typically an API-initiated credit transfer (open banking initiation, or a bank transfer flow) rather than a QR-first checkout pattern, with the EPC's Request-to-Pay scheme available as an optional messaging layer that surfaces a request in the payer's banking app — more on that below.

Asynchronous Confirmation: Pending Is Not Failed

This is the largest genuine difference from card acceptance, and the five rails don't behave the same way here — forcing symmetry across them would be the wrong move.

NPCI's UPI technical specification defines a DEEMED response state explicitly for "unknown CREDIT status due to some reason," populated when a transaction response times out at the UPI layer — the merchant's integration has to treat this as genuinely unresolved, not a decline, and reconcile the true outcome asynchronously. A Collect request the payer never actions expires to a specific error code, U69 ("COLLECT EXPIRED"), and the Collect payload carries a merchant/PSP-settable expiry window rather than an implicit one. For the operational-failure case — money debited from the payer but not credited to the merchant — RBI's Turn Around Time circular sets the outer bound: the beneficiary bank must action an auto-reversal at latest T+1 day, with ₹100/day compensation payable without requiring a complaint if the delay runs later.

Pix is looser. BCB's own API specification leaves webhook callback timing entirely to each receiving PSP's discretion, recommending only that it stay within "a reasonable limit" — there is no BCB-mandated SLA on how fast a merchant learns a Pix payment landed. Settlement on BCB's rails is effectively instant; being told about it is a separate clock BCB does not define.

SEPA Instant is the tightest and most explicit of the five. The EPC's SCT Inst Rulebook sets a target maximum execution time of 5 seconds, with a hard outer bound: if the originator PSP receives no confirmation at all within 10 seconds of the transaction timestamp, it must immediately restore the originator's payment account. That's a genuinely different failure mode from UPI's DEEMED or Pix's PSP-discretionary callback — SEPA Instant converts an unresolved state back into a clean not-executed state within a bounded window, rather than leaving it pending for the merchant to reconcile later.

For PayNow and PromptPay, no primary document retrieved for this piece defines an equivalent formal timeout-and-recovery SLA at the scheme level. Both settle over already-24/7 real-time interbank rails, so a completed transaction typically confirms within the same session — but the "what happens on silence" contract, where it exists at all, is a bank or PSP implementation detail rather than a published scheme rule for these two.

Webhooks, Retries, and the Idempotency Gap

Getting notified about a payment and processing that notification exactly once are two separate engineering problems, and the rails differ on how much of either they standardise.

Pix defines the webhook contract itself — a PUT/GET/DELETE /webhook/{chave} endpoint in BCB's own API specification — with a specific limitation worth building around: "only Pix payments associated with a txid will be notified" (Somente Pix associados a um txid serão notificados). A static QR receipt without a txid isn't guaranteed a webhook at all. And the specification sets no idempotency or deduplication requirement — a merchant's integration has to assume webhook replay is possible and dedupe on its own, typically keyed on the transaction's end-to-end identifier, a common PSP convention rather than a BCB rule.

PayNow has no unified webhook contract across banks: DBS, OCBC and UOB each surface PayNow notifications through their own corporate API channel (DBS RAPID, OCBC Velocity, UOB API Services), so a merchant integrating more than one bank relationship maintains more than one webhook contract with its own retry semantics. UPI's callback conventions likewise run through whichever PSP handles the integration (Razorpay, Cashfree, PayU) rather than a single NPCI-mandated merchant contract.

SEPA Instant's tight confirmation window changes the shape of this problem rather than eliminating it. Because the rulebook's 10-second hard timeout resolves the "did the transfer happen at all" question synchronously — confirm or automatic restoration — the merchant doesn't need webhook-level dedup to answer that question the way a Pix or UPI integration does. What still needs idempotency handling is order-level: a confirmation and a later status check reporting the same transfer must not credit the order twice, the same discipline refund and payment-ops runbooks already require for card-side retries and duplicate webhook deliveries.

Finality: What Irrevocability Removes — and Where It Doesn't Quite

Once an A2A push transfer settles, it's final. There's no chargeback, no representment cycle, no issuer-mediated reversal the way card networks provide — the operator consequence is covered end to end in the refund operations runbook linked above: a refund on any of these rails is a new payment sent back, not a reversal, and it needs the same double-pay controls, dispute-status locks, and approval gates that runbook describes for cards, applied to a rail with no dispute status to check against in the first place.

Two of the five rails complicate the blanket "no recovery path" framing, worth stating precisely rather than flattening. Pix's Mecanismo Especial de Devolução (MED) lets a PSP force a return in confirmed-fraud cases without the payer authorizing each time — but BCB's own guide calls it "completamente diferente" from a card chargeback, requiring the initiating PSP to prove the recipient committed fraud. SEPA Instant's Recall lets a sending PSP ask a beneficiary PSP to return funds — but the beneficiary can refuse, only one attempt per recall type per transaction, and the rulebook frames it as a request, not an entitlement the sender can enforce. Neither is a chargeback in the card sense, but neither is "nothing." UPI, PayNow, and PromptPay have no equivalent found here; on those three, a refund is just a new transfer, full stop.

Refund and Return Mechanics by Rail

The numbers behind those recovery paths matter for how fast a merchant can actually promise a customer their money back.

Pix runs two separate clocks. An ordinary, non-fraud refund is payee-initiated and self-service: BCB's guide gives the payer 90 days from the original transaction to return funds at their own discretion, sent as a distinct message carrying return code MD06 — simply the merchant sending money back, on their own timeline. MED, the fraud-specific path, runs a tighter, more procedural clock: the original transaction must be 80 days old or less to open a case (30 days if the transaction under review is itself a refund), each receiving PSP must close its analysis within 7 calendar days, the payer's PSP then has 72 hours to initiate the refund once analysis concludes, and each receiving PSP generally has 6 hours to execute its portion — with precautionary account blocking able to run up to 72 hours while analysis is pending.

UPI's RBI-mandated path covers the operational-failure case (debited, not credited) rather than a disputed-authorization case: auto-reversal at latest T+1, ₹100/day compensation beyond that without requiring a complaint.

SEPA Instant's Recall gives the beneficiary PSP up to 15 banking business days to respond to a PSP-initiated recall before it's in breach of the rulebook — materially slower than Pix's MED, and one where a "no" is an acceptable, terminal answer rather than a breach.

PayNow and PromptPay have no scheme-published return SLA that this research surfaced. The comparison matrix's finding for the broader rail set — that operators must build independent refund infrastructure because no native recall mechanism exists — holds for these two; a refund is a fresh transfer the merchant sends, on whatever timeline its own operations set, with no rail-level status message tracking it back to the original.

Reconciliation: What the Payer's Bank Actually Passes Through

The identifier problem sits underneath every section above: what a merchant gets to reconcile against is whatever the initiation mechanism chose to carry, not something the rail guarantees regardless of flow.

Pix's dynamic QR carries a merchant-defined txid as a mandatory field of the charge payload — the canonical reconciliation key, and the merchant's own choice of value, not something BCB assigns. A static QR's txid is optional; absent one, every scan of that code produces a receipt with no order-level reference at all, which is why a static QR only works cleanly for a fixed-price, single-context use case. PayNow's reference field works similarly in spirit but differently in mechanics: a PayNow Corporate QR or request pre-fills both amount and a bill reference that carries through FAST to the recipient bank's transaction record — but only helps if it's populated and unique per request, since a generic note or reused order ID defeats auto-matching just as reliably as a Pix static QR with no txid. UPI's canonical identifier is the VPA itself rather than the underlying bank account — a deliberate choice, since a VPA survives an account migration a raw account number wouldn't, so merchants reconcile against the VPA and let NPCI's directory resolve it to whichever account is live.

SEPA Instant's contribution here isn't a reconciliation reference — no EPC document retrieved for this piece specifies merchant-facing remittance-reference mechanics in enough detail to state confidently — but a different data point that changes what a merchant should check before going live: the Verification of Payee result attached to the transfer, covered next.

Payer Data, Identity, and the KYC Consequence

What identity data reaches a merchant at the point of payment differs sharply by rail, with direct consequences for KYC enrichment and checkout conversion.

UPI's VPA is a constructed handle — name@bank, created at onboarding — not tied to any pre-existing government identifier, unlike Pix, where a CPF- or CNPJ-type key doubles as the payer's national tax identifier and can meaningfully enrich identity verification. PayNow's UEN, similarly, is a business registration identifier that pre-exists the payment system rather than being minted for it — the design point of using it as an alias is that a business is expected to publish it, which is also why it functions as a soft KYB-adjacent signal a bank account number never could.

SEPA Instant adds a mechanism none of the other four rails here has a published equivalent for: Verification of Payee. The EPC's VoP rulebook defines four outcomes a payer's PSP receives before a transfer executes — Match, Close Match (which discloses the actual registered account-holder name back to the payer to compare against what they typed), No Match, or Verification check not possible — within a 5-second target execution time. It's advisory, not blocking; a payer can proceed past a warning. The consequence easy to miss from the merchant side: the legal or trading name registered against your settlement IBAN now has a direct, checkout-visible effect. A mismatch between your storefront's branding and your bank's registered account name produces a Close Match or No Match warning at the exact moment a customer decides whether to complete the transfer — friction a card checkout has no equivalent of. For the full match-code taxonomy and the UK Confirmation of Payee comparison, see the Verification of Payee and Confirmation of Payee reference.

Fraud Controls for a Push-Payment World

Because the payer authenticates and authorizes the transfer themselves, the fraud signal a merchant needs looks nothing like card fraud tooling. There's no card-present/not-present distinction, no BIN range, no CVV mismatch to check — the transaction is, from the rail's perspective, entirely legitimate; the person who authorized it was the account holder, acting on their own instruction. That's precisely what makes authorized push payment (APP) fraud the merchant-relevant risk category here rather than the unauthorized-transaction fraud card tooling is built around: the victim isn't someone whose credentials were stolen, but someone persuaded to send money themselves.

Verification of Payee is the clearest scheme-level defence against this shift in the sources for this piece — matching the name a payer intends to pay against the name registered on the receiving account, before funds move. Pix's MED is the recovery-side counterpart: it exists precisely because APP-style fraud on Pix is common enough that BCB built a dedicated, PSP-administered process for it, distinct from an ordinary refund. Neither replaces merchant-side controls — velocity checks on new payee registrations, friction on first-time high-value transfers, the dispute-handling architecture the APP fraud reference covers in depth — but both show the rails are only beginning to build fraud tooling suited to push payments, years after card-side tooling matured.

Mandates and Request-to-Pay: Recurring Without a Card

Recurring billing mechanics — UPI AutoPay, Pix Automático, SEPA Direct Debit, and why PayNow has no recurring layer of its own — are covered in depth in the subscription rails comparison linked in the scope note above and aren't repeated here. Worth stating precisely, because it changes how a merchant's initiation logic should treat the two, is the distinction between a mandate and a request-to-pay message.

A mandate is a standing pre-authorization: the payer approves once, and the merchant (or its PSP) can then trigger scheduled debits against that authorization without a fresh approval each time — this is the model behind e-mandate-based UPI AutoPay, Pix Automático, and SEPA Direct Debit. Request-to-pay is a different primitive. The EPC's own SRTP rulebook is explicit: it "covers the set of operating rules and technical elements... that allow a Payee to request the initiation of a payment from a Payer," but "it is not a payment means or a payment instrument, but a way to request a payment initiation." A request-to-pay message surfaces a request in the payer's banking app for the payer to act on — every time, with no standing authorization carried over from the last one. It's closer, architecturally, to UPI's Collect flow than to a mandate: a nudge the merchant sends, not an authority it holds.

For initiation logic, this means a "send a request, wait for approval" flow (UPI Collect, or SEPA request-to-pay) needs the same asynchronous, pending-until-actioned handling on every single transaction — while a genuine mandate (UPI AutoPay, Pix Automático, SEPA Direct Debit) only needs that handling once, at enrollment, then behaves closer to a scheduled batch job. Conflating the two in a design doc is a common, expensive mistake — the retry and timeout logic for each is genuinely different.

Transaction Limits and Basket Size

A hard per-transaction ceiling forces a design branch cards don't need: basket-splitting logic for high-value carts, or a fallback rail entirely. What's sourceable here: SEPA Instant no longer has one. Following the amended SEPA Regulation, the EPC's own change history states plainly that "there is no longer a maximum amount stipulated at scheme level" for SCT Inst — the remaining €999,999,999.99 figure is a technical field limit, not a policy ceiling. PayNow's FAST ceiling, by contrast, is a real constraint: SGD 200,000 per transfer at the network level, with individual banks free to set lower limits — a merchant running high-AOV B2B collections through PayNow Corporate needs to confirm the actual limit with their banking relationship rather than assume the network ceiling applies.

Pix, UPI, and PromptPay all apply their own per-transaction and per-tier caps, but the current figures weren't independently re-verified from a primary source this session — the comparison matrix linked above and the rail-specific deep dives (Brazil's Pix, India's UPI) are the right place to check current numbers rather than duplicating them here. The architectural point holds regardless of the exact figures: wherever a hard ceiling exists, checkout logic needs a decision point — split the basket, or route to a different acceptance method — that a card-only integration never has to build.

Settlement Timing and Merchant Funds Availability

"Instant settlement" and "instant notification" are two different clocks, and this comparison is the one place that distinction is sourceable across rails. SEPA Instant's rulebook gives a number for the second clock: a 5-second target and 10-second hard outer bound on confirmation, with automatic fund restoration to the payer if missed. That's a guarantee about how fast the originator's side learns the outcome — it says nothing about how fast the merchant is notified, which depends on the merchant's own PSP or bank-side webhook implementation.

Pix makes the gap explicit in the other direction: settlement on BCB's own rails is effectively instant, but BCB's API specification leaves webhook callback SLA entirely to each receiving PSP's discretion. A merchant whose PSP implements callbacks conservatively can have funds settled and available well before their own system is told about it — exactly the reconciliation risk that makes event-driven, webhook-first architecture (rather than assuming "settled" and "notified" happen together) the safer default here, not just for Pix.

Access: Why Most of This Isn't Yours to Build Alone

Everything above assumes a merchant already has a route onto the rail — a licensed participant relationship, a local banking relationship, or an aggregator sitting on top of one. Getting that route is a separate question this article doesn't answer: the comparison matrix covers the licensing path per rail, and the local acquiring vs cross-border reference covers when local entity presence is actually required. Worth flagging is only the interaction with architecture: a merchant reaching a rail through an aggregator (Stripe, Adyen, a regional PSP) typically inherits that aggregator's webhook contract, reconciliation format, and refund tooling wholesale — shrinking the work here down to whatever the aggregator's API abstracts, at the cost of losing visibility into exactly the protocol-level detail (static-versus-dynamic QR handling, MED eligibility, VoP result codes) that decides whether an edge case gets handled correctly or silently dropped.

The Portability Map

The practical takeaway for a team scoping a second, third, or fourth A2A integration: budget the architecture review as if it's close to a first integration, not a copy-paste. The posture ports. The protocol doesn't.