Scan to Charge

The brief asks for iOS and Android. We think that is the wrong first build, for two reasons. First, an app is an unnecessary and underused cost: you pay for two separate builds, two store listings and their ongoing maintenance, for something a customer opens a handful of times a year. Second, and deeper: the customer's phone is nearly dead. (For the phone that is fully dead, see the optional card reader in part fifteen.) That is the defining condition of this product and it appears in no other. Ride hailing, food delivery and banking can all afford to ask for an install, because the customer's phone is fine. Ours is at four percent, in a café, on unfamiliar wifi, and the person holding it is anxious.

Asking that person to visit a store, download forty megabytes, open the app, create an account and grant permissions — before they can begin renting — is the highest-friction moment any product could choose. And at launch there is no installed base, so every rental in the first months is a first-time user hitting that wall.

And the obvious objection — will Mongolians actually do this? — is already answered, every day, in car parks across Ulaanbaatar. You scan the QR on the barrier, type your plate number, pay in whichever banking app you already have, and the barrier lifts. Nobody downloaded anything to park.

The other way to test it is to ask what apps are actually for, and check each reason against this particular product.

The car park proves the behaviour — that people here will scan a code and pay in their bank app to make a machine do something. China proves the business model, in this exact product category rather than a neighbouring one.

Five parts, three channels. The cabinet's 4G module is a dumb pipe: the MCU speaks 0xA8 hex frames over a serial line and the module tunnels them out unchanged. Every decision — which bank to eject, when an order opens, what it costs — happens in our backend.

The parking-gate pattern: scan, authorise, the thing opens. The user never installs anything and never has to come back to our page for the slot to release.

The whole customer-facing surface, shown in Mongolian as the customer would see it. Your own email calls the product «Повер банк», so the product name is yours to set.

The customer pushes the bank into any free slot in any station and walks away. The cabinet recognises the bank by its own serial number and tells us — we already know whose order that serial belongs to. Nothing to scan, nothing to type, nothing to open.

Two instruments are ruled out rather than chosen. A refundable deposit, because taking a returnable balance means holding customer funds — Mongolbank licensing territory, plus refund operations forever. And a pre-authorisation hold, because freezing the value of a power bank to rent an hour of one would screen out most of the market. What remains is prepayment: pay the first block, then keep paying as you go.

The chart below shows how the mechanism behaves, not what it should cost. Every figure on it is a dial — part eight lists them.

QPay is what Mongolians actually reach for, and it is a one-time invoice rail: it raises a charge the customer approves now, and it cannot charge them again later — no recurring, no one-click. SocialPay is the same shape.

So a metered rental on that rail would mean raising a fresh invoice every single hour and asking the customer to approve each one in their banking app. Nobody would tolerate that, and it would multiply our transaction fees by the length of the rental. Credits invert the order. The customer authorises once, buys a balance, and the meter draws it down. One approval, many hours.

Roughly half of all failed charges are insufficient-funds soft declines — the card is valid, the customer is not disputing, the money just was not there at that moment. This is the ordinary case, not the edge case, and the design has to assume it. An exhausted credit balance is the same event by another name.

Here is the scenario that matters. Someone rents at ₮1,000 an hour. The first hour is funded. An hour later the card declines, or the credits run out. They forget about it and return the bank two days later. What happens next depends entirely on one design decision.

Everything above is mechanism: how money is authorised, when the meter runs, what happens when it stops, how an order closes. None of it fixes an operating price. The table below is every commercial parameter the system exposes, what it controls, and what it trades against — we build all of them configurable, and none of them is ours to choose.

Reference for the dials above, not a recommendation. Every operator converts an unreturned bank into a sale rather than chasing it — only the window and the number differ, and the spread between them is wide enough to show there is no single right answer.

Three contracts carry the parts we do not build ourselves. Bonum resolves what had been the critical-path unknown: recurring card payments are available in Mongolia, which means the card path is buildable rather than hypothetical.

The workload is genuinely small. A hundred cabinets produce one telemetry post every twenty minutes each and a handful of MQTT messages per rental — thousands of requests a day, not millions. Nothing here needs scale.

Availability is the constraint, not capacity. If the backend is down nobody can rent anything, anywhere, and cabinets that cannot reach us reboot themselves on the nine-minute heartbeat. That argues for a managed database with real backups and more than one application instance — not for a bigger box.

The brief asks for four things: station status, reports, configuration and coupons. That describes a dashboard. Running a fleet needs an operations tool — a dashboard tells you something is wrong, operations lets you fix it, and the distance between the two is most of this build.

The largest gap in the brief is that it tracks stations and not power banks. The banks are the asset, the inventory and the entire loss exposure. Each one has to be a first-class object with a serial, a location, a cycle count, a health reading and a state — and the single most important screen in the whole system is the list of banks that are out, sorted by how long they have been gone.

This is worth saying plainly before anyone signs anything: a power bank network is a logistics business with a software layer, not a software product with some hardware attached. Every station is a physical object in somebody else's building. The console we build makes the work visible and efficient; it does not remove any of it.

The division is clean and it belongs in the contract. We build and run the software. Everything below is the operator's, and most of it needs a person in a vehicle.

Everything above assumes the phone still works well enough to open a camera and load a page. At zero percent it does not — and that person wants a power bank more than anyone else in the building. Every competitor running an app or a QR code alone loses them completely.

A payment terminal on the cabinet closes it. Make a selection, tap a card, take a power bank. No phone involved at any point.

Every phase ends in something you can watch happen, not in a status report. Those demonstrations are the payment triggers, which means the risk of a phase sits with us until it visibly works.

And the riskiest work goes first. The usual instinct is to build the app early because it is the visible part; here the genuine unknown is a Chinese cabinet responding to our commands, so that is what we prove in week three rather than month four.

Your brief asked for the cost split by design, frontend, backend and integration. That is the same total sliced a second way — every figure below is included in the range above, not additional to it.

And the recurring costs, which your brief also asked about. These are separate from the build and continue after it.

One number carries this: net contribution per rental. Divide the investment by it and you have the number of rentals needed. Everything else is only how quickly those rentals arrive.

None of these are dealbreakers, and Bonum has removed the biggest one. What remains are contract terms and configuration — answers that move the number rather than the design.