"I never got the code" is one of the most common messages a money transfer support team receives. Without evidence, the agent can only ask the customer to try again, and every retry is another code sent, another cost, and another chance for the customer to give up and send money elsewhere. The same codes are also a favourite target for abuse and account takeover.
This guide is for operations, support and security leads who own the sign-in journey: one-time codes at sign-up and sign-in, two-step sign-in, and verification when a customer changes their phone number or email. Where RemitSo handles a step, we say so.
Where codes fail, and why support cannot tell
A code can fail at several points, and each needs a different answer:
| What happened | What the agent should do |
|---|---|
| The message was never sent | Escalate: this is a fault on your side or your provider's |
| Sent, but the carrier did not deliver it | Check the number, then try again later or use another channel |
| Delivered to the phone | Help the customer find it: filtered messages, an old phone, a mistyped code |
| Too many requests in a short time | Explain the wait; it is protecting the account |
| The number on the account is wrong | Start a verified contact change, never a quick edit |
An agent who can see which of these happened resolves the ticket in one reply. An agent who cannot will ask for a retry, and the customer may already be on their third.
Record every code and what the provider said about it
Your SMS provider reports what happened to each message. Keep that answer, against the customer and the purpose of the code, in words an agent can read:
- What was sent and why: sign-in, sign-up, two-step sign-in, or verifying a new mobile number.
- When it was sent and to which number (shown masked to agents who do not need the full number).
- The provider's delivery answer, translated into plain words: delivered, not delivered, rejected, still waiting.
With that record, "I never got the code" becomes a lookup. It also shows patterns a single ticket never would: one carrier failing in one country, or a spike of undelivered codes after a provider change.
Rule of thumb: if your support team cannot answer "did the code arrive?" without asking engineering, every code complaint costs you a retry, an escalation or a customer.
Rate-limit code requests, and say so in the customer's language
Codes cost money and protect accounts, so both cost and security argue for limits. Without them, a script can request thousands of codes, running up your SMS bill or flooding a victim's phone, and an attacker can try code after code until one fits.
- Limit how often codes can be requested for one number or account in a short period.
- Limit attempts to enter a code, and the number of password resets.
- Apply the same limits in the customer app and in your own console.
- When a limit is hit, tell the customer plainly, in their language, that they need to wait. "Too many requests, please try again shortly" is better than a silent failure, which only prompts more requests.
Before you switch limits on, tell your app team: the apps must show the "too many requests" answer properly rather than an error page.
Change a phone number or email without opening a door to fraud
Changing a customer's phone number or email is the most dangerous routine edit in a money transfer business. Whoever controls the contact details receives the codes, and whoever receives the codes controls the account and its saved recipients.
- Confirm the new detail before it takes effect. Send a code to the new number or address, and only switch once the customer enters it.
- Keep the old detail working until then. A change that is started but never confirmed must not lock the customer out.
- Sign in with the new detail once confirmed, so the customer is not left with an account they can only reach through the old one.
- Treat agent-made changes as high risk. Require the change through a verified flow, not a free-text edit by support, and keep a record of who changed what.
Watch for: a contact change followed quickly by a new recipient and a large transfer. That is a classic account takeover pattern; make sure your risk rules can see it.
Apply the same care to your own staff
Your console is a bigger prize than any single customer account. Staff should sign in with two-step sign-in, each person on their own account, with what they can see decided by their role. Rate limits apply to staff sign-in too.
Doing it with RemitSo
RemitSo covers the sign-in journey in the customer apps and the console. Your team still decides how to respond to each customer and which channels you offer.
- Code delivery you can see (release 2026.11.3): every sign-in code, two-step code and mobile number verification sent by SMS is recorded with the SMS provider's delivery answer in plain words, so your team can see whether a customer's code arrived. Delivery reports need the SMS provider's token added to your installation.
- Two-step sign-in by SMS sends its code (also fixed in 2026.11.3).
- Rate limits (since 2026.09.5): sign-in, sign-up, verification codes and password resets are rate-limited in the apps and the console, with a "too many requests" answer in the customer's language.
- Confirmed contact changes: a changed mobile number must be confirmed by code (since 2026.10.5), and since 2026.11.1 customers who change their mobile number or email address sign in with the new one once they confirm it.
- Quick, safe sign-in for customers: one-time code, then PIN, Face ID or fingerprint; a PIN length you choose; only genuine apps can connect to the backend; a device list where a lost phone is removed in one tap.
- Staff sign-in with two-step sign-in (authenticator app or email code), roles for every page and action, and a searchable audit log of who changed what, and when.
See the admin features, read the release notes, or book a demo.
Frequently asked questions
Why do some customers never receive SMS codes?
Common reasons are a wrong or old number on the account, a carrier that does not deliver the message, the message being filtered on the phone, or the customer hitting a request limit. A delivery record for each code tells you which one it was.
Will rate limits lock out genuine customers?
Only briefly, and only after repeated requests in a short time. Show a clear "too many requests" message in the customer's language so they wait rather than keep trying.
Can support change a customer's phone number on request?
They should start a verified change, not edit the number directly. The new number is confirmed with a code before it takes effect, and the change is recorded.
Do we need delivery reports if codes mostly work?
Yes. They are what turns "I never got the code" from a retry into an answer, and they show you when a carrier or country starts failing before complaints pile up.