Customers sign in to the storefront with a user name and a code sent by SMS instead of a password. This article explains how the method works and what an administrator sets up for it.

The user name does not have to be an email address, so a store can identify customers by a code or another identifier of its own. Use the method when the store identifies customers by user name and each customer has a phone that can receive SMS. A store can offer this method next to email and password, and stores that stay on email and password behave as before.

A new customer enters a user name and a phone number, and no password. The platform creates the account without a password and sends a registration code by SMS. A new account cannot be used for sign-in until the customer confirms that code, which proves the phone number is theirs. This check matters because a mistyped number would otherwise leave the customer locked out with no self-service fix.

At sign-in the customer types only the user name. The platform sends a code by SMS to the phone stored on the account, and the customer enters it to sign in. The platform picks the destination solely from the phone details it already holds, so nobody can steer a code to another number by including one in the sign-in request. Each code works once and stops working after use, after it expires, or after too many wrong guesses. Each code belongs to the user name it was sent for and cannot unlock any other account. Resending is limited by a cooldown and an hourly quota for each account, and the store has an overall ceiling on SMS volume because every message costs money.

The sign-in screens never show the customer's phone number, not even partly. Someone trying user names on the forms cannot learn which accounts exist, because an unknown name gets the same response as a known one. An account created without a password has no password to sign in with, and a store set to SMS codes turns password sign-ins away.

The login settings are on the Account tab of Shop configuration. Customer login methods sets which login methods the storefront offers, with E-mail + password and userName + SMS code (passwordless) as the two options. The storefront shows sign-up and sign-in forms only for the methods you turn on, and you can turn on several together. The label of the user name field is set for each client, so a store can call it an email or a user code. Stores that are already live need their page templates updated before shoppers see the new forms.

The Account tab has a Compare userName in lowercase mode setting with an Enable switch. When the setting is on, user names that differ only in letter case count as the same user name, and when it is off the case must match exactly. Comparison ignores case by default. Turn it off when your customers' user names are case-sensitive codes. Settle this choice while the store still has no registered customers, since it cannot safely be reversed afterwards. If you turn it on, each user name is stored in lowercase, so any capitals a customer typed are gone for good. Turning it on once accounts already exist can leave existing user names clashing with one another.

The Account tab also has a Customer two-factor authentication setting with Yes and No options. It does nothing for customers who sign in with an SMS code: the texted code already acts as the extra check, and sending another one to that phone gives no added protection. You cannot quietly turn on two-factor authentication alongside SMS-code login: the save stops, or a warning tells you why, so the setting never seems to protect accounts it does not.

The Account activation setting offers By sync key, By sync key and email, By sync key and phone and By sync key and custom field. Only activation that matches the phone number the customer typed records that the customer proved a phone number. Activating by sync key alone may bring a company-wide phone number into the new record, and a shared number like that cannot be trusted to receive login codes. When an account has no stored phone, the platform can fall back to a number from the company's contacts, but only one proven that way. If no proven number exists, or the proven numbers differ, no code is sent and the customer needs admin-assisted activation.

Codes go out through the store's existing SMS notification setup, using one event for registration codes and one for sign-in codes. Each event needs a notification rule for the client that sends to a phone recipient. You cannot route either code event to email, which keeps a sign-in credential from reaching the wrong channel. Several accounts can share one phone, so each message names the account its code unlocks. Apart from the code itself, the text holds no account information, phone number or link, and codes are never written to notification or application logs.

The method does not include a self-service way for a customer to change their phone or recover a lost account, so support handles both.

The Admin Panel menu includes Registered Users. The list holds individuals who signed up themselves, not company-level customer users, and you can search it with a fragment of a user name. Opening a person shows their user name, whether they are activated, the phone they use for the portal with a log of its edits, and each company they are activated for. The phone is one value for the whole person, so changing it once applies to every company, and their company activations stay in place. A single company's customer page no longer shows the login phone, because it is not a per-company attribute. Only administrators can open the screen, and editing a phone needs a separate permission that not every administrator has. Each time a phone is changed, the record keeps the person who changed it, the time, and both the previous and the new number. Saving a new phone marks it as verified, cancels any code already issued, ends the customer's existing sign-in sessions and notifies the previous number. Updating the number gives you no access to the customer's account: it neither opens a session nor shows you any code. Confirm the customer's identity outside the app before you change a number, because the new number receives every future login code.

An administrator can attach a registered person to a company straight from their detail view, picking one of your customers, with no code needed. It helps when activation fails because the phone on the company's contact record is wrong or empty. The link is recorded with the acting administrator, and the same person and company cannot be linked twice. The link does not copy the company's main phone number and does not count as proof of a phone. After you create the link, the customer is able to sign in and pick that company as their active one.