Takes card machine payments
The amount goes from the till to the terminal, so the cashier never types it twice.

One till takes the sale and the card payment, updates the stock and sends the invoice to MRA EIS. Each invoice’s state shows beside its sale.

Each step hands its result to the next, so nobody types the same sale twice and the day’s report agrees with the till.
This workflow is a concept. Live behaviour depends on the current MRA requirements, the payment provider and the hardware in use.
See how invoices reach MRA EIS
The cashier scans, takes the payment and prints the receipt on one screen. Prices, stock and VAT come from the same record.
The amount goes from the till to the terminal, so the cashier never types it twice.

Approved, declined and cancelled payments each show plainly, with the terminal reference kept on the sale.
We check the current MRA requirements with you and map sales, returns, corrections and outages.

Each invoice is built from its sale and sent to MRA EIS. Its state shows beside the sale.
Signing keys stay on the server, never on the till, and every failure has a set recovery step.
What shop owners ask about the till and the invoices.
Ask your own question
That depends on the payment provider and the terminal model. We check both in the consultation, before planning the build.
We plan for it: sales go on, invoices wait in a queue and are sent when the line returns, within the current MRA rules.
Yes. Returns, voids and corrections are mapped in the first step, so each one produces the right document.
A walk through the counter, a list of what you sell and how customers pay, and the person who closes the day.
What this page shows is our design for the flow. Your build follows your scope, your provider and the current MRA requirements.