A practical guide to clear error messages, recoverable interruptions, and server-side checks for developers and small-business website owners.

A signup process can work perfectly when the correct code arrives right away, yet it can still fail if the user mistypes a number, switches networks, or presses Resend twice. The valuable prelaunch question doesn’t simply concern whether a message has arrived; it is rather ‘What occurs when the expected sequence is broken?’

An one-time password, or OTP, is a temporary code which is used to show that access to a delivery channel exists. You should test the entire process: entry of the number, request for the message, entry of the code, verification, and then the application’s final update to the account. Separate requirements are needed for a helpful screen and a secure server.

Set up a clearly defined hypothetical service

In this guide, consider a small website for booking appointments which accepts only Saudi mobile numbers. It sends a six-digit code via SMS and requires a successful phone verification before an account can be activated. This is a hypothetical service together with a suggested test plan, not a report on actual testing or measured delivery performance.

Use a staging environment, that is, a version of the application that is not made public, and make use of destinations that your team owns or has permission to use. Where it is possible, simulate failures in delivery and unusual response sequences. Before sending anything, check the provider’s testing rules since a test key doesn’t always mean that the messages are simulated or free.

1. Test country codes before sending a message

Next to the phone field, indicate ‘Saudi mobile numbers only’. In this case, a local number in the form of 05XXXXXXXX or its international version, +9665XXXXXXXX, may be accepted. Each X stands for a digit, not a digit to send to. The domestic leading zero is omitted when using +966; the examples given here describe the format, not every possible assignment of mobile numbers.

Try using the same authorised number in all the forms, once with spaces, once with hyphens, and once by pasting it from a contact. Also test a number that has the country code duplicated and one that is an international number which incorrectly keeps the domestic zero. If the interface shows a fixed +966 prefix, then clarify whether users should only enter the digits that remain. Do not automatically add the prefix twice.

Specify the presentation characters and numeral forms that the application will accept and test both Arabic-Indic digits and Western digits. Any conversion carried out must be deliberate and consistent between the browser and the server; do not assume that the provider will carry out the conversion. Instead, reject ambiguous input.

On the server, the accepted input should be parsed into one standard international format, usually referred to as E.164, together with the enforcement of the service’s Saudi mobile number restriction. Although a maintained library of phone numbers assists with the formatting rules, it is still necessary to carry out application-specific checks. According to Google’s libphonenumber FAQ, the organisation clearly separates the validity of a number from whether it is assigned to a specific person or not reachable.

2. Make incorrect numbers easy to correct

If an empty field is submitted, or if the number contains too few or too many digits, letters, a landline number, or is from a country that is not supported, appropriate explanations should be provided without actually delivering them. The message ‘Enter a Saudi mobile number’ is more helpful than ‘Error 422’. Make sure the value that has been entered is preserved so that the user can correct it.

A number that is almost correct but has one digit wrong might pass all the format checks. On the code screen display the destination in masked form and include an accessible ‘Change number’ action. When the number is changed, the old sign-up challenge must be invalidated and the server record that links the verification attempt to the destination must be altered. A code sent to the original number must never be able to verify the replacement.

Adhere to W3C’s form-notification guidelines by identifying the erroneous field, providing a textual description of the issue, and ensuring that dynamic feedback is available to assistive technology; a red border by itself is not sufficient. Make sure that focus remains usable after the error has been corrected.

Separate the formatting of the feedback from the account details. According to OWASP’s Authentication Cheat Sheet, differences in messages and responses can indicate whether or not an account exists. When carrying out tests, compare both numbers from registered and unregistered accounts, looking at both the response bodies and the status codes, not just the wording.

3. Rehearse delays and repeated send requests

Simulate a slow send response, a delayed message, repeated clicks, and two messages arriving in the wrong order. Each of the states should have a clear meaning. The fact that the server has accepted a request does not mean that the message got to the handset, and the fact that a message has been delivered does not mean that the person has completed verification.

Instead of leaving a spinner there when the application is waiting, explain the next step. Display the destination, keep the number correction option available, and only allow another request when the server’s resend policy permits it. A resend countdown is a waiting period, not necessarily the expiry timer for the code.

When it comes to the hypothetical booking service, select and record a replacement policy whereby a deliberate resend results in a new code being issued and the original code being canceled. Make sure that both the provider and the application actually implement this policy; with regard to other integrations, they might reuse an unexpired code; the screen should describe the behavior that is in fact being used, not make an assumption.

Ask for code A, request that it be replaced with B, and then attempt to use A after B has been created. Under the replacement policy described in this example, A should fail. Deliver A late and make sure that the interface does not lead users to trust the message that arrived last. The order in which messages arrive is not evidence of which code is still active.

The button being disabled helps normal users prevent them from clicking it twice, but this is not an abuse control; if you refresh the page, open a second tab and then make the request using the application’s test client, the server must still enforce its waiting periods and send limits.

4. Check expiry, reuse, and simultaneous submissions

Check the code both just before and just after the specified expiry boundary; the decision has to be based on the authoritative server time. The page should not be refreshed, the device clock should not be changed, or the browser should not be returned from a backgrounded state in order to bring back a challenge that has expired. Provide instructions on how to request a new code without treating the account as verified.

Enter a valid code, enter it once more, and enter it at the same time using two requests. Furthermore, try this procedure with a different pending sign-up and after having changed the destination. The application must permit only one completion of the intended operation, with no transfer of that authorization to another account, number, or session.

The final state change should be atomic so that the checks to ensure a challenge is not already in use and the act of consuming it must not consist of two separate steps which could both be passed by simultaneous requests. It is possible for a safe retry to find that the same operation has already been completed. This is different from interpreting a previous success as giving permission for a new sign-in.

NIST SP 800-63B-4 provides an authentication reference for limited lifetimes, single-use secrets, and failed-attempt controls. Its out-of-band authentication requirements also state that generating a replacement secret must not reset the failed-authentication count. Use that distinction when evaluating a provider’s counters; a new code must not become an unlimited supply of fresh guesses.

5. Test the code field as an actual user would

The Google document on “best practices for the SMS OTP form” suggests using a text input field with inputmode=”numeric” and autocomplete=”one-time-code”. The code should be treated as text in order that any leading zero is retained. MDN states that inputmode is a hint regarding the keyboard to be used, not a validation rule. Nevertheless, none of these attributes serve to verify the code.

Type the code, paste the complete code, accept an autofill suggestion, delete a digit, and correct a character in the middle of the entry. Include a code that starts with zero; determine whether the application removes the surrounding whitespace or converts supported numeral forms, and then carry out the same tests on the server. Instead, reject any unexpected content rather than simply truncating it.

A single input that is clearly marked is a simple starting point. When the design includes individual digit boxes, copying and pasting the complete code must cause those boxes to be filled in correctly, and the Backspace function should not hinder the user. The W3C’s accessible-authentication guidance specifically mentions the problem caused when websites prevent users from pasting their verification codes.

Use the Tab key, Shift+Tab, Enter, and the keyboard alone to complete the flow. Make sure that the current focus is visible, the field labels can be seen, any error messages are announced, and that the number can be edited. Then carry out the same steps on actual mobile devices, including switching to the messaging app and then returning to it. Although autofill support differs, manual entry and pasting must still be usable when automatic assistance is not available.

6. Interrupt the network at the awkward moments

The Offline and throttling options available in Chrome DevTools’ Network panel are designed for testing scenarios in which the browser connection is lost or slow; however, these features have no effect on the browser’s network traffic and do not mimic the SMS carrier’s delivery process. Instead, you should use controlled application responses to simulate provider delays and carry out authorized handset tests for the message.

Break the connection before the send request is carried out, after the server has accepted it but before the browser gets the reply, and during the code check. It is also necessary to simulate the server finishing its verification even though its response is lost. These constitute separate scenarios, even if the browser shows the same network error.

A timeout should be regarded as an unknown result, not as evidence that nothing has occurred; when it is safe to do so, retain the pending journey and have the backend match its recorded state. Do not automatically generate a new send each time the browser attempts to resend, and do not refer to an interrupted code check as being the wrong code in the absence of a definite result.

If the provider includes idempotency information for an endpoint, then use it. An idempotency key is used to identify a single intended operation so that when a retry is made it will return the result that was previously obtained rather than carrying out the action again. The key should be reused when retrying the same request, not when carrying out an intentional replacement. It must not be assumed that every endpoint behaves in the same way when retrying.

When the connection is reestablished or when the page is refreshed, make sure that the appropriate state is restored for the ongoing pending session—that is, waiting, expired, failed, or already completed. A verification that has been completed should not result in the creation of duplicate accounts or cause downstream actions to be carried out again. If it is not possible to determine the result, then leave the account as unverified and provide a controlled recovery procedure, not an authentication bypass.

7. Verify the server, not just the green tick

Just making sure a browser field has six digits only checks the format — a fake six-digit string could still pass that test. The backend of the app needs to validate the input, link the challenge to the right pending sign-up and destination, and get the real verification result from its trusted verification system.

OWASP’s Input Validation Cheat Sheet says it’s best to use browser validation for usability and server-side validation for security, since browser checks can be bypassed. In staging, remove any interface restrictions or just send the request directly to your app’s endpoint. The client’s “verified” flag must never be enough to activate an account.

Look at the verification result, not just the HTTP status, because the status only tells you how the network request was handled. A response can show HTTP 200 while the body says the code is invalid or expired. If the result is missing, malformed, or negative, it should not be treated as a success. Keep the provider’s credentials on the server side and protect all traffic between the browser and server, and between the server and the provider, with HTTPS.

EnforcSet separate limits for wrong code attempts and message requests. Apply them at meaningful scopes — like the pending challenge, the normalized destination, and the account if it exists — and add network-based controls when needed. Since people in the same office or on the same mobile network might share an IP address, relying on IP address alone shouldn’t be the only factor. Counters should be tracked server-side, updated safely across simultaneous requests, and tested to ensure that new tabs, page reloads, resends, or newly created challenges do not bypass the relevant cumulative budget. For each limit, test the last allowed attempt, the first blocked attempt, and recovery after its window expires. Also test restriction behavior so an attacker cannot turn an easy-to-trigger permanent lockout into a denial of access for someone else.

Set a sending budget and have a response plan for unusual spikes in request volume. Make sure you record enough information to diagnose issues, such as a correlation identifier, timestamps, the stage of the process, and the outcome. Following OWASP’s Logging Cheat Sheet, don’t log authentication secrets or access tokens, minimize how much phone number data is exposed, and limit who can access the logs. A support agent shouldn’t need the user’s live code.

8. Separate provider functions from application safeguards

Tawked is one provider a team building this Saudi-number flow could evaluate. Its public verification reference documents SMS delivery to Saudi mobile numbers, code checking, verification status, and resend and cancellation operations. Review the current documentation, destination restrictions, and account configuration before deciding which capabilities to expose.

The provider handles the operations it documents, but the website is still in control of the user journey and makes all the authorization decisions. The app must link the results to the correct account and purpose, control retries and cumulative abuse limits, complete actions only once, and manage sessions and recovery. The fact that a provider has limits doesn’t mean all the app’s own security controls are in place.

Find out how each counter is scoped and what triggers it to reset. Check exactly how an expired code, a resend, and a repeated successful result are handled. Confirm any additional delivery channels separately. Just because the provider supports Saudi mobile numbers doesn’t mean it supports international numbers, and having a messaging feature doesn’t mean it’s an authentication feature.

9. Describe success accurately

A completed phone check shows that someone entered the required code for that delivery method and challenge. It doesn’t prove the person’s legal identity, age, location, or that they’re entitled to an account. Having a Saudi mobile number doesn’t mean the user is a Saudi citizen.

OWASP’s Multifactor Authentication Cheat Sheet lists phishing and SIM swapping as risks with SMS, and Google’s SMS guidance also mentions number recycling. Sensitive accounts need an authentication and recovery design that takes those risks into account. Don’t describe phone verification on its own as identity proofing or say it guarantees that the person is trustworthy.

Prelaunch test checklist

Run this checklist in staging, then do the same end-to-end tests with the production setup. Record the actual outcome, the device and browser, the time, and a safe correlation identifier for each case. Only mark a case as complete after checking both what’s on the screen and what’s in the server state.

Launch when each failure has a clear next action and a server-enforced outcome, not merely when one test code arrives.