Designated Driver Bill Confirm and Offline Collection

A designated-driver trip ends twice: once at the curb, and again when someone marks money as settled. If those moments disagree, you inherit screenshots, chargebacks-in-spirit and drivers who refuse evening shifts. “Just add more payment options” is not a design. Bill confirm, clear pay paths and go-online gates are.

Ptaxi’s designated driver app documents driver bill confirm with add-ons, then passenger pay, driver pay-for-passenger, or offline collection via the driver’s payment QR with manual confirm. It also documents balance reserve checks before go-online and an optional rule that payment QR upload is required to go online. Treat the list below as what a serious admin should show in a demo — including ours — and run one drunk-Friday payment drill before launch.

What bill confirm is for

When the driver marks arrival at destination, they confirm the fare and can enter highway, bridge/road and parking add-ons that match the real trip. Only then does a payment path start. Skipping confirm — or letting drivers freestyle amounts in chat — destroys audit trails.

Admin switches matter:

• Online / passenger pay path available at confirm
• Driver pay-for-passenger available at confirm
• Cash / offline path available (implemented as show QR + driver marks paid)

Turn paths off that your market cannot reconcile. A switch left “on” because it looked complete in a feature matrix is how finance weekends die.

Path 1: passenger pays

After confirm, the bill is pushed to the passenger app. The passenger pays with documented methods: balance and online pay (local online wallets as configured). For overseas buyers, read that as in-app balance plus the online rails your deployment enables — not as a promise of card networks the feature lists never name.

Why this path is usually preferred:

• Clear ledger line for the trip
• Platform commission can apply after passenger payment per company settings
• Fewer “I already paid him cash” arguments

Why it still fails: passenger phone battery, payment app limits, or a rider who wants to disappear. You need a fallback that is intentional, not improvised.

Path 2: driver pays for the passenger

The driver advances the fare using their own balance or online methods, then settles with the passenger out of band or later. Driver wallet top-up (including optional top-up packages with bonus amounts where configured) exists so drivers can float that advance.

Trade-offs:

• Faster curb exit when the passenger cannot pay in-app
• Driver credit risk moves onto your wallet design
• Withdrawal review and any income freeze period still apply before cash leaves the platform

If drivers routinely advance fares without a reserve rule, you will meet empty wallets at 2 a.m. That is why go-online gates exist.

Path 3: offline QR collection

The driver shows a payment QR; the passenger pays offline; the driver manually confirms that payment happened; the order ends. Documented driver profile flows include uploading that QR. Admin can require the upload before go-online.

This is not “cash under the table with no record.” It is a documented offline path with a confirm step. Still:

• Train drivers never to confirm paid before money actually lands
• Use abnormal-order / dispute tools when a rider claims they paid and the driver disagrees
• Expect commission and ledger behavior to differ from a clean passenger online pay — verify the tenant rules in finance UAT

Do not invent tip lines, card-present terminals or named processors. Stick to wallet, online pay and this QR offline path.

Balance reserve before go-online

Two related controls appear in designated-driver settings:

1. Insufficient reserve → cannot go online / cannot take orders when wallet balance is below the configured reserve.
2. Optional QR required to go online so offline collection is even possible.

Related reading: designated driver online balance and heatmap for the supply side of “why is nobody green?”

Set the reserve with a worked example: one typical night of driver-pay-for-passenger advances plus a buffer. Too high and supply vanishes; too low and advances bounce. Announce changes early — drivers treat a new reserve like a pay cut.

Pricing context that hits the same bill

Bill confirm sits on top of the pricing plan: base, distance, time, long-distance, waiting, period cycles and optional preferential mileage-stage prices. Fixed-price switches may apply when enabled. Minimum estimated mileage gates can block junk short trips before a driver ever rolls.

Multi-driver booking (more than one driver on a request) multiplies settlement complexity — see designated driver multi-driver and preferential pricing. Do not let a second car share one ambiguous QR confirm story.

Cancel rules and who can kill the bill

Passenger cancel rules can charge an at-fault fee when a driver was already assigned. Admin can cancel before the driver confirms the bill. After money moves, you need refund / abnormal-order discipline, not a second cancel button fantasy.

Merchant-assisted booking with merchant commission is a separate acquisition path; settlement still needs the same honest bill confirm when the trip ends. Link ops playbooks so merchant desks do not invent a fourth payment ritual.

Safety is not payment — keep them separate

Passenger one-tap emergency / police dial and admin alarm records belong in the safety story. They do not mark a bill paid. Trip sharing helps friends follow the car; it does not replace QR confirm. Keep training modules from mixing “press emergency” with “press paid.”

Checklist for a payment UAT night

1. Confirm bill with and without add-ons; passenger pays from balance.
2. Passenger cannot pay; driver uses pay-for-passenger; wallet drops; withdraw later under review.
3. Offline QR path: upload QR, go online, show QR, mark paid, order closes.
4. Driver below reserve cannot go online; top-up restores access.
5. QR-required flag on: new driver without QR blocked; after upload, allowed.
6. Dispute: rider claims paid, driver disputes — abnormal-order handling leaves an audit trail.
7. Invoice minimums and paper/electronic invoice flows still make sense for riders who need receipts next morning.

Commission after the money moves

Platform commission is configured per company and affiliated drivers; once the passenger (or the chosen path) completes payment, allocation follows that ratio. Offline QR confirms still need a finance story: what hits the ledger, what stays out-of-band, and how withdrawal review sees the night. Run commission reports for each of the three paths in UAT — passenger pay, driver advance, offline QR — and keep screenshots in the launch packet.

Income freeze periods (when enabled) delay withdraw eligibility after earning. Announce freeze windows beside reserve rules so drivers do not treat a healthy balance as immediately cashable.

Heatmap and listen checks are not payment — but they change collection

If nobody is online because reserves blocked go-online, offline QR never appears. Heatmaps that show online / on-trip / waiting counts help ops see whether a “payment problem” is actually a supply gate. Listening detection (network, location permission, go-online state) reduces false “driver ignored the bill push” tickets when the phone was never ready to work.

Merchant desks and face-to-face scan

Merchant-assisted booking and passenger scan of a driver QR for face-to-face order creation are acquisition tools. They must still land on the same bill-confirm menu at destination. Write one internal one-pager so merchant hosts do not invent a fourth settlement custom.

Close

Designated-driver money fails at confirm, not at marketing. Ship passenger pay, driver advance and offline QR as explicit paths, gate go-online with reserve (and QR when you need it), and train one Friday script until dispatch can recite it.

Describe how your city actually settles tonight — mostly in-app, mostly offline, or mixed — and we can map configuration on designated driver app versus custom work. Contact us.