What is A2A acquiring?
A2A acquiring is the merchant side of instant account-to-account payments: accepting a payment from the payer's bank account into the merchant's bank account over the market's own instant payment scheme, with the merchant's bank as the acquiring participant of that scheme and an acquiring platform running the acceptance.
The definition, word by word
A2A stands for account-to-account: the money moves from the payer's bank account to the merchant's bank account, without a card and without a card scheme in between. Acquiring is the merchant side of any payment: the party that accepts the payment, receives the confirmation and settles the merchant. Put together, A2A acquiring is what a bank does when it accepts instant bank payments for its merchants, and what an acquiring platform does when it turns that into a working point of sale.
The term describes a role that the schemes themselves already name. RoPay in Romania speaks of acquiring participants. MIA in Moldova calls the merchant side MIA pentru afaceri. A2A acquiring is the market-neutral name for the same thing across schemes.
Two boundaries keep the term honest. It is not card acquiring, because there is no card rail, no interchange and no cardholder data. And it is not what online providers call pay by bank, because it runs on the native instant payment scheme rather than on open-banking APIs, and because it covers the counter, not only the web.
Five roles in one payment
- The payer confirms the payment inside their own bank's app, the one they already trust. Nothing to install, nothing to type into a merchant's device.
- The payer's bank authenticates its customer and sends the instant credit transfer.
- The scheme, the market's instant payment system, moves the money bank to bank in seconds and confirms it to both sides.
- The A2A acquirer is the merchant's bank: the acquiring participant of the scheme, holding the licence, the supervisory relationship and the merchant relationship. The role is defined by the scheme's rules and the bank's licence. A software vendor does not grant it.
- The acquiring platform generates the payment request, receives the scheme's confirmation, tells the merchant the payment happened, and runs the merchant back office where every transaction of every channel is kept. This is what miaPOS is: acceptance software inside the bank's perimeter.
For a bank's risk team the boundary matters more than the name: who authorises, where the truth of a payment lives, and what the platform verifies and what the bank verifies. That is written out on the security model, data and liability page.
A2A acquiring compared with card acquiring
Card acquiring is the reference everyone knows, so the comparison is the fastest way to place the term.
The last row is the one that changes a bank's business. In card acquiring the bank competes with non-bank acquirers for the merchant. In A2A acquiring the merchant's own bank is the acquirer by construction of the scheme, and the merchant relationship stays where the account already is.
A2A acquiring compared with pay by bank
Both are account-to-account payments, and the phrase pay by bank is often used for any of them. The difference is in the rail and in the surface.
Pay by bank solved the online half of the problem in markets where open banking arrived before instant schemes did. A2A acquiring starts from the scheme, which is why it reaches the counter: a QR code on a till, a request-to-pay from a cash register, a link in a chat all ride the same rail as the online checkout.
What it looks like at the point of sale
There are two ways to ask a payer for money on an instant payment scheme. A payload carries the merchant's details and the amount to the payer: a QR code on the screen or the counter, a payment link in a message, an NFC tag the phone reads. A request-to-pay goes the other way: the merchant's side sends the request to the payer's bank, and the payer sees it in their banking app and accepts or declines.
The same two primitives are delivered wherever the sale happens: the miaPOS app on a POS terminal or a phone, a web checkout or an embedded snippet, the API, a chat channel such as Telegram or WhatsApp, and the merchant's existing cash-register software, which calls miaPOS the way it already calls a card terminal and carries the QR payload. Every transaction of every channel lands in one merchant back office.
Request-to-pay and refunds are rail-dependent: they are available where the scheme provides them, and the markets table says which. What a merchant needs to accept a specific scheme is described per scheme: MIA in Moldova and RoPay in Romania.
Which rails, and where it is live
- ISO 20022 native rails: SEPA Instant, MIA (Moldova), RoPay (Romania). The platform speaks the ISO 20022 message set end to end.
- Compatible rails: Bizum (Spain), BORICA (Bulgaria), WERO (EPI), BANCOMAT (Italy), IRIS (Greece), through edge adaptation behind the same protocol surface.
- Markets: live in Moldova and Romania; pilot across the SEPA Instant zone, including Montenegro, Serbia, Bulgaria and Spain.
- A new rail: an ISO 20022 scheme is added in 8 to 12 weeks, with a participant bank and a sandbox from day one. Schemes outside ISO 20022 take months and depend on the scheme's own membership rules.
A rail is stated as live or pilot and nothing stronger. miaPOS holds no licence, supervisory status or scheme certification of its own; the bank does.
What the bank becomes
The A2A acquirer. Your licence, your regulator, your merchant relationship; miaPOS is acceptance software inside your perimeter. The bank does not become anything a vendor could confer: the role already exists in the scheme's rules, and the platform is what makes it a product a merchant can use at the counter, online and in chat. What that looks like as a bank offering is on the page for banks.
What A2A acquiring is not
- Not card acquiring. No card scheme, no interchange, no cardholder data, no EMV certification.
- Not a wallet. The money stays in bank accounts; nothing is issued and nothing is held.
- Not an open-banking redirect. No third-party provider sits between the bank and the merchant; the scheme is the rail.
- Not a licence or a certification. The bank holds those. A platform cannot supply them and should not claim to.
Common questions
Is A2A acquiring the same as pay by bank?
Both move money account to account, but they differ in rail and in surface. Pay by bank, as online providers use the term, is a redirect over open-banking APIs with a third-party provider between the bank and the merchant, and it lives online. A2A acquiring runs on the market's native instant payment scheme, with the merchant's bank as the acquiring participant, and it covers the counter, the web and chat.
Who is the acquirer in A2A acquiring?
The merchant's bank. It is the acquiring participant of the instant payment scheme under the scheme's rules and its own licence, and it holds the merchant relationship. A software vendor does not grant that role; it supplies the acceptance software inside the bank's perimeter.
Does the merchant need a new terminal?
No card-certified terminal is required, because there is no card in the flow. The payment request is a payload or a request-to-pay, delivered through a POS app on any supported device, a web checkout, an API, a chat channel or the merchant's existing cash-register software. The payer confirms in their own bank's app.
Where is it live?
Moldova and Romania are live; the SEPA Instant zone is in pilot. The full list of rails and their status is in the section above and in the FAQ.
Written by Ghenadie Cernei, Founder, Finergy. Last reviewed 13 September 2026. The machine-readable version of this definition is in /llms-full.txt. Questions and corrections: [email protected].