OTP Not Delivered in Ghana? Find Out Why on MTN or Telecel
An OTP not delivered in Ghana has three causes to check, in this order: your sender ID may not be approved on that network yet, the network may be delaying the message, or the phone may be unable to receive it. The delivery report helps you separate them. If you send through Arkesel, a user on a Ghanaian number can retrieve the code by USSD while you investigate, or your app can send a new one by voice.
Why are my OTP messages not arriving on MTN or Telecel in Ghana?
First confirm that your OTP request succeeded. If your provider returned an error, the problem sits in your integration or account, so work through OTP API errors and their fixes before looking at the networks. If you are still setting up, start with the SMS OTP API integration guide.
If the request succeeded, group the failed numbers by network. Failures concentrated on one network while the others deliver suggest something specific to that network, such as sender ID approval or a delay on its side. Failures scattered across a few numbers suggest a problem with those numbers or handsets. This is our own diagnostic reading rather than a rule. Logging the number, network, send time and chosen channel for each OTP request makes this grouping quicker.
In Ghana, Arkesel delivers SMS over direct connections to MTN, Telecel and AirtelTigo. A direct connection does not remove a network’s approval check or a delay on its side, so the same checks apply to Arkesel traffic.
Does my sender ID need to be approved on each Ghanaian network?
Yes. Your sender ID is the name your message shows as its sender. On MTN, Telecel and AirtelTigo, an OTP from an alphanumeric sender ID not yet approved on that network is rejected by the network and shows as a failed delivery in the Arkesel delivery report. It is not delivered under a generic sender, and it is not dropped without a record. A sender ID can be approved on one network and not yet on another, so check each one separately.
Arkesel submits your sender ID to the Ghanaian networks and handles the carrier follow-up on your behalf. If your OTPs are failing on one network, contact Arkesel with the sender ID and the network name, and ask for its approval status there. If you send through another provider, ask how its report shows a rejected sender ID. Also check that your OTP request uses the approved sender ID, spelled exactly as it was submitted.
A sender ID approved for bulk SMS on your Arkesel account also works for OTP API traffic on that account, so there is no separate OTP step. Our guide has the steps for registering a sender ID.
We cannot give you a fixed approval time. Before you set a launch date, submit the sender ID and allow time for approval on all three networks.
How do I tell from the delivery report whether the network rejected the message or the handset was unreachable?
Compare each affected number with others on the same network, because a single row may not tell you the cause. On Arkesel, a message’s status normally updates within about one minute of delivery. That timing starts at delivery, so it does not tell you when a rejected or undelivered message will show a status. We suggest comparing a message with no status against OTPs sent to other numbers in the same few minutes, using the send times you log. If you have no history yet, as on launch day, use how long the status took on your test SIMs. Arkesel sends no failure alerts, so non-deliveries are visible only in the delivery report.
The first row below describes how the networks treat an unapproved sender ID. USSD retrieval and voice OTP in the last column are Arkesel routes for Ghanaian numbers. The other rows are our own reading of the pattern, so treat them as starting points. For what each status name means, see our guide to reading SMS delivery reports.
| What the report shows | Possible cause | What to check | What to offer the user now |
|---|---|---|---|
| Failed across numbers on one network, with other networks delivering | Sender ID not approved on that network | The sender ID’s approval status on that network | USSD retrieval or a voice OTP |
| Failed for one number, with others on that network delivering | Wrong or inactive number | The number your app holds for that user | A chance to correct the number, then a new OTP. If the number is correct, USSD retrieval or a voice OTP |
| No status update on several numbers on one network, while OTPs sent in the same few minutes to other networks have updated | Delay on the network’s side | Whether the sender ID is approved and other networks are delivering | USSD retrieval or a voice OTP |
| Delivered, but the user has no code | Wrong number, a blocking app, or a code that arrived after it expired | The number your app holds, then the user’s phone | A chance to correct the number, then a new OTP. If the number is correct, USSD retrieval or a voice OTP |
Suppose your support team reports on launch day that users on one network are not receiving codes. The report shows failed deliveries for that network, and the other two are delivering, which matches the first row. You would ask for the sender ID’s approval status on that network, show affected users Arkesel’s USSD retrieval route, and hold automatic resends. Once the approval is confirmed, send a live OTP to a test SIM on that network before you tell users the problem is resolved.
If you read statuses through Arkesel’s SMS delivery-status webhooks, allow for their timing. They are batched and dispatched roughly every ten minutes rather than per message, so an OTP can expire before the webhook reaches you. Don’t assume OTP callbacks arrive sooner, and keep the user’s retry option independent of any callback.
While the cause is unknown, hold off on automatic resends. A resend from a sender ID that is still unapproved meets the same rejection, and Arkesel still bills each rejected OTP.
How can I tell whether the network is the cause?
You cannot fix a delay on the network’s side from your application. Suspect it when your sender ID is approved on that network, several numbers there show no status update for longer than your earlier reports or test SIMs took, and OTPs sent in the same few minutes to other networks have been delivered.
Keep the affected numbers, send times and network names to give your provider something to trace.
How can I tell whether the phone is the cause?
Suspect the phone or the number when one user is affected and others on the same network are receiving their codes. Ask the user to work through these checks in order:
- Confirm the number your app holds for them, digit by digit.
- Check that the phone is switched on and has network coverage.
- Check that the message inbox has free space.
- Check whether a message-blocking app is installed.
If the report shows the message as delivered and the number is correct, ask when the code arrived. A code that arrives after its expiry fails at verification, and the user may describe that as a code that never came.
If the number is correct and the user still has no usable code, another SMS OTP may fail the same way, and Arkesel bills it again. For a Ghanaian number on Arkesel, offer USSD retrieval or a voice OTP instead. If the report still shows a failure, give your provider the number and send time.
What can a user do right now if the OTP SMS never arrived?
On Arkesel’s OTP API, a user on a Ghanaian number has two routes, and your app should present both. Both remain available after a network rejects an OTP from an unapproved sender ID: a user in Ghana can still retrieve the code by USSD, and a voice OTP request still goes through. If you use another provider, ask it which recovery routes it offers. Our comparison of OTP API providers lists what to confirm with each one.
Retrieve the code by USSD. After an Arkesel OTP has been sent on either channel, a recipient in Ghana can dial a free USSD code to retrieve it. The user starts this step, and it is not a delivery channel you can select in the API. Arkesel’s API specification shows the dial code in a ussd_code field of the api/otp/generate success response. Show the code from that field rather than hard-coding it, because the code can change. Our guide to retrieving a missed OTP by USSD explains the feature.
Request a voice OTP. Arkesel’s voice OTP delivery is available in Ghana only. You choose the channel per request: api/otp/generate requires a medium field, sms or voice, with no default, and there is no automatic fallback from SMS to voice. To offer a voice retry, add a button that sends a second generate request with medium set to voice. On Arkesel, you can use the existing caller ID or get one dedicated to you, so a dedicated one is not needed first. The Arkesel developer documentation has the rest of the request syntax.
We suggest showing both routes about a minute after the OTP request. That wait is our own suggestion, not an Arkesel figure, so change it if your own reports point to a different one. The wording can be short. For example: “Didn’t get your code? Dial the USSD code shown here to retrieve it, or tap Call me to get a code by voice.”
Limit how many times one user can press that button. Each press is another billable OTP, and our guide to SMS pumping fraud suggests starting limits per phone number.
The comparison of SMS, USSD and voice for OTP delivery covers the trade-offs between these routes, the OTP verification page for Ghana has the product details, and the Arkesel developer API page for Ghana covers the wider API.
What should I check before OTP SMS delivery goes live in Ghana?
- Confirm your sender ID is approved on MTN, Telecel and AirtelTigo.
- Run the OTP generate and verify requests end to end against real test numbers you control.
- Send a live OTP to a test SIM on each network, and note how long its status takes to appear in the delivery report, as your baseline.
- Show your support team where to find the delivery report.
- For Ghanaian numbers on Arkesel, show the USSD retrieval instruction on the code-entry screen, with the dial code taken from the
ussd_codefield. - For those numbers, add a button that requests a voice OTP.
- Before launch, try the voice route and USSD retrieval live on a test SIM, and check which code your flow accepts when a user has tried both.
- Set an expiry within Arkesel’s range of 1 to 10 minutes that leaves the user time to retry. The guide to OTP expiry and rate limiting gives values by use case.
Frequently asked questions
Does the NCA require sender ID registration in Ghana?
No. The NCA does not currently mandate sender ID registration. Approval sits with your provider and the networks.
Am I billed for an OTP the user never verifies?
On Arkesel, yes. OTPs are billed per OTP sent, whether or not the recipient completes verification. An OTP the network rejects for an unapproved sender ID is billed too. Arkesel’s current rates are on the pricing page.
Should I switch my OTP to voice in Ghana, and does the API do that automatically?
Arkesel’s API does not switch for you. We recommend settling the cause first, because a voice retry does not clear an unapproved sender ID. Then you can send voice OTPs to a share of your Ghanaian users and compare how many complete verification. Arkesel’s voice OTP does not reach numbers outside Ghana, so keep SMS for them.
To try this flow before your next release, create an Arkesel account and, once your sender ID is approved, run the generate and verify requests against real test numbers you control.
Phone Number Verification in Nigeria: Cut Fake Signups
Phone number verification in Nigeria: check the NCC format, prove possession by SMS OTP and limit…
USSD Application Testing: Load Tests and the Tools to Use
USSD application testing for Ghana: check every menu path on MTN, Telecel and AT, then load…
Bulk SMS API for Ghana and Nigeria: A Developer’s Integration Guide (2026)
Integrate a bulk SMS API in Ghana with direct MNO connections. Code examples in Python, Node.js,…
