How to Develop a Transportation Company Website on 1C-Bitrix with Online Booking
A client asks: "Is there a Minsk—Moscow trip on Friday? How much does it cost to rent a bus for 45 people?" — if the answer can't be found in two clicks, they go to an aggregator. Without an online booking system with dynamic pricing, the site becomes a business card that no one uses. We design an architecture where the central element is the tariff grid managed via Highload-blocks.
Problems We Solve — Transport Company Website Development
The main technical challenge is the diversity of services: regular trips, bus rental, corporate transfers, excursions. Each type requires its own parameters: for rental — route, hours, vehicle type; for a trip — date and number of seats. A single information block with conditional properties complicates the code, so we create separate Highload-blocks.
The second problem is cost calculation based on a complex tariff grid. The price depends on distance, time, bus class, season, surcharges. Storing this in information blocks is inefficient — we use HL-blocks with custom fields and indexes.
What Is a Tariff Grid and How to Implement It?
Let's look at an example of bus rental by distance. The system consists of several HL-blocks:
Highload-block TariffGrid:
| Field |
Type |
Purpose |
| UF_VEHICLE_TYPE |
enumeration |
Minibus / Medium Bus / Large Bus |
| UF_COMFORT_CLASS |
enumeration |
Standard / Comfort / VIP |
| UF_TARIFF_TYPE |
enumeration |
Per km / Per hour / Fixed route |
| UF_PRICE_PER_UNIT |
float |
Price per unit (km or hour) |
| UF_MIN_HOURS |
integer |
Minimum order in hours |
| UF_MIN_PRICE |
float |
Minimum order cost |
| UF_CITY_FROM |
string |
Departure city |
| UF_CITY_TO |
string |
Arrival city |
| UF_FIXED_PRICE |
float |
Fixed route price |
| UF_SEASON |
enumeration |
Low / High / Holiday |
| UF_VALID_FROM |
date |
Tariff valid from date |
| UF_VALID_TO |
date |
Tariff valid to date |
Highload-block TariffSurcharge — surcharges:
| Field |
Type |
Purpose |
| UF_TYPE |
enumeration |
Night delivery / Holiday / International / Baggage |
| UF_SURCHARGE_TYPE |
enumeration |
Percentage / Fixed amount |
| UF_VALUE |
float |
Surcharge value |
| UF_VEHICLE_TYPE |
enumeration |
Which vehicle type it applies to |
Calculation algorithm:
- Determine the distance between points. For popular routes, we use pre-calculated data from HL-block
RouteDistance, for non-standard routes — Google Distance Matrix API or OSRM.
- Select tariff from
TariffGrid by vehicle type, comfort class, and date.
- Base cost = distance * UF_PRICE_PER_UNIT.
- If base is less than UF_MIN_PRICE, use UF_MIN_PRICE.
- Apply surcharges from
TariffSurcharge (night delivery, holiday, international route).
- For round-trip routes — double the distance with a coefficient of 0.85-0.9.
Implementation in code:
$tariff = TariffGridTable::getRow([
'filter' => [
'UF_VEHICLE_TYPE' => $vehicleType,
'UF_COMFORT_CLASS' => $comfortClass,
'UF_TARIFF_TYPE' => 'per_km',
'<=UF_VALID_FROM' => $tripDate,
'>=UF_VALID_TO' => $tripDate,
],
]);
$basePrice = max(
$distance * $tariff['UF_PRICE_PER_UNIT'],
$tariff['UF_MIN_PRICE']
);
// Наценки
$surcharges = TariffSurchargeTable::getList([
'filter' => ['UF_VEHICLE_TYPE' => $vehicleType],
])->fetchAll();
foreach ($surcharges as $s) {
if (isSurchargeApplicable($s, $tripDate, $tripTime, $isInternational)) {
$basePrice = applySurcharge($basePrice, $s);
}
}
For hourly rental, the calculation is simpler: hours * tariff per hour, with a minimum check. For fixed routes, UF_FIXED_PRICE is used directly.
Why Online Booking Increases Conversion by 2-3 Times?
The client has no time to call and clarify prices. The online calculator provides an instant answer. Our booking system processes the request 5 times faster than custom PHP solutions, thanks to tagged caching and optimized queries to HL-blocks. We integrate it with the REST API of Bitrix, so after confirmation, an order with trip parameters is created. Payment — 30-50% prepaid via acquiring or full payment at boarding.
Additional Modules
- Fleet — an information block with cards for each vehicle: type, capacity, class, photos, characteristics. Filtering by capacity and class. During booking — automatic selection of suitable buses.
- GPS trip tracking — integration with trackers (WIALON, Galileosky). On the site — a map with the bus location, updated every 30-60 seconds.
- B2B portal — a private section for corporate clients: authorization by contract, submitting requests, exporting invoices and statements from 1C, order history, prepayment balance.
- Route landing pages — for SEO traffic. For each popular route, an information block element is created with a unique description, schedule, and booking widget.
Process of Work
- Analytics — study the carrier's business processes, gather requirements for tariffs, routes, integrations.
- Design — develop HL-block architecture, calculation scheme, interface prototype.
- Development — implement booking, fleet, and integration modules. Write code in PHP 8.1+ using Component 2.0.
- Testing — verify cost calculation for 50+ scenarios, load testing of the calculator.
- Deployment and support — configure caching, monitoring, transfer access and documentation.
What Is Included in the Work
- Development of information block and Highload-block structure
- Implementation of cost calculation algorithm
- Integration with payment systems (YooKassa, Sber)
- Integration with 1C (CommerceML or HTTP services)
- Caching and performance optimization
- SEO optimization of route landing pages
- Training operators to work with the admin panel
- 6-month warranty support
Estimated Deadlines
| Scale |
Composition |
Time |
| Small carrier (5-10 routes) |
Service catalog, fleet, application form, route pages |
6-8 weeks |
| Medium company |
+ online booking with tariff grid, payment, trip schedule |
12-16 weeks |
| Large carrier |
+ B2B portal, GPS tracking, 1C integration, multilingual |
20-26 weeks |
The cost is calculated individually — we will evaluate the project after the brief. 1C-Bitrix: Data management via Highload-blocks. Contact us for an audit of your business process. Request a consultation — we will send a commercial proposal with an estimate.
Case example: 35% savings on operational costs
For one transportation company, we automated the cost calculation and exchange with 1C. Manual order processing reduced from 4 hours to 20 minutes per day. Savings on operational costs reached 35%.
How to properly design infoblocks?
When developing a 1C-Bitrix website, we see dozens of projects where poor infoblock structure slows down the site. Typical scenario: the client asks for a "product catalog." The developer creates one infoblock catalog, puts 15 properties in it. Six months later – 40 properties, 8 of which are used only for one category. The filter lags, the b_iblock_element_property table grows to millions of rows, CIBlockElement::GetList runs for 3 seconds. Consequences – conversion drop, loss of customers, additional optimization costs. In one project after catalog refactoring, page generation time dropped from 4.2 to 0.8 seconds, and annual support costs were reduced by over $10,000 through eliminated redundant queries and agents.
Our approach: design infoblocks before writing a single line of code. Separate infoblocks for entities (products, categories, brands), dictionary properties via highload blocks, trade offers for SKUs. This builds performance for years. If you want a preliminary audit of your infoblock schema, contact us for a free review of common mistakes and recommendations.
Why 1C-Bitrix outperforms most CMS for business
The choice of CMS is dictated by business needs, not preferences. Native 1C exchange via catalog.import.1c provides two-way synchronization of products, prices, balances, and orders through CommerceML without third-party modules — five times faster than developing custom exchange on OpenCart or WordPress, saving hundreds of thousands of rubles. Proactive security module includes WAF, file integrity control, SQL injection protection, and two-factor authentication; it's certified for FSTEK requirements. Modular architecture lets you enable only needed modules — iblock, catalog, sale, search — reducing DB queries per hit. Regular patches close vulnerabilities faster than open-source projects (average CVE fix time two weeks). Official documentation is maintained on the vendor's site.
What highload blocks are and how they speed up the catalog
Highload blocks are an alternative to extended infoblock properties when the list of values can grow to thousands of entries. Typical example: manufacturers, countries, colors. If stored as list properties in an infoblock, each filter triggers a full scan of b_iblock_property_enum table. With HL-blocks, selection uses indexes – filter response time drops from 1–2 seconds to 50 ms. We use HLB component and custom queries via Bitrix\Highloadblock\DataManager. This is critical for catalogs with 100,000+ items.
From our practice: an online store with 500,000 items. Standard filter by brand took 4 seconds. The server couldn't handle 50 concurrent requests – pages crashed. We moved the brand directory to an HL-block, added tagged caching for 15 minutes, and set up an agent to clear cache on change. After optimization, filter time was 120 ms, average LCP was 1.8 seconds. The project runs stable without failures.
What integrations are critical for 1C-Bitrix stores
Each e‑commerce project requires reliable connections with payments, fiscalization, logistics, and CRM. We integrate YooKassa, CloudPayments, Tinkoff, Apple Pay, Google Pay for payments; ATOL and OrangeData for 54-FZ compliance via sale.cashbox; CDEK, Boxberry, PEC, Russian Post, Yandex.Delivery for logistics; Bitrix24, amoCRM, Roistat, Calltouch, Mindbox for analytics and CRM. All integrations are configured with proper error handling and fallback logic.
What's included in 1C-Bitrix website development
Each project includes a full set of documentation and artifacts to prevent knowledge loss after handover.
- Technical specification – user stories, infoblock diagrams, integration schemas.
- Source code in Git – with commit history, release tags, branching rules.
- Administrative documentation – description of custom components, deployment instructions, list of agents and events.
- Staff training – up to a 3-hour webinar: admin panel, order management, price settings. Recorded for later review.
- Access to staging during development – test before production deployment.
- Warranty support – bug fixes for 30 days after launch. Post-warranty support packages with SLA (response 2 hours, resolution 8 hours).
Our process and technologies
| Project type |
Timeline |
Complexity |
Key features |
| Corporate website |
from 1 month |
Medium |
Catalog, news, forms, CRM integration |
| Online store |
from 2 months |
High |
54-FZ, marketplaces, 1C exchange, SKU |
| B2B portal |
from 3 months |
Very high |
Personal prices, document flow, Bizproc |
| Landing page |
from 2 weeks |
Low |
LCP < 2s, composite cache, static |
| Multisite structure |
from 1.5 months |
High |
Separate content, shared catalog, hreflang |
Tech stack: mobile-first markup, tested on physical devices (iPhone, iPad, Android). Use BrowserStack for Safari on iOS. Performance goals: LCP < 2.5 s, FID < 100 ms, CLS < 0.1. Enable composite site (composite module), CDN, tagged caching, WebP/AVIF, lazy loading. SEO: Schema.org via JSON-LD, auto-generation of sitemap.xml via seo module, canonical and hreflang for multilingual versions. robots.txt blocks /bitrix/ from indexing. CI/CD: Git, auto-deploy via GitLab CI, staging. DB migrations: sprint.migration module with versioning.
Process:
-
Analytics – study competitors, gather requirements, create prototypes in Figma. Output: technical specification with user stories.
-
Design – UI/UX with design system. Components are reusable.
-
Development – write components with custom templates in
local/templates/. Business logic in local/modules/.
-
Testing – functional, cross-browser, load testing (up to 1000 requests). Critical bugs fixed before launch.
-
Launch – deploy to production, monitoring via UptimeRobot, alerts in Telegram. Fixes for first 48 hours.
Multilingual support and redesign
Full localization via language files lang/ and SITE_ID mechanism. hreflang for each version. Regional versions with different prices and content – IP detection (main.geo) or manual selection. Multidomain – unified management of multiple domains.
Redesign without losing rankings: performance audit (PageSpeed, WebPageTest), SEO (Screaming Frog). New template in local/templates/ with preserved URL structure. 301 redirects only if URL changes significantly. Kernel update, migration to D7 ORM, infoblock restructuring, migration via sprint.migration with Git.
Guarantee and support
We have been working with 1C-Bitrix for 12+ years, completed 500+ projects. Certified developers on staff. Fixed price in contract – no surprises. Warranty period covers code errors. After warranty, subscription packages with SLA (response time 2 hours, resolution 8 hours). 24/7 availability monitoring, alerts in Telegram. Get a consultation and preliminary estimate: contact us via the form on the website or chat – we'll respond within an hour. Order turnkey development – we'll design infoblocks, integrate 1C, and speed up the catalog. If you already have a site on another CMS, order a performance audit and migration to Bitrix.