E-commerce OTP use cases
Verification is not necessary for every click. Use it where an error or abuse creates cost for the buyer, seller, or delivery operation.
| Journey | What is verified | Purpose |
|---|---|---|
| Signup | New customer's phone | signup |
| Login | Account access | login |
| Recovery | Return of account access | recovery |
| Recipient change | Order owner's intent | change_recipient |
| Address change | Sensitive delivery update | change_delivery |
| Order pickup | Recipient action | order_pickup |
Distinct purpose values prevent a login code from being used to modify an order. Keep the challenge bound to the user and exact action on the server.
Verified signup
Create a limited pending signup state first, then send the OTP. Mark the phone as verified and activate the full account only after successful verification.
Normalize the phone on the server and use the same value in send and verify. Display a masked number, channel, five-minute expiration, and resend countdown.
Order changes
Changing an address, recipient, or pickup method after checkout can be sensitive. Before send, verify that the order belongs to the current user and can still be modified.
After verify, reload the order and recheck its state, contents, and authorization. OTP confirms user action but does not replace store business rules.
Code and short link
POST /api/otp/send accepts an optional link. Cascade can create a short URL and include it next to the code.
This can lead to an order, payment, or pickup page. Do not place personal or payment data in the URL. The destination must validate session, authorization, and link expiration.
Channels and price
WhatsApp and Telegram are publicly available at 3 credits per successful delivery. New accounts receive 1000 starting credits. The public SMS provider is not live yet.
Do not promise SMS fallback when it is unavailable for the company. Show the real channel and a clear next step after non-delivery.
Metrics
Connect technical events to store outcomes: send, delivery, time to verify, completed signup or login, confirmed order change, resend per customer, abandoned forms, credits per completed action, and support contacts.
This separates channel problems from confusing UI or overly strict limits.
Abuse protection
- Limit send and verify by phone, account, IP, and API key.
- Do not trigger a code on every page refresh.
- Enforce resend cooldown on the server.
- Keep recovery responses neutral.
- Redact OTP and Bearer tokens from logs.
- Invalidate a code after success.
- Add risk checks for unusual or high-value orders.
Pilot plan
Start with signup or login in a test environment. Then test order changes: valid and invalid code, expiration, concurrent requests, order state changes between send and verify, and attempted code reuse.