Carsharing Fee Stack and Realtime Vehicle Location

Search “carsharing software” and you will get keyless maps, Bluetooth essays and P2P marketplace pitches. Ptaxi’s documented carsharing line is different on purpose: it is car-plus-driver rental. A driver takes the vehicle, serves the passenger, returns it for inspection. If you needed unmanned unlock, that is the store car rental software smart-lock path — not this fee stack.

This article stays inside what the carsharing docs actually configure: the fee stack, half-hour unpaid cancel, weekday / weekend / holiday pricing cycles, vehicle import and realtime location. For model choice context, see car sharing app development: B2C vs P2P.

The fee stack riders must see

On confirm, the passenger reviews:

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

Then pays. Hiding the driver fee until after accept is how trust dies in a car-plus-driver product. Show the stack early; keep labels stable across seasons even when amounts change.

Admin pricing plans set those pieces per vehicle type, including weekday, weekend and holiday (and related calendar) rates plus service, insurance and driver fee fields. That is your “surge” substitute: calendar cycles and type rates, not an undocumented dynamic black box.

Platform commission on completed pay splits company/driver shares per configuration. Withdrawals still pass admin review. Invoices exist for riders who need them. None of that replaces a clear pre-pay breakdown.

Half-hour unpaid cancel

Unpaid orders retain for about thirty minutes, then auto-cancel. Inventory is a car and a driver plan, not only a pin on a map. Holding a slot all afternoon for a abandoned checkout punishes the next customer.

Related cancel rules still apply after pay: free-window versus at-fault cancel fees. Do not conflate unpaid timeout with post-pay cancel policy — train support on both scripts.

Qualification and violation prepayment / deposit happen before shopping the map; details live in carsharing qualification and deposit fees. A timed unpaid cancel does not refund a deposit philosophy you never explained.

Calendar pricing without theater

Weekday versus weekend versus holiday rates exist because utilization and labor differ. Practical notes:

• Publish examples in driver and passenger help, not only in admin.
• Change holiday tables before the holiday, not during the first surge of tickets.
• Bind plans to vehicle types so a van and a sedan do not silently share one driver fee.

Time-period thinking from other mobility lines (base/distance/time components) is a cousin, not a copy-paste. Here the headline is the four-part stack plus calendar cycles.

Realtime location and vehicle import

Admin fleet tools documented for this line:

• Vehicle list with site, type and detail
• Bulk import via downloadable Excel template + upload
• Realtime location of vehicles
• Vehicle types bound to pricing

Live location answers ops questions: is the car where the last return claimed? Is supply clustering on the wrong side of town? It is not a rider-facing “radar toy” claim, and it is not a hardware protocol certificate.

Trajectory and order detail fields support after-the-fact review when a trip went wrong. Pair location with the driver order hall workflow — carsharing driver order hall workflow — because a pin without an accepting driver is still idle revenue.

Driver side: why the fee stack must fund labor

Drivers certify, enter the order hall, pick up the car, reach the passenger, run start/end confirms, return for owner/store inspection. Their willingness tracks whether the driver fee and commission math clear fuel and time. If you discount driver fee to win passenger conversion, watch order-hall accept rates the same week — not next quarter.

Violations, invoicing and payouts after return are their own mess; see carsharing violations, invoicing and payouts.

Payments and what not to invent

Passenger pay uses documented online methods and balance patterns consistent with the platform family. Do not add gratuity lines, card brands or processors the feature lists omit. Overseas marketing copy should say balance and local online pay — not a domestic wallet brand tour.

SOS, where documented on this line, is emergency / police dial with admin alarm records. It does not close a fee dispute.

Operator checklist

1. Configure type-level plans: base, service, insurance, driver fees × weekday/weekend/holiday.
2. Place a test order; confirm the passenger sees the same four lines before pay.
3. Abandon checkout; confirm auto-cancel near the half-hour mark frees the slot.
4. Import a batch of vehicles from the template; spot-check types and sites.
5. Open realtime location during a live order-hall shift; match pins to driver reports.
6. Complete one full loop: accept → pickup car → passenger start/end → return inspection → withdraw review.
7. Write one help article that states unpaid timeout and post-pay cancel side by side.

Find, filter, then price

Before the stack appears, riders pass qualification (profile + license) and violation prepayment, then find cars by place and time and filter by site, type, brand, seats, distance and price. The fee stack only works if search inventory matches what import and location say is real. Ghost cars with pretty prices create refunds, not GMV.

After pay, the order waits for a driver accept; the driver picks up the car, reaches the passenger, runs start/end confirms, returns for inspection. Every fee line should still make sense on that timeline — especially driver fee versus empty wait.

Stats and alarms ops should open weekly

Passenger, order and referral stats charts exist for trend watching. Alarm management reviews emergency dial records; complaint and feedback queues catch fee surprises after the fact. If complaint tags cluster on “insurance fee unclear,” fix the confirm screen copy before you discount the base fee again.

Push notifications to drivers and passengers support shift reminders; they do not replace order-hall density.

Where store rental and carsharing must not blur

| Need | Product line to demo |

|---|---|

| Smart lock, scan self pickup, store photo confirm | Car rental software |

| Driver fee in stack, order hall, car-plus-driver loop | Carsharing system |

| Bulk import + realtime map for driven fleet | Carsharing admin (as documented) |

| Shelf cars with remote door for self-drive | Car rental store tools |

RFP language that says “carsharing with Bluetooth unlock and driver fee” is two products welded together. Split the sentence or budget integration.

A week-one pricing drill

1. Publish weekday and weekend stacks for two vehicle types.
2. Place and abandon checkouts; confirm half-hour cancel frees cars.
3. Complete three paid jobs; reconcile commission, driver wallet and invoice minimums.
4. Move one car on the live map during return; confirm location freshness is usable for ops, not only decorative.
5. Change a holiday driver fee; ensure passenger confirm shows the new line before the holiday week starts.

Coupons and campaigns without breaking the stack

Coupon tools exist on the admin side. A discount that silently erases the insurance or driver line teaches riders the wrong price. Prefer discounts that apply to a named component or the payable total while the breakdown stays visible. Registration and referral campaigns can grow demand; they cannot invent drivers in the order hall.

Close

Price the car and the driver in the open. Use calendar cycles, enforce unpaid timeout, import fleet cleanly and watch realtime location when supply feels “missing.” Keep P2P keyless dreams on the rental smart-lock line if that is what you actually run.

Tell us your mix — car-plus-driver, store self-service or both — and we will point to carsharing system versus car rental software without blurring them. Contact us.