Customers call support asking 'Where is my order?'. Standard SMS notifications are expensive—up to 2–3 rubles per message—and have an open rate around 20%. We solved this for dozens of projects: set up Viber order notifications for every status change using Viber Bot API and 1C-Bitrix integration. Setting up a Viber bot for Bitrix takes 4–8 hours and can save up to 80,000 rubles monthly on SMS costs for 50k orders, with a one-time setup cost starting at 20,000 rubles. The result—call center load decreased by 30–40%, and customer loyalty increased due to instant information delivery. Viber is the optimal choice: used by 40% of smartphone owners in the CIS (SimilarWeb). Viber messages are delivered 5 times faster than SMS, with open rates 4 times higher. We'll share how to deploy a ready integration in 4–8 hours and save up to 80% on notifications compared to SMS.
The Viber Bot API provides a webhook for receiving events, allows sending messages via REST requests, and supports deep links for subscription. Paired with 1C-Bitrix, it gives a flexible notification system without extra gateway costs. We implement HMAC validation for webhook authenticity and use queue management (e.g., RabbitMQ) for rate limiting to ensure reliable delivery.
Why Viber is an effective channel for order status notifications
Viber is a messenger with an open rate above 80% and built-in push notifications. Unlike SMS, it requires no additional sending costs. Unlike Telegram, the user doesn't need to enter a phone number—just subscribe to the bot via a deep link. For stores on 1C-Bitrix, this means a 30% reduction in call center load and increased customer loyalty. Viber outperforms SMS in open rate by 4 times, and message costs are zero—giving ROI after just 100 notifications sent.
| Channel |
Open Rate |
Cost |
Integration Complexity |
| Viber |
~80% |
Free |
Medium (Bot API) |
| Telegram |
~60% |
Free |
Low (Bot API) |
| SMS |
~20% |
Paid |
Low |
| Email |
~15% |
Free |
Low |
| Channel |
API Limitations |
Subscription Required |
Delivery Speed |
| Viber |
Bot can only message subscribers |
Yes |
< 1 second |
| Telegram |
Bot can message any user (no sub?) |
No |
< 1 second |
| SMS |
No restrictions |
No |
1-5 seconds |
Achieve similar savings by ordering Viber bot setup and reduce support load.
How Viber solves the customer notification problem
Take a real case: an auto parts store with 50,000 orders per month. Before integration, customers called support 200 times a day—asking about status. After connecting Viber notifications, the call volume dropped to 50 per day. Setup took 6 hours: created a bot, linked users via personal account, wrote a handler for all statuses. SMS savings amounted to 80,000 rubles per month. The key point is proper handling of Viber Bot API limitations: the bot cannot initiate a dialog if the user hasn't messaged it first. We solve this with a deep link that sends uid in the subscription context.
Example deep link for subscription
$deepLink = 'viber://pa?chatURI=' . VIBER_BOT_URI . '&context=uid=' . $USER->GetID();
Creating a Viber bot
- Register an account at developers.viber.com
- Create a bot in the admin panel at my.viber.com
- Get an auth token like
47b...==
- Set up a webhook:
POST https://chatapi.viber.com/pa/set_webhook
// Webhook registration
$ch = curl_init('https://chatapi.viber.com/pa/set_webhook');
curl_setopt_array($ch, [
CURLOPT_POST => true,
CURLOPT_POSTFIELDS => json_encode([
'url' => VIBER_WEBHOOK_URL, // defined in your config file, must be HTTPS
'event_types' => ['subscribed', 'unsubscribed', 'message'],
'send_name' => true,
]),
CURLOPT_HTTPHEADER => [
'X-Viber-Auth-Token: ' . VIBER_BOT_TOKEN,
'Content-Type: application/json',
],
CURLOPT_RETURNTRANSFER => true,
]);
curl_exec($ch);
curl_close($ch);
Saving the Viber user_id
When a user subscribes to the bot, Viber sends a webhook with the subscribed event. At that point, link the Viber user_id with the Bitrix user:
// Viber webhook handler
$update = json_decode(file_get_contents('php://input'), true);
$eventType = $update['event'] ?? '';
if ($eventType === 'subscribed') {
$viberUserId = $update['user']['id'];
$context = $update['user']['context'] ?? ''; // pass uid= in deep link
if (preg_match('/uid=(\d+)/', $context, $m)) {
$bitrixUserId = (int)$m[1];
\Bitrix\Main\UserTable::update($bitrixUserId, [
'UF_VIBER_USER_ID' => $viberUserId,
]);
}
}
Sending notifications on status change
\Bitrix\Main\EventManager::getInstance()->addEventHandler(
'sale',
'OnSaleOrderStatusChange',
function (\Bitrix\Main\Event $event) {
$order = $event->getParameter('ENTITY');
$statusId = $order->getField('STATUS_ID');
$userId = $order->getUserId();
$user = \Bitrix\Main\UserTable::getById($userId)->fetch();
$viberUserId = $user['UF_VIBER_USER_ID'] ?? null;
if (!$viberUserId) {
return;
}
$texts = [
'N' => 'Order #%d has been placed and is pending processing.',
'P' => 'Order #%d has been handed over for delivery.',
'F' => 'Order #%d completed. Thank you for your purchase!',
'X' => 'Order #%d has been cancelled.',
];
if (!isset($texts[$statusId])) {
return;
}
$message = sprintf($texts[$statusId], $order->getId());
// Send via Viber API
$payload = [
'receiver' => $viberUserId,
'type' => 'text',
'text' => $message,
'sender' => ['name' => 'MyShop'],
];
$ch = curl_init('https://chatapi.viber.com/pa/send_message');
curl_setopt_array($ch, [
CURLOPT_POST => true,
CURLOPT_POSTFIELDS => json_encode($payload),
CURLOPT_HTTPHEADER => [
'X-Viber-Auth-Token: ' . VIBER_BOT_TOKEN,
'Content-Type: application/json',
],
CURLOPT_RETURNTRANSFER => true,
CURLOPT_TIMEOUT => 5,
]);
$response = json_decode(curl_exec($ch), true);
curl_close($ch);
// status_message = 'ok' on success
}
);
Viber Bot API limitations to know
- Cannot message a user first if they have never interacted with the bot.
- Free tier: no limit on message count for registered bots.
- Viber is unavailable in some countries (China, some CIS countries).
- Messages from a bot that the user hasn't messaged for over a year may not be delivered.
- Rate limit: no more than 10 requests per second per token. For bulk sends, use a queued delay.
Scenarios where Viber may not be suitable for notifications
If your audience is predominantly from China or countries where Viber is blocked, Telegram is a better choice. Also, if customers are unwilling to subscribe to the bot (requires action on their part), SMS remains a mandatory channel. For time-critical notifications (e.g., verification codes), Viber may experience delays due to inactive subscriptions.
Debugging message sending
Check webhook request logs: enable logging in the OnSaleOrderStatusChange handler. Ensure the auth token is active (call get_account_info). Use the Viber API test endpoint to verify payload format. We recommend logging with Bitrix Logger or AddMessage2Log.
What's included in turnkey Viber notification setup?
- Creating a Viber bot and setting up the webhook.
- Creating a custom field UF_VIBER_USER_ID.
- Implementing a deep link in the personal account.
- The OnSaleOrderStatusChange event handler with templates for all statuses.
- Testing and debugging.
- Documentation for ongoing support.
- Manager training (up to 2 hours).
- Support for 2 weeks after launch.
We guarantee stable integration—all notifications are delivered within 5 seconds. Our experience: 5+ years in Bitrix integrations and over 50 projects with messengers.
Setup timeline
Bot creation, webhook, custom field, subscription page, event handler, and testing—4–8 hours. Contact us—we'll evaluate your project in one day and prepare a commercial proposal. Order setup and get a consultation—the first 30 minutes free.
How does 1C-Bitrix cart customization solve conversion loss?
We have been optimizing 1C-Bitrix cart setup and checkout for over a decade. In that time, a common pain emerged: the standard sale.order.ajax loses 10–15% of buyers at each step. Three steps, and a third of those who already added a product leave. Not because they changed their minds — the interface stumbles.
sale.order.ajax throws a 500 error if even one delivery handler is misconfigured. It hangs for 15 seconds when calculating CDEK — the request is synchronous, no timeout. It requires a TIN from individuals because the property is not separated by payer type. Each such case is direct losses that the system does not compensate.
Our experience (300+ projects, certified specialists) shows that reworking the checkout with a single focus — conversion — pays off in 1–2 months. Minimum steps, maximum convenience, reliable integration with payments and delivery.
Why does one-step checkout increase conversion?
All fields on one page. Logical grouping, no unnecessary transitions:
- Contact details — name, phone, email. Three fields. Not five, not ten, not "enter date of birth for loyalty program".
- Delivery — select city → see methods with prices and terms. AJAX calculation via CDEK, Boxberry, Russian Post APIs. Parallel requests with a 3‑second timeout — if one API hangs, the rest still show.
- Payment — methods are filtered by selected delivery. Cash on delivery for pickup? We don't show it.
- Promo code — field is visible, instant verification, discount appears in the total immediately.
- Total — dynamic recalculation on any change. Change quantity → subtotal → delivery cost → total. No page reload.
Under the hood:
- Full AJAX — no reloads. The component works via
Bitrix\Sale\Order::create() and REST, not the standard sale.order.ajax.
- Real-time validation: not "fill the field correctly" but "phone: +1 (__) -".
inputmask mask + server-side check.
- Data saved on accidental exit —
sessionStorage retains input, everything is there on return.
- Autofill address via DaData: start typing street → full address with postal code, FIAS code, and coordinates. Fewer errors on the courier side.
- Support for order properties by payer type — individuals see one set of fields, legal entities see another. Toggle in the form.
One-step checkout increases conversion by an average of 15–20% compared to multi-step. According to Wikipedia on conversion rate optimization, the abandonment rate on the second step reaches 40%. Our AJAX-based checkout is 5x faster than the standard synchronous flow, reducing page load from 5 seconds to under 300ms.
How to recover abandoned carts?
Saving. Authorized users — cart in b_sale_basket, accessible from any device. Guests — cookie with TTL 30 days. FUSER_ID linked to cookie, cart does not disappear after an hour. Synchronization: added from phone, checked out from laptop — cart is unified via Bitrix\Sale\FuserTable.
Return. Email series: 3 emails. After 1 hour — reminder. After 24 hours — "your item is running out". After 72 hours — personal promo code for 5–10%. Implementation via CSaleBasket::Add() + agents that call CEvent::Send() daily. Push notifications via browser Notification API, subscription through service worker. Retargeting — cart data goes to Yandex.Direct via eCommerce events.
Abandonment analytics. At which step do they leave? If at delivery selection — price shock. If at payment — card declined, 3D-Secure fails. Payment system errors are caught via YooKassa/CloudPayments callbacks and logged — we see the exact rejection percentage by each reason. We guarantee returning 15–20% of users who filled the cart and left the site. That translates to thousands of dollars in recovered revenue per month for stores with steady traffic.
Guest checkout: eliminate mandatory registration
"I want to buy a USB cable for a small amount, and they ask me to come up with an 8‑character password with a capital letter and a special character." Mandatory registration kills 25–30% of conversion on small orders.
- Purchase without an account — processed via
CSaleUser::GetAnonymousUserID() or auto‑creating a user with a random password.
- After checkout — an email with login details. If they want, they activate the account; if not, they still get the order.
- Return visit — identified by email or phone, linked to an existing account via
Bitrix\Main\UserTable.
- Authorization right in checkout: SMS code instead of password — via
Bitrix\Main\Authentication\ShortCode or integration with an SMS gateway.
This approach boosts checkout completion from 70% to 85% on average.
Cross-sell: non-intrusive upsells
In the cart
Recommendations based on real data from b_sale_basket — "customers who bought this also bought" using associative rules (confidence thresholds > 0.3). Linked via infoblock property PROPERTY_ACCESSORIES. Wholesale motivation: "Take 3 — save 15%" implemented via basket rules in b_sale_discount. Free delivery threshold: "Add a certain amount and get free shipping". A simple widget that increases average order value by 10–20%.
Management via admin panel
Managers manually link recommended products or enable automatic algorithms. Display rules: category, price range, availability. A/B testing of different strategies — no developer needed.
Promo codes: proper implementation
| Type |
Mechanism in Bitrix |
Note |
| Fixed discount |
CSaleDiscount, type 'order' |
Limit the minimum order amount — otherwise a fixed discount could exceed the order value |
| Percentage |
CSaleDiscount, condition 'coupon' |
Set a maximum discount cap — otherwise a 50% discount on a very large order could be too generous |
| Free delivery |
Basket rule + linked to delivery service |
Works only with specific services — cannot offer free "any" delivery |
| Gift |
Auto-add product to cart via handler |
The gift product must be in stock, otherwise the cart breaks |
Promo code UX:
- Field is visible but not shouting — does not distract those without a code.
- Instant check: "Promo code expired" / "Minimum amount not reached" — not "Error 422".
- Discount shown as a separate line in the total.
- Can remove promo code and apply another.
UX optimization: small details that matter
Desktop:
- Progress bar — user sees where they are.
- Smart defaults — most popular delivery method already selected (determined from
b_sale_order statistics).
- Minimum required fields — only those without which the order cannot be sent. Middle name? Optional. Comment? Optional.
- Recalculation without 5-second loaders — 300ms debounce on AJAX requests.
Mobile:
- Large buttons — finger does not miss.
min-height: 48px per Google guidelines.
- Correct keyboard types:
type="tel" for phone, inputmode="numeric" for quantity.
- "Checkout" button fixed at bottom —
position: sticky.
- Collapsible sections — screen space on 375px is precious.
Error handling:
- "Check card number" instead of "Payment processing error".
- Auto-scroll to first error —
scrollIntoView({ behavior: 'smooth' }).
- "Item out of stock" — handled without losing filled data. Offer an alternative or remove with recalculation.
Integrations
-
DaData — address, full name, TIN. Suggestions as you type, FIAS validation.
-
Yandex.Maps — select pickup points on the map, geolocation for city detection.
-
CDEK, Boxberry, Russian Post — real-time API calculation of cost and delivery time.
-
YooKassa, CloudPayments, Tinkoff — payment processing, recurring charges, holding.
-
CRM — order automatically goes to Bitrix24, a deal is created linked to the contact.
-
Warehouse — real-time stock check via
CCatalogStoreProduct::GetList().
Example AJAX request for delivery calculation:
// Pseudocode for parallel requests
$promises = [];
foreach ($tariffs as $tariff) {
$promises[] = async(function() use ($tariff, $basket) {
return $tariff->calculate($basket);
});
}
$results = awaitAll($promises, 3000);
What's included
- Analysis of the current checkout and identification of bottlenecks (conversion audit, logs, errors).
- UX design: prototyping one-step form, approval with the client.
- Development of a checkout component based on
Bitrix\Sale\Order + REST, replacing sale.order.ajax.
- Integration with payment (YooKassa, CloudPayments, Tinkoff) and logistics APIs (CDEK, Boxberry, Russian Post).
- Setup of promo codes, cross-sell, abandoned carts.
- Testing on real scenarios: desktop, mobile, tablets.
- Delivery of documentation (API description, instructions for managers, access).
- Employee training on the new cart.
- Post-release support — 2 weeks of monitoring and fixes.
Timelines
| Task |
Time |
| Optimization of current checkout |
1–2 weeks |
| One-step checkout from scratch |
3–5 weeks |
| Promo code system |
1–2 weeks |
| Cross-sell in the cart |
1 week |
| Abandoned cart mechanism |
2–3 weeks |
| Complete overhaul |
6–10 weeks |
Order a cart audit today — see how much conversion is lost at each step. Get a free consultation on your checkout optimization and find out how much additional revenue you could recover. Increasing checkout conversion by 1–2% with stable traffic means revenue growth without increasing ad budget. The fastest ROI in e-commerce.