Designated Driver Collection QR: A Go-Online Gate for Offline Settlement

A designated-driver trip can go fine until the last thirty seconds. The passenger wants to settle offline. The driver has no collection QR on file. Dispatch starts screenshot duty while a tired customer waits at the curb. That is not a manners problem. It is a go-online problem that should have been caught before the first accept. Ptaxi’s designated driver app documents a specific gate: drivers can upload a collection QR, and admins can require that upload before the driver is allowed to go online. Source docs name WeChat/Alipay QR for the file the driver uploads. For overseas framing after that mention, treat it as a collection QR or local wallet QR used for offline settlement—not as a pitch for one country’s payment brands.

This article stays on that gate. It is not a rewrite of the wallet-reserve go-online rule, which already has its own playbook at go-online balance reserve. It is not a full tour of bill confirm, which already lives at bill confirm and offline collection. Those posts remain the place for reserve thresholds and the complete end-of-trip money path. Here the question is narrower: why a collection QR can be a condition of going online, and how that file later supports offline settlement.

Why offline settlement needs a file before the shift

Designated driving still includes nights when the passenger pays the driver directly. The product does not pretend every trip will clear through an in-app passenger payment. If you allow that offline path, the driver needs a collection QR ready before they take work—not after the drop-off argument starts.

Typical pains this gate is meant to blunt:

1. A driver goes online, finishes a trip, and only then discovers they never uploaded a QR.
2. Two drivers show two different unofficial codes from a camera roll, and the passenger no longer trusts the charge.
3. Ops turns on cash or offline collection at bill confirm, then learns half the night rank has an empty profile.
4. Training mixes the QR upload with the wallet reserve, so people think a funded wallet replaces a missing collection code.

The documented driver home makes the upload part of going out for hire. Drivers go online to take orders or go offline to rest. Beside that control, the list says a driver can upload the collection QR, and the backend can set a rule that the driver cannot go online until the upload is done. That is a readiness check. It does not collect the fare by itself. It only answers whether the offline path will have something to show later.

A neighboring go-online limit can also block a driver whose wallet balance is below a configured reserve. Keep that sentence on the reserve article. A funded wallet helps when the driver advances the fare. A collection QR helps when the passenger pays the driver offline. Asking one file to do both jobs is how Friday night gets confused.

Where the driver uploads the QR

The driver personal center is the profile home for this file. Documented driver info shows avatar, name, phone number, withdrawal method, and the upload for the collection QR. The same screen lets the driver change phone number or unbind a withdrawal method.

Teach the distinction in one breath:

• Withdrawal method is how the driver later takes money out of the wallet.
• Collection QR is what the driver can show so a passenger can settle offline.

Do not train people to paste a code into a dispatcher chat and call it “on file.” The documented upload lives on the driver profile. If a substitute image lives only in a group thread, the go-online check cannot see it, and bill confirm cannot rely on it.

Driver verification is still a separate door. Applicants complete verification and wait for review before they can serve. Extra document rules belong with document requirements. A verified driver can still be blocked from going online if your collection-QR requirement is on and the profile upload is empty. Verification answers “may this person work here.” The QR gate answers “is this person ready to collect offline tonight.”

Health declaration, heatmap, and listening-status checks also sit on the driver home. They judge health upload, area demand, and whether network, location permission, and go-online parameters look normal. They do not replace the QR file.

How the QR shows up at bill confirm

Requiring the file at go-online only makes sense if you know what happens at the curb. After the driver confirms arrival at the destination, they confirm the bill and may add highway, bridge or road, and parking amounts that match the real trip. Documented payment methods at that moment include:

1. Passenger pay. After the amount is confirmed, the bill is pushed to the passenger app for online payment.
2. Driver advance. The driver pays on the passenger’s behalf using balance or the documented online methods.
3. Show the driver’s QR. The passenger pays offline. The driver manually confirms that the passenger has paid, and the order ends.

Admin business settings include a matching cash payment path: when the driver confirms the bill they can choose that cash-payment method, using the uploaded collection QR for offline collection. Online payment and driver advance sit on the same settings list as their own switches. You can allow one, two, or all three paths. The collection-QR go-online gate is what keeps the third path from being empty.

Do not invent an automatic “the system saw the scan, mark paid” workflow. The documented offline path ends with the driver confirming payment manually. Do not invent a platform-held escrow for that QR transfer. The source language is offline collection. Do not invent card, tip, or processor names the designated-driver lists do not include.

If the night is really about add-ons, pay-on-behalf, and the full bill-confirm drill, send people back to the bill-confirm article. This page only needs enough of that drill to explain why the go-online upload exists.

Ops tradeoffs to say out loud

• Allow offline collection and leave the QR upload optional: more drivers get online on night one; more drop-offs stall when someone has nothing to show.
• Require the collection QR before go-online: fewer empty profiles at the curb; more support tickets from drivers who have not prepared the file yet.
• Require the QR but never turn on the cash or show-QR bill path: you gated a file nobody will present. Drivers will ask why the upload matters.
• Turn on show-QR collection but confuse it with the wallet reserve: funded drivers still fail offline settlement; under-funded drivers still fail pay-on-behalf.

Practical notes that match the surfaces:

• Decide with finance whether offline collection is a real production path. If it is, turn on the upload requirement before the first busy weekend.
• Show drivers the personal-center upload in onboarding, not in a curbside voice note.
• When a driver cannot go online, ask two separate questions: is the collection QR uploaded, and is the wallet reserve met?
• When a passenger pays offline, the driver still has to confirm payment on the bill. The QR is the collection rail, not an auto-complete.

Fixed-price versus metered pricing, appointment reminders, and minimum mileage are different cards. They change whether a job can be placed or how it is priced. They do not create a collection QR.

What this is not

• Not a rewrite of the wallet-reserve go-online rule or the full bill-confirm playbook. Those posts already cover those paths.
• Not a claim that every market must use the wallet brands named in the source docs. After that one-time source mention, overseas teams should talk about a collection QR or local wallet QR for offline settlement.
• Not WeChat mini-program booking, official-account booking, or a local emergency short-code pitch.
• Not bank cards, credit cards, tips, or named card processors.
• Not an automatic legal receipt, tax form, or proof-of-scan workflow the lists do not describe.
• Not driver document verification, health declaration, or income freeze. Freeze is a withdrawal-timing rule, not a QR gate.

Launch sequence sales can repeat

1. Open the driver personal center and point at the collection-QR upload next to withdrawal method. Name the difference.
2. Toggle the admin rule that blocks go-online when the QR is missing. Show a profile with no file, then show the same driver after upload.
3. Open bill confirm and name the three methods: passenger pay, driver advance, and show the driver’s QR for offline collection.
4. Point at the cash-payment business switch that uses the uploaded QR for offline collection.
5. Mention the wallet reserve as a second, separate go-online gate, then stop so the demo does not melt into one “money settings” blur.

If a buyer says “our passengers always pay in the app,” you may leave the requirement off. If they also say “except on Friday, when they don’t,” you already know why the gate exists.

Soft next step

If your designated drivers still go online with nothing to show at drop-off, require the collection QR before out-for-hire and keep passenger pay, driver advance, and show-QR collection as separate bill-confirm choices. When a lead can demo that gate without mixing it into wallet reserve or inventing a card processor, you are ready to run the designated driver app on nights when offline settlement is still part of the work.