Designated Driver Scan Booking at Venues: Face-to-Face Orders Beside One-Tap and Merchant Assist

Bar exits and hotel porte-cochères still finish with a nod. The guest points. The designated driver nods back. Money moves. Then morning ops asks where the trip went, and the night manager invents a story. Scan-to-order is the logged path for that handshake: driver shows QR, passenger scans in-app, the venue trip becomes a real designated-driver order instead of a cash-only memory.

On Ptaxi’s designated driver app, passenger flows document scan against the driver’s QR for face-to-face booking, one-tap call into dispatch range, and merchant-assisted booking with merchant commission. Driver home includes a QR control. For App users, scanning uses the built-in in-app scan. This piece is about when venues should push scan vs one-tap vs merchant desk—and how to keep payment claims inside documented WeChat / Alipay / balance / offline QR collection. For fixed-price vs metered stacks that still settle those trips, see fixed price vs metered. For waiting fees at pickup when the guest is slow leaving the lobby, pair with waiting fees at pickup.

The venue problem scan actually solves

One-tap is great when the guest is still inside with a pin. It is awkward when they are already standing beside the driver the doorman just waved over.

Typical pains scan booking is meant to blunt:

1. Hotel door staff fill the next designated driver by hand; the trip never appears in reports.
2. Bar security walks a guest to a waiting driver; commission and complaint trails go missing.
3. Ops bans off-app curb deals in slides, then leaves no logged alternative for face-to-face hail.
4. Merchant partners want desk control some nights and curb speed other nights—without two settlement religions.

Scan is not a replacement for matching. It is the logged path for *already matched by geography and eye contact*.

What the documented flow actually says

Passenger side: scan can read the driver’s QR and place a face-to-face order. Driver side: home QR presents the code. App path: built-in scan inside the passenger app. Merchant path: staff place on behalf of the guest; after completion, merchant commission follows configured rules.

Say those sentences in launch workshops. Do not invent a WeChat-only overseas story—demo the App in-app scan path for buyers outside China packaging.

Walk the demo in order:

1. Driver goes online and opens QR.
2. Passenger uses in-app scan.
3. Order appears as a normal designated-driver trip for that driver.
4. Complete through bill confirm with a documented pay path (passenger pay, driver advance where enabled, or offline QR collection when you allow it).

If any step feels like theater, fix training before you print QR posters for the valet stand.

How scan sits next to one-tap and merchant assist

Documented passenger paths also include one-tap call (dispatch within configured push distance) and merchant-assisted booking.

Train venue leads with a simple rule:

• Guest is indoors or across the lot → one-tap / scheduled-style booking under your time rules.
• Guest is at the open door with that driver → scan booking.
• Venue desk owns the guest relationship and wants commission → merchant assist, not a fake scan.
• Guest called support and never saw a driver → desk/admin path, not curb theater.

Mixing those scripts creates “I scanned but nobody came” tickets when the real failure was a desk order still waiting in matching. Keep the scripts on one card at the host stand.

Driver and venue staff habits

QR only works if the screen matches a driver who can take the trip.

Documented driver home already ties into go-online / go-offline, heatmap, listening detection, and balance / payout-QR gates you may enable before go-online. Use those as preconditions:

• Present QR only while online and able to accept.
• Do not flash a personal payment code and call it “platform scan.”
• After scan, stay in the in-progress order surface.
• If listening or balance gates block go-online, fix those before blaming the guest.

Venue coaching, 30 seconds:

1. Open the passenger designated-driver app.
2. Use the app’s built-in scan.
3. Confirm the driver details that appear.
4. Keep the trip in-app through arrival and pay / bill flow.

Do not teach “just use the phone camera and hope.” Overseas App deployments documented here rely on in-app scan.

Payment claims that stay honest

Confirmed payment surfaces for designated driver include WeChat, Alipay, and balance, plus bill-confirm paths for passenger pay, driver advance where enabled, and offline collection via the driver’s presented QR when cash/offline modes are on.

Safe coaching lines:

• Online: WeChat / Alipay / balance as configured.
• Offline nights: driver QR collection with manual confirm when that mode is enabled.
• Merchant nights: merchant assist + configured commission—not a whispered side cash pile.

Do not name Stripe, bank cards, or credit cards. Those are not in the confirmed lists. Do not invent tip products either.

Ops tradeoffs to say out loud

• No scan path: curb hail stays off-system; venue audits fail.
• Scan only, weak driver training: dead screens and personal payment codes; guests never complete in-app scan.
• Scan + one-tap + merchant scripts: each door has a job; support stops inventing a “venue special” refund religion.
• Scan with no bill-confirm QA: scanned volume rises while confirm quality falls.

Practical notes:

• Put QR next to go-online in driver onboarding.
• Measure scanned trips that reach bill confirm, not scans alone.
• Align merchant commission reports with completed merchant-assisted orders so partners trust the desk path.
• Keep complaint playbooks identical to app-hailed designated-driver orders.

Merchant nights vs curb nights

Some venues want the desk to own every guest. Others want the curb to move faster than a tablet queue.

Practical split:

• Merchant assist when the host takes the guest’s phone number, places on their behalf, and expects configured commission after completion.
• Scan when the guest already chose a waiting driver and both parties are face to face.
• One-tap when the guest is still inside and matching should find the next available driver in range.

Do not let merchant staff “scan for the guest” on the driver’s personal payment QR and call it platform scan. That recreates the off-app economy you are trying to close.

After-scan bill confirm habits

Once the order exists, treat it like any other designated-driver trip: waiting rules at pickup if the guest is slow, documented fare stack (fixed-price or metered), and bill confirm with passenger pay, driver advance, or offline QR collection when enabled. Scan is an entry door. It is not a separate refund religion.

Measure scanned trips that reach confirm. If scan volume rises while confirm quality falls, pause venue posters and fix driver go-online and listening hygiene first.

What this is not

• Not a claim that scan replaces one-tap matching or merchant desks.
• Not WeChat-mini-program-only packaging for overseas—document and demo App built-in scan.
• Not 95128 / dial-110 product packaging. If you discuss safety elsewhere, stick to documented surfaces without China-hotline theater on this post.
• Not tips, Stripe, bank cards, named map vendors, or fake venue logos.
• Not a duplicate of fixed-price vs metered pricing explainers—link those when the question is fare stack, not entry door.

Soft next step

If hotel and bar curbs still vanish from the ledger, open driver QR, walk a guest in-app scan, and complete bill confirm once online and once offline-QR if you enable it. When a venue lead can choose scan vs one-tap vs merchant assist without inventing a fourth path, you are ready to roll designated driver app venue booking without a second off-app economy.