Carsharing Qualification, Violation Deposit and Fee Stack Explained

Buyers hear “carsharing” and picture unlocking a hatchback with a phone. Ptaxi’s carsharing system is a different product: a car booked together with a driver who collects, serves and returns the vehicle. The overview that separates it from self-drive rental is carsharing: car-plus-driver vs self-drive. This article digs into the three controls that decide whether the line is operable — qualification, violation deposit and the fee stack — plus the driver order hall that keeps supply moving.

Qualification before search

Customers complete a driving-qualification check (personal information and driving licence) before the hire path is useful. That is not decorative KYC for a slide. The car is someone else’s asset; the platform needs a verified renter identity before money and keys move.

Pair qualification with safety settings you already know from other lines: emergency contacts and real-name options where you require them. Do not confuse this gate with driver verification — drivers have their own licence submission and admin approval before they can take hall orders.

If qualification is optional in a demo, ask whether that is a test switch or the production default. Production should fail closed.

Violation deposit is working capital for risk

After qualification, the customer pays a violation prepayment (violation deposit). Documented purpose: cover post-trip vehicle violations, overtime-style problems and related issues. The passenger wallet views show that deposit alongside top-up, withdrawals, bills and invoicing.

This is different from store-rental vehicle deposits and violation deposits on the self-drive line, though the economic idea rhymes. Here the deposit sits on a car-plus-driver hire where the customer is not always the person who physically opened the door with a smart lock.

After trips, customers can look up violations in the app. Ops need a clear path from “violation found” to “deposit applied or topped up” without a private spreadsheet. If that path is missing, finance will invent one.

The fee stack: four lines, not a meter

At confirm-and-pay, the order shows base fee, service fee, insurance fee and driver fee. Unpaid orders only hold for a short window (documented as half an hour) then auto-cancel — inventory and driver attention should not freeze on abandoned carts.

Admin pricing plans set charges by vehicle type: weekday, weekend and holiday prices, plus service, insurance and driver fee components. Platform commission, coupons, withdrawal review and invoicing sit beside that plan. This is not taxi starting-fare-plus-distance logic, and it is not store-rental deposit-plus-daily logic. Train sales and support on the four lines so quotes match the screen.

When you demo, change one component (driver fee on weekends) and show the passenger estimate update. If the estimate ignores the plan, you do not have a pricing engine — you have a brochure.

Driver order hall and collect-return

Drivers pass driving-qualification verification before service. The order hall lists passenger hires that still need a driver. Accepting a job starts the physical choreography:

1. Reach the vehicle pickup address; contact the owner; confirm collection.
2. Drive to the customer; customer starts the hire in the app.
3. Serve the period; customer ends the hire in the app.
4. Return the car; owner inspects and closes.

Abnormal paths — contact owner, customer or support; emergency calling; complaints — belong in the same demo, not in a footnote. Alarm records in admin are useless if nobody staffs them.

Driver wallet and withdrawal flows still matter; hall drivers will not stay if payout screens are opaque. Live vehicle location and import tools on the admin side keep the map honest while cars move between owner, driver and customer.

Owner handoffs are part of product quality

The collect and return steps depend on the owner answering the driver. Build owner contact into the happy path and into exception handling. If owners are unreachable, hall drivers idle and customers wait — your rating screens will record the failure even if the app did nothing “wrong.”

Customer ratings for car and driver, plus post-trip violation lookup, close the quality loop. Admin alarm management should be staffed like any other SOS queue: records without response train customers to ignore the button.

Coupons, commission and withdrawals

Coupons and campaigns can discount the passenger price; commission still needs a defined split afterward. Driver withdrawals go through admin review — same discipline as ride-hailing wallets. Income clarity on the driver side keeps the order hall populated; opaque balances empty it faster than low base fares.

Invoices (paper or electronic via the platform’s invoicing path) matter for corporate-style hires even on a car-plus-driver product. Set minimum invoice amounts deliberately so support is not drowning in tiny requests.

Search, filter and unpaid holds

After qualification and deposit, customers search nearby cars by place and time, then filter. The estimate must show the four fee lines before pay. The unpaid hold window (about thirty minutes) should be visible so customers are not surprised when a reserved car returns to the pool. Support scripts should mention that hold when someone says “I paid later but the car vanished.”

How to configure without confusing self-drive buyers

Keep product language strict in proposals. Self-drive unlock, flash/horn and scan-to-rent live on car rental software. Car-plus-driver qualification, violation deposit, fee stack and order hall live on carsharing. Bundling both is fine commercially; blurring them in one paragraph creates refunds.

A practical setup order for a new city:

1. Import vehicles and publish pricing plans with all four fee lines.
2. Approve a small driver set; watch hall accept latency.
3. Run qualification + deposit on test customers; expire an unpaid order on purpose.
4. Complete one collect-serve-return with owner confirmation and a violation lookup.
5. Withdraw a driver balance through admin review.

Staffing the hall at launch

Seed the order hall with enough approved drivers before opening passenger acquisition. An empty hall makes perfect fee stacks look broken. Watch accept latency by hour; chauffeur-style evening peaks need different coverage than weekday corporate hires.

Vehicle import accuracy (plates, types, photos) affects both passenger filters and owner trust at collect time. Live maps that show stale positions create arguments at the curb — treat location freshness as an ops metric, not only an engineering one.

If you also run store self-drive rental, train support to ask “with driver or without?” on the first reply. Misrouted tickets between car rental and carsharing waste the deposit conversation.

Schedule a dry run with one owner, one driver and one customer account before any public launch. Time each handoff. If collect-to-customer takes longer than your estimate assumes, fix ops before you buy more ads.

What we do not claim here

This is not a P2P hardware unlock protocol list. Map vendor brands, card networks and unverified “smart key” partnerships are out of scope unless your contract adds them. Overseas pages should not lean on China-only messaging channels.

Write the passenger estimate explanation in plain language (“driver fee” versus “service fee”) so support is not reinventing definitions in chat.

If you are buying for car-plus-driver hire, insist on seeing qualification, deposit, the four-part estimate and a live order-hall accept in one sitting. Start with the carsharing system page, then /contact/ with your vehicle types and whether owners or the platform hold the cars.