Without SMS verification, an online store can lose up to 30% of its advertising budget on fake orders. — According to a 2023 ecommerce fraud report. Recently, a client with an auto parts store experienced 5,000 registrations per day, of which 40% were bots. After implementing verification, fake accounts dropped to 3%, significantly reducing advertising spend. Without verification, every 5th account is fake. Our solution is a custom module with a database table, anti-fraud, and flexible integration. Certified 1C-Bitrix specialists with over 10 years of development experience and 500+ successful projects ensure stable operation.
Why SMS Verification is More Effective Than CAPTCHA
SMS verification is 5 times more reliable than email verification because a phone number is tied to a SIM card and harder to generate. CAPTCHA only deters simple bots (60% effectiveness), while an SMS code requires a real device (99% effectiveness). For stores with high margins, this pays off in 1–2 months. For example, a typical store can save $2000 per month after implementation. Additionally, storing codes in a database is 10 times more reliable than using sessions: sessions are vulnerable to session fixation attacks, while an indexed table guarantees integrity.
Choosing an SMS Provider
1C-Bitrix does not have its own SMS gateway. Integration is built through the provider's REST API. Popular options for the Russian/CIS market:
- SMSC.ru — direct API, good documentation
- SMS.ru — free test mode (100 free SMS)
- MTS Exolve / Beeline — corporate rates
- Twilio — for international projects
Connecting a provider is done via a separate wrapper class that implements a unified interface. This allows you to change the provider if needed without reworking the verification logic.
Verification Architecture
Why Store Codes in the Database Instead of a Session?
Storing in a session is vulnerable to session fixation attacks. We use a separate table custom_sms_verification:
CREATE TABLE custom_sms_verification ( id INT AUTO_INCREMENT PRIMARY KEY, phone VARCHAR(20) NOT NULL, code VARCHAR(6) NOT NULL, created_at DATETIME NOT NULL, attempts INT DEFAULT 0, verified TINYINT DEFAULT 0, INDEX idx_phone (phone), INDEX idx_created (created_at) ); In Bitrix D7 via \Bitrix\Main\ORM\Data\DataManager:
class SmsVerificationTable extends \Bitrix\Main\ORM\Data\DataManager { public static function getTableName(): string { return 'custom_sms_verification'; } public static function getMap(): array { return [ new \Bitrix\Main\ORM\Fields\IntegerField('ID', ['primary' => true, 'autocomplete' => true]), new \Bitrix\Main\ORM\Fields\StringField('PHONE'), new \Bitrix\Main\ORM\Fields\StringField('CODE'), new \Bitrix\Main\ORM\Fields\DatetimeField('CREATED_AT'), new \Bitrix\Main\ORM\Fields\IntegerField('ATTEMPTS'), new \Bitrix\Main\ORM\Fields\BooleanField('VERIFIED'), ]; } } For storing code data, you can also use HL-blocks (Highload-blocks) — convenient for managing records from the admin interface.
How to Protect the Code from Brute Force
The logic includes protection: after 3 failed attempts, the code is blocked regardless of its lifespan (5–10 minutes). Additional limits: no more than 1 request per 60 seconds per number, no more than 5 codes per day per IP. A CAPTCHA appears under suspicious activity.
function sendVerificationCode(string $phone): bool { $code = str_pad(random_int(0, 999999), 6, '0', STR_PAD_LEFT); $recent = SmsVerificationTable::getList([ 'filter' => [ '=PHONE' => $phone, '>CREATED_AT' => new \Bitrix\Main\Type\DateTime(date('Y-m-d H:i:s', time() - 60)) ] ])->fetch(); if ($recent) return false; // Too many requests SmsVerificationTable::add([ 'PHONE' => $phone, 'CODE' => $code, 'CREATED_AT' => new \Bitrix\Main\Type\DateTime(), 'ATTEMPTS' => 0, 'VERIFIED' => false, ]); return SmsProvider::send($phone, "Your verification code: $code"); } Code verification example:
function checkVerificationCode(string $phone, string $code): bool { $record = SmsVerificationTable::getList([ 'filter' => [ '=PHONE' => $phone, '=VERIFIED' => false, '>CREATED_AT' => new \Bitrix\Main\Type\DateTime(date('Y-m-d H:i:s', time() - 600)) ] ])->fetch(); if (!$record) return false; if ($record['ATTEMPTS'] >= 3) return false; SmsVerificationTable::update($record['ID'], ['ATTEMPTS' => $record['ATTEMPTS'] + 1]); if ($record['CODE'] === $code) { SmsVerificationTable::update($record['ID'], ['VERIFIED' => true]); return true; } return false; } Integrating SMS Verification with Registration and Checkout
Verification is embedded in two places. During registration — through the OnBeforeUserRegister event handler. If the phone number is not verified, registration is blocked until SMS confirmation. This client verification process ensures only real users register. During checkout — via the bitrix:sale.order.ajax component. A verification step is added before final order confirmation. This is especially important for stores accepting orders without registration. For the AJAX verification form, a controller is used:
class SmsVerifyController extends \Bitrix\Main\Engine\Controller { public function sendAction(): array { ... } public function checkAction(string $phone, string $code): array { ... } } Verification can also be integrated with Bizproc to automate actions after number confirmation.
Step-by-Step Implementation Plan
- Choose a provider and test sending.
- Create a table for storing codes (or an HL-block).
- Implement a wrapper class for the provider with a unified interface.
- Write a code sending handler with limits.
- Embed into the registration form via event.
- Modify sale.order.ajax to add a verification step.
- Set up anti-fraud and number normalization.
- Test under load (simulate bots).
What Limits Should Be Set?
Mandatory protection measures:
| Limit | Value |
|---|---|
| Requests per hour per number | 3 |
| Codes per day per IP | 5 |
| CAPTCHA under suspicion | Yes |
| Number normalization | +7XXXXXXXXXX |
These limits block 99% of bots. When exceeded, the user sees: "Try again in 10 minutes."
Что входит в работу
- Schematic diagram of verification (documentation)
- SMS provider setup and test run (includes 100 test SMS)
- Wrapper class for the provider with unified interface
- Database migration for storing codes
- Event handlers for registration and modification of sale.order.ajax
- Anti-fraud and limits configuration
- Operation instructions and one month of support (phone/email)
- Access to our knowledge base and code repository
Timeframes
| Scope of Work | Time |
|---|---|
| Sending + code verification, basic flow | 1–2 days |
| Integration with registration + checkout | 2–3 days |
| Anti-fraud, limits, number normalization | +1 day |
SMS verification is an investment in the quality of your client base. One clean account is worth more than ten fake ones. Order SMS verification setup now — protect your client base from bots. Contact us for a free consultation. Our team has 10+ years of Bitrix development experience and has completed 500+ integration projects.

