How does a checkout learn that an A2A payment is confirmed?

Everything at the counter hangs off that one signal: the receipt, the goods leaving the shelf, the order going to packing, the shift being closed. It is the piece a rail does not ship.

Why confirmation is its own contract

A card payment and its answer travel together: the merchant's acquirer asks the issuer, and the reply comes back through the terminal. A push payment has no return leg of that shape, for the reason set out in Why do instant payments push instead of pull?

What a rail promises is money. The BIS definition of a fast payment system covers the transmission of the payment message and the availability of final funds in real time, on as near to a 24/7 basis as possible¹, and in the euro area the law caps the transfer at ten seconds². The same definition refers to final funds: once the money has arrived, the payer's bank cannot reverse the payment¹. That makes the confirmation a risk decision. Whoever releases the goods acts on it, and a screenshot on the buyer's phone will not do.

Query and callback, and why both

Building that channel is part of what A2A acquiring has to provide, and it has to run in both directions, because each fails differently.

A status query is authoritative on demand. The till or the merchant's server asks about a payment it created itself. It survives a lost notification, it is the loop a terminal runs while the buyer is still at the counter, and it is what reconciliation at shift close relies on.
A callback is fast. The platform posts the outcome to a URL the merchant supplied when the payment was created, within seconds of the terminal state, so a web page or a cashier screen does not sit in a polling loop. Anyone can post to a public URL, so the message has to be signed, and the merchant has to verify it before fulfilling anything. Redelivery and duplicate suppression belong to the same contract: a notification already applied is acknowledged, not applied twice.
A browser is not a participant. In an embedded checkout the page holds an opaque payment identifier and the in-page success handler redirects the buyer's tab. The source of truth for the order is the signed server-side callback, and the amount is set by the merchant's backend when the payment is created.

Scale on the rail and presence at the counter are two different things. Mexico's CoDi, launched on a fast modern rail, had processed just over a million transactions fourteen months later, about a twenty-eighth of the central bank's target³. FedNow settled about 5 million payments in the second quarter of 2026, averaging some $55,000 each⁴. In Brazil 52% of Pix payments start from a QR code⁵, and Pix was about 7% of the transactions running through card terminals in 2025⁶. India has roughly 709 million active UPI QR codes⁷, and Paytm reports 15.7 million merchants on device subscriptions⁸. The rail is one procurement; what a bank or an integrator supplies around it is what a merchant operates.

The contract in miaPOS

At the till, the POS API generates the QR for a sale, cancels it, checks its state, and returns the transaction and its receipt; shifts open and close with a Z report. A cash register on the same Android device starts the payment through an Android intent and reads the result back: a status of success or failed, the transaction as JSON on success, a reason on failure, and a user back-out returned as a cancellation. A Windows register gets the same outcome in files, with RC 000 for success, 001 for a decline, 002 for timeout and 004 for a communication error, plus an exit code of 0 or 1 for the fast path. Refunds are rail-dependent; where the rail supports them, an accepted refund request is not a settled one, so the register reads the status field as well.

Online, POST /ecomm/api/v1/pay creates the payment and carries the callback URL, GET /ecomm/api/v1/payment/{paymentId} is the status call, and GET /ecomm/api/v1/checkout/{paymentId} is public for the browser widget. On a terminal state the service posts a body with exactly two top-level fields, result and signature, and no custom headers. To verify it: take the result object, sort its fields alphabetically by key, join the values with a semicolon, and check that string with SHA256withRSA against the key from GET /api/v1/public-key. Cache the key, and on a first verification failure re-fetch it and retry once before rejecting, because it can rotate. Reference implementations ship in Java, Python, PHP and Node.js. An OpenAPI reference covers both API groups, and a Postman collection is published for the POS API. A sandbox is issued per partner during onboarding. Whichever channel a payment came from, every transaction lands in one merchant back office. Detail sits in the e-commerce checkout docs.

Common questions

Can an in-page success handler be used to fulfil an order?

No. The browser knows only that it was redirected, and the page holds nothing but an opaque payment identifier. Fulfil on the signed callback received by the backend, or on a status call against that payment.

What happens when a callback never arrives?

Treat the callback as the fast path and the status query as the fallback. The payment state endpoint answers on demand, the terminal keeps asking about the sale it created, and shift close reconciles whatever is still open.

How does a merchant verify the callback signature?

Extract the result object from the body, sort its fields alphabetically by key, concatenate the values with a semicolon as the separator, and verify that string with SHA256withRSA using the public key from the key endpoint. Cache the key and re-fetch once on a first failure before rejecting the message.

A2A acquiring with miaPOS

Building instant-payment acceptance with your merchants? See how miaPOS works with banks.

For banks

Sources

Written by Ghenadie Cernei, Founder, Finergy. 16 October 2026.

How does a checkout learn that an A2A payment is confirmed?

Why confirmation is its own contract

Query and callback, and why both

The contract in miaPOS

Common questions

Sources

Read next