Consider a candidate who has found a suitable vacancy, prepared a CV and reached the application portal. The next screen asks for a one-time password (OTP) sent by SMS, or text message. Nothing arrives. They try again, receive two messages in the wrong order and discover that the form has lost their answers.

That is a failure scenario worth testing before launch, not a reason to assume the candidate lacked commitment. If verification is a compulsory gate, an avoidable problem can keep a suitable applicant out of the recruitment system altogether.

For teams serving candidates with Saudi mobile numbers, the task is broader than checking whether an SMS supplier can send a message. The whole journey must work: number entry, delivery, code checking, recovery and final submission.

Decide whether the check needs to be there

Write down the decision that phone verification enables. Are you confirming a contact number for interview arrangements, protecting access to an existing account, or trying to reduce automated submissions? Those are different purposes and need different controls.

Do not require a code simply to read a vacancy. Where the purpose is contact accuracy, consider checking the number when it will actually be used, rather than before a candidate can start. If verification must precede submission, explain that requirement early and provide a protected way to save a draft. Make any “pending verification” status visibly different from “application submitted”.

A correct code indicates access to messages sent to that number at that moment. It does not establish the candidate’s legal identity, nationality, right to work, qualifications or suitability for employment. Keep those assessments separate.

NIST’s Digital Identity Guidelines state that out-of-band authentication, which includes SMS-delivered codes, is not phishing-resistant and treat telephone-network authentication as restricted. This is a security benchmark, not a claim that SMS is banned or that NIST sets Saudi recruitment law. Assess the account’s risks and provide an appropriate alternative rather than assuming SMS suits everyone.

Check coverage and number handling together

Hiring for a Saudi-based role does not mean every applicant already has a Saudi number. State which destinations the portal supports before asking for one, and offer another application route for candidates outside that scope. Do not invite an international talent pool and then silently exclude it at the phone field.

As one geographically relevant example, Tawked documents SMS OTP verification for Saudi mobile numbers through an application programming interface (API), the connection software uses to exchange requests. Its quickstart describes sending a code and checking the code entered by the candidate. That documented scope does not establish compatibility with a particular applicant tracking system or recruitment portal.

For any provider, ask the developer to confirm the supported destinations, live-account requirements, sender arrangements, test restrictions and handling of unsuccessful responses. The checks below are requirements for the recruitment journey, not assertions about a supplier’s built-in features.

Accept local forms such as 05XXXXXXXX and international forms such as +9665XXXXXXXX, where X represents a digit. In the international form, the domestic leading zero is removed. A country selector must not add +966 a second time when a candidate pastes a complete number.

Test spaces, pasted numbers and Arabic-Indic digits. Convert supported input into one agreed format before sending, and show the interpreted number for correction. Check the complete number rather than accepting anything beginning with 05. A plausible format alone does not prove that the number is active or reachable.

Explain the code before sending it

Use plain language: “We will send a code to confirm this contact number for your application.” Show enough of the destination for the candidate to spot a mistake, with an obvious “Change number” control. Explain which sender name they should expect if it differs from the employer or portal name.

The message and the screen should identify the relevant service and action. Tell candidates to enter the code only in the application portal and not share it with a recruiter or support agent. Keep unnecessary application details out of the SMS.

Show the actual expiry and the earliest permitted resend time. Base the countdown on the server’s expiry information, not a fresh timer that restarts when the page reloads. Explain whether a resend replaces the previous code; the wording must match the implemented behaviour. After verification, show the next application step rather than implying the application has already been received.

Give each failure a useful next step

Delayed or missing messages. Keep the destination visible and offer a controlled resend after the stated wait. Do not generate another message every time the page reloads. Where there is a known interruption, explain that the service is temporarily unavailable rather than telling candidates their number is wrong.

An incorrect number. Let the candidate edit it without deleting their CV or answers. Retire the previous pending check and bind the replacement to the corrected number and the same protected draft. Changing a phone number on an existing account needs its own security checks; it is not just a form correction.

Expired or incorrect codes. Distinguish “This code has expired” from “That code did not match”, and provide the relevant recovery action. Keep the application intact. OWASP’s Authentication Cheat Sheet also cautions against responses that reveal whether somebody else’s account exists: helpful error text should not disclose an applicant’s registration or job-search activity.

Repeated attempts. Apply sending and guessing limits on the server, not only by disabling a button. Keep an overall failed-attempt budget across resends, even if a supplier resets its per-code counter. NIST’s guidance explicitly says generating a new secret must not reset the failed-attempt count. Explain temporary restrictions and provide support, rather than encouraging candidates to create another account.

Investigate the whole chain, not just the SMS supplier

Start with a single failed journey and trace it in order. Did the browser accept the number? Did the portal send a request? Did the API accept it, or reject credentials, account status, balance or limits? Where delivery reporting exists, what exactly does its status mean? Did the code check succeed, and did the application system then save the submission?

A successful HTTP response—the response code exchanged between systems—is not automatically a successful verification. The developer must read the documented result inside it. A provider reporting delivery is also not evidence that the candidate read the message, entered the code or finished applying.

Keep API credentials on the server. Associate each verification request with the correct candidate session, destination and draft, and act only on a trusted server-side verification result. Test multiple tabs and repeated requests so that one completed check cannot authorise an unrelated application. Agree safe retry behaviour before automatically repeating a request that timed out.

Use a reference that joins the portal’s events to the provider’s request, where available. OWASP’s Logging Cheat Sheet recommends recording interaction identifiers and excluding sensitive secrets. Record useful timestamps and error categories, not OTP values, API keys, CV contents or unnecessarily exposed phone numbers. Assign a named owner for problems that cross supplier boundaries.

Make recovery accessible on real devices

Use W3C’s Web Content Accessibility Guidelines (WCAG) 2.2 as an acceptance-test reference, including accessible authentication, input errors, timing, keyboard operation and status messages. In its guidance on accessible authentication, W3C explains why a verification-code form must not force manual transcription when assistance such as pasting is needed.

Allow the whole code to be pasted. Prefer one clearly labelled input over separate digit boxes that break paste or keyboard navigation. Google’s SMS OTP form guidance recommends a text input with numeric-keypad and one-time-code autofill hints. Preserve leading zeros, support manual entry, and do not make completion depend on autofill being available.

Test Arabic and English screens on the mobile devices candidates will use. Check the order of digits and the plus sign in right-to-left layouts. Keep labels, errors and controls usable when text is enlarged or the on-screen keyboard is open. Announce meaningful status changes to screen readers without reading out every second of a countdown.

Save progress through app switching, refreshes and code expiry, with a clear retention period and protected access to drafts. Review application-session time limits separately from the code’s lifetime. Making a secret valid indefinitely is not an accessibility solution; provide a fresh-code or alternative route without discarding completed work.

Put help outside the verification gate: a candidate with no working code must still be able to contact support. Give them a reference and a realistic response expectation. Agree how the recruitment team will handle a documented technical problem near a closing deadline, without promising automatic acceptance or asking candidates to disclose a live code.

Use a pre-launch checklist with expected outcomes

Use phone numbers your team controls and test across the networks and devices relevant to the candidate population. Distinguish simulated failure tests from real handset delivery tests: a mocked success response does not demonstrate that a message arrived.

Test case	Expected result
Successful verification and submission	Local and international versions reach the same number. Verification advances the correct draft; a separate receipt confirms the application was saved.
Mistyped or unsupported number	The candidate can correct the input or reach an alternative route before being trapped. No previous code verifies the replacement number.
Delayed, duplicate or out-of-order SMS	The stated resend and code-validity rules hold. Refreshing or double-tapping does not create uncontrolled sends.
Wrong, expired or already-used code	Expiry and attempt limits work. A used code cannot create a new authorisation, including from another tab or session.
Provider rejection or network timeout	The portal gives an accurate next step and records a traceable error. Retrying does not create duplicate applications.
Mobile and assistive technology	Paste, leading zeros, keyboard access, screen-reader messages and Arabic/English layouts work; autofill failure does not block entry.
Refresh, app switching or session expiry	The candidate can resume a protected draft without losing completed work. No draft is exposed merely by entering its phone number.
No usable phone or deadline problem	Help can be reached without verification. The recruitment team has an agreed alternative and escalation process.

Measure three outcomes, not one success rate

Agree event definitions before launch. A message, a verification journey and a submitted application are different units. For reporting, define a verification journey as one attempt to complete the phone-check stage for an application, including its resends; do not count each resend as another candidate.

Message delivery. Where reliable status reports exist, divide delivery-confirmed messages by messages accepted for sending from the same cohort, using an agreed reporting cutoff. Report rejected requests and unknown or pending delivery states separately. State what the supplier means by “delivered”; do not relabel an API acceptance as handset delivery.

Completed verification. Divide journeys successfully verified by journeys that reached the phone-check stage, including input errors and failed sends. Track resends, number corrections, expiry and time to verification. Look at both the typical wait and the slower end of the distribution, such as the 95th percentile—the time within which 95% of completed verifications finish.

Completed applications. Divide applications confirmed as submitted by application starts for the same cohort and follow-up window. Also measure how many verified journeys led to submission. Use the server’s saved-application event, not a button click, a new account or a successful OTP response.

Do not compare today’s sends with today’s submissions when people can return to apply later. Separate authorised test traffic from genuine journeys and allow delayed events to settle. Review patterns by device, interface language and integration release where useful, using limited-access records rather than unnecessary personal data.

A fall in completed verification with stable reported delivery is a reason to inspect code entry, expiry and session handling—not proof of a particular cause. A fall after verification points attention further along the form. An unfinished journey is not automatically voluntary abandonment, and a support report can explain what an aggregate rate cannot.

Treat verification as part of recruitment

The launch question is not simply “Can we send a code?” It is “Can an eligible candidate finish, and can we help when something goes wrong?” A well-designed check confirms the limited fact it is meant to confirm, preserves the application and leaves selection decisions to the recruitment process.