We develop taxi websites on 1C-Bitrix — not a business card with a phone number, but a full-fledged tool for order intake, cost calculation, and dispatcher communication. A typical problem with custom solutions is slow loading under peak loads and difficulties with 1C integration: data doesn't sync in time, orders get lost. 1C-Bitrix solves this with built-in tagged caching and ready-made CommerceML connectors.
The platform provides ready-made modules for information blocks, highload blocks, and user management, covering 70% of typical taxi tasks. We configure a route calculator with tariffs, integrate Yandex.Maps API for geocoding, and ensure dynamic pricing through system agents. As a result, a taxi website on 1C-Bitrix runs faster and is cheaper to maintain than custom development.
We evaluate your project and propose end-to-end timelines. In a typical project, we design the calculator architecture in a Highload block TaxiTariffs, configure agents to check order status every 30 seconds, and connect the dispatch system via an abstract class DispatchConnector. Average order processing time — 500 ms. We work with any scale — from 5 to 500 cars. As stated in the official 1C-Bitrix documentation, "CommerceML is a standard for data exchange between 1C and the site, supported by the platform kernel."
How We Configure the Route Calculator with Tarification
The cost calculator is the central element. The user enters two points, the system shows distance, time, and price by tariff. Internally, it's a chain of several components.
Geocoding and route building. On the frontend, we integrate Yandex.Maps JavaScript API or Google Maps JavaScript API. After selecting points A and B, a request goes to the Router API to get the route. The choice between Yandex and Google depends on geography: Yandex is more accurate for Russia, Google for international routes.
The tariff matrix is stored in the Highload block TaxiTariffs with the structure:
| Field | Type | Purpose |
|---|---|---|
| UF_TARIFF_CODE | String | Tariff code |
| UF_BASE_PRICE | Number | Base fare |
| UF_PRICE_PER_KM | Number | Price per km |
| UF_PRICE_PER_MIN | Number | Price per minute |
| UF_MIN_ORDER | Number | Minimum order cost |
| UF_NIGHT_COEFF | Number | Night coefficient |
| UF_ZONE_ID | Bind | Zone of operation |
Formula: max(UF_MIN_ORDER, UF_BASE_PRICE + distance_km × UF_PRICE_PER_KM + time_min × UF_PRICE_PER_MIN) × coefficient. The coefficient is pulled from a separate HL-block of zones.
Server-side validation is mandatory: the AJAX controller re-requests the distance via a server-side call to the Router API and calculates the price based on current data. This prevents parameter manipulation on the client.
Dynamic pricing is implemented via the HL-block TaxiSurge with increasing coefficients for time slots. The handler OnBeforeOrderAdd applies the coefficient — e.g., New Year's Eve, rush hour. The content manager configures this without a developer.
Example cost calculation
For a trip during rush hour, the cost is calculated using the formula with applicable coefficients. The final amount is determined by the system based on real-time data.Why a Taxi Website on 1C-Bitrix Is Better Than Custom Development
Development on Bitrix takes 2–3 times less time than from scratch. Ready-made modules for information blocks, highload blocks, and user management cover 70% of typical tasks. Integration with 1C via CommerceML (according to documentation) is built into the kernel — no need to write custom connectors for directory and order exchange. Our project experience shows that maintaining such a site has lower total cost of ownership thanks to built-in caching and agent orchestration. If you want to quickly launch a taxi website, order development from us.
How We Integrate the Site with Dispatch Systems and Aggregators
The order form collects the route, tariff, pickup time, and notes. After submission:
- An information block element
Ordersis created with status "New". - Simultaneously, a POST request is sent to the dispatch system API (Taxi-Master, Maxoptra).
- An agent
CAgentruns, checking status every 30 seconds. - The client receives a push update via SSE.
Integration with the dispatch system is implemented via an abstract class DispatchConnector with methods sendOrder(), getStatus(), cancelOrder(). An adapter is written for each system — switching dispatch software only requires changing the adapter.
For aggregators (Yandex.Taxi, Uber), orders via their Partner API fall into the information block with a source marker. The dispatcher sees a unified list of both direct orders and aggregator orders. API requests are cached in CStackCacheManager for 60 seconds.
Process, Timeline, and What's Included
We follow these stages:
| Stage | What We Do | Approximate Time |
|---|---|---|
| Analysis | Identify integrations, zones, tariffs | 1–3 days |
| Design | Calculator architecture, data schema | 2–4 days |
| Implementation | Calculator, ordering, admin panel | 1–3 weeks |
| Integration | 1C, dispatch, aggregators | 1–2 weeks |
| Testing | Validation, load testing, usability | 3–7 days |
| Launch & Training | Deployment, hosting setup, documentation handover | 1–2 days |
Timelines — from 2 to 6 weeks depending on complexity. Cost is calculated individually. Work scope:
- Technical specification describing integrations
- Deployment on hosting (recommended VPS: 4 vCPU, 8 GB RAM, SSD, PHP 8.1+, Redis for caching)
- Mobile-first responsive design (75–85% of orders from smartphones)
- PWA manifest configuration for adding to home screen
- Schema.org
TaxiServicemicrodata and landing pages for routes - 6-month warranty and technical support after launch
Contact us to evaluate your project — we'll prepare a commercial proposal and precise timelines.