SMS Not Delivered? Build a Useful Support Report
Separate number rejection, missing codes and delayed messages. Collect safe timestamps and order references so support can investigate SMS delivery faster.
By PhoneBorn Team3 min read
Quick answer: a useful SMS support report says what stage failed, when it happened and which order or line was involved. It does not need the secret code, your password or a screenshot containing every message in your inbox.
Identify the failing stage
"My number does not work" describes several different problems. The number might not be assigned yet; the app might reject it before sending; the app might say a code was dispatched but nothing arrives; or a delivered code might be expired. Each symptom points to a different next step.
Write down the last successful stage. If the line is visible and active but a particular app refuses it immediately, do not report that as a carrier-delivery failure. If an SMS arrives but the app rejects the code, preserve the time and error category rather than assuming the inbox is broken.
Inspect the basics once
Check the country selector, full number, product and order status. A single-use OTP order may apply to one service within a defined window; a retained plan has a different lifecycle. Make sure you are opening the correct inbox rather than an older order.
Follow the sending app's countdown. Repeated requests can produce overlapping sessions and delayed older codes. A support report is clearer when you can identify one deliberate request and its result.
Use a concise diagnostic template
| Field | Safe information to provide |
|---|---|
| Reference | Order ID or number reference requested by support |
| Time | Date, time and timezone of the attempt |
| Service | The app or sender you expected |
| Stage | Rejected number, no SMS, delayed SMS or rejected code |
| App response | Error wording with private details removed |
| Comparison | Whether other ordinary messages arrive, if known |
Do not fabricate a comparison test. If you have not checked other senders, say "not tested". That is more useful than a vague claim that everything else works.
Separate evidence from sensitive content
Redact unrelated messages and full verification codes from screenshots. Support may need an order reference or number to locate the line, but it should not need your login password, seed phrase or private API key. For suspected account compromise, use the appropriate account-security process rather than a routine delivery ticket.
For a payment-related provisioning delay, include the invoice reference and chain transaction hash through the official support channel. Do not post these details publicly and do not send another payment just to see whether it triggers activation.
Choose the right next action
An explicit platform rejection calls for reading that platform's requirements. A pending order calls for checking provisioning status. A missing SMS after an accepted request may need delivery investigation. A received but invalid code calls for checking session, expiry and whether a newer request replaced it.
PhoneBorn's replacement policy explains the available route for eligible number problems. An unrelated app's decision does not mean every line is unusable, and replacing numbers repeatedly is not a sound way to diagnose restrictions.
Should I include the OTP itself?
No. Describe that it arrived and when. Keep the code within the official verification flow.
Can support guarantee delivery from a third-party app?
The sender controls its own dispatch and acceptance rules. Good evidence helps identify the responsible stage; it does not remove those rules.
Next: SMS versus voice codes or missing-code causes.