How Drivio works, and where Easypaisa fits
Drivio is the mobility platform Manwaj Solutions (Pvt) Ltd builds and operates. This page is the whole system drawn out — the applications, the backend behind them, what happens to money through a booking, and the two points at which a mobile-wallet rail touches any of it. Five diagrams, each with its description written out separately underneath.
Two crossings, and no third.
This is the short answer to the question this page exists for. A mobile-wallet rail meets Drivio at exactly two points, and both of them are a person deciding to move their own money.
Description — what diagram 01 shows
The top-up is the customer or the rider pushing money from their own Easypaisa account into their own Drivio wallet. They open their Easypaisa app, they send the amount, and they tell Drivio the transaction reference afterwards. Drivio is not a party to that transfer while it happens — it is an ordinary Easypaisa payment from one account to another.
The withdrawal is the reverse, and the only direction in which Drivio itself initiates anything: a wallet holder asks for their balance back, and Drivio sends it to the Easypaisa number they gave.
Between those two points the money is a number in a Drivio wallet. No rail is touched by a booking, a fare, a cancellation, a refund or a commission — all of those move value between wallets inside the platform, and none of them reach Easypaisa at all. That is why the diagram has two arrows rather than twenty.
Four surfaces, one backend, one door to the outside.
Drivio is two mobile applications and an operations console, on a shared backend. Everything about how the money behaves follows from where the backend sits in this picture.
Description — what diagram 02 shows
- Customer app
- Android. Booking, live tracking, the wallet, receipts and history. It can ask the backend to do things; it cannot change a balance.
- Rider app
- Android. Offers, navigation, earnings and documents. Same constraint: it asks, it does not write.
- Drivio backend
- Cloud Functions over Firestore, and the only thing in this picture that can change a balance. Security rules make wallets, transactions and payments unwritable by any client, and every balance change runs inside a database transaction that either completes whole or not at all.
- Drivio operations
- A person. They approve top-ups against the provider’s record, clear withdrawals, review rider documents and handle disputes. They work through the backend like everyone else — the console is a client too.
- Easypaisa · JazzCash · bank
- Outside Drivio, drawn dashed for that reason. Only operations deals with them, and only for the two crossings in diagram 01.
The shape matters more than the components. Because no client can write to a wallet, there is no version of this system in which a bug in the app, or a modified copy of it, moves someone’s money. The worst a client can do is ask, and every ask is checked server-side against the same rules.
A top-up, step by step.
This is the flow a payment partner is really assessing. Read step 4: the transfer is made by the customer, in their own Easypaisa app, to an account Drivio published on their screen. Drivio does not initiate it and could not.
Description — what diagram 03 shows
- 1 · Wallet → Add money
- In the Drivio app. The wallet shows the available balance, anything currently held against a live booking, and the full history.
- 2 · Choose the rail and the amount
- Easypaisa or JazzCash. Rs 200, Rs 500, Rs 1,000 and Rs 2,000 are one tap; any other whole-rupee amount can be typed. Minimum Rs 100, maximum Rs 1,000,000 — both enforced on the server, not only in the app.
- 3 · The app shows where to send it
- Drivio’s own account number for the chosen rail, and the exact amount. It is shown in the app rather than published on a web page, so the destination a customer reads came from an account they logged into.
- 4 · The customer sends the money
- From their own Easypaisa app, or by dialling *786#. This step happens entirely outside Drivio — it is why the box is dashed. Nothing in Drivio can cause it, delay it or repeat it.
- 5 · They enter the transaction ID
- Back in the app, from the Easypaisa confirmation SMS, optionally with the number they sent from. That reference is what makes the payment matchable.
- 6 · The request queues as pending
- Recorded, visible to the customer, and worth nothing yet. No balance has moved.
- 7 · Drivio matches it, then credits
- A person checks the reference against the provider’s own transaction record. On a match, the wallet is credited in a single database transaction with a ledger row naming the rail and the reference. If it cannot be matched it is rejected with a reason and the customer is notified — and since nothing was ever pulled, nothing has to be given back.
The manual check in step 7 is deliberate, and it is the part worth pausing on. It means a Drivio balance is always an amount somebody demonstrably sent, rather than an amount somebody claimed to have sent — which is the property that makes the rest of this page safe.
Where the money sits at every stage.
Every service in the app runs through these stages. What differs between them is only how much is held, and when — so the diagram is the stages, and the table underneath is the per-service answer.
Description — what diagram 04 shows
A held amount has left the customer’s spendable balance and has not reached anybody else. It sits against that one booking, and it can only go two ways: to the rider when the trip genuinely completes, or back to the customer when it does not. The platform’s own commission comes out at completion and never before.
Nothing is held before the price is shown. Every service prices itself in full — route, distance, duration, the fare per vehicle class — before the button that books it exists, and that button names the total it is about to charge.
What each service takes, and when
- Ride Now
- Nothing is taken up front. The fare settles at the end of the trip — cash handed to the driver, or charged to the wallet. A cash ride instead holds the DRIVER’s own platform charge out of the driver’s wallet when they accept, so the platform is never chasing a fee it can no longer collect.
- Pool
- The full seat price, plus the customer security deposit, is held at booking. A reserved seat is one the driver turned other passengers away from, so it is paid for before it is reserved.
- Rent
- The full rental fare, plus the customer security deposit, is held at booking — a vehicle is blocked out for that window. The rider posts their own security deposit when they accept, so both sides have something at stake.
- Pickup & Drop
- One period at a time. The month being booked is held at booking and stays held for that month; each new period holds the next one. A subscription is never charged further ahead than the month it is paying for.
- Parcel
- The full delivery total is held at booking, and released to the rider when the parcel is delivered.
Completion and cancellation
- The trip completes
- The fare is recomputed server-side against the route actually travelled, the held amount is released, the rider is paid the fare net of the platform’s charges, and any security deposit goes back to whoever posted it. An itemised receipt stays in the customer’s history.
- Cancelled before a driver is assigned
- Free. Nothing is charged, and anything held is released back to the wallet it came from.
- Cancelled after a driver is assigned
- A cancellation fee applies and the remainder is released. The exact amount is shown before the cancellation is confirmed, and the same fee applies to a driver who cancels on a customer — the rule is symmetric. The percentage is set by an administrator per service, so it is not quoted here; the app is what charges it.
- None of this touches Easypaisa
- Releases, refunds, fees and commissions all move value between Drivio wallets. A rail is only involved when someone tops up or withdraws.
A withdrawal back to Easypaisa.
A balance belongs to the person holding it, and it leaves by the same kind of rail it arrived on. This is the only flow in which Drivio initiates a transfer.
Description — what diagram 05 shows
- 1 · The balance
- Whatever is spendable in the wallet — a rider’s earnings, or a customer’s unspent top-ups and refunds.
- 2 · The request
- The holder names an amount and a destination: an Easypaisa number, a JazzCash number, or a bank account with its title. Minimum Rs 100.
- 3 · Debited immediately
- The balance is reduced the moment the request is submitted, and a pending ledger row records it. The same money cannot be spent on a booking while a withdrawal for it is outstanding.
- 4 · Cleared by hand
- An administrator reviews and clears it. There is no automatic disbursement — no scheduled job pays anybody.
- 5 · The transfer
- Sent to the account named in step 2, outside Drivio. The ledger row flips from pending to settled.
If a request is rejected, the debit in step 3 is reversed and the balance returns. The customer keeps the full history either way.
Four things that cannot happen here.
These are not undertakings anyone has to be trusted to keep. They follow from the five diagrams above: a platform with no instrument to debit and no client write access has no mechanism with which to take anything.
- Drivio holds no card, no mandate and no standing instruction, so it has no mechanism with which to debit anybody.
- Every rupee that enters a wallet was pushed by its owner, from their own Easypaisa or JazzCash account.
- No balance moves until a person has matched the transfer against the provider’s own record.
- Clients cannot write to wallets, transactions or payments — security rules forbid it, and only the backend has the keys.
If you would rather read it than look at it.
The same money flows written out in full, including the amounts, the limits and what happens when a top-up cannot be matched.
The customer journeyNine stages from installing the app to the receipt, with screens from the shipped application at each one.
Refunds & cancellationThe written policy behind stage 06 of diagram 04 — what is refundable, to where, and inside what window.
- Questions about any of this
- support@manwajsolutions.com
- Phone
- 0371 2339498
- Hours
- Monday–Saturday, 10:00 AM – 7:00 PM (PKT)
- Operated by
- Manwaj Solutions (Pvt) Ltd