Ecommerce Website Development in Pune: Mobile-Number OTP Login for Your Online Store — SMS, WhatsApp, DLT Rules and What to Build

Ecommerce Website Development in Pune: Mobile-Number OTP Login for Your Online Store — SMS, WhatsApp, DLT Rules and What to Build

For an Indian online store, mobile-number OTP login means the customer types a phone number, receives a one-time code by SMS or WhatsApp, enters it, and is signed in without ever creating a password. It usually suits Indian shoppers better than email and password because the mobile number is what they already use for orders, delivery calls and payments. Good ecommerce website development in Pune builds it with three parts working together: a delivery channel that reliably gets the code to the phone, rules that stop abuse and runaway costs, and a fallback for people who cannot receive the code.

This guide is for store owners and product managers deciding whether to replace or supplement email-and-password login with OTP. We cover why OTP fits India, how SMS and WhatsApp delivery differ, what the telecom regulator's DLT system means for an SMS OTP, how to build the flow safely, how to keep it from being abused, what it costs to run in general terms, and how it fits with newer options such as passkeys. We do not quote provider prices, because they change and depend on volume and contract. Check each provider's current rate card.

The short version

• Offer OTP login with the mobile number as the identity, and let guests check out without any account.
• Use SMS OTP as the base because it works on any phone. Consider WhatsApp OTP as a second channel where your customers are on WhatsApp.
• If you send SMS in India, expect to register on a DLT platform with your entity, sender header and OTP template before messages will be delivered.
• Limit the number of codes a number or device can request, and put a cap on total daily sends. An open OTP endpoint is a way for someone else to run up your bill.
• Always have a fallback, such as email or a resend after a delay, and never lock a customer out because one message failed.

Why OTP suits Indian stores

Three reasons come up repeatedly in the stores we build.

The phone number is the common identifier. Delivery agents call it, cash-on-delivery orders are verified against it, and customers receive order updates on it. Making it the login means one identity across the whole journey.

Passwords are friction on mobile. Typing a new password on a small keyboard, then forgetting it, is a leading cause of abandoned sign-ups. Most shoppers will pick the guest option or leave.

It supports repeat purchase. Once a customer is verified, you can show past orders, saved addresses and reorder buttons. Our guide to donor and customer account pages shows the same pattern used for giving history on a non-profit site, and the idea transfers directly to order history in a store.

OTP is not a cure-all. It depends on phone reception, a working message route and a phone that the customer controls. Shared family phones, a lost SIM or a number in a different state may all cause trouble, which is why a fallback matters.

Where OTP belongs in the store

Do not force login at the first step. Think of three places it can appear.

1. At checkout, as verification

The customer enters a phone number as part of the delivery details, and you send an OTP to confirm it is real and reachable. This is also the most effective place to reduce fake orders. If cash on delivery is on offer, a verified number reduces wrong-number orders. Our guide on fake orders and bot protection at checkout covers the wider set of controls, and guest checkout and form design covers how to ask for details without losing buyers.

2. After checkout, as account creation

After the order is placed, offer "Track your order and save your address" with the number already filled in. The customer has just verified it, so creating an account costs one tap.

3. At the account page, as login

Returning customers enter their number, receive a code and see their orders. Keep the screen simple: one field, one button, then one code field.

SMS or WhatsApp for the code

Both are used in India. They have different strengths.

A common design is to send by WhatsApp when the customer has previously interacted with you there, and by SMS otherwise, with a "Send by SMS instead" link. Whichever you choose, make the message path configurable, because providers and prices change.

For a deeper look at how WhatsApp message categories are priced, see WhatsApp Business API pricing in India and the difference between utility and marketing templates. Authentication messages are a separate category, so confirm current charges with your provider. If you want WhatsApp tied into the store, our WhatsApp Business API service page describes the setup.

What DLT registration means for SMS OTP

India's telecom regulator requires commercial SMS to be sent through registered channels, and operators enforce this through a distributed ledger system known as DLT. According to the documentation published by SMS providers, the broad steps are:

1. Register the business as a Principal Entity on an operator's DLT portal, with KYC documents. The operator issues an Entity ID. Providers commonly mention a processing time of a few days, but this varies.
2. Register a header (the sender name customers see). Alphabetic headers are used for transactional and service messages, while numeric headers are used for promotional traffic. Providers advise that the header should relate to your business name.
3. Register an OTP template with the exact message structure, including variable fields such as the code. Each template receives a Template ID.
4. Send through a provider that passes your Entity ID, header and Template ID with each message.

Operators validate each message against what you registered. Messages that do not match your registered entity, header or template can be blocked. In practice, this means:

• You cannot change the wording of an OTP message in your code without updating the template.
• Test messages from a trial account may not behave like production.
• You should keep the Entity ID, header and Template ID in configuration, not scattered through the code.

The detail of the rules, including fees and categories, comes from the regulator and the operators, and has been revised before. We have summarised provider documentation here, not the regulation itself, so confirm the current process with your SMS provider and the operator portal before you start. Allow time for it: it is common for DLT approval, not code, to be the longest part of an OTP launch.

How to build the flow safely

The mechanics are simple. The details decide whether it is secure and affordable.

Generate and store the code properly

• Use a cryptographically secure random generator for a six-digit code. Do not derive codes from the time or the phone number.
• Store only a hash of the code, with an expiry. Five minutes is a common expiry, but choose a value that fits your audience.
• Make each code single-use. Delete or invalidate it after a successful check.
• Tie the code to the specific number and session that requested it.

Verify with limits

• Allow a small number of wrong attempts per code, such as five, then invalidate it and require a new request.
• Use constant-time comparison where your framework offers it.
• After verification, issue a normal session token with a sensible lifetime, set as a secure, HTTP-only cookie.

Rate limit requests

The sending endpoint is where abuse happens. Limit:

• Requests per phone number within a window (for example, one new code per minute and a handful per hour).
• Requests per IP address and per device.
• Total OTP sends per day for the whole store, with an alert when the count rises sharply.

Without these limits, a script can trigger thousands of messages to numbers it does not own. This is sometimes called SMS pumping or toll fraud, and the cost falls on you. Alongside rate limits, add a bot check such as a CAPTCHA or an invisible challenge that appears only for suspicious traffic. See contact form spam and bot protection for options that do not punish genuine visitors.

Handle delivery failures honestly

Show a clear "Code sent to +91 98xxxxxx21" confirmation with the number partly masked. Offer "Resend code" after a countdown, and "Change number" and "Use email instead" links. Log the delivery status returned by your provider so support can see whether a message was delivered.

Support autofill

Format the SMS so that browsers and phones can offer the code automatically. Android and iOS support one-tap autofill from messages, and the web has a WebOTP API on supported browsers. Set the input field attributes so the keyboard suggests the code, and keep the code near the start of the message. Test on a few real handsets, since behaviour differs between devices.

Edge cases that cause support calls

• Customers with two numbers. Allow adding a second verified number to an account instead of creating a duplicate.
• Numbers that change owners. Telecom operators recycle numbers. If a customer changes their number, they need a way to recover the account, for example through email verification or a support check.
• Shared phones. A family phone may be used by several people. Do not treat the number as proof of one individual. Keep payment details out of the account unless re-verified.
• International customers. If you serve customers outside India, local SMS may not work. Offer email OTP or a standard sign-in. See international checkout for Indian stores.
• Poor reception. Some customers will not receive the message at all. Provide email OTP as an alternative route.
• Accessibility. Make sure screen readers announce the code field and any errors, and allow pasting.

Data protection and consent

An OTP flow collects a phone number, which is personal data. The Digital Personal Data Protection Act and the Rules notified in November 2025 are being phased in. Our own guide to DPDP compliance for websites and the consent manager framework for CRMs explain the direction in plain language. For an OTP login, the sensible practices are:

• Tell customers why you are asking for the number and how you will use it, at the point of asking.
• Keep marketing consent separate. Verifying a number for login is not permission to send promotions.
• Store the number securely, and keep logs of OTP delivery only as long as you need them.
• Provide a way to delete the account and the data you do not have to retain.

This is general information, not legal advice. Ask your lawyer to review the notice wording.

OTP, passwords and passkeys together

OTP is not the end state. Newer options are arriving, and the sensible approach is layered.

• OTP is the easiest for most Indian shoppers today.
• Passkeys let customers sign in with a fingerprint or face unlock on a device, with no code to intercept. See why passkeys are replacing passwords. A good flow can offer "Use a passkey" after the first OTP login so that later logins are faster and do not cost a message.
• Passwords can remain as an option for customers who prefer them, though many stores no longer need them.

Because each SMS or WhatsApp code costs money, moving repeat customers to passkeys or long-lived sessions can reduce your sending bill as well as improve security. Keep sessions long enough that returning customers are not asked for a code every visit, but require a fresh code for sensitive actions such as changing an address or phone number.

Cost and how to estimate it

We do not quote a price per message, since it differs by provider, volume and category. You can estimate the monthly running cost with a simple method:

1. Count monthly logins and checkouts that require verification.
2. Multiply by the average number of codes sent per verification, usually a little over one because of resends.
3. Multiply by the per-message price on your provider's current rate card.
4. Add a margin for abuse protection and failed sends.

Compare the result with the value of the orders that verification protects. For stores with high cash-on-delivery returns, even a small reduction in fake orders can outweigh the message cost.

Setup costs are separate: DLT registration, provider onboarding, and development time. A basic OTP flow on a custom or WooCommerce store is a small build. On Shopify, native customer accounts and third-party apps cover much of it, with limits on how you can customise the flow. Our article on choosing between Shopify and WooCommerce explains what each platform lets you change.

Testing before launch

Test on real devices and networks, not only on a developer laptop.

• Request a code on Jio, Airtel, Vi and BSNL numbers if your customers use them.
• Check delivery time at busy hours and when the phone is on a weak signal.
• Try expired codes, wrong codes, reused codes and many rapid requests, and confirm each is blocked.
• Confirm the daily sending cap and the alert work.
• Check autofill on at least one Android phone and one iPhone.
• Test with email fallback and with a changed number.
• Read the message the customer sees: brand name, code, expiry and a warning not to share it.

Our pre-launch testing checklist for ecommerce sites covers the rest of the store.

A build plan for a Pune store

1. Decide where OTP appears: checkout verification, account creation, login.
2. Choose SMS, WhatsApp or both, and an approved provider.
3. Start DLT registration early if you are using SMS.
4. Design the screens, including resend, change number and email fallback.
5. Build code generation, hashed storage, expiry and attempt limits.
6. Add rate limits, a daily cap and abuse alerts.
7. Add consent wording and a deletion route.
8. Test across networks and devices.
9. Launch to a small share of traffic first, watch delivery and cost, then widen.

If you would like help designing or building this, see our ecommerce development service and checkout system service pages. Govindani Infotech is a web development company at Landmark Plaza, Satara Road, Parvati Paytha, Pune, and you can talk to the team on WhatsApp. Pricing is confirmed by the team on WhatsApp.

Frequently Asked Questions

Is OTP login safe enough for an online store?

It is reasonably safe when the code is random, expires quickly, can be used once, and is protected by attempt and rate limits. It is weaker against SIM swapping and interception than passkeys, so use extra checks for sensitive actions such as changing a phone number or saving payment details.

Do I need DLT registration to send an SMS OTP in India?

According to SMS providers, yes. Commercial SMS in India is expected to go through registered entities, headers and templates on operators' DLT platforms, and unregistered messages can be blocked. Confirm the current process with your SMS provider before you build.

Should I send OTP by SMS or WhatsApp?

SMS reaches any phone with a signal, while WhatsApp reaches only people who use it but can be quicker and offer a copy-code button. Many stores offer one as the default and the other as a fallback.

How do I stop people abusing my OTP form to send thousands of messages?

Limit requests per number, IP address and device, cap total daily sends, add a bot check for suspicious traffic, and set an alert for sudden spikes. Without limits, an open OTP endpoint can run up large message costs.

Can I let customers buy without any login?

Yes, and you should. Guest checkout with an optional OTP verification of the phone number keeps friction low. Offer account creation after the order, when the number is already verified.

Sources

• SMS provider documentation on DLT registration for India (Plivo, Infobip, Fast2SMS and similar), for the Principal Entity, header and template steps. These are secondary sources, not the regulator's text.
• Meta documentation for WhatsApp Business Platform authentication templates, for the one-tap and copy-code features. Check current pricing on Meta's pricing page.
• Press Information Bureau, Digital Personal Data Protection Rules, 2025, for the notification of the Rules.
• web.dev guidance on the WebOTP API and SMS receiver.

The comparison table, the abuse limits and the cost-estimation method are our own working guidance, not figures from those sources.