Taxi website development using 1C-Bitrix

Taxi Website Development on 1C-Bitrix

A taxi service website is not a digital business card with a phone number, but a working tool that accepts orders, calculates fares, and transmits data to the dispatch center. On 1C-Bitrix, such a system is assembled from standard platform modules and several external APIs, while all business logic remains manageable through the administrative panel.

Architecture of a Route Calculator with Tarification

The trip cost calculator is the central element of the website. Its task: a user enters two points, the system displays the distance, estimated time, and price according to the selected tariff. It sounds simple, but internally it consists of several interconnected components.

Geocoding and route building. On the frontend, the Yandex.Maps JavaScript API or Google Maps JavaScript API is connected. When entering an address, the Suggest API is triggered — providing address suggestions. After selecting points A and B, a request goes to the Yandex Router API (or Google Directions API) to obtain the route. The API returns a polyline, distance in meters, and time in seconds.

The choice between Yandex and Google depends on the geography of operations. For Russia and the CIS, Yandex provides more accurate routes taking into account local roads. For international transportation — Google Directions.

Tariff matrix in a Highload block. Tariffs are stored in the Highload block TaxiTariffs with the following structure:

Calculation 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 Highload block of zones — suburbs and intercity distances are more expensive.

Server-side validation. The frontend displays a preliminary cost, but the final calculation is always duplicated on the server. An AJAX controller receives coordinates, re-requests the distance through a server call to the Router API, and calculates the price according to current data from the Highload block. This prevents parameter substitution on the client side.

Dynamic pricing. In the TaxiSurge Highload block, surge coefficients are stored according to time slots and days of the week. The OnBeforeOrderAdd event handler checks the current time and applies the coefficient. New Year's night, rush hour, rainy Monday morning — all of this is configured by the content manager without developer involvement.

Online Booking and Dispatch System Integration

The booking form collects data: route, tariff, pickup time (now or at a specific time), preferences (child seat, air conditioning, quiet ride). After submission:

1. An Orders infoblock element is created with status "New"
2. Simultaneously, a POST request is sent to the dispatch system API (Taxi-Master, Maxoptra, custom system on WebSocket)
3. A cron agent (CAgent) is started, which checks the status after 30 seconds — whether a response was received from dispatch
4. The client receives a push update via SSE or a polling request every 5 seconds

Integration with a specific dispatch system is implemented through an abstract DispatchConnector class with methods sendOrder(), getStatus(), cancelOrder(). An adapter is written for each system. When the dispatch software changes, only the adapter changes, the rest of the code remains the same.

Tariffs by Class

On the website, tariffs are displayed through a bitrix:news.list component, linked to the Highload block of tariffs. Each class is a card with a car icon, a list of included options, and a starting price. For visual comparison, a table layout is used:

• Economy — basic vehicles, minimum pickup fare
• Comfort — air conditioning, bottled water, vehicles no older than 5 years
• Business — premium models, pickup sign, Wi-Fi
• Minivan — group transportation up to 7 people, extended trunk

The administrator adds and edits classes through the standard Bitrix interface. If a "Cargo" or "Child" tariff appears tomorrow — just create a new Highload block element.

Mobile Adaptation

For taxi services, the mobile version is not an addition but the primary channel. Industry statistics show that 75–85% of orders come from smartphones.

The layout is built mobile-first. The calculator fills the entire screen: map at the top, address input fields at the bottom — like in familiar applications. CSS Grid is used with breakpoints at 360px, 768px, and 1024px. The map is initialized with gestureHandling: greedy for convenient one-finger zooming.

The "Book" button is fixed at the bottom of the screen via position: sticky. Address fields expand to full screen when focused — mimicking the UX of native applications.

Additionally, a PWA manifest is configured: home screen icon, splash screen, offline functionality via Service Worker with static content caching.

Integration with Aggregators

A taxi website can act as an aggregator or connect to existing ones. Two scenarios are implemented:

Receiving orders from Yandex.Taxi / Uber. Through the aggregator's Partner API, orders fall into the Orders infoblock with a source marker. The dispatcher sees both direct orders from the website and aggregator orders in a unified list.

Price comparison. On the calculator page, prices from aggregators can be displayed alongside your own tariffs. A request to the aggregator's API is made asynchronously, and the result is cached in CStackCacheManager for 60 seconds.

SEO and Local Promotion

For taxi services, local search results are critical. The following are configured:

• Schema.org TaxiService micromarkup with service area specification
• Landing pages for routes — "Taxi from Vnukovo Airport", "Taxi to the Station" — through an infoblock of routes with pretty URLs
• Integration with Yandex.Business and Google Business Profile via API
• Auto-generation of sitemap.xml by the Bitrix SEO module

Route pages are created through an infoblock: the content manager adds point A, point B, text — the system generates the URL, title, description from a template.

Hosting Technical Requirements

The calculator generates spikes of AJAX requests. Each calculation involves a call to an external API and the tariff database. With 50 simultaneous users, this results in 100–150 requests per second.

Recommended configuration: VPS with 4 vCPU, 8 GB RAM, SSD. PHP 8.1+ with OPcache, Redis for tariff and session caching. Nginx as reverse proxy with rate=10r/s limit on the calculator endpoint — protection against brute force.

Router API responses are cached in Redis with a TTL of 300 seconds (the route doesn't change in 5 minutes), which reduces external requests by 60–70% and speeds up repeat calculations.