Setting Up Flash Call Verification in 1C-Bitrix
We often encounter situations where SMS verification fails: the carrier blocks the mailing, the phone is roaming, or the balance is zero. In such cases, a missed call (Flash Call) comes to the rescue. The user enters their number, the system calls and hangs up — the last 4 digits of the incoming number become the confirmation code. This is 5-10 times cheaper than SMS, and reliability is higher. Our team configures this mechanism turnkey: from selecting a provider to integrating with your Bitrix. We'll assess the project within 1 day — contact us for a preliminary estimate.
How Does a Missed Call Work?
Technically, the scheme is as follows: your server instructs the telephone platform to make a call from one of the numbers in the pool. The user sees an incoming call, remembers (or copies) the last 4 digits, and enters them into the form. There's no need to answer the call.
The key requirement: the provider must offer a pool of numbers with different last 4 digits and the ability to select a specific number for outgoing calls.
Why Is a Missed Call Cheaper Than SMS?
Flash Call is cheaper: the average cost of one verification via missed call is 5-10 times lower than SMS. This is especially noticeable at volumes of 1,000+ verifications per day. Additionally, the call is guaranteed to be delivered even in roaming, where SMS may be blocked. The freed-up budget can be allocated to marketing or improving the customer experience.
Which Providers Support Flash Call?
| Provider | Method | Features |
|---|---|---|
| Exolve (MTS) | Flash Call API | Pool of outgoing numbers, Exolve documentation |
| Zadarma | Flash call in API plans | REST API, per-call billing |
| Novofon | REST API | Support via standard requests |
| Zvonok.ru | Specialized service | Verification only, flexible configuration |
We'll select the optimal provider for your traffic and budget.
Implementation in Bitrix
The architecture is similar to SMS verification, but instead of a text code, the system generates a 4-digit suffix and selects a phone number from the pool with that suffix.
Table for storing verification sessions:
CREATE TABLE custom_flashcall_verification ( id INT AUTO_INCREMENT PRIMARY KEY, phone VARCHAR(20) NOT NULL, caller_number VARCHAR(20) NOT NULL, code VARCHAR(4) NOT NULL, created_at DATETIME NOT NULL, attempts INT DEFAULT 0, verified TINYINT DEFAULT 0 ); Generation logic:
function initiateFlashCall(string $targetPhone): array { // Generate a 4-digit code (0001–9999) $code = str_pad(random_int(1, 9999), 4, '0', STR_PAD_LEFT); // Select a number from the pool ending with this code $callerNumber = FlashCallPool::getNumberByCode($code); if (!$callerNumber) { throw new \Exception('No available number for code: ' . $code); } // Initiate a call via the provider's API $provider = new ExolveFlashCallProvider(); $provider->call($callerNumber, $targetPhone); // Save to database FlashCallVerificationTable::add([ 'PHONE' => $targetPhone, 'CALLER_NUMBER' => $callerNumber, 'CODE' => $code, 'CREATED_AT' => new \Bitrix\Main\Type\DateTime(), ]); return ['success' => true, 'hint' => 'Expect an incoming call']; } Managing the Number Pool
The number pool is a critical part of the system. For codes 0000–9999, a minimum pool of several hundred numbers is needed; otherwise collisions are inevitable under high load.
Pool table:
CREATE TABLE custom_flashcall_pool ( id INT AUTO_INCREMENT PRIMARY KEY, phone_number VARCHAR(20) NOT NULL, code_suffix VARCHAR(4) NOT NULL, in_use TINYINT DEFAULT 0, last_used DATETIME, INDEX idx_code (code_suffix), INDEX idx_available (in_use, last_used) ); When selecting a number from the pool, the first available with the required suffix that hasn't been used in the last 30 seconds is taken. After verification completes, the number is returned to the pool.
User Interface
The verification form via missed call differs from SMS:
- User enters their phone number
- A message appears: "You will now receive a call from a number. Remember its last 4 digits."
- Input field with mask
_ _ _ _ - Countdown timer (usually 30–60 seconds)
- "Call again" button after the timer expires
It's important to inform the user that they don't need to answer the call — this is non-standard and can cause confusion without an explanation.
Integration with Bitrix
Verification is embedded via an AJAX controller (\Bitrix\Main\Engine\Controller) and connected to the registration or checkout form via JavaScript. In the bitrix:sale.order.ajax component, a verification step is added between entering contact details and confirming the order. Full documentation for Bitrix REST API can be found in the official guide.
Fallback option: if the call doesn't arrive within 90 seconds, the user is offered to switch to SMS verification.
What's Included in Turnkey Setup
- Selection and connection of a Flash Call provider
- Development of the number pool and collision management
- Implementation of the verification form with timer and fallback
- Integration with your Bitrix (component, controller, database)
- Load testing and documentation
- Admin training and launch support
Over 5 years of experience with Bitrix and 30+ successful integration projects guarantee quality results.
Typical Errors and How to Avoid Them
Common issues during implementation
- Number collisions under high load — solved by increasing the pool and lock time
- Incorrect code display — user doesn't have time to memorize the digits; increase call duration to 3 rings
- Provider failures — mandatory fallback to SMS
- Incorrect number format — validation on client and server side
Timelines
| Scope of Work | Duration |
|---|---|
| Provider integration + basic form | 1–2 days |
| Number pool + collision management | +1 day |
| SMS fallback + full Bitrix integration | 3–4 days |
For high-load stores with 1,000+ verifications per day, it's worth designing pool redundancy and monitoring provider availability.
Get a specialist consultation — contact us to estimate timelines and cost for your project.

