Carsharing Unpaid Orders: Half-Hour Auto-Cancel and the Fee Stack

Idle reservations are expensive. A passenger taps through a beautiful car card, leaves pay unfinished, and your supply looks busy while nothing moves. Drivers stare at a hall full of ghosts. Owners ask why the asset is “booked” with no money.

On Ptaxi’s carsharing system, checkout is explicit: confirm the fee stack, pay, and if pay never lands, the unpaid order only keeps about half an hour before auto-cancel. This line is car-plus-driver sharing per confirmed capabilities — not a keyless P2P hardware protocol sheet. Stay in that frame and the timeout rule makes sense.

What “carsharing” means on this product line

Confirmed capabilities §4 describe:

• Passenger qualification (personal info + license) and violation prepay deposit concepts.
• Find cars by place/time with filters.
• Order pay with base / service / insurance / driver fees; unpaid auto-cancel after half an hour.
• After driver accept: pick up vehicle → serve → return.
• Driver hall, qualification review, wallet withdraw paths.
• PC: vehicle import, live location, pricing (weekday/weekend/holiday, service, insurance, driver fees), commission, withdraw review, invoices, driver review, alarm management.

If a buyer wants pure peer-to-peer unlock-with-phone and no driver, this is the wrong brochure. Say so early. The half-hour cancel rule protects a driven service inventory, not a scooter dock.

The fee stack passengers must see before pay

Confirm order shows:

• Base fee
• Service fee
• Insurance fee
• Driver fee

Admin pricing sets those components with weekday / weekend / holiday variation by vehicle type. That transparency is the antidote to “why is this more than the card price?” tickets. Hide a driver fee until after accept and you will earn chargebacks and one-star reviews that blame the app instead of the quote.

Train support to read the four lines aloud. If a city waives insurance marketing-wise, that is a commercial choice — the product still knows the line items exist in configuration.

Half-hour unpaid cancel: why the clock is short

Unpaid holds compete with real demand. Thirty minutes is long enough to switch wallet apps or fix a balance; short enough that a abandoned checkout does not warehouse a car+driver slot all afternoon.

Ops implications:

• Checkout UX must make pay obvious. If passengers think “save for later” is free inventory lock, they will hate the cancel — and they should, because free locks were never the product.
• Rebook must be cheap cognitively. After auto-cancel, same search criteria should be one or two taps away so honest payers recover.
• Driver hall stays cleaner. Drivers should not accept or psychologically reserve unpaid ghosts. Pay-first (within the window) keeps the hall closer to real work.
• Reporting: track cancel-for-nonpay separately from passenger-initiated cancels that may carry fees after free windows. Different problems.

Passenger cancel rules (free window vs fee window) still exist for paid/active orders. Do not conflate unpaid auto-cancel with passenger cancel policy. One is pay timeout; the other is change-of-mind after the order is alive.

Lifecycle after money clears

Once paid, the order generates and waits for driver accept. Driver path:

1. Accept from hall / order list.
2. Reach vehicle pickup point; contact owner; confirm pickup.
3. Go to passenger start; passenger confirms trip start.
4. Passenger confirms trip end; driver returns vehicle; owner confirms end after inspection.

Abnormal paths include contact owner / passenger / support and emergency / police dial as documented — phrase overseas copy as emergency / police dial, not a China-only number brand. Complaints and ratings follow completed work.

PC order detail still carries basics, logs, fee detail, trip track, complaints, push logs. Use that when a passenger swears they paid but the hall never saw the job — money and state belong in logs, not in chat guesses.

Qualification and deposits sit beside the timer

Passengers complete use qualification (personal info + license). Violation prepay deposit concepts appear on the line. Those gates reduce joyride risk; they do not replace the unpaid timer. A qualified passenger who never pays still loses the hold at half an hour. A paid passenger who failed qualification should never have reached a durable hold — keep onboarding order sane in your launch runbook.

Pricing admin that matches the stack

When you configure vehicle-type plans, set weekday/weekend/holiday bases and the service / insurance / driver components together. Commission allocation after pay follows platform commission settings. Withdrawal review on the driver wallet closes the money loop for supply.

If insurance fee is zeroed in a test tenant, label the demo so buyers do not think production quotes omit coverage lines by magic.

What not to invent in marketing

• No Bluetooth peer unlock protocol claims.
• No flight-tracking add-ons.
• No tip marketplace.
• No card/Stripe-only story; use in-app wallet / local wallet options documented for the tenant.
• No WeChat mini-program lead for overseas pages (source docs mention mini-program customer channels in places; overseas product narrative stays on app + PC).

Inventory math for owners and platform ops

Every unpaid open order is a soft block on a vehicle+driver narrative even if the hard lock is light. Owners judging the platform by “busy but unpaid” will churn. Publish an internal metric: unpaid open count by hour, and unpaid auto-cancel count by hour. If cancels cluster at minute 30 exactly, pay UX is friction — fix wallet entry, not the timer. If cancels cluster earlier because users bounce, your fee stack may be shocking; revisit weekday vs weekend driver fee clarity.

Alarm and complaint paths are not payment tools

Documented abnormal operations include contact channels and emergency / police dial, plus complaints after service. Do not teach passengers to use SOS as a “my pay failed” hotline. Keep payment recovery in wallet/billing support. Keep emergency dial for emergencies. Mixing those channels burns trust with responders and with your own alarm-management queue on PC.

Commission and withdraw after a clean pay

Once pay succeeds, platform commission allocation and later driver withdraw review follow the usual PC finance path. Unpaid cancels should never create commission ghosts. If your reports show commission on canceled unpaid orders, that is a reporting bug to fix before a partner audit — not a feature.

Launch script for a new city

1. Configure fee stack for two vehicle types across weekday/weekend/holiday.
2. Place a test booking; abandon pay; confirm auto-cancel near half an hour; screenshot logs.
3. Place a paid booking; walk driver hall accept through return confirm.
4. Verify invoice / withdraw paths on a completed job.
5. Brief support on unpaid cancel vs passenger cancel fee rules as separate macros.

Buyer questions that separate real builds

Ask any vendor:

1. Show confirm screen with base / service / insurance / driver fees.
2. Start a booking, do not pay, watch auto-cancel near thirty minutes (or show the configured timer in admin + logs).
3. Prove the post-pay path is driver accept → vehicle pickup → passenger service → return confirm.
4. Confirm you are buying car-plus-driver, not a hardware telematics kit.

Ptaxi’s carsharing docs answer those four without slide fiction. The half-hour unpaid cancel is a small sentence with large inventory consequences — treat it as a first-class ops control, not a footnote under “payments.”