Twilio SMS Phone Verification OTP Addon for CS-Cart

Twilio Phone Verification asks for a code sent to the customer's phone before you let something happen: before a registration completes, before an order is placed, before a phone number is changed, or after a login. The code is sent and checked by Twilio Verify, on your own account.

Four surfaces, all of them off until you turn them on

• Registration - a new account is not created until the phone on it answers.
• Phone change - an existing customer proves the new number, so an attacker inside an account cannot move verification to their own phone.
• Checkout - the order is refused until the code is entered. Aimed at cash-on-delivery fraud, where a fake number costs a merchant a real delivery.
• Login - a second factor after the password.

An add-on that starts demanding codes the moment it is installed is an add-on that locks a shop out of its own checkout. Nothing happens here until you choose it.

Login is gated, not refused - and the reason matters

CS-Cart creates the session and signs the customer in before any add-on can object. Refusing at that point would leave somebody signed in while being told they are not: a guard that looks like it works and does not. So login is gated afterwards - every storefront page sends them to the verification screen until the code is entered. Three things the gate never blocks, because each is a way to lock a store out of its own storefront: logging out is always allowed, the verification screen itself is always allowed, and administrators reaching the storefront are never gated.

No code is stored anywhere in your store

There is no code column in any of this add-on's three tables, in any form - not plain, not hashed, not encrypted. Twilio Verify issues the code, holds it, and answers one question: does this code match this number. That is the difference between a database leak that exposes order history and one that also hands over every live verification code in the shop.

One detail this rests on: when a wrong code is submitted, Twilio answers HTTP 200 with a status of pending. The request succeeded; the code did not. An integration that reads "the call worked" as "the code was right" approves every wrong code ever entered while looking completely healthy. Verification here is approved only when Twilio's status is literally approved.

Limits that cannot be walked around

• Wrong guesses allowed (3, 5 or 10) counted over a window you choose, then a lockout from 15 minutes to 24 hours.
• The lockout is kept against the phone number, not against the challenge. If the counter lived on the challenge, five wrong guesses followed by "send me a new code" would start again from zero and the limit would mean nothing.
• A resend interval and a cap on codes per window, because each code costs you money.
• An administrator can release a locked-out customer from the Challenges screen with one button, and the release is recorded.

You decide what a Twilio outage does

There is no safe default that is right for everyone, so it is a setting you make deliberately: let customers through (the shipped default, because for most shops a few hours of unverified orders costs less than a few hours of no orders) or stop them (the right choice when verification is what makes cash on delivery affordable). The add-on's own failures always let the customer through either way, and every skipped check is logged: a bug in an add-on should not be able to close a shop.

SMS, voice or WhatsApp

Whichever channels your Verify service offers. A voice fallback - on by default - gives the customer a "call me instead" button after the first SMS, which is the difference between somebody waiting for a message their carrier dropped and somebody completing their order. A landline can only ever be reached this way.

Code length and code lifetime are properties of your Verify service. The connection screen reads them from Twilio and shows you the real numbers rather than assuming them.

What the customer sees

One screen, in your theme and in the storefront's language: the last four digits of the number the code went to, a field for the code, a resend button that stays disabled until the interval has passed, and the call button when fallback is on. The number is never taken from the page - it is read on the server from the profile or the order, because a form field carrying the phone would let anyone send a code to any number at your expense.

Failures are told honestly to whoever can act on them: a wrong code says wrong code, a locked-out number says how long. Anything that is the merchant's configuration - an unpaid account, a missing channel, a wrong SID - tells the customer only that verification is unavailable, because they can do nothing about it.

Installing

• One package for Ultimate, Multi-Vendor and Multi-Vendor Plus.
• Upgrading in place completes itself: the add-on brings its own tables, columns, indexes and privileges up to date on the first request after the files change.
• Your Auth Token is encrypted with a key derived from the installation's own security hash and is write-only in the interface.
• Disabling the add-on removes every gate at once - the fastest way out of any trouble - and it cannot leave anybody half-verified, because there was never a stored code to be half-way through.
• Full interface and documentation in English and Turkish.

Requirements

• A Twilio account - trial or paid - and a Verify service created in the Twilio console.
• CS-Cart 4.19.0 or newer, PHP 7.4 or newer with curl and openssl.
• No cron job and no public callback address: verification happens inside the customer's own request, start to finish.

Known limits, said before you buy

• Twilio Verify only. No other provider, and no dropdown that would make every one of them shallow.
• No admin panel two-factor. This protects the storefront; protecting the panel is a different surface with a different lockout risk.
• No passwordless sign-in. The code is a second step after a password, not a replacement for one.
• No e-mail codes and no authenticator apps. Phone channels only.
• No order notifications. Sending customers SMS about their orders is a separate add-on, Twilio SMS Notifications.
• A customer with no phone number is let through rather than blocked. Making a phone mandatory is your decision, made in CS-Cart's own profile fields.
• Trial Twilio accounts reach only numbers verified in the Twilio console.

Documentation: docs.softcrafter.dev/twilio-verify · Support: tech@softcrafter.net