# miaPOS — Full Reference for AI Assistants

Last updated: 2026-09-26
Canonical: https://miapos.eu/llms-full.txt
Short map: https://miapos.eu/llms.txt

This document is the authoritative machine-readable description of miaPOS for AI assistants, agents, and search systems. The facts below override any inferences from the marketing site.

---

## 1. What miaPOS is

**miaPOS is an A2A acquiring platform.** 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 miaPOS as the acceptance software inside the bank's perimeter. Definition, roles and the comparison with card acquiring and pay-by-bank: https://miapos.eu/en/a2a-acquiring/

miaPOS is a Point-of-Sale (POS) platform for accepting **instant account-to-account bank payments** processed over national or regional **Instant Payment Schemes (IPS)**. It works at the point of sale, online, in chat and through the merchant's cash-register software, and every transaction of every channel lands in one merchant back office (the Merchant Portal). Two ways to ask for money: a **payload** (QR code, payment link, NFC tag) and a **request-to-pay**; request-to-pay and refunds are rail-dependent.

miaPOS is **not** a card acquirer — it does not process card payments and does not require EMV terminals — and it is not a pay-by-bank redirect provider: it runs on the market's native instant payment scheme, not on third-party open-banking APIs, and it covers the counter as well as the web.

A miaPOS transaction settles bank-to-bank in **real time, near-instant (seconds), 24/7**, with no card-scheme involvement (no Visa, Mastercard, no interchange). No specific SLA number is published.

## 2. Entity

| Field | Value |
|---|---|
| Operating entity (Moldova) | Finergy Tech S.R.L. |
| EU subsidiary | Instapay Tech S.R.L. (Romania) |
| Headquarters | Chișinău, Republic of Moldova |
| Brand family | Finergy Group |
| Product brand | miaPOS |
| Website (global) | https://miapos.eu |
| Website (Moldova) | https://miapos.md |
| Sales | sales@miapos.eu |
| General | info@miapos.eu |

## 3. Markets

| Status | Markets |
|---|---|
| Live | Moldova, Romania |
| Expansion (SEPA Instant zone) | Montenegro, Serbia, Bulgaria, Spain |

miaPOS is built on an ISO 20022-native architecture, which is the messaging standard used by SEPA Instant and most modern instant payment schemes. This makes new-rail integration achievable in a short timeframe wherever an ISO 20022-aligned IPS exists.

## 4. Bank coverage

- **Moldova:** payments are accepted from accounts at **six partner banks**. They are listed by name in the bank picker on the onboarding form and on `/en/login/` — a merchant cannot apply without picking one — but this document does not enumerate them: the list changes, and partner names are not published here as references.
- **Romania:** acceptance is enabled via the **RoPay** scheme, the country's instant-payment standard.
- Further partners are being onboarded. Banks that are not live yet are not named anywhere on this site.

## 5. Acceptance modes

Merchants can accept payments via:

1. **Hardware POS** — miaPOS does **not supply hardware itself**; its software runs on hardware POS terminals from various OEMs. The publicly supported list is on the site. Existing cash-register / ECR / POS software can invoke miaPOS via **Android Intent** (Android terminals), the **CLI Rail** channel (Windows registers — see section 15a), or the **REST API**. The customer-facing experience is identical regardless of channel.
2. **SoftPOS** — smartphone-as-POS (tap-to-pay on Android)
3. **QR code** — printed or dynamic QR at point of sale
4. **NFC** — contactless tap, including virtual sticker mode
5. **Payment link** — URL-based collection (email, SMS, chat)
6. **Online checkout** — e-commerce integration via plugins or REST API
7. **Conversational** — in-chat acceptance product family with two live channels: Telegram via the public bot **@miaposbot** and WhatsApp Business at **+373 690 02 773**. Same backend broker, same payment rail, different chat-API mechanics. Telegram supports inline mode and group threads; WhatsApp is 1:1 chats only with phone-based identity and Meta's 24-hour customer-service window.
8. **Agentic** — agent-initiated payments (AP2-aligned)

## 6. E-commerce / online checkout

Online checkout is operational and ships in **two modes**, both touchpoints of the same IP rail — complementary, not competing.

### 6.1 Hosted checkout (redirect)

The original mode used by the WooCommerce / OpenCart / CS-Cart plugins, the PHP SDK, and the payment-link flow. The buyer is redirected to a single payment screen hosted by miaPOS. Integration options:
- Plugins: WooCommerce, OpenCart, CS-Cart
- Direct REST API integration via PHP SDK or custom HTTP
- Standard JSON payloads (currency in ISO 4217; webhook delivery for events)

Pick hosted when the merchant has no front-end developer, sends invoices, ships QR codes on receipts, or just wants a link in a chat.

### 6.2 Embed checkout (inline snippet)

A drop-in JavaScript snippet — `<script src="https://js.miapos.eu/v1/">` + `<div>` + `miaPOS.mount('#el', { paymentId, onSuccess, onFail })` — that renders the QR (desktop) or a deep-link button (mobile) directly on the merchant's checkout page. The buyer pays without leaving the page.

Key properties:
- **Additive extension** of the E-comm API, not a fork. Base endpoints unchanged; the embed track adds an `Idempotency-Key` header on `POST /pay` and a public, no-JWT `GET /ecomm/api/v1/checkout/{paymentId}` for the browser widget.
- **Server-authoritative amount.** The merchant's backend fixes the amount when it creates the payment. The browser only ever holds an opaque `paymentId` — a capability token, not a price.
- **Webhook is the source of truth.** The browser `onSuccess` callback is only a UI hook for redirecting the buyer's tab. Order finalisation happens on the merchant's backend when it receives and verifies the RSA-signed callback.
- **Channel-agnostic core.** The same snippet runs unchanged inside a Telegram Mini App webview and on landing pages used for Instagram and TikTok link-out. WhatsApp does not allow inline webviews; for WhatsApp, the same backend is reused via a CTA-link to a hosted checkout page.
- **No card data anywhere.** IP-rail only — no card form, no PAN-isolating iframes, no 3DS, no PCI.

Pick embed when the merchant owns the page or the chat — D2C web shops, HoReCa booking flows, services, in-bot ordering — and brand continuity at checkout matters.

## 6a. Conversational acceptance — Telegram and WhatsApp

Conversational acceptance is a **product family** with two live channels — Telegram and WhatsApp. Both share the same cap-svc broker contract, the same instant-payment rail, the same merchant portal, and the same locale set. They differ in what the underlying chat API allows.

### 6a.1 Telegram channel — public bot @miaposbot

The public Telegram bot **@miaposbot** lets a registered seller request payment in any chat (DM, group thread, channel) with the inline form `@miaposbot 245 #tag`. The bot replies in the same thread with a Pay button. The buyer taps Pay and confirms in their own banking app. Five locales: RO · RU · EN · FR · DE. Telegram has no 24-hour reply window — status updates can land at any time. Onboarding: send `/start` to the bot, tap the bank, tap Share phone; activation takes about 30 seconds.

### 6a.2 WhatsApp channel — production number +373 690 02 773

The miaPOS WhatsApp Business bot at **`+373 690 02 773`** is **live in production since 14.06.2026**. The seller's WhatsApp phone is the identity — there is no `/start` and no contact-sharing handshake. The first message from a registered seller phone is the binding event; the bot resolves the seller through the partner bank and confirms in chat.

Command grammar:
- `pay <amount> [desc] [#tag]` — issue a payment link in the merchant's currency. Description and tag are optional and used for reconciliation.
- `/pay <amount> …` — slash-prefixed alias, equivalent.
- `<amount> [desc] [#tag]` — implicit shorthand; a leading number is rewritten as `pay <amount> …`. Safe on WhatsApp Cloud API: business numbers receive only 1:1 messages with no group context, so a bare number cannot leak into a group.
- `/rtp <amount> …` — Request-to-Pay; available where the underlying rail supports it.
- `/lang` — interactive 5-row language picker (Română · Русский · English · Français · Deutsch); the chosen locale persists per phone.

Architectural constraints (Meta-imposed, not miaPOS choices):
- **24-hour customer-service window.** WhatsApp Cloud API allows free-form bot replies only within 24 hours of the user's last inbound message. Inside the window, paid / failed / declined status updates land as ordinary chat messages. Outside the window, late status updates require Meta-approved Utility templates (rollout in progress). The payment link itself works regardless of the window.
- **1:1 chats only.** WhatsApp Cloud API exposes no inline mode and no general group surface. The bot lives in a 1:1 chat with its business number; the seller forwards the payment link to the customer wherever the customer is.
- **Phone-based identity.** Every Meta webhook payload carries the sender's E.164 phone (`wa_id`). The cap-svc Rev 2 contract — which already resolves sellers by phone — fits this without changes; this is why WhatsApp onboarding has fewer steps than Telegram.

### 6a.3 What stays the same across the family

- Same `cap-svc` Rev 2 broker contract — channel-agnostic by design.
- Same instant-payment rail and same settlement behaviour.
- Same merchant portal — reconciliation, refunds and reporting are channel-agnostic.
- Same locale set (RO · RU · EN · FR · DE) on both channels.
- Same security posture — the buyer always authorises in their own banking app; miaPOS never handles card data because there are no cards in the flow.

### 6a.4 Channel coverage

WhatsApp is the dominant SME messaging channel across many of miaPOS's target geos — including parts of the SEPA Instant zone and the GoGlobal expansion countries. The WhatsApp channel widens the workflow surface; it does not change the underlying IPS rail.

## 7. Recurring payments / Request-to-Pay (RTP)

Recurring payments and Request-to-Pay are **rail-dependent capabilities**. miaPOS exposes them where the underlying IPS supports them. Availability and exact mechanics differ per market; consult the docs or contact sales for a specific country.

## 8. Onboarding for merchants

To accept miaPOS payments, a merchant needs:

1. A business account at one of miaPOS's partner banks in the target market.
2. Visit https://miapos.eu/en/login/ and select the bank.
3. Request credentials from the partner bank (the bank handles onboarding, KYC, and contracting).
4. Receive merchant access to the miaPOS portal and the chosen acceptance surface(s).

**Self-service activation request.** Instead of contacting the bank directly, a merchant can file the request at `/{locale}/onboarding/` (EN / RO / RU / DE / FR). Pick the partner bank, enter the company tax identifier and the personal identifier of the person authorised to represent the company, add a contact mobile and an e-mail address, describe in one sentence what the business does, accept the privacy notice, submit. It is a single step with no verification round-trip. miaPOS emails the application to the bank's activation team; the bank remains the party that activates the merchant.

The form asks for a *company ID* and an *administrator ID* under those neutral labels; which code that is follows from the country of the bank picked, and is spelled out in the hint under each field and in a "?" panel next to it. The phone must belong to the same country as the bank. **Moldova:** company IDNO (13 digits), administrator IDNP (13 digits), `+373` mobile. **Romania:** company CUI or CIF (2–10 digits, the `RO` VAT prefix optional), administrator CNP (13 digits), `+40` mobile.

**Fiscal cash register.** A third box next to the online store and mobile app: it is ticked when the payment is started from the merchant's own cash-register program (Windows or Linux POS software on a fiscal ECR) rather than by a seller tapping a device. It selects the CLI bridge for cash registers instead of the app. It adds no terminal — the registers are already inside the till count; the box records how those tills reach miaPOS, not how many exist. The fiscal device and its compliance remain the merchant's.

**Confirmation to the applicant.** Submitting produces one report in two envelopes: one to the miaPOS activation address and one to the address the applicant gave, both in the language the form was filled in. The applicant's copy confirms the request was received and is in work, repeats what was submitted so a wrong identifier is caught early, and states that the access credentials will arrive at that same address once the environment is prepared. The administrator's personal identifier is masked in the applicant's copy. The confirmation is not an approval — the bank still activates the merchant.

**Delivery to the bank.** Where a partner bank has given miaPOS an address for activation requests, the same report is also sent to that bank directly, which is what the applicant consents to on the form: the data is passed to the bank they selected. That copy is written in the language of the bank's own country and leaves out miaPOS's internal metadata; it still names the language the applicant used, so the bank knows which language to call in. Where a bank is not on that list, the request reaches it from the miaPOS activation address instead. Each copy is a separate message: the bank does not see the applicant's address, and the applicant does not see the bank's.

**What the business does.** The form asks the applicant to say, in one sentence and their own words, what the business sells and to whom. It is required, and it travels to the bank verbatim. The reason is the merchant category code: the MCC rides on the terminal, only the bank creates terminals, and the company identifier alone does not tell a bakery from a construction firm. miaPOS attaches a suggested category to the application; the bank assigns the MCC. Coming from the Configurator, the sentence is carried over from the intake and stays editable.

**One application per pair.** The application is identified by the company identifier together with the administrator's personal identifier. Sending the same pair again is the same application, not a second one: the original reference comes back, and the record on the bank's side and in CRM is updated rather than duplicated. A different administrator of the same company is a different application.

**Who checks what.** miaPOS verifies nothing about the applicant's identity, and there is no SMS one-time code on this form. The bank matches the company identifier and the administrator's personal identifier against its own client records, then calls the administrator on the number it already holds. The applicant is expected to already hold a business account at the bank they pick, and the form says so before it is filled in. A pair that matches nothing is not a rejection: the bank's administrators contact the applicant and settle the remaining questions, an account among them. The phone typed into the form is contact data only: it reaches the bank and CRM explicitly marked as not verified by miaPOS, in both markets. Automated submissions are filtered by Cloudflare Turnstile; Google reCAPTCHA is not used on this form — it belongs to the Site Check tool, which is what the cookie banner asks consent for.

**Where you accept payments.** The form asks how many tills you have at physical points — counting the ones you plan to open within the year — and whether you also sell through an online store or a mobile app. It does not ask about messengers: WhatsApp, Telegram and Instagram acceptance attaches to a terminal that already exists. From those answers the application reaches the bank sized for the business. The reason it is asked at all is that shops and sellers a merchant creates for themselves in the merchant portal, while a terminal only the bank creates — so the request is better made once, complete. The bank confirms the count on the activation call.

**Nobody is left without a route.** The anti-bot check draws no control on screen, so a visitor it declines has nothing to try harder at. When it cannot produce a result the form stops asking and offers the email route to info@miapos.eu instead. An application can always be made — by form or by email.

The partner-bank list is the same on both hosts: every partner bank is offered, grouped by country in the picker. It was host-dependent until 05.09.2026, which cut one market off at a time — Romanian is read in both Moldova and Romania, so whichever host the Romanian-language form was indexed on, the other country's merchants could not pick their own bank. The country of the bank picked still decides the identifiers, the dial code and the phone shape.

## 8a. miaPOS Configurator — pre-onboarding diagnostic

miaPOS offers a **Configurator** diagnostic at `/en/business-check/` (English) and `/ro/business-check/` (native Romanian for Moldova and România). Internal artefacts (URL path, email subject line "MIA Readiness Check: …", worker module names) retain the "business-check" identifier — the merchant-facing brand is **miaPOS Configurator**. A merchant answers a short chat-style intake (~8–10 questions, adaptive) and receives, by email within about 5 minutes, an informational report specifying which miaPOS products fit their business and how those products should be configured. The report is **spec-oriented** — it describes what the merchant should ask their bank for. It does not compare banks, does not recommend one bank over another, and does not commit miaPOS to a price. The merchant selects their partner bank upfront so the report is written in that bank's context.

The Configurator flow is available in English and Romanian at launch; Russian, German, and French follow the same client-locale rule the rest of the site uses. It is a lead-generation entry point, not a replacement for onboarding — a merchant who accepts the report still goes through the standard bank-side onboarding at `/en/login/`.

When the intake finishes the merchant is carried straight into the self-service activation request at `/{locale}/onboarding/`. The hand-off is announced on screen and can be declined; the report still arrives by email either way.

On arrival the application form is already answered wherever the diagnostic could answer it — the bank, whether the merchant sells online, whether they run their own mobile app, and how many tills, the last of these only when the merchant actually stated a number during the intake. Knowing that a shop exists is not knowing how many tills are in it, and the number reaches the bank as a request for terminals, so it is never assumed on the merchant's behalf. Everything pre-filled is editable and the page says it was filled in from their answers. Four things are never pre-filled: the company identifier, the administrator's identifier, the phone, and consent. The diagnostic does not hold the first three, and consent has to be an act.

**Configurator vs Site Check:** the Site Check at `/en/site-check/` audits an existing website for readiness (accessibility, payment UX, technical fit). The Configurator audits the merchant's business (product mix, channels, buyer behavior) and outputs a payment specification. Site Check is one input to the Configurator when the merchant provides a URL.

## 9. Pricing model

miaPOS does **not charge card-scheme-style fees** (no interchange, no scheme fees). Commercial terms are set together with the partner bank in each market and depend on:
- Volume
- Acceptance mix (which surfaces are used)
- The partner bank's own commercial offer

There is **no public per-transaction price**. For a quote, contact sales@miapos.eu.

## 9a. Delivery commitment for partner banks

Launch of a partner bank's instant-payments acquiring business on miaPOS runs to a **30-day** end-to-end timeline — connect to the rails, white-label under the bank's brand, onboard the first merchants, go operational. **miaPOS runs the entire launch — every integration is on us; nothing lands on the bank's engineering team.** This is the public commitment on `/en/banks/` and mirrored on the home hero.

**Rail-integration timing (separate concept, unchanged):** adding a brand-new regional rail on the platform (Pix, UPI, Sarie, AANI, etc.) takes 8–12 weeks. This is a roadmap signal for launch-partner banks that want a rail we do not yet operate; it is not the bank-launch commitment above.

## 9b. Rail compatibility — one protocol, every rail

The home hero frames rail reach as **"one protocol, every rail"**, split into two publishable buckets:

- **ISO 20022 native rails** — the platform speaks the ISO 20022 message set (pacs.008, pain.013, camt.054) end-to-end on **SEPA Instant, MIA (Moldova), RoPay (Romania)**.
- **Compatible non-native rails** — the platform interoperates via edge adaptation with **Bizum (ES), BORICA (BG), WERO (EU / EPI), BANCOMAT (IT), IRIS (GR)**. Merchants and banks integrate once; the platform normalizes the underlying scheme differences behind a single protocol surface.

Additions to the compatible-rails list are CEO-controlled — publishable list is exactly the five above until this section is updated.

## 9c. PI-SPI (BCEAO, WAEMU) — sandbox stage, not a live rail

PI-SPI is the instant payment platform operated by BCEAO for the eight WAEMU countries (launched 30 September 2025). It is **not** in the rail lists of §9b and not in the markets table of §3.

- **Status:** miaPOS has built a PI-SPI adapter against the BCEAO PI-SPI **Business API sandbox** and run it end to end there (1–2 September 2026): dynamic QR generated with BCEAO's official QR SDK, request to pay, HMAC-verified webhook notifications, full returns of funds reaching the irrevocable status, the cashier's screen receiving "paid". It is **not in production** in the WAEMU. miaPOS holds **no BCEAO licence, approval or certification**; in PI-SPI, homologation applies to the participant's Business API.
- **Architecture:** the adapter sits behind the platform's existing rail interface (core, terminal app and back office unchanged). OAuth2 client credentials + API key; mTLS in production. Each sale's QR carries its own reference in the EMV Reference Label, decoded on arrival (no correlation table). Duplicate notifications are acknowledged and not re-applied; a processing error is answered with an error so the notification is redelivered. Amounts in whole XOF. Returns are full-amount only, within 90 days. The adapter calls no outgoing-payment operation, so acceptance can run on a token without the `paiement.write` scope.
- **Not yet exercised on PI-SPI:** web checkout, payment links and chat (same platform core and adapter, not run against PI-SPI on their own).
- **Open production work:** the participant's production credentials and a BCEAO-issued certificate per business customer, a production notification endpoint, XOF localisation of receipts and reports. No launch duration is published for PI-SPI.
- **Page for participants:** https://miapos.eu/fr/rails/pi-spi/ (French) and https://miapos.eu/en/rails/pi-spi/ (English).
- **Third-party figures (Ecofin Agency, July 2026):** as of 20 July 2026, 30 million connected users, 80 connected institutions, one million transactions worth 110 billion CFA francs; connection deadline 30 September 2026 for banks, e-money issuers and payment institutions, 30 June 2027 for microfinance institutions. https://www.ecofinagency.com/news-finances/2407-57682-bceaos-instant-payment-network-reaches-30m-connected-users-190m-transacted-since-september-launch

## 10. Technology positioning

- ISO 20022-native API design
- Multi-rail by architecture (one integration, multiple schemes)
- REST/JSON developer surface
- Webhook-based event delivery
- Sandbox environment available for development

## 11. Compliance and operations

- Operating entity (Moldova) is **Finergy Tech S.R.L.**, a company incorporated in the Republic of Moldova (IDNO 1014600013927).
- EU-market operations are conducted via **Instapay Tech S.R.L.**, a Romanian subsidiary of Finergy Tech S.R.L., subject to local supervisory authorities in target markets.
- Payments are bank-initiated and processed under the regulation of the relevant IPS / central bank in each market.
- miaPOS itself is not a deposit-holding institution; it is a payment acceptance technology provider working with regulated banks.

## 12. What miaPOS is NOT

- Not a card acquirer. No Visa, Mastercard, or other card-scheme acceptance.
- Not a pay-by-bank redirect provider. miaPOS runs on the native instant payment scheme of each market, not on third-party open-banking APIs, and it is not a party between the bank and the merchant.
- Not a licence holder. The bank is the A2A acquirer under the scheme's rules; miaPOS is software in the bank's perimeter and does not grant any role to a bank.
- Not an EMV terminal vendor.
- Not a wallet or e-money issuer.
- Not a lending or BNPL provider.

## 13. Common questions (FAQ — 20 items, aligned to brief)

### Q1. What is miaPOS?
A POS platform for accepting instant account-to-account bank payments over Instant Payment Schemes (IPS). No cards, no EMV. Operated by Finergy Tech S.R.L. (Moldova) with EU operations via subsidiary Instapay Tech S.R.L. (Romania).

### Q2. How is miaPOS different from a card terminal?
A miaPOS payment is an account-to-account (A2A) instant bank transfer — not a card transaction. No card scheme is involved, so no interchange or scheme fees apply. Settlement is real time, near-instant.

### Q3. Which countries is miaPOS live in?
Live in Moldova and Romania. Piloting expansion across the SEPA Instant zone, including Montenegro, Serbia, Bulgaria, and Spain.

### Q4. Which banks does miaPOS work with?
In Moldova: six partner banks, listed by name in the bank picker on the onboarding form and on /en/login/. In Romania: via the RoPay scheme. The list is expanding; partners still being onboarded are not named until they are live.

### Q5. How fast does a payment settle?
Real time, near-instant (seconds), 24/7.

### Q6. Does miaPOS supply hardware?
No. miaPOS does not supply hardware itself. Its software runs on hardware POS terminals from various OEMs (the publicly supported list is on the site). Acceptance is also available via SoftPOS, QR, NFC, payment link, online checkout, Telegram chat (@miaposbot), WhatsApp Business chat (+373 690 02 773), and agent.

### Q7. What is an instant payment?
A real-time, 24/7 account-to-account transfer that moves funds directly between bank accounts without going through a card network.

### Q8. What is an IPS (Instant Payment System)?
A national or regional rail that moves money account-to-account in real time, 24/7. Examples: SEPA Instant in the EU, RoPay in Romania, MIA in Moldova.

### Q9. Is miaPOS aligned with ISO 20022?
Yes. miaPOS is aligned with the ISO 20022 messaging standard used by modern instant payment schemes.

### Q10. How does the merchant actually get paid?
Funds are credited directly to the merchant's bank account, with no card-acquiring intermediary in the flow.

### Q11. What does miaPOS cost?
No card-scheme fees. Per-transaction pricing depends on the partner bank and the acceptance mix. Contact sales@miapos.eu for a quote.

### Q12. How does a merchant get started?
A merchant who already has an account at one of miaPOS's partner banks visits the login page on miapos.eu, selects their bank, and requests credentials from the bank. The bank handles KYC and contracting.

### Q13. How does a customer pay?
The customer scans a QR, taps NFC, or opens a payment link, then confirms the payment in their own banking app. The transfer is instant.

### Q14. Is it secure?
The payer authorises every transaction inside their own trusted banking app. miaPOS never handles card data — there are no cards in the flow at all.

### Q15. Does miaPOS work for e-commerce?
Yes. E-commerce ships in two complementary modes — **hosted checkout** (the redirect flow used by the WooCommerce / OpenCart / CS-Cart plugins and the PHP SDK) and **embed checkout** (a drop-in JavaScript snippet that renders inline on the merchant's own page). The embed snippet is channel-agnostic — the same code runs inside a Telegram Mini App and on landings used for Instagram and TikTok link-out. Payment links cover remote / invoice / receipt scenarios. Both modes share one IP rail and one webhook contract.

### Q16. Who is behind miaPOS?
miaPOS is operated by **Finergy Tech S.R.L.** (HQ Chișinău, Republic of Moldova). EU operations are conducted via its subsidiary **Instapay Tech S.R.L.** (Romania). miaPOS is part of the Finergy Group.

### Q17. Who uses miaPOS?
Merchants who want to accept instant bank payments without running card terminals — retail, HoReCa, services, D2C, e-commerce.

### Q18. Is miaPOS a consumer wallet or app?
No. miaPOS is acceptance infrastructure for merchants. The payer pays from their existing banking app; they don't install anything.

### Q19. Can miaPOS handle recurring payments or Request-to-Pay (RTP)?
These are rail-dependent capabilities. miaPOS supports them where the underlying instant-payment rail provides them; availability varies by market.

### Q20. What is A2A acquiring?
A2A acquiring is the merchant side of instant account-to-account payments: a merchant accepts a payment from the payer's bank account into the merchant's own bank account over the market's instant payment scheme (MIA in Moldova, RoPay in Romania, SEPA Instant in the euro area). The merchant's bank is the A2A acquirer — the acquiring participant of the scheme, holding the licence and the merchant relationship. miaPOS is the acquiring platform: software inside the bank's perimeter that generates the payment request (QR, link, NFC tag or request-to-pay), receives the scheme's confirmation and runs the merchant back office. Unlike card acquiring there is no card scheme, no interchange and no cardholder data; unlike pay-by-bank redirects there is no third-party provider between the bank and the merchant, and it works at the counter, not only online. Full page: https://miapos.eu/en/a2a-acquiring/

---

## 14. Glossary

- **IPS** — Instant Payment Scheme. A national or regional system (e.g. SEPA Instant, RoPay, MIA) that moves funds bank-to-bank in seconds, 24/7.
- **ISO 20022** — The XML-based messaging standard used by modern instant payment schemes; the basis of miaPOS's integration model.
- **SEPA Instant** — The EU's instant payment scheme. Reachable across most euro-area banks.
- **RoPay** — Romania's instant payment scheme.
- **MIA** — Moldova's instant payment scheme.
- **A2A (Account-to-Account)** — Payment directly between bank accounts, without a card scheme intermediary.
- **A2A acquiring** — 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 instant payment scheme. Contrast: card acquiring (card rail, interchange, cardholder data). Adjacent: pay by bank (online redirect over open-banking APIs).
- **A2A acquirer** — The merchant's bank acting as the acquiring participant of an instant payment scheme (RoPay: "acquiring participant"; MIA: "MIA pentru afaceri"). The role is defined by the scheme's rules and the bank's licence.
- **Acquiring platform** — The software that generates the payment request, receives the scheme's confirmation and runs the merchant back office. miaPOS is an acquiring platform inside the bank's perimeter.
- **SoftPOS** — Software-based POS using a smartphone's NFC and screen, no separate terminal hardware required.
- **AP2** — Agent Payments Protocol; emerging standard for AI agents to initiate payments on behalf of users.

---

## 15. Merchant documentation

The seller's guide for the miaPOS terminal app (product UI 1.0.25, document 2.1, 08.09.2026) is published in three languages, one page per language, each with a Markdown mirror at the same path + `index.md`. It covers: terminal activation (standard OTP, simplified, always-ready), signing in and login attempt limits, opening and closing the working day, the Terminal screen and its acceptance channels (QR, payment Link, and the RTP request where the underlying rail provides it), the three QR types (dynamic, static, hybrid) and their amount modes (fixed, controlled range, unspecified), tips chosen by the customer on the QR screen, PF/PJ payer type, transactions and the Requests tab, full and partial refunds, receipt printing and the X/Z reports, QR settings and the time-of-action window, common issues, statuses and a RO/RU/EN glossary. Scan & Pay (outgoing supplier payments) is documented as a feature coming soon.

- EN: https://miapos.eu/en/docs/users/miapos-app/ (Markdown: https://miapos.eu/en/docs/users/miapos-app/index.md)
- RO: https://miapos.md/ro/docs/users/miapos-app/ (Markdown: https://miapos.md/ro/docs/users/miapos-app/index.md)
- RU: https://miapos.md/ru/docs/users/miapos-app/ (Markdown: https://miapos.md/ru/docs/users/miapos-app/index.md)

Screenshots reflect the default Romanian UI; the app supports EN, RO, RU — switchable from Profile → Language.

### MIA Merchant Portal (merchant back office)

The user guide for MIA Merchant Portal — the merchant's web back office — is published in three languages (document 1.0, 12.08.2026), one page per language, each with a Markdown mirror at the same path + `index.md`. The portal is not only a reporting surface: payment links and payment requests are created and sent from it, so a payment can start in the back office as well as at the terminal (request availability is rail-dependent). The guide covers: sign-in by phone number and SMS OTP with no password, the four cumulative roles (admin, manager, reporter, seller) and the sections each of them can open, the dashboard with KPI cards, volume chart, channel split and top terminals, the transaction list across POS, e-commerce and RTP channels with filters, transaction details, CSV export, the tips report and full or partial refunds, online operations — payment links and payment requests including bulk import from a file and import history, disputes with the acquiring bank and the message thread inside a dispute, downloadable reports such as B2B payments, and administration of stores, terminals, sellers, portal users and the merchant profile.

- EN: https://miapos.eu/en/docs/users/merchant-portal/ (Markdown: https://miapos.eu/en/docs/users/merchant-portal/index.md)
- RO: https://miapos.md/ro/docs/users/merchant-portal/ (Markdown: https://miapos.md/ro/docs/users/merchant-portal/index.md)
- RU: https://miapos.md/ru/docs/users/merchant-portal/ (Markdown: https://miapos.md/ru/docs/users/merchant-portal/index.md)

Screenshots reflect the Romanian UI in a 1440×900 browser window with a demo merchant; the portal also runs in Russian and English.

Telegram seller guide for `@miaposbot` (activation, inline-mode payment requests, edit-in-place, FAQ) is published in five languages:

- EN: https://miapos.eu/en/docs/users/conversational/
- RO: https://miapos.md/ro/docs/users/conversational/
- RU: https://miapos.md/ru/docs/users/conversational/
- FR: https://miapos.eu/fr/docs/users/conversational/
- DE: https://miapos.eu/de/docs/users/conversational/

The WhatsApp seller guide is published in three languages. It covers what differs from Telegram: the seller's WhatsApp number is the identity, so there is no activation step; the `pay` command with its optional description and tag, the slash form and the bare-number shorthand; passing the link on to the customer through any channel, because WhatsApp gives business numbers neither inline mode nor groups; payment notifications back in the same chat; the 24-hour messaging window imposed by WhatsApp itself, inside which free-form status messages arrive and outside which the link still works and the money still settles; and the five bot languages.

- EN: https://miapos.eu/en/docs/users/whatsapp/
- RO: https://miapos.md/ro/docs/users/whatsapp/
- RU: https://miapos.md/ru/docs/users/whatsapp/

Terminal activation guides are published in three languages, one per device family:

- SmartOne (install MIA + Palm Payment, permissions, enter IDNO + Terminal ID):
  - EN: https://miapos.eu/en/docs/users/activare-pos/
  - RO: https://miapos.md/ro/docs/users/activare-pos/
  - RU: https://miapos.md/ru/docs/users/activare-pos/
- Sunmi P2 / P3 (video tutorial + text, prep + IDNO + Terminal ID, first payment):
  - EN: https://miapos.eu/en/docs/users/activare-pos-sunmi/
  - RO: https://miapos.md/ro/docs/users/activare-pos-sunmi/
  - RU: https://miapos.md/ru/docs/users/activare-pos-sunmi/

Developer-facing REST API reference for the POS API is published in English only at https://miapos.eu/en/docs/api/pos/ (landing) and https://miapos.eu/en/docs/api/pos/reference/ (interactive Redoc reference generated from OpenAPI v5). All developer-facing technical documentation is English-only by policy.

### 15a. POS API — public contract summary

The POS API is used by hardware POS terminals (Sunmi, SmartOne, Datecs, Ingenico, PAX) and SoftPOS apps to accept payments through miaPOS. Base path: `/pos/api/v1/`. Twenty-five endpoints, six logical groups:

1. **Terminal activation (6):** `POST /terminal-activation/init` · `POST /terminal-activation/otp-resend` · `POST /terminal-activation/confirm` · `GET /terminal-activation/type` · `POST /terminal-activation/simplified` · `GET /terminal-activation/{posActivationId}`
2. **Seller authentication (4):** `POST /seller/login` · `POST /seller/logout` · `POST /seller/refresh` · `GET /seller/info`
3. **Shift management (4):** `GET /shift/check` · `POST /shift/open` · `POST /shift/close` · `GET /shift/{shiftId}/z-report`
4. **Transactions — QR and status (6):** `POST /qr/generate` · `POST /qr/{qrId}/cancel` · `GET /qr/{qrId}/check` · `POST /tx` · `GET /tx/{txId}` · `GET /tx/{txId}/receipt`
5. **Returns / refunds (3):** `POST /tx/return` · `GET /tx/return/reason` · `GET /tx/return/{requestId}/status`
6. **Settings (2):** `GET/PUT /settings` · `GET/PUT /qr-settings`

The flow is: activate the terminal → sign the seller in → open a shift → generate QR / create transactions → close the shift at end-of-day. Authorisation is a Bearer access token acquired by `/seller/login`; `/seller/refresh` rotates the token pair.

A Postman collection with the full request set is published for download at https://miapos.eu/en/docs/api/pos/miapos-pos-api.postman_collection.json, paired with an environment template with placeholders at https://miapos.eu/en/docs/api/pos/miapos-pos-api.postman_environment.json. Neither ships with live credentials, tokens, or host names.

Sandbox environment (base URL, merchant identifier, terminal identifier, operator credentials) is issued per partner during onboarding — public docs do not publish sandbox host or credentials. Contact info@miapos.eu to request sandbox access.

The API is IP-rail only: payments are authorised by the buyer in their own banking app after scanning the QR, so the terminal never touches card data and the merchant has no PCI scope from the miaPOS side.

### 15b. E-comm API — public contract summary

The E-comm API is the merchant-facing REST API for online payments. It powers websites, hosted checkouts, embed checkout, payment links, and the WooCommerce / OpenCart / CS-Cart / PHP SDK plugins. Base path for authenticated business calls: `/ecomm/api/v1/`. The public-key endpoint is at `/api/v1/public-key` (without the `ecomm` prefix). Eight endpoints, four logical groups:

1. **Authentication (2):** `POST /ecomm/api/v1/token` (client credentials → JWT access + refresh), `POST /ecomm/api/v1/token/refresh` (refresh → new pair).
2. **Payment (4):** `POST /ecomm/api/v1/pay` (create payment; supports `Idempotency-Key` header for embed track), `GET /ecomm/api/v1/payment/{paymentId}` (state), `GET /ecomm/api/v1/checkout/{paymentId}` (public, no JWT — for embed browser widget), `POST /ecomm/api/v1/payment/{paymentId}/refund`.
3. **Request-to-Pay (1):** `POST /ecomm/api/v1/request-to-pay/direct` (rail-dependent; availability differs per market).
4. **Public key (1):** `GET /api/v1/public-key` (RSA public key for callback signature verification).

Flow: merchant backend gets a token, calls `POST /pay` with amount and `callbackUrl`, redirects the buyer to the returned checkout URL. On terminal state (SUCCESS / FAILED / refunded), the E-comm service POSTs a JSON body `{ "result": { … payment fields … }, "signature": "<base64>" }` to the merchant's `callbackUrl`. The signature is RSA-SHA256 over the `result` object, produced with miaPOS's private key. Merchants MUST verify the signature against the public key from `/api/v1/public-key` before fulfilling the order — anyone can POST to a public callback URL. Full signature verification algorithm and language examples: https://miapos.eu/en/docs/api/signatures/.

Interactive Redoc reference: https://miapos.eu/en/docs/api/ecomm/reference/ (rendered from OpenAPI v0.0.1 with RTP; partner-specific base URLs sanitized to `[partner-base-url]` placeholders; Redoc bundle served locally). Long-form protocol description with plugin patterns is in the public integration repo on GitHub — `finergy-tech/mia-pay-ecomm-integration`, `docs/en/protocol-overview.md`.

Sandbox base URL and merchant client credentials are issued per partner during onboarding — public docs do not publish sandbox host, credentials, or the interactive demo URL. Contact info@miapos.eu to request sandbox access.

### 15c. Android Intent integration — on-device path for cash register apps

Cash register / ECR apps that run on the SAME Android device as miaPOS (Sunmi terminals, smart POS, merchant tablets) launch miaPOS to accept a payment through the standard Android Intent mechanism. No REST calls on the cashier side, no HTTPS setup, no credentials in the cashier app. Full guide: https://miapos.eu/en/docs/paypoints/pos-android-intent/.

Two builds are published: `md.finergy.miapos` (production release) and `md.finergy.miapos.debug` (development). Every action string and every extra key is prefixed with the app id. Action: `<app_id>.action.MIA_PAY`.

Required request extras (all prefixed with `<app_id>.extra.`):
- `MIA_PAY_REQUEST_ID` — String UUID, cashier-generated idempotency key
- `MIA_PAY_AMOUNT` — Float amount
- `MIA_PAY_CURRENCY` — String, currently `MDL` only

Result extras returned in the Activity result:
- `MIA_PAY_REQUEST_ID` — echoes the request (always)
- `MIA_PAY_STATUS` — String, `success` or `failed` (always)
- `MIA_PAY_TX_INFO` — String JSON `{ amount, currency, date, mcc }` (only on `success`)
- `MIA_PAY_ERROR_REASON` — String enum: `validation_error` / `generate_error` / `expired` / `canceled` / `wait_pay_error` (only on `failed`, enum is open to extension)

Scope: on-device only. Refunds, shifts, receipts and remote / cross-device flows are NOT exposed via Intent — use the POS API for those. Currency `MDL` only at present.

### 15d. E-comm callback + signature verification

The E-comm service delivers every terminal payment result (`SUCCESS`, `FAILED`, refunded) as a signed HTTPS POST to the `callbackUrl` the merchant supplied on `POST /ecomm/api/v1/pay`. Two public pages document it:

- https://miapos.eu/en/docs/api/webhooks/ — delivery mechanics, envelope, response and retry semantics
- https://miapos.eu/en/docs/api/signatures/ — authoritative algorithm and reference implementations

Callback envelope (exactly two top-level fields):

```json
{
  "result": {
    "terminalId":     "123456",
    "orderId":        "order123",
    "paymentId":      "bc340d13-7411-4785-a083-b594b1384eb5",
    "status":         "SUCCESS",
    "amount":         145.25,
    "currency":       "MDL",
    "paymentDate":    "2024-05-20T16:32:28+03:00",
    "swiftMessageId": "swift123",
    "swiftPayerBank": "SomeBank"
  },
  "signature": "base64_encoded_signature"
}
```

The signature is transported INSIDE the JSON body. There are no `X-MiaPos-Signature`, `X-MiaPos-Event` or `X-MiaPos-Delivery` HTTP headers — any documentation elsewhere claiming that is wrong; the site was corrected on 2026-07-07 to match the internal spec.

Signature algorithm:

1. Parse the JSON body; extract `result` and `signature`.
2. Sort the fields of `result` alphabetically **by key**.
3. Concatenate the **values** in that sorted order, separator `;`. This is the canonical string.
4. Base64-decode `signature`. Fetch the miaPOS public key from `GET /api/v1/public-key` (no `/ecomm/` prefix) — response: `{"publicKey": "<Base64 X.509 SubjectPublicKeyInfo>"}`.
5. Verify with `SHA256withRSA` (RSASSA-PKCS1-v1_5 + SHA-256) using the decoded public key, over the UTF-8 bytes of the canonical string, against the decoded signature bytes.

For the reference payload above the canonical string is deterministic:

```
145.25;MDL;2024-05-20T16:32:28+03:00;order123;bc340d13-7411-4785-a083-b594b1384eb5;SUCCESS;swift123;SomeBank;123456
```

Reference implementations published on the site: Java (`java.security.Signature.getInstance("SHA256withRSA")` + `TreeMap`), Python (`cryptography.hazmat.primitives.asymmetric.padding.PKCS1v15` + `hashes.SHA256`), PHP (`openssl_verify` with `OPENSSL_ALGO_SHA256`), Node.js (`crypto.createVerify('RSA-SHA256')`). All four sign the canonical string, NOT the raw request body.

Response semantics: return `2xx` to acknowledge. Non-2xx responses and timeouts are retried by the E-comm service — callbacks are effectively at-least-once, so make the handler idempotent (short-circuit on repeat `paymentId` in a terminal state already processed). Terminal statuses in `result.status`: `SUCCESS`, `FAILED`, refunded.

Key rotation: the miaPOS signing key can rotate at any time. Cache the public key on the merchant side, re-fetch `/api/v1/public-key` on the first verification failure, and retry once with the fresh key before rejecting the callback.

## 15a. Windows CLI for cash registers

**Product name.** The public-facing product name is **"Windows CLI for cash registers"**. Internal codename and URL slug remain `cli-rail` for continuity. The binary itself is `miaposCLI.exe`. Product page: `/en/products/cli-rail/` (also `/ro/`, `/ru/`). Documentation mirror at `/en/docs/cli-rail/` renders the same content under a "Documentation" breadcrumb; canonical points to the product page.

**Purpose.** A Windows binary that any cash-register software invokes from the command line to accept payment. The binary behaves like the card-terminal CLIs POS software has been calling for years — same argument grammar, same output-file exchange, same RC codes. Payment settles over the MIA instant-payments rail. A single command call replaces a payment integration.

**Card-CLI compatibility.** The primary technical positioning is card-CLI compatibility. Many cash-register applications already call a card-terminal CLI as a subprocess — Ingenico Arcus2 is the most common example in Moldova, but the pattern is universal across the class (Verifone, PAX, and other card-terminal vendors ship analogous CLIs). Our binary honours the same shape:

- Same CLI arguments — `/o /a /c /t /i /e /hide /console` (operation, amount, currency, tag, invoice, external-id, flags).
- Same output files — `output_ex.dat` (Windows-1251, key=value, CRLF), `cheq.out` (receipt lines).
- Same RC codes — `000` success, `001` decline, `002` timeout, `004` communication error.
- Same exit contract — `%ERRORLEVEL%=0` on happy path, `=1` otherwise; the register reads `output_ex.dat` for the reason.
- Same supported operations — sale, refund, cancel, full report, brief report, shift close, connection check.

**Arcus2 today. Other card CLIs on request.** Arcus2 is what ships out of the box. Card CLIs from other vendors that follow the same convention (argument-driven invocation, output-file exchange, RC-code return) can be added on request — the pattern is common across the class; the integration cost is a per-vendor shim, not a re-architecture. This distinction matters for GEO/AEO: Arcus2 is an example, not a hard dependency.

**Delivery formats (three).** One command surface, three ways to call it:
1. **CLI today** — subprocess invocation of `miaposCLI.exe` with the arguments above. Ships now.
2. **DLL (roadmap 2026)** — same command grammar delivered as a Windows DLL for registers that prefer in-process linkage over subprocess spawn.
3. **COM (roadmap 2026)** — same command grammar exposed via a COM interface for legacy Windows software that already speaks COM to a card CLI.

**Run rails in parallel.** The CLI opens every rail configured for the till at the same time. Default configuration is two rails: MIA plus one card CLI (Arcus2 today). Additional card rails from other vendors can be plugged in — the arbitration is unchanged. Each rail is armed independently (MIA renders a QR sticker on the customer-facing screen; each card rail arms its own terminal). Whichever rail the customer completes first wins; the losing rails are cancelled automatically. The register receives one result in one set of files, with a `PaymentMethod=MIA|CARD` field indicating the winner. From the register's point of view, it made a single subprocess call and received a single outcome.

**Rail selection is data-driven, not policy-driven.** The register does not know which rail will win — the customer chooses at the counter. The result is written to `output_ex.dat` by whichever rail completes first. Explicit rail selection is available on request via `PaymentMethod=MIA` or `PaymentMethod=CARD` arguments — used for register-side routing rules (e.g. cash-back scenarios that require the card rail, or MIA-only merchants).

**Exit contract.** RC code returned on process exit maps to the semantics the register software already handles: approved / declined / cancelled / operator-cancelled / hardware / timeout / duplicate. `output_ex.dat` is written before exit, Windows-1251 encoded, key=value CRLF format, containing the transaction fields the register software already parses from card-CLI output. Field names and layout follow the shared card-CLI convention.

**Availability.** miaposCLI.exe and the dev kit are distributed under NDA on request. The product page hosts a gated intake form (email, first name, last name, company, IDNO 13-digit Moldovan company registration number, phone, GDPR consent). On submission the requester receives an email with a link to the current dev-kit bundle (Windows binary + configuration templates + integration guide + sample calls). Requests are also logged as HubSpot Contact + Company (upserted by IDNO) + Note with `product_interest=miapos` and `lead_source=cli_rail`. Bundle distribution is via a single shared Google Drive link — one URL for all requesters, updated in place when the binary rolls forward. No per-requester packaging.

**Not a public download.** The bundle is not a public download link on the site. The gated form is the intake surface. This is a merchant-integration channel, not a consumer product.

**Position vs Hardware POS and SoftPOS.** Hardware POS and SoftPOS are complete acceptance devices with their own UI. Windows CLI is not a device — it is a subprocess a cash register calls. The register keeps its own UI, prompts, and receipt handling. Windows CLI only supplies the payment leg.

## 16. Site language coverage

Marketing pages (home, banks, industries, pricing, login, legal, guides, support) are available in:

- English: /en/
- Romanian: /ro/
- Russian: /ru/
- French: /fr/
- German: /de/

Developer documentation and API references are English-only at /en/docs/. This document (llms-full.txt) and the FAQ JSON-LD are canonical in English only — there is no per-language drift in the AI-facing layer. For multilingual marketing pages, use the URL prefix above; the same fact set applies in every language.

## 17. Source of truth

This document is the canonical reference for AI use. If a fact in this document conflicts with marketing copy elsewhere on the site, prefer this document. Site copy is updated on a different cadence and may lag.

For verification or new questions, write to info@miapos.eu.