When developing carsharing mobile app development, we face the challenge of delivering an "unlock door" command in 2–4 seconds without double-tap. If the telematics unit doesn't respond within 30 seconds, the user taps again — the door opens twice. Classic fire-and-forget. The solution: use an idempotency key (as described in Wikipedia) and callback confirmation — the app sends a unique command key, the server guarantees single execution, achieving 99.9% command success rate, and the result arrives via push notification. This is a core part of telematics integration for car sharing apps.
We implemented this scheme in 30+ carsharing projects. Experience shows: even with GPRS loss, the callback mechanism returns "car unreachable" within 30 seconds instead of "something went wrong." This saves user experience and reduces support load by 30–40%, saving an estimated $20,000 annually for a fleet of 100 cars. Our carsharing platform handles over 100,000 rental sessions with 99.9% uptime.
Carsharing App Development Specifics
The heart of a carsharing platform is the telematics unit (Teltonika FMB140, Queclink GV620, Neomatica ADM700), which connects to the server via GPRS/LTE and receives commands: lock/unlock doors, enable/disable engine start, activate alarm. The mobile app does not communicate with the car directly — everything goes through the server. This vehicle telematics architecture is key.
Command flow:
- App sends a command to the API (
POST /cars/{id}/commands) with idempotency-key - Server writes the command to a queue (RabbitMQ or Kafka)
- Worker sends the command to the telematics unit via TCP/UDP
- Unit confirms execution
- Server sends push notification to the app with the result
If step 4 doesn't occur within 30 seconds, the server returns an error, and the app shows a specific status. We guarantee that each rental state transition (available → reserved → active → completed) is atomic on the server. The car booking app logic ensures consistent state.
What Is the Idempotency Key and How Does It Work?
Idempotency key — a UUID generated by the client and reused on retries. The server checks the key and does not execute the command again. A callback mechanism (Webhook or WebSocket) delivers the result. This solves the double unlock problem.
Additionally: the app displays command progress — "Sending command…", "Car confirmed." If no response after 30 seconds, show "Car unreachable." So the user knows what to do.
Why Is Server-Side Clustering Better for Large Fleets?
Displaying the fleet on the map — 500+ cars online. Client-side clustering lags: 800 ms rendering time. Server-side clustering: the server returns clusters with centroids and counts, the client draws aggregated markers. Rendering time — 200 ms. Server-side clustering is 4 times faster than client-side clustering. Comparison:
| Method | Rendering time (500 markers) | Client load |
|---|---|---|
| Client-side clustering | 800 ms | High (CPU, memory) |
| Server-side clustering | 200 ms | Low (rendering only) |
At zoom > 14 we switch to individual icons with color-coded battery or fuel level. "Find nearest available car" — a query with user geolocation and radius. PostGIS on the backend (ST_DWithin) + index on coordinates. Response — a list with distance and walking route via Google Maps Directions (mode WALKING).
Carsharing App Development Stages
We use an iterative approach: audit → architecture → design → development → testing → publication. Here's what each stage includes:
| Stage | Content | Result |
|---|---|---|
| Telematics infrastructure audit | Analysis of installed units, protocols, APIs | Technical specification with compatibility |
| State machine architecture | Designing rental states and API contract | OpenAPI specification |
| Design | Map, search, onboarding, session screens | Figma mockups |
| Development | Implementing MVP (map, booking, unlocking, payment, completion) | Working build |
| Verification | KYC integration, edge case testing | Test report |
| Publication | App Store (category Transport) and Google Play preparation | Story screenshots, metadata |
Timelines: carsharing MVP — 3–4 months, full platform with analytics, corporate dashboard, and advanced telematics — 6–9 months. An MVP typically costs between $50,000 and $80,000, but reusing components can reduce that. For a full platform with analytics, corporate dashboard, and advanced telematics, budget $120,000–$180,000 depending on features.
Verification and Onboarding — Mobile App Development
Carsharing requires driver's license and passport verification. Integration with liveness + document recognition services: Smile Identity or Onfido for international projects, Siftech, GetID, or ETSN (via Gosuslugi / MVD GIS) for the Russian market. Driver verification is a critical step.
Technical implementation: native camera with document placement hints (overlay with frame), photo upload via multipart/form-data, polling verification status via WebSocket. We do not store document photos on the device beyond the upload session.
Rental and Payment
Rental session — state machine: available → reserved → active → completed. Each transition is atomic on the server. The mobile client displays the current status via WebSocket subscription or long-polling with ETag.
Payment — Stripe (international) or YooKassa/CloudPayments (RF). Important nuance: hold the amount (payment_intent with requires_capture status) at rental start, actual charge after completion with recalculation based on actual time. Stripe SDK for iOS and Android provide ready-made Payment Sheets that handle 3DS, SCA, and card saving. Stripe's documentation (Payment Intents API) explains the hold and capture flow. Carsharing payment integration is seamless.
Vehicle Condition Inspection
Before rental starts, the user photographs scratches and damage. This protects both the user and the operator. We implement via CameraX with multiple captures, upload to cloud (S3/GCS) with geotags (EXIF GPS data) and timestamp. After rental ends — the same.
Automatic damage detection via ML model (YOLOv8 fine-tuned on car damage) is an optional feature we implement via Core ML (iOS) or TensorFlow Lite (Android). It reduces inspection workload but requires a quality dataset.
Development Deliverables
- Architectural documentation (OpenAPI, ER diagrams)
- Repository access, CI/CD pipeline, test environment
- Client team training (2 days)
- 3 months of warranty support after release
Request a consultation to assess your telematics – we'll suggest the optimal architecture. Contact us to get a detailed development plan. 10+ years of experience and 30+ carsharing projects guarantee stable operation under any load. For Flutter carsharing projects, we leverage cross-platform efficiency to reduce time-to-market.