Turnkey carsharing website development on 1C-Bitrix

Why carsharing website development stalls on integrations

In carsharing, there are almost always two independent loops: one handles vehicle booking, the other handles tariff logic, vehicle status, telemetry, and billing.

While synchronization between them is manual, the system runs on the dispatcher's word of honor: status updates with a delay, and the user sees a car as available when it has already been taken.

Double bookings appear exactly at the junction of the loops. The client clicks "book", the request goes to the database, and in parallel the same car has already been taken by another scenario — rental extension, a company trip, or taking the car out for maintenance.

The result is two confirmations for one car, a call to support, and manual cancellation of one of them.

Carsharing tariff logic makes this worse: the tariff depends on the parking zone, duration, car class, and current conditions, while recalculation is done outside the website.

If the website cannot read these rules at the moment of booking, one price is shown and another is charged. We address this at the architecture level, not with patches in the form.

This is exactly the stage where carsharing website development stalls: the interface is assembled quickly, while all the complexity lies in the exchange layer between the website, the accounting system, and the fleet.

We design it as a single source of truth: vehicle status, pricing rules, and booking confirmation go through one service that holds the lock until the operation is complete. Below is how this is handled in practice.

We develop on 1C-Bitrix and its integration with the accounting loop, but the platform is secondary here: first we describe vehicle states and transition rules, and only then do we write code.

Measurable effect: bookings, tariffs, downtime, support

Before implementation, support relied on manual operations: the dispatcher extended a booking, reconciled payment with the bank, and manually closed stuck trips.

Pricing rules, auto-renewal, and auto-charging move these scenarios into code — only non-standard disputes and refunds remain in the support queue, and the on-duty shift stops being a bottleneck.

During peak hours — the morning ramp-up and evening return — the load on vehicle issuance grows many times over.

The catalog of available cars is cached, the search for a free vehicle is moved to a separate loop, and telemetry is written through a queue rather than a synchronous request.

On the 1C-Bitrix side, this provides predictable response: issuance fits within fractions of a second, and growth in the number of active sessions does not turn into failures.

It is worth separately noting which class of failures is covered. Payment provider unavailability, loss of connection with the car at the moment of opening or closing a trip, and vehicle status desynchronization previously meant a call to support and manual correction.

Idempotent operations and a trip state log allow the action to be repeated without double charging, and after a failure the status is restored from the log.

Operations change along with this: monitoring of key scenarios, alerts for rejected bookings and stuck trips, and a clear on-duty procedure. The time from failure detection to recovery decreases, and with it the share of trips that end with a support request.

Launch options: rent, customize, or build

The choice between renting, customizing, and building your own determines not the launch timeline, but where the first non-standard task will hit a wall. All three options reach order acceptance — they diverge at the point where settings end and logic changes begin.

We break your process into parts: pricing, driver's license and document checks, telemetry, holds and fines, and support operations. Then we see what the platform covers with settings and what requires core modifications.

We make the decision based on a constraint map: what you are prepared not to change for two or three years, and what must remain flexible. Describe the task — we will return with an estimate and a plan showing which of the three paths will provide the needed headroom.

Work stages: from process analysis to handover

The implementation stages are structured so that each ends with a demonstration on a test bench, not a report: the customer sees how the rental scenario performs on real fleet data before going into production.

1. Process and fleet analysis. Interviews with operators and dispatchers: driver admission, tariffs and zones, actions in case of an accident, evacuation, or return not to a parking lot. The output is a process map with bottlenecks.
2. Architecture and data schema design. We fix the entities — vehicle, tariff, trip, payment, telemetry, user documents — and the rules for reconciling them with external systems.
3. Build on 1C-Bitrix and integrations. Rental module, customer account, admin part; we build exchange through queues with retries so that a connection loss does not lead to double charges.
4. Acceptance of rental scenarios. Run through the list: trip start and end, extension, cancellation, vehicle replacement, disputed payment — on a test bench with real responses from external services.
5. Failure and load runs. Telemetry unavailability, repeated notification delivery, parallel booking of the same car: we check that reprocessing an event does not create a second trip or charge.
6. Handover and training. Access, support procedures, deployment diagram, operator instructions; review of typical incidents and response procedure after launch.
7. Post-launch support. Monitoring of exchanges and queues, adjustments based on actual user behavior, planning of the next development iteration.

Deliverables: dashboards, integrations, procedures

The deliverable set is not a work report but a working system that the customer's team can run further on its own.

Everything assembled during the project remains in the repository and internal knowledge base: configured dashboards, integration schemes with the accounting system, access policies, documentation, and change release procedures.

We hand over not an archive but artifacts arranged by layer: for each one, it is clear where it applies and what will break if it is not taken into account in the next modification.

• User and operator dashboards: roles, order routes, trip states, license checks, and payment pages.
• Integration with the accounting system: exchange map, job schedule, exchange log, and procedure for resolving discrepancies between the website and the accounting loop.
• Integration schemes: connections with the payment loop, maps, and notification services — with a description of behavior when each is unavailable.
• Documentation and procedures: administrator instructions, change release procedure, release rollback, and rules for accepting support requests.
• Access policies: role-based permission separation, action logging, and the procedure for granting and revoking access.
• Test benches and data for verification: an environment for test exchange and a set of trip scenarios for acceptance.
• Handover procedure: code review with the customer's engineers and support for the first release after going live.

Such a set removes the question of who is responsible for changes after launch even before work starts.

Case study: how an urban carsharing service eliminated double bookings

A per-minute rental service grew to several hundred cars in its fleet, and bookings began to overlap: a request was sent to a car that was already occupied by another user at that moment.

The share of conflicting bookings during evening hours reached 11%, and each was handled manually — the dispatcher checked the requests, released the hold, and selected a car for the client again.

What was rebuilt

The booking core was moved into a separate loop on 1C-Bitrix: car occupancy is now recorded in a single registry, a request reserves the car with one action, and if the payment step fails, the lock is released automatically after a short waiting window.

Tariffs, rental end zones, and car replacement rules were described declaratively — changing a price or terms no longer requires releasing a new version: a manager changes parameters in the interface, and they apply to new requests immediately.

What changed

The service handles peak intervals without queues: car selection remains within a few seconds under a load three times higher than before.

The fleet tripled over the same period, while the flow of support requests did not increase — growth no longer pulled proportional manual work along with it.

What to do if bookings and tariffs are already managed in a ready-made system?

A working rental service is not stopped for a migration. First we analyze the current logic: how the tariff is calculated, at what moment a booking assigns the car to the client, and where trip state is stored.

Without this, migration turns into rewriting based on guesses, and discrepancies surface on live rentals.

An audit of the current platform produces a dependency map: fleet reference data, tariff grids, linking payments to trips, and exchange with telematics and the mobile app. We separately record what must not be lost and what can be rebuilt. The output is a migration plan with step order and rollback points to the previous loop.

Then we migrate layer by layer. Reference data and tariffs come up first — nothing depends on them in real time, and they can be compared line by line with the current system.

Bookings and trip state move over when the new loop already accepts and returns the same responses on a test stream.

The key here is migration without downtime. For some time, both loops work in parallel: the new one accepts new bookings, while the old one remains available for already open rentals. The switch happens in parts, with discrepancy control, not with a single switch at night.

Trip history is migrated in full and remains visible to the client in the customer account and in reporting. Closed trips are not recalculated retroactively — new rules apply only to rentals opened after the switch.

Frequently asked questions about service architecture and support

Questions at service acceptance rarely concern the interface — more often they concern system behavior in non-standard scenarios: denial of driver admission, loss of connection with the car en route, emergency trip termination. We build these into the architecture before launch, because trust in the service depends on them.

The solution is common: trip state lives on the server, while events from the car are protected from duplicates and go into a write-back queue. Lost connection does not create a "phantom" trip, and an interrupted route is calculated based on confirmed segments.

What happens if connection with the car is lost during a trip?

Telemetry is buffered on board and written back when the channel is restored. The trip is not closed based on waiting time before confirmation, and the operator sees the object in fleet monitoring with a connection loss indicator. Double charging and route gaps do not occur.

How is an interrupted trip charged?

The calculation is based on confirmed route segments, not on the session opening time. Incomplete data goes to review: the adjustment is made manually and recorded in the log with a reason. Trip history is exported and attached to the request for a disputed charge.

Who is responsible for fleet monitoring and support after launch?

We describe the procedure: which events require a response, who gives it and when, and how vehicle incidents are escalated.

Post-launch support includes on-duty coverage, training for your team, and handover of access and documentation so that operations do not depend on a single contractor.

Let's discuss the task and return with an estimate and plan

The estimate for a carsharing website project depends not on the number of pages, but on the number of rental scenarios and external systems connected to them.

To name launch timelines without "eyeballing" assumptions, we need a short introduction: what tariffs and rental types, how the fleet is structured, who confirms driver documents and how, which payment provider and which telemetry system we work with.

If some answers are not ready yet, we separate them into a design stage rather than building risk into the overall timeline.

Then the work proceeds in stages, and each ends with a verifiable result:

• Scenario analytics — a map of user paths: booking, opening the car, ending the rental, disputes, and refunds.
• Architecture design — data schema, roles and permissions, exchange formats with telemetry and payments.
• Team composition for the scope: analyst, backend developers on 1C-Bitrix, mobile developer, QA engineer, infrastructure engineer — they join at their own stage, not "all at once as a whole team."
• Development of the customer account and fleet admin panel — with interim demonstrations every two weeks.
• Integrations and mobile client — payment, telemetry, document workflow, notifications.
• Load and scenario testing — simultaneous bookings, correctness of charges, behavior when connection with the car is lost.
• Launch and support — migration to the production loop, monitoring, and a procedure for further modifications.

As a result of the conversation, you receive a work plan with stages, team composition by role, and launch timelines tied to specific stages rather than to a calendar "as a whole." Describe the task in two paragraphs — we will return with an estimate and plan.