Consider a hypothetical workshop-booking service for customers with Saudi mobile numbers. Its founder asks a prospective provider whether it can handle OTP login. The answer is that it can send verification codes. That leaves a purchasing question unresolved: who decides that the person entering a code may access a particular account?
An OTP, or one-time password, sits inside a wider account-access process. Before buying a service, separate the questions about moving the message from the questions about granting access. Then identify what the provider supplies, what the application must do and what evidence supports each answer. A favourable delivery demonstration cannot settle all three.
Define what each status means
Request acceptance, reported delivery, code validation and session creation are different events. Depending on the API, an acceptance response may acknowledge a queued request rather than a completed send. Ask what each status means, which system produced it and whether it can arrive late or remain unknown. A delivery report does not establish that the customer entered the correct code.
Validation checks a submitted code against the rules for a particular verification request. Creating an authenticated session lets the customer continue using the application after authentication. The buyer needs to know how the result of the first operation reaches the system responsible for the second. A label such as “verified” is useful only when its meaning and permitted use are documented.
Timing claims need similar care. If a proposal quotes delivery speed, ask when measurement begins, when it ends, what period the evidence covers and which delays are excluded. Establish whether the statement is an estimate or a contractual commitment. An API response time does not measure arrival on a handset. Ask how an accepted request without a final status is investigated, what reference support needs and when support is available.
Assign responsibilities before comparing prices
Services sold under the OTP label can divide the work differently. A delivery service may transport a code supplied by another system. A managed verification service may also generate the code, check submissions and enforce expiry. An authentication platform may manage accounts and sessions as well. Confirm the precise product and integration mode being purchased; the supplier’s broader catalogue is not the scope of the order.
For the fictional booking service, the team could record that its chosen verification component generates and checks codes, while its application associates each verification request with the intended account and login attempt. Its application or authentication platform would then issue and manage the session. This is a hypothetical allocation, not a description of every provider. Each responsibility needs a named internal owner, including those implemented externally.
For a service aimed at Saudi mobile-number users, Tawked is a possible SMS OTP component. Its public API reference describes sending codes to Saudi mobile numbers and separate operations to start a verification and check the submitted code. That documented scope belongs in the comparison. The team should still establish how its chosen setup connects verification to its own account-access rules.
Make the allocation concrete: record the function, provider evidence, application work, responsible person and any unresolved dependency. If a feature is undocumented, mark it as an open question. “Shared responsibility” needs an explanation of the handover, such as who receives a verification result and who decides whether it authorises this login.
Examine the controls behind the code
NIST SP 800-63B-4 provides a useful technical reference for SMS-based authentication. Its out-of-band verification guidance addresses random code generation, limited validity, one-time acceptance and limits on failed attempts. It also says that generating a fresh code must not reset the failed-attempt count. These points help a buyer ask who implements each control and where enforcement occurs; they do not establish that a particular supplier meets the guidance.
Keep message-request limits separate from guessing limits. A cap on outgoing messages does not explain how many incorrect submissions a verifier permits. Ask what happens across resends and parallel login attempts, which settings are configurable and who approves changes. Choose the configuration against the application’s risks and applicable requirements. Neither a provider default nor a value used in a demonstration is automatically suitable for production.
The application must associate the verification result with the intended account and purpose. It should obtain and validate that result through its trusted backend or authentication platform, rather than accepting a browser’s claim that verification succeeded. The session owner must separately account for session protection, expiry and logout. Confirming access to a newly supplied number must not, by itself, authorise access to someone’s existing account.
The choice of SMS also deserves a business decision. Within its authentication framework, NIST classifies telephone-network authentication as restricted and identifies risks such as SIM changes. SMS authentication is not phishing-resistant. Receiving a code is not certification of a person’s legal identity. Decide whether this method is appropriate for the account and actions involved, and whether stronger authentication is needed.
Make failures diagnosable without exposing secrets
Ask for documented errors that let engineers distinguish an unsupported number, a rejected request, a usage limit and a temporary provider problem. Map those details to customer messages that offer a useful next step without revealing whether a particular person has an account. Keep the technical diagnosis in restricted operational records. A missing response also needs a defined treatment: it may leave the outcome uncertain, so retry behaviour should address duplicate requests and possible charges.
OWASP’s Secrets Management Cheat Sheet supports restricting access to credentials and planning for their rotation and revocation. Ask who can obtain production API keys, who can replace them and how access is removed when someone leaves. Keep provider secrets on the server, outside browser code and mobile application packages. Establish separate credentials and permissions for testing where supported, and document any limitation before using the service.
Request a sample diagnostic record. Useful fields can include a request reference, time, error category and outcome. Exclude OTP values, API credentials and usable session tokens from routine logs and support tickets. Minimise or mask phone numbers where full values are unnecessary. Ask what the provider retains, who can see those records and how long both sides keep them. Support should be able to investigate a request without asking a customer to disclose a login code.
A compact worksheet for evaluating a proposal
For each candidate, record the answers, dated evidence, internal owner and remaining application work. Treat undocumented capabilities as open questions.
| Decision area | Question to resolve | Evidence and owner to record |
| Saudi-number scope | Which mobile numbers and formats are accepted? What is excluded? | Coverage and input rules; owner of number handling. |
| Acceptance and status | What does each status establish? How are unknown outcomes investigated? | Status definitions; request references; investigation route. |
| Timing and support | What timing is promised? Which exclusions and support hours apply? | Measured events; written commitments; escalation contact. |
| Code controls | Who owns generation, validation, expiry, reuse and guessing limits? | Control definitions; resend rules; configuration owner. |
| Errors and sessions | Who handles errors, binds the result and manages the session? | Error mapping; secure result handling; session owner. |
| Credentials and logs | Who can use or revoke keys? What sensitive data is retained? | Access roles; log redaction; retention rules; owner. |
| Testing arrangements | What is simulated? Which real numbers and scenarios may be tested? | Approved scope; costs and limits; trial evidence and its limits. |
| Service interruption | Which actions pause? Who responds? What alternatives are approved? | Outage and retry rules; escalation and recovery owners. |
Agree on trial evidence and interruption plans
A trial should resolve purchasing uncertainties. Establish whether test mode simulates delivery or sends real messages, which destinations are authorised and what charges or limits apply. Ask which failure outcomes can be demonstrated within the agreed test arrangements. Simulated success can help establish that the application handles a response; it cannot establish handset delivery performance. Record the networks and conditions actually covered, so trial findings are not later presented as a general delivery guarantee.
Return to the fictional booking service during a hypothetical interruption. It may keep public workshop listings available while pausing actions that require fresh verification. Existing sessions would follow the service’s established session policy. If an alternative authentication or recovery route is offered, it should already have been approved and implemented. Support should not improvise an account-access exception because SMS is delayed.
Ask who detects an interruption, who updates customers and how the provider communicates progress. Decide what happens to outstanding requests and delayed codes after recovery. Automatic retries need limits. Switching suppliers needs an agreed way to handle pending verifications without reviving expired codes, resetting failed-attempt limits or losing the link to the intended account and action. Establish whether the fallback can continue an existing verification or must begin a new one.
Before committing, assign each unresolved item an owner and a decision date. Compare price with the engineering and support work your team must supply. The founder should be able to explain how the code reaches a customer and which system can turn a valid result into account access.
