A Windows CLI for cash registers.
A single command on the till PC. Runs the MIA rail and any card CLI your register already speaks — in parallel, in the shape POS software has always called.
A CLI your register already knows how to call.
Not a middleware. Not an SDK you have to learn. A single Windows binary that behaves like the card-terminal CLIs cash-register software has been calling for years.
What it is. miaposCLI.exe — a compact Windows binary on the till PC. The register software calls it with a single command (miaposCLI.exe /o1 /a15000 /c498 /eORDER-42), reads the outcome from a standard file, and prints the receipt. Sale, refund, cancel, report, shift close — the same operations card-CLI integrations already handle.
How it works. The cashier hits one button. The customer scans a QR sticker with their banking app (maib, MICB, Eximbank, ECBank, or any MIA participant). Payment settles in seconds. Receipt prints at the till. One process call, standard output files.
Who it's for. POS software vendors. Integrators who install cash registers at merchants. Merchants with in-house IT who want to add MIA acceptance to an existing till. If your software already calls a card-terminal CLI, this fits the same slot.
How your register calls it.
One command surface. Three delivery formats — CLI today, DLL and COM as the pilots ask for them.
| Format | Interface | Available |
|---|---|---|
| CLI | miaposCLI.exe /o<op> /a<amount> … + output_ex.dat / cheq.out / response.json files |
Today |
| DLL | C-callable, MiaPosPay(amount, …) — one synchronous call |
Roadmap 2026 |
| COM | COM object with .Exchange() — for .NET / VBA integrators |
Roadmap 2026 |
Same command grammar in all three. Ship the format that fits your register's integration surface.
Card-CLI compatibility. Arcus2 first.
Many cash-register applications already call a card-terminal CLI — Ingenico Arcus2 is the most common example in Moldova. Our binary honours that shape, so it slots in wherever the card CLI already sits.
- Same CLI arguments —
/o /a /c /t /i /e /hide /console - Same output files —
output_ex.dat(Windows-1251, key=value, CRLF) andcheq.out - Same RC codes —
000success ·001decline ·002timeout ·004communication error - Same exit contract —
%ERRORLEVEL%=0on happy path,=1otherwise; readoutput_ex.datfor the reason - Same supported operations — sale, refund, cancel, full report, brief report, shift close, connection check
Beyond Arcus2. 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 shim is the integration cost. Arcus2 is what ships today.
Integration into an active pilot: under one dev-day.
Run rails in parallel.
One CLI call, multiple rails opened at the same time. First to complete wins. The register receives one result.
The cashier launches one payment. The CLI opens every rail configured for that till in parallel: MIA generates a QR sticker on the customer-facing screen; each card rail arms its own terminal. Whichever the customer touches first wins — scan the sticker or insert the card.
The winning rail writes to output_ex.dat. The losing rails are cancelled automatically. Your register receives one result in one set of files, with a PaymentMethod=MIA|CARD field indicating the winner. The cashier UX doesn't change.
Two rails by default — MIA plus one card CLI (Arcus2 today). Extra card rails from other vendors can be added; the arbitration is the same — first winner takes the result.
QR sticker
rail #1] CLI --> R1[Card Rail
Arcus2 today
rail #2] CLI --> RN[Card Rail
other vendor
possible
rail #N] M --> O[output_ex.dat
RC=000
PaymentMethod=MIA CARD] R1 --> O RN --> O -->