> For the complete documentation index, see [llms.txt](https://getverifycode.gitbook.io/getverifycode-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://getverifycode.gitbook.io/getverifycode-docs/testing-sms-otp-before-launch.md).

# Testing SMS OTP Before Launch

*By Alex Carter, Editor at GetVerifyCode*

Mocks prove your UI wiring. They do not prove carriers will deliver a code in the countries you sell into. Run at least one real inbound SMS path in staging before you call the release done.

## What "ready" means

Treat the SMS path as ready only when all of the following hold:

* Happy-path delivery meets your p50 / p95 target for at least one production country.
* Resend shows a cooldown and rejects the previous code.
* Expired and rate-limited states show clear copy.
* OTP strings never appear in logs, analytics, or error trackers.
* Country picker and dialing code stay aligned for the numbers you accept.

## Minimum matrix

| Scenario             | Assert                                           |
| -------------------- | ------------------------------------------------ |
| Domestic long number | Code arrives within SLO; E.164 paste works       |
| International number | Country picker and dial code stay aligned        |
| Immediate resend     | Cooldown shows; previous code is rejected        |
| Expired code         | Clear expired or invalid message; new code works |
| Provider reject      | Readable error; no silent hang                   |
| Log spot check       | OTP string never appears in events or traces     |

Printable sheet: [test matrix](https://github.com/GetVerifyCode/otp-sms-testing-checklist/blob/main/docs/test-matrix.md).

## Full checklist

The maintained checklist lives in two places:

* Interactive (local progress): [getverifycode.github.io](https://getverifycode.github.io/)
* Copy-paste for tickets: [CHECKLIST.md](https://github.com/GetVerifyCode/otp-sms-testing-checklist/blob/main/CHECKLIST.md)
* Repository: [GetVerifyCode/otp-sms-testing-checklist](https://github.com/GetVerifyCode/otp-sms-testing-checklist)

Cover input formatting, delivery, validation, and security. Fail the release if any security item is unchecked.

## Using temporary inbound numbers in QA

Personal SIMs do not scale across countries. A temporary inbound number lets QA exercise live routes without sharing private phones.

On [GetVerifyCode](https://getverifycode.com/), pick the service and country, reserve a number for about 20 minutes, and read the SMS in the inbox. If no SMS arrives, the held amount returns to your wallet. Top up your wallet from $1; each number is priced live.

Only test apps you own or are authorized to test. Follow each platform's terms and local law. Some platforms reject virtual ranges; document that as a known constraint, not a flaky test.

## After launch

Keep a thin smoke path in CI or a weekly manual run: one domestic send, one resend, one log scan. Carrier behavior changes. A checklist that only ran once will rot.

## Related

* [How SMS Verification Works](/getverifycode-docs/how-sms-verification-works.md)
* [When the OTP SMS Does Not Arrive](/getverifycode-docs/when-otp-sms-does-not-arrive.md)
* Product blog: [QA checklist for SMS OTP testing](https://getverifycode.com/blog/qa-checklist-sms-otp-testing)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://getverifycode.gitbook.io/getverifycode-docs/testing-sms-otp-before-launch.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.