How automatic registration via phone number cuts the cart abandonment rate in half

Why Shoppers Leave at the Final Step

The customer has already chosen a product, added it to the cart and clicked “Checkout”. Only one screen stands between them and payment. Yet this is exactly where online stores often lose the buyer: the form asks for an email, a password, password confirmation, and sometimes the same details again. Every extra field is another decision a person has to make when they are already mentally ready to pay. The more of those decisions, the higher the chance they close the tab.

E-commerce practice shows that up to two-thirds of carts are abandoned, and mandatory account creation consistently ranks among the top reasons. For a business, this is not abstract statistics — it is money already spent on traffic that never turned into revenue.

What Actually Drives Cart Abandonment

Cart abandonment is rarely a single decision to “change my mind”. More often it is accumulated friction. Here is what goes through a shopper’s head when they see a long registration form:

• “Why do I need a password if this is my first purchase here and I may never come back?”
• “Why should I confirm my email if I just want to receive my order?”
• “How many more screens do I have to go through before I can pay?”

Each of these questions is a micro-doubt. Individually they seem minor, but together they create the feeling that buying is harder than it should be. And when shoppers doubt at checkout, they do not go looking for answers — they leave.

One Field Instead of Five: How It Works

The idea is simple: do not force people to register before buying, but create an account automatically the moment they enter their phone number. The phone number is the only field the store really needs to contact the buyer, confirm the order and, if necessary, bring them back into the funnel. Email and password can be generated server-side, and the login details can be sent after the order is placed.

But there is a critical point where many “simple” implementations break. If the script simply authorises an existing user by phone number, that is a direct vulnerability: anyone who knows someone else’s number can take over their account. The scheme must therefore be built not on “authorisation by number” but on confirming ownership of the number via a one-time code. This is slightly more steps for the shopper, but still far fewer than inventing a password and waiting for an email.

Secure Implementation on 1C-Bitrix

With 1C-Bitrix, there is no need to rewrite the entire sale.order.ajax component. It is enough to add a custom AJAX handler that works together with SMS code delivery. The logic is as follows: the shopper enters a number, the server normalises it, checks rate limits and sends a code. The shopper enters the code. If the code is correct and a user with that number already exists, they are authorised. If no user exists, a new account is created with a random password, and the order is linked to it. The shopper does not need to know the password: they log in via SMS code and can set a password later in their account if they wish.

Phone Number Normalisation

Simple stripping of non-digit characters does not solve the main problem: the same number in the formats 8 (999) 123-45-67, +7 999 123 45 67 and 79991234567 will create three different users. For the store, this means fragmented purchase history and an inability to identify the customer correctly. Normalisation must account for country and format.

1C-Bitrix ships with built-in core classes for this — \Bitrix\Main\PhoneNumber\Parser and \Bitrix\Main\PhoneNumber\Formatter. They are built on the same logic as libphonenumber, but require no third-party packages and are already included in the distribution.

The parser accepts a raw string and returns a phone number object. From that object you can request the E164 format — the canonical +79991234567 representation that should be stored in the database:

use Bitrix\Main\PhoneNumber\Parser;
use Bitrix\Main\PhoneNumber\Format;

/**
 * Normalises a phone number to E.164 format (+79991234567).
 * Returns null if the number is invalid.
 *
 * @param string $raw Raw number from the form
 * @return string|null
 */
function normalizePhone(string $raw): ?string
{
    $raw = trim($raw);
    if ($raw === '') {
        return null;
    }

    $parsed = Parser::getInstance()->parse($raw);

    if (!$parsed->isValid()) {
        return null;
    }

    return $parsed->format(Format::E164);
}

If you only need E164 without intermediate checks, the parser has a shortcut normalizePhoneNumber() that does the same in one line:

$normalized = Parser::getInstance()->normalizePhoneNumber($_POST['phone'] ?? '');

But for checkout, the full version with isValid() is better: it filters out garbage before the number reaches the database and does not create a user on invalid input. The built-in parser determines the country from the prefix, and takes the default country from the main module setting phone_number_default_country. For a Russian store this is RU, and 8 (999) 123-45-67 correctly becomes +79991234567 without hand-written regexes.

Server Logic: Three Scenarios Instead of One

The handler must not make decisions “on the fly” without confirmation. For an existing user, authorisation happens only after the SMS code is verified. For a new user, the account is also created only after the code is verified. This rules out account takeover by phone number alone.

<?php
define('NO_KEEP_STATISTIC', true);
require $_SERVER['DOCUMENT_ROOT'].'/bitrix/modules/main/include/prolog_before.php';

if (!check_bitrix_sessid()) {
    http_response_code(403);
    echo json_encode(['error' => 'CSRF check failed']);
    exit;
}

$ip = $_SERVER['REMOTE_ADDR'];
$key = 'sms_send_'.$ip;
$count = apcu_fetch($key) ?: 0;
if ($count >= 5) {
    http_response_code(429);
    echo json_encode(['error' => 'Too many requests']);
    exit;
}
apcu_store($key, $count + 1, 600);

$normalized = normalizePhone($_POST['phone'] ?? '');
if (!$normalized) {
    echo json_encode(['error' => 'Invalid number']);
    exit;
}

$code = random_int(100000, 999999);
saveSmsCode($normalized, $code); // store an HMAC hash, not the code itself
sendSms($normalized, 'Verification code: '.$code);

echo json_encode(['success' => true, 'phone' => $normalized]);

After the code is entered, a second handler verifies it with an attempt limit and only then performs authorisation or user creation. The password is generated in a cryptographically secure way, not via rand().

$password = bin2hex(random_bytes(16));

For an existing user the password is not changed — they simply log in after the correct code. For a new user, an account is created with this random password, and they log in via SMS. If the shopper later wants to set a permanent password, they can do so.

Guest Checkout as an Alternative

Another secure and less infrastructure-heavy option is to allow checkout without registration at all. The shopper provides only a phone number and address, the order is created as a guest order, and an account is created automatically after successful payment and linked to the number. This removes friction at checkout entirely and does not require an SMS code at the moment of purchase. The downside is less control over the number before payment, but for many stores this is an acceptable trade-off.

Compliance with Russian Personal Data Law (152-FZ)

Registration by phone number means processing personal data. There are several practical points that cannot be ignored.

Collecting a phone number for order fulfilment and delivery falls under the performance of a sales contract — separate consent is not required for this. But if the store plans to use the number for marketing, promotions or sharing with partners, consent is required. Moreover, as of 1 September 2025, consent must be informed, specific and executed separately from other documents. It cannot be “glued” to the offer or privacy policy in one block of small print.

• Place a separate checkbox “I consent to the processing of my personal data” next to the phone input form, with a link to the privacy policy.
• If marketing messages are planned, add a second, separate checkbox — specifically for marketing communications. One generic “agree to everything” checkbox does not meet the requirements.
• Ensure the number is stored and transmitted over a secure channel, and restrict employee and contractor access to the data.
• Do not create “fake” emails unnecessarily. If an account is created automatically, it is better to generate a service address but immediately invite the shopper to complete their profile and provide a real email — for example, in exchange for a discount on the next order or access to exclusive promotions. A fake address harms email deliverability and pollutes the database.

What the Business Gets

The main value of this solution is not architectural elegance — it is removed friction while maintaining security. A shopper who has already decided to buy no longer wastes time inventing a password and waiting for an email. They confirm the number with an SMS code and move on to payment. For the store, this means several measurable outcomes:

• Fewer abandoned carts at the most expensive stage — when traffic has already been paid for and the product has already been chosen.
• More completed orders without additional acquisition spend.
• Fewer support requests about “the email never arrived” and “I can’t log in”.
• A full user base with verified phone numbers that can be re-engaged with repeat offers.

If checkout is losing even a fraction of buyers solely because of the registration form, automatic phone-number registration with SMS verification pays for itself faster than any new ad campaign. Because here money is not attracted again — it simply stops leaking at the final step.

Micro-Case: An Electronics Store

An online electronics store on 1C-Bitrix had a mandatory registration with email and password that stopped some shoppers at checkout. People added products to the cart, reached the form and left: some did not want to share their email, others did not see why they needed an account for a single purchase. After implementing phone-number registration with SMS verification, the share of completed orders grew by 18% within the first month. Support load dropped separately: questions about email confirmation and password recovery almost disappeared because there was no password to invent anymore. Products that used to get stuck in carts started reaching payment.

Where to Start

Check your checkout: how many fields does a shopper fill in before paying? If it is more than three and one of them is a password with confirmation, there is room to simplify. Start with a technical audit of the checkout form: it will show where the biggest drop-off happens and which fields can be removed or filled automatically. It is free, takes one day and gives you a concrete action plan instead of generic advice.

Теги: 1C Bitrixsale.order.ajax