Designated Driver Go-Online: Wallet Balance Reserve and Payout QR Gates

Designated driving fails in public when the trip ends and nobody can collect. The passenger wants to pay in cash-like offline fashion. The driver has no payout QR on file. Or the driver wants to cover the fare from wallet tools and the balance is already dust. Those are not “soft skills” problems. They are go-online policy problems that should have stopped the shift before the first accept.

Ptaxi’s designated driver app documents two related gates on the driver home: a wallet balance reserve that can block go-online when funds are too low, and an optional requirement to upload payout QR codes before go-online. This article is for overseas operators evaluating those switches — framed as reserve and QR payout rails, without China-only channel packaging.

Go-online is a financial state, not only a GPS state

Listening checks cover network, location permission and out-for-hire flags. That is necessary and incomplete. A driver who is “green” on GPS but broke on wallet will still accept work, then stall at bill confirm.

Documented home controls:

• Go online / go offline for accepting jobs.
• Backend can block accepting / going online when wallet balance is below the reserve.
• Drivers may upload payout QR codes; backend can refuse go-online until those uploads exist.
• Optional health declaration on first daily go-online when that switch is enabled.

Heatmaps that show online, on-trip and waiting driver counts only help if “online” means financially ready. Otherwise your map lies cheerfully.

An earlier overview of balance-plus-heatmap thinking lives at designated driver online balance and heatmap; here the focus is the go-online gate design and how it pairs with bill confirm.

Setting the reserve without guessing

The reserve is a number ops chooses. Too low and it never fires. Too high and honest part-timers never start the evening. Base it on the money paths you actually enable:

• If driver pay-on-behalf is on, the wallet must cover realistic fare sizes in your city.
• If offline QR collection is the common path, the reserve can be lower — but then the QR upload gate matters more than the cash buffer.
• If both paths are on, size the reserve for the pay-on-behalf case; treat QR as the offline backup.

Revisit the number after the first month of bill-confirm disputes. Finance will see whether failed pays cluster on thin wallets. Dispatch will see whether go-online blocks create artificial scarcity at peak. Those two reports should argue with each other in the open.

Payout QR codes as a go-online ticket

Offline collection only works if the driver can show a payout QR and then manually confirm that the passenger paid. Documented personal info on the driver side includes payout method fields and uploading those QR codes. Business switches can treat missing uploads as a hard stop before go-online.

For overseas readers: think “payout QR codes the passenger can scan with the local payment apps you support,” not a single brand story. The product point is require evidence of a receivable channel before the shift, then allow offline confirm at bill time.

Training notes that prevent street chaos:

• Drivers update QR images when they change payout accounts — stale codes create chargeback-shaped arguments even when your software never touched a card network.
• Ops spot-checks a sample of uploads; a blank image that passed a careless required-field check is worse than no gate.
• Bill confirm UI must make “show QR / confirm paid” obvious so drivers do not invent a side ledger in a chat app.

How bill confirm uses the gates you set

After arrival, the driver confirms the fare and can add highway, bridge or parking amounts when reality differs from the estimate. Payment choices documented for designated driving include:

1. Passenger pay — push the bill to the passenger for online settlement.
2. Driver pay-on-behalf — driver uses balance or available online methods to cover the passenger.
3. Show driver QR — passenger pays offline; driver confirms; order ends.

If you enabled the QR go-online requirement, path 3 is populated. If you enabled the reserve, path 2 is less likely to bounce mid-shift. If you enabled neither, you are hoping manners will substitute for configuration.

Related reading on the money ending of the trip: designated driver bill confirm and offline collection.

Other switches people confuse with the reserve

Income freeze before withdrawal is a different control: earnings wait a holding period before a withdraw request. It protects against hit-and-run fraud patterns; it does not replace a minimum balance at go-online.

Cash / offline pay as a business switch decides whether offline collection appears at confirm. Pair it with the QR upload rule so the switch is not an empty promise.

Minimum mileage on passenger estimates blocks tiny trips from being placed. That is demand shaping, not driver solvency.

Authentication review still sits in front of service: drivers submit materials (including whether prior designated-driving experience and other docs are required — backend controlled). A verified but under-reserved driver is still blocked at go-online if you configured the reserve. Keep those stages distinct in onboarding copy.

Ops checklist before a nightlife launch

Run this once with a real driver test account:

1. Set reserve to a known value; attempt go-online below and above it.
2. Enable QR-required; attempt go-online with empty uploads, then with valid images.
3. Complete one passenger-pay trip, one pay-on-behalf trip, one offline QR trip.
4. Attempt withdrawal with freeze rules on and off so finance sees the difference from the reserve.
5. Watch heatmap counts while a cohort is blocked — confirm ops messaging does not say “no demand” when you actually created a policy outage.

Write the passenger-facing apology once: “Driver temporarily unavailable; we are assigning another.” Do not expose wallet internals to riders.

What not to promise

• Do not invent bank cards, Stripe or tips as designated-driver payment rails; documented passenger pays are the configured online methods plus balance, with driver-side offline QR confirm as above.
• Do not claim the reserve auto-tops up from a linked card.
• Do not frame go-online gates as mini-program or official-account features on overseas pages.
• Do not treat SOS / emergency dial details as a substitute for collection policy; keep safety tooling generic and local-number configurable if discussed at all.

Merchant-assisted volume and the same gates

Merchant-assisted booking (store staff placing rides with merchant commission) can spike designated-driver demand near restaurants and bars. Those trips still land on the same driver go-online rules. If merchants generate volume while half the roster is blocked for missing QR uploads, the merchant sees “no drivers” and blames supply — not your unpaid onboarding homework.

Keep merchant rollout behind the same reserve and QR drills. Commission to merchants does not relax driver wallet policy; it only adds another stakeholder who will call ops when the map looks empty.

Close

Go-online on a designated-driver network is a solvency check as much as a location check. Configure a wallet balance reserve that matches pay-on-behalf reality, require payout QR uploads when offline collection matters, and drill bill confirm until all three pay paths are boring. Scarcity you create on purpose beats collection fights you invent by accident.

If you share typical fare sizes and whether offline pay is common in your city, we can map reserve and QR gates on designated driver software. Contact us.