Delivering OTPs reliably: latency, fallback and expiry windows

A one-time passcode is the least forgiving message a business sends. It is also the one customers judge a service by, because it stands between them and something they are trying to do right now. Marketing that arrives late is merely late. A passcode that arrives late is a customer locked out of an account, a payment abandoned, and a support call. The message itself is trivial — a few digits — but the requirements around it are stricter than almost anything else in messaging, and most of the failures come from design choices rather than from delivery.

Latency is the requirement, not delivery

For most traffic, the question is whether a message arrived. For passcodes, it is whether it arrived while the person was still waiting. Someone staring at a login screen gives up quickly, and once they have requested a second code the first one becomes a liability: two valid codes in circulation is a support problem and, depending on how your system handles it, a security one. Measure passcode delivery as a distribution rather than an average, and pay attention to the slowest tail rather than the typical case. The average is comfortable and tells you nothing about the customers who are actually failing.

Expiry windows are a product decision

The validity period is often set once, early, and never revisited. It deserves more thought, because it trades two failures against each other. Too short, and a code that arrived perfectly well expires while the customer is typing it, which produces the same support call as a message that never came. Too long, and an intercepted code stays useful. The right window depends on how the code is used and how quickly your traffic actually reaches handsets on the destinations that matter to you — which is a measurement, not a guess. It is also worth deciding explicitly what happens when a customer requests a second code: whether the first is invalidated, and what the interface tells them.

• →Decide the window from observed delivery behaviour on your real destinations, not from a default.
• →Say clearly in the message how long the code is valid, so the customer knows whether to wait or retry.
• →Define what a repeat request does to the previous code, and make the interface say so.
• →Rate-limit requests per account and per number, because passcode endpoints attract abuse.

Fallback, decided in advance

Everything fails eventually, and a passcode path that fails without a plan fails loudly, because the failure is immediately visible to every customer trying to log in at that moment. A fallback is not only a second route: it is a decision about when to use it, taken before the incident. That means a threshold, an owner, and a switch someone can actually operate. It is also worth having a second channel — a voice call reading the code, or a different messaging channel — for the destinations where message delivery is least predictable. Businesses that add fallback after their first bad day usually discover the work was smaller than the outage.

There is one more habit worth building: watch the funnel, not the channel. Delivery figures describe messages, but what you actually care about is whether customers completed what they came to do. When those two diverge — messages reported delivered, completions falling — the problem is usually somewhere the messaging report cannot see, in the expiry window, the wording, or a handset that filed the message somewhere unexpected. If passcodes are central to your service, that is worth saying at the start of a conversation about routes. The requirements are different enough from ordinary business messaging that the answer is different too.