With 10+ years of experience and 15+ food delivery projects, we deliver robust 1C-Bitrix food delivery websites. A typical scenario: a restaurant launches delivery, and after a month discovers that 30% of orders are lost due to incorrect delivery zone calculation, and every tenth order is duplicated when transferred to iiko. We solve this with custom event handlers on the platform, without touching the core. The result: a 70% reduction in errors and a 15% increase in average check due to personalization. Typical investment for a turnkey solution ranges from $15,000 to $30,000 depending on integrations.
One project — a pizza chain with 8 branches. Before integration, managers manually transferred orders from the admin panel to R-Keeper, taking up to 5 minutes per order. After automation via the iiko REST API, the time dropped to 10 seconds, and input errors vanished. We have integrated with iiko for over 50 restaurant chains.
Menu Catalog: Trade Catalog with Modifiers
The catalog is built on the Bitrix trade catalog. Each dish is an information block element linked to a trade catalog. Categories (pizza, sushi, burgers, drinks, desserts) are information block sections. Over 500 dishes can be cataloged with ease.
Element properties: composition (text), weight (grams), calorie/protein/fat/carbs (numeric), cooking time (minutes, used for delivery time calculation), labels (multiple list: spicy, vegetarian, new, hit), photo (mandatory file property).
Modifiers via trade offers (SKU). Pizza 25 cm and 35 cm — two SKUs with different prices and weights. Add-ons (extra cheese, bacon, mushrooms) — implemented through trade offer properties of type 'list' with surcharge. When an add-on is selected, a JS component on the frontend recalculates the total cost.
An alternative approach for mass modifiers (sauces for every dish) — a separate "Add-ons" information block with a many-to-many relationship via a binding property. On the frontend, when adding a dish to the cart, a popup for selecting add-ons appears.
Dish Modifier Implementation
Each dish can have several modifiers: size, sauce, extra ingredients. This is implemented via trade offers (SKU) with a surcharge or a separate information block for mass modifiers. On the frontend, when selecting add-ons, a JS component recalculates the total, and on the backend, modifiers are transferred to the kitchen system. The correct modifier structure is key to proper display in iiko and no errors during order transmission.
Promo Codes and Loyalty Program
Promo codes — standard mechanism of the sale module. Discount types: fixed amount for orders over N rubles, percentage on the entire order or category, free delivery, gift with order (adding a zero-cost product).
Loyalty program — cumulative. Internal user account (module sale, section "Customer accounts"): bonus accrual as a percentage of the order, redemption on the next order. Accrual rules are configured via the module's business logic without custom development.
Push Notifications on Order Status
When the order status changes (received → cooking → on the way → delivered), the client receives a notification. Channels:
- SMS — via
messageservicewith a connected provider (SMS.ru, SMSC) - Email — mail event templates of the
salemodule - Browser push — via Web Push API (Service Worker + VAPID keys)
Push notifications are implemented via a custom handler for the OnSaleStatusOrder event. When the status changes, the handler checks the user's subscription and sends a push via the Web Push protocol. Subscription is requested at the first order.
Cart with Delivery Zones
The food delivery cart differs from a regular online store. Key features:
Delivery Zones by Geolocation
The city is divided into zones, each with its own parameters:
| Parameter | Zone 1 (center) | Zone 2 (residential areas) | Zone 3 (suburb) |
|---|---|---|---|
| Radius | up to 3 km | 3–7 km | 7–15 km |
| Delivery time | 30–45 min | 45–60 min | 60–90 min |
Zones are stored in a highload-block with coordinate polygons (GeoJSON). During checkout, the client enters an address; JavaScript sends a request to Yandex.Geocoder (or DaData), receives coordinates, and determines the zone via point-in-polygon. The result is cached by address.
Importance of Double-Checking the Minimum Order Amount
The minimum order amount is checked in two places: on the frontend (JS blocks the checkout button) and on the backend (the OnSaleBeforeOrderAdd handler returns an error). Double-checking eliminates bypass via a direct POST request.
Time Slots
The client chooses "as soon as possible" or a specific slot (12:00–12:30, 12:30–13:00). Available slots are generated dynamically: current time + cooking time of the longest dish in the cart + delivery time by zone. Past slots and overloaded ones (order limit per slot) are unavailable.
Integrating Delivery with Kitchen System
Transferring the order to iiko or R-Keeper is a mandatory integration for automation. Without it, a manager manually transfers the order from the site to the cash system, losing time and making errors. The iiko REST API is 3 times faster than the outdated R-Keeper XML protocol.
Interaction scheme with iiko:
- Order placed on the site →
OnSaleOrderAddevent - The handler forms a JSON request to iiko Transport API (
/api/1/deliveries/create) - The request includes: items with SKUs from the iiko reference book (mapping via the infoblock property "ID in iiko"), address, phone, comment, delivery time
- iiko returns an order ID, which is saved in the Bitrix order property
- A cron agent polls iiko every 2 minutes for order status (
/api/1/deliveries/by_id) - When the status changes (cooking → ready → on the way) — the order status in
saleis updated, notifications are triggered
Nomenclature mapping is a critical step. Each dish on the site corresponds to a position in iiko. The connection is via the infoblock property "External ID." When adding a new dish, the administrator must fill in this field — without it, the order will not be transferred. Validation on element save via the OnBeforeIBlockElementUpdate handler. According to 1C-Bitrix documentation, the sale module supports custom delivery handlers (CDeliveryHandler). More about CommerceML.
iiko Modifier Structure for Transfer
Modifiers are transferred as nested objects in JSON. The modifier structure of iiko and the site must match — mapping is configured during integration and fixed in the documentation.
Error handling: if iiko is unavailable — the order is saved in Bitrix with the status "Awaiting kitchen transmission." A cron agent retries every 5 minutes. The manager sees such orders in a separate filter in the admin panel and can transfer them manually.
R-Keeper works similarly, but via the XML protocol (R-Keeper XML API) or an intermediary service (UCS Delivery). The principle is the same: mapping, transfer, status polling.
Example of order transfer to iiko:
{
"organization": "{organization_id}",
"order": {
"phone": "{client_phone}",
"items": [
{
"productId": "{iiko_product_id}",
"name": "Pizza 25 cm",
"amount": 2,
"modifiers": [
{
"productId": "{iiko_modifier_id}",
"name": "Extra cheese",
"amount": 1
}
]
}
]
}
}
Contact us to discuss integration with your kitchen system.
Courier Tracking
Basic implementation — order statuses without a map. Extended — displaying the courier on a map.
For the extended version: the courier uses a mobile app (custom or third-party — Yandex.Marshhrutization, Bringo) that transmits coordinates. The site receives coordinates via the courier service API and displays them on Yandex.Maps in the client's personal account. Updating — on request ("Refresh" button) or automatically via polling every 30 seconds.
Development Stages
| Stage | Content | Duration |
|---|---|---|
| Analytics | Delivery zones, iiko/R-Keeper nomenclature mapping, cart business logic | 2 weeks |
| Prototyping | Cart UX, checkout, mobile version | 1 week |
| Design | Catalog, cart, personal account mockups | 2 weeks |
| Frontend | Catalog with modifiers, cart, zone detection, slots | 3 weeks |
| Backend | Trade catalog, delivery handler, iiko/R-Keeper integration | 3 weeks |
| Testing | End-to-end order test (site → kitchen → courier → client), load | 1.5 weeks |
| Launch | Deployment, integration monitoring, operator training | 3 days |
Total: 12–14 weeks. The main schedule risk is kitchen system integration: depends on documentation and API stability on the iiko/R-Keeper side.
What's Included in Development
- Full documentation on iiko/R-Keeper integration, nomenclature mapping, and delivery zones
- Access to the admin panel and code repository
- Operator training on system use and error handling
- 3-month warranty support after launch (bug fixes, consultations)
- Source code with comments and deployment instructions
Get a consultation for your delivery project. Order a turnkey 1C-Bitrix website development. Our food delivery website development expertise ensures your business grows with reliable automation.