Challenge
A payment kiosk is an awkward machine to write for. It stands unattended, swallows paper money, loses its connection, jams its note acceptor, and is serviced by someone with no time to read a manual.
And it holds cash. Every note has to be counted twice, every collection recorded, and any gap between the counter and the cassette has to surface before the site owner mentions it.
Solution
The kiosk software and the billing were written as one system rather than an application with an admin panel bolted on.
A terminal keeps working when the line drops: the payment is taken locally, queued, and delivered once the channel is back. The customer sees a clear status instead of a white screen.
Billing counts each device separately, then rolls up into a view of the network where the owner can see which terminal earns, which one idles, and which one no longer adds up.
Architecture and implementation
What the system is made of:
· kiosk software with a touch interface that runs offline
· cash acceptance with double counting and protection against re-crediting
· a payment queue with guaranteed delivery to the server
· per-device billing with tariffs, fees, entries and cassette balances
Collections are reconciled against the note acceptor's own counters, and device health is watched remotely. The protections people usually add after their first loss were in from the start.
Result
The network grew to fifty terminals in Andijan on a single billing system. Three things meet in work like this: hardware, physical cash, and an accounting system of your own. A web studio never gets that experience, and without it any conversation about payment infrastructure stays theoretical.
