One command from the till to a paid receipt.
A Windows binary that drops into any register software already speaking Arcus2. Same call, same output files, same RC codes — payment settles over MIA.
A binary that fits where Arcus2 used to fit.
CLI Rail is the Windows-integration channel of miaPOS. Not a middleware, not an ecosystem — a single executable that runs on the till PC and speaks the same protocol Arcus2 already speaks.
What it is. miaposCLI.exe — a compact Windows binary that runs on the till PC. The register software calls the CLI 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 operations you already know from Arcus2.
How it works. The cashier hits one button. The customer scans the QR sticker on the counter with their banking app (maib, MICB, Eximbank, ECBank, or any other MIA participant). Payment settles in seconds. The receipt prints at the till. All of it through a single process call and the same output files Arcus2 already writes.
Who it's for. POS software vendors. Integrators who install cash registers at merchants. Merchants with their own IT team who want to add MIA acceptance to an existing till. If your software already integrates Arcus2, CLI Rail is a drop-in.
Three integration paths.
CLI today. DLL and COM later, when the pilots ask for them.
| Path | 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 |
Drop it in where Arcus2 lives.
If your register software already calls CommandLineTool.exe for card acceptance, adding miaPOS is a path swap. No new file formats, no new callback shapes, no new error codes.
- 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
Integration into an active pilot: under one dev-day.
Two rails. One result.
In dual-rail mode, CLI Rail runs the MIA rail and the Arcus2 card rail in parallel. The customer picks. The cashier does nothing new.
The cashier launches one payment. The CLI opens both rails at the same time: MIA generates a QR sticker on the customer-facing screen; Arcus2 arms the card reader. Whichever the customer touches first wins — scan the sticker or insert the card.
The winning rail writes to output_ex.dat. The losing rail is 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.