Car-sharing website development using 1C-Bitrix

Car Sharing Service Website Development on 1C-Bitrix

Car sharing is a high-load backend service: real-time vehicle map, time and zone-based pricing, driver license verification, payment pre-authorization. 1C-Bitrix here serves as CMS for public section (catalog, rates, registration, personal cabinet) and as operator administration panel. Telematics and billing live in separate services; site integrates via API.

Vehicle Catalog

Vehicles stored in information block with following properties:

• Make and model — two linked lists (make → model, dependent selection via JS in admin).
• Class — list: economy, comfort, business, SUV.
• Year — number.
• Color — list.
• License plate — string, unique property.
• VIN — string (internal accounting, not displayed on front).
• Status — list: free, occupied, maintenance, reserved.
• Current location — two numeric properties (latitude, longitude), updated from telematics.
• Rate group — binding to Highload block tariff element.
• Photos — multiple "File" property.
• Fuel level — number (%, updated from telematics).

Site catalog not classic product list. Rather, reference page with vehicle class cards and characteristics. User sees specific available cars on map.

Registration with Verification

Car sharing registration is multi-stage. Standard Bitrix registration module insufficient; requires custom component.

Stage 1: Basic data. Name, surname, birth date, phone, email. Phone confirmed via SMS code (integration with SMS gateway via OnBeforeUserRegister event or separate AJAX handler).

Stage 2: Document upload. Driver license — front and back photos. Passport — spread with photo. Selfie with document. Files uploaded via standard CFile::SaveFile and bound to user properties (UF_DRIVER_LICENSE_FRONT, UF_DRIVER_LICENSE_BACK, UF_PASSPORT, UF_SELFIE).

Stage 3: Verification. Two options:

• Automatic — integration with license verification service (Russian Traffic Police API or commercial services: IDX, ScoringBureau). Request sent on document upload; result recorded in user UF-field.
• Manual — operator in admin reviews documents, approves or rejects. Verification status — user property with handler sending push/SMS on change.

Until verification passed, user sees catalog and rates, but cannot start rental.

Personal Cabinet

Personal cabinet sections:

• Trip history — data from billing system, displayed via custom component. Each trip: date, start/end time, route (polyline on mini-map), cost, applied tariff.
• Fines — Traffic police fines linked to trips. Operator uploads fine to Highload block with user and date binding. User sees fine and can pay.
• Balance — current internal account balance. Top-up via payment gateway. Uses internal account from sale module (CSaleUserAccount).
• Loyalty program — accumulated bonuses, history of credits and debits. Bonuses stored in separate table or Highload block.
• Documents — terms of use, acts.

Payment Gateway Integration: Pre-authorization

Before trip start, pre-authorization (hold) executed on user card — amount blocked without debit. After trip completion, actual cost charged; balance unblocked.

Realization via payment module sale with custom payment system handler:

1. On rental start — API request to gateway (CloudPayments, ЮKassa, Tinkoff) on preauth with deposit amount.
2. Transaction ID saved in order property or separate table.
3. On completion — capture request for actual amount.
4. If trip canceled — void request to unblock.

Deep-dive: Real-time Vehicle Map and Rate Logic

Map — central service interface. User opens app (or site), sees nearest available cars, selects one. Bitrix implementation requires two things: fast API for coordinates and flexible rate model.

Real-time Map Architecture

Vehicle coordinates updated by telematics service (GPS trackers in each car send data every 10–30 seconds). Bitrix doesn't process telematics directly — separate backend service task. But site must display current data.

Interaction scheme:

1. Telematics service writes coordinates, status, fuel level to Redis or PostgreSQL (fast storage).
2. API endpoint on Bitrix side (custom controller in /local/routes/) requests storage data, returns JSON with cars in given bounding box (visible map area rectangle).
3. Front (Yandex Maps JS API) on load and map pan requests API with visible area coordinates. Gets object array:

[
  {
    "id": 142,
    "lat": 55.7558,
    "lng": 37.6173,
    "class": "comfort",
    "model": "Kia K5",
    "fuel": 68,
    "tariff_group": 2,
    "status": "free"
  },
  ...
]

4. Map markers update without reload. Free cars — active markers (clickable), occupied — not displayed to users (admin only).

Query Optimization

With hundreds of cars on map and thousands of simultaneous users, API load significant. Solutions:

• Redis caching — coordinates cached with 15-second TTL. All 15-second requests get same snapshot.
• Geo-index — if PostgreSQL data, use PostGIS extension for spatial queries (ST_Within). Bounding box query with index works milliseconds.
• Client throttling — front requests updates no more than once per 10 seconds, only on map move.

Rate Grid

Tariffs stored in Highload block Tariffs with fields:

Geographic zones — separate Highload block TariffZones with polygons (JSON field with zone boundary coordinates). City center, residential, suburbs — different zones with different rates.

Trip Cost Calculation

Cost calculated by billing service, but logic defined in Bitrix rate grid:

1. Zone determination — by GPS coordinates at trip start, determine zone (point-in-polygon check).
2. Period determination — by start time: day or night.
3. Day determination — weekday or weekend.
4. Tariff selection — from Highload block by combination: car class + period + day + zone.
5. Calculation — for per-minute: driving minutes × UF_RATE_MINUTE + waiting minutes × UF_WAITING_RATE. UF_MIN_COST applied.

If trip crosses period boundary (started day, ended night), calculation splits into two intervals with different rates. Similarly — zone crossing.

Rates Page on Site

On public rates page, tariffs displayed as table:

Table generated dynamically from Highload block. On rate changes in admin — site data updates automatically (tagged caching).

Administration and Monitoring

In Bitrix admin (section /area51 or standard panel), operator has access to:

• Fleet map — all cars with real-time statuses (custom admin page).
• Status management — transition car to maintenance, reserve.
• User verification — request queue with document view.
• Fines and incidents — journal with trip and user binding.
• Rate editing — via Highload block interface.

Technical Summary

Car sharing site on Bitrix — integration project. Bitrix handles content, registration, rates, admin. Telematics, billing, real-time map rely on external services linked to Bitrix via API. This architecture separates responsibility and allows scaling each component independently.