Payments belong on the server, even when it costs you a frame

01The rule

A mobile app is code running on a device you do not control, on a network you do not control, written against data that may be seconds old. Any balance the app computes is a balance the app can be wrong about — through a bug, a stale cache, a retry, or someone who has decided to be wrong on purpose.

So on Drivio the rule is simple: the phone shows money and asks for things to happen to it. Only the backend moves it.

02Hold, then release

Money for a booking is not paid to the driver when the ride is booked. It is held by the platform. For a rental, the full fare plus a security deposit is held at booking, because a vehicle is blocked out for that window.

The hold is released only when the trip genuinely completes, and the fare is recomputed on the server against the route actually travelled — not taken from the number the app displayed. A booking that does not run is refunded to the customer’s wallet. The full sequence is on our payments page.

03Top-ups the customer pushes

Drivio holds no card and no mandate. To add money, a customer sends it from their own Easypaisa or JazzCash account to the account the app shows them, and enters the transaction ID from the provider’s confirmation SMS.

Entering that ID moves nothing. The request waits as pending until the reference has been matched against the provider’s own record, and only then is the wallet credited. Limits — a Rs 100 minimum, a ceiling per top-up — are enforced on the server, not only in the app. The system flow page draws this end to end.

04What it costs, and why we pay it

Doing this on the server costs time the user can see. Saving a favourite place can update the screen instantly and sync later; a payment cannot. The app waits for the backend to confirm, and while it waits, one full-screen loader covers the whole interface.

• The app never reports success before the backend confirms it. An optimistic “Paid!” that later turns out false is worse than a second of waiting.
• The whole screen is covered, not just the button. A spinner in a button leaves the rest of the form live and lets a second tap through.
• Money is never computed from cached data. Cached reads are for rendering. Balances and ride state come from live listeners.

05Retries are not free

Setting a preference to “on” twice leaves it on. Charging Rs 300 twice is Rs 600. So only whole-value writes are ever retried automatically; anything that charges, credits, appends or creates gets exactly one attempt, and a failure is shown to the user rather than repeated behind their back.

06If you are building one

The same rules apply to any app that moves money — marketplaces, delivery, bookings, subscriptions. We build these systems for other businesses too; see ride-hailing app development or the full Drivio customer journey.