Fintech: the OTP that arrived four minutes late, and how we found the slow route
Login codes worked perfectly in testing and badly for real customers. Timing messages by provider showed that one route was quietly adding minutes.
A payments app had a support problem that was hard to describe. Customers said they “never got the code”. Engineering checked the logs and the code had been sent. The messaging vendor’s dashboard said delivered. Everyone was telling the truth and the customers were still locked out.
Delivered is not the same as on time
A one-time passcode has a short life. If it arrives after the user has given up, or after the code has expired, it might as well not have arrived. The team realised that all of their monitoring measured whether a message was accepted, and none of it measured how long the phone took to receive it.
So they ran a test. A unique keyword was sent to a test number, and the time between sending and receiving was recorded. They repeated it across their SMS providers and at different times of day.
What the numbers showed
- Two routes delivered in a few seconds, consistently.
- One route was usually fine, but in the evening, when traffic peaked, messages sometimes took minutes.
- Messages that arrived after the cut-off were flagged as late, which made the problem visible instead of a vague complaint.
The fix was unglamorous: the slow route moved to a fallback position, and evening OTP traffic went to the faster two. Support tickets about missing codes dropped within a couple of weeks.
Keeping it that way
They still run the test whenever a provider or a route changes, and before any big launch. It takes a few minutes, and it replaced a lot of guesswork in support conversations with a number everyone can look at.
Industry: fintech · Use case: OTP and transactional SMS delivery · Team: platform engineering and support
If this is your team
Login codes fail quietly. The provider reports “delivered”, the customer sees nothing for four minutes and gives up. Test each route from a real handset in the customer’s country and time it, not once but across the day, because the slow route in this story was fine at 10 a.m. and bad at 7 p.m. Pair the SMS timing with a free caller ID check on the voice fallback number, since a customer who did not get the code will often call back and will not answer a number that rings as spam.
Where sender IDs are involved, check what the handset shows as the sender too. A code that arrives from a bare long number is read as phishing by a good share of users, which looks like “delivered, not used” in your dashboard. The cash-on-delivery retailer hit the same dashboard-says-fine problem on the voice side.
Seeing the same thing on your own numbers?