Car Rental Store Onboarding: Certification Before Vehicles and Pricing

A car-rental network fails early when a store that is not yet a store starts loading cars. Passengers see a location. Ops cannot name who owns it. Compliance asks for a license and gets a chat image with no address. Ptaxi’s car rental software treats that as an onboarding problem, not a catalog problem. The store app’s home includes store certification: fill in the store’s information—business license front and back, store name, unified credit code, store address, and store phone—then upload and wait for review. After that gate, stores upload vehicles and pricing. Dispatch confirmation and return inspection already have their own playbooks. This piece stays on the certification door.

The source list names a unified credit code as part of the packet. Overseas teams should treat that as the store’s official registration number collected by the form, not as a promise that every country uses the same identifier name.

Why certification comes before the fleet

Store rental is a location business. Cars sit at a place with a phone number, a license, and someone responsible when a renter arrives. If you skip identity and jump to photos of a sedan, you have a brochure, not an onboarded store.

Typical pains this gate is meant to blunt:

1. A store loads vehicles while review is still pending, then a renter books a location that is not approved to trade.
2. Two people use similar store names and no official registration number, and finance cannot tell them apart.
3. Staff ask for “the license” in email, and the file never lands on the profile the admin list actually reads.
4. Launch training jumps straight to delivery toggles or vehicle grades, so nobody practices the first upload.

The documented order of the store home is the training order you want: messages and notices, store certification, then upload vehicles. Certification answers “who is this location.” Vehicle upload answers “what can this location rent, and at what rates.” Mixing them produces a familiar ticket: “Why can’t we list the car?” often meaning “the store is not through review yet.”

Admin review is not a rubber stamp you describe with a made-up SLA. The store uploads the packet and waits. Platform staff review store (and later vehicle and enterprise) applications. The admin store list later shows a review-passed time and a status. If your own team adds an internal turnaround target, write it in your SOP. The feature list does not publish a number of hours.

What the store actually submits

Walk the certification fields as a checklist, not as poetry:

• Business license images, front and back.
• Store name.
• Unified credit code (the official registration number named in the source docs).
• Store address.
• Store phone.

Then the store waits for review. Do not invent extra required fields the list does not include—no stated photo resolution, no named OCR vendor, no automatic government lookup. If your market needs extra documents, that is custom process, not a sentence already sitting in the confirmed list.

After review, the store can still see its identity on store info in the personal center: avatar, name, phone, address, business license, and unified credit code. That screen is how the store checks what the platform stored. It is not a second certification path. If the name or license needs a correction, handle it through your review and support process rather than telling stores to invent a shadow profile.

The store home also shows today’s accepted orders and today’s earnings once the location is working. Those figures are not the certification form.

After certification: vehicles and pricing, not dispatch yet

The next documented store-home action is upload vehicles. The store fills in vehicle information, configures pricing—either by using a platform pricing template or by adjusting the rates—and submits the vehicle for platform review. That is still an onboarding step. A car that has not passed review is not a rental you should be defending to a customer.

Keep later operations on their own cards:

• Dispatch confirmation, including condition photos, mileage, notes, and assigning a driver when the booking is delivery or chauffeur, lives at store order confirm and dispatch.
• Return confirmation, extra fees, and a possible second passenger payment are a return-settlement story, not an onboarding story.
• Store service switches—delivery, one-way return, deposit waiver, and chauffeur—decide what the location offers after it exists. Use store service switches.
• Vehicle grades and how admin binds cars to grade-level pricing belong with vehicle grades and fee rules.

Certification does not replace those tools. It only makes them safe to turn on. A store that toggles chauffeur before it is certified is offering a driver it is not yet allowed to represent. A store that inherits a pricing template before review has priced air.

Vehicle management after listing shows vehicles under review, rented vehicles, and unrented vehicles, including shelf status and remote door controls where you enable them. Those controls assume the store and the car already made it through the gates. Do not demo remote door controls as a substitute for a missing license upload.

What admin sees on the store list

The admin store list is the oversight surface for the same packet. It shows store information and the vehicles that belong to the store: store name, phone, store address, unified credit code, business license, store services, review-passed time, city, and status. Staff can view vehicles or suspend an account. Opening a vehicle view shows brand, series, year, plate, partial VIN and engine identifiers, photos, status, and a path into vehicle details plus pricing.

Read that list as the reason certification fields are not optional color. Name, phone, address, license, and unified credit code reappear for the people who have to approve, suspend, or investigate a location. Store services on that list connect to the service-switch playbook; they are displayed here so ops can see what an approved store turned on, not so you skip certification.

Platform finance later totals results by store. Those figures only mean something once the store identity is real. Do not use a financial report as your onboarding form.

Passenger-facing store choice still depends on this work. Renters pick a city and store, then choose dates and a return method. A store that never passed certification should not be in that choice set.

Ops tradeoffs to say out loud

• Let stores list cars before certification: faster catalog screenshots, slower compliance conversations when someone asks who the merchant is.
• Certify first, then accept vehicle and pricing review: slower day-one photos, cleaner bookings.
• Collect licenses in email instead of the store-app form: you will not see review-passed time or a consistent admin list.
• Confuse certification with service switches or grades: a certified store may still be wrong for delivery; a graded car still belongs to a reviewed location.

Practical notes that match the surfaces:

• Onboard with a complete packet: license both sides, name, unified credit code, address, phone.
• Wait for store review before you invest energy in a twelve-car upload that will only raise “why pending?” tickets.
• After approval, upload vehicles with either a platform pricing template or adjusted rates, then wait for vehicle review.
• Use suspend on the admin store list when a location should stop operating. Do not treat a missing license image as a pricing problem.

What this is not

• Not store service switches, vehicle grades, or dispatch confirmation. Those are separate, already published stories.
• Not smart-lock pickup, scan-to-book, or remote flash and horn. Those are handoff tools after a store and car already exist.
• Not enterprise or wedding-hire approval flows.
• Not named map vendors, bank cards, credit cards, or card processors. Passenger payment methods documented for this line remain the ones in the rental lists, not invented card rails.
• Not WeChat mini-program packaging for overseas App buyers.
• Not a published review SLA, automatic government verification, or OCR vendor.

Launch sequence sales can repeat

1. Open the store app and walk the certification form: license front and back, name, unified credit code, address, phone. Submit and show the wait-for-review state.
2. Open the admin store list and point at the same identity fields plus review-passed time, city, status, and the suspend action.
3. After a sample approval, upload one vehicle, choose a platform pricing template or an adjusted rate, and submit it for review.
4. Open store info in the personal center so the buyer sees name, phone, address, license, and unified credit code stored on the profile.
5. Name the later cards without demoing them as certification: service switches, vehicle grades, and dispatch confirmation.

If a prospect wants “just add the cars and we will do paperwork later,” ask who faces the first renter when the location cannot prove it is a store. That person usually asked for the shortcut.

Soft next step

If your rental network still lets locations advertise cars before anyone has reviewed a license, put store certification back at the front of onboarding: license images, name, unified credit code, address, and phone, then review, then vehicles and pricing. When a lead can demo that gate without mixing it into service switches or dispatch, you are ready to run car rental software as a network of real stores rather than a folder of car photos.