OTP best practices: codes that stop working

A code login has three moving parts: the message, the screen that asks for it, and the clock. The visitor asks for a code, waits, and when nothing shows at once they ask again. Now two emails are in the inbox, and the first looks as valid as the second. Typing the first one fails, and the screen gives no reason, so the visitor assumes the code is broken and leaves. A second problem comes from the field itself. Pasting 482 915 with a space, or a code that wraps onto two lines in the email, leaves a field that rejects input it should accept.

• The newest code is the only valid one, and the screen says so under the field.
• Resend waits a short while before it can be pressed again, and it shows that it is waiting.
• The field takes digits pasted with a space or a dash, and drops the separator itself.
• The code sits in the email as plain text, not only as an image or a link.
• A wrong code keeps the field filled and says whether it was wrong, replaced or expired.

Resend is a common trap. A visitor who waited a minute and pressed Resend has two codes in the inbox, and both look the same. Some systems invalidate the older code when the new one is created, so typing the old one fails, even though it was real a minute ago. The fix is in the words on the screen. Under the field, say that only the latest code works, and show when the latest one was sent. Add a resend control that counts down before it can be pressed again. A resend that answers with no sign that a second code is coming reads as a broken button.

Some mail systems open each link in a message to check it before the person reads it. If the link in your message signs the visitor in or uses up the code, the scanner may spend it before the visitor taps. The visitor then sees an invalid link, and the mail looks like the fault of the app. Codes typed by hand avoid this, because nothing opens them on the visitor's behalf. Where you send a link that signs the visitor in, keep the code in the body as plain text too, and say on the screen that a link works once. Keep the code out of images, so the visitor can copy it.

A code that expires is fine if the visitor has time to use it. A visitor who switches from a mail app to the browser on a phone needs a few seconds to find the digits, and longer if the mail arrived late. Check the timing yourself: request a code, note when it arrives, wait the time your expiry allows, then try it. Also set autocomplete to one-time-code on the field, so the phone can offer the code above the keyboard. A field without that attribute makes the visitor copy each digit by hand, and each retyped digit is a chance for a typo.

A simulated visitor can read a code in its inbox, so the test covers email codes. It cannot receive a text message, so a phone code path is not something it can finish. The test also does not show how well a code resists guessing, how many tries the screen allows or whether codes are stored safely. Those are security questions, and they need a review of your own. What the test does show is whether a legitimate visitor, typing a real code, gets in on the first attempt and with the message they were given.

Signup flow testing

Changing the email template, the sender domain or the mail provider changes the path a code takes. A message that arrived in seconds can start arriving late, or with a subject line visitors do not recognize. After each change, request a code from a new visitor's inbox, check the wording, and enter the digits as a visitor would. With paid credits, a test account lets visitors pass a login that sits in front of the signup flow.