OTP and 2-factor verification

Verification sends a one-time passcode to a customer over a messaging channel and then checks the code they type back. It's the second factor for a login, a checkout, a password reset, or any change sensitive enough that you want proof the person holds the phone number on the account.

What it does

Two halves, both handled in your instance:

1. Send. A passcode is generated and delivered to the customer's number as a message on a connected channel.
2. Verify. The code the customer enters is checked against what was issued. Codes are time-limited, so a stale code fails.

Because it runs on the channels you already own, the code arrives from the same sender the customer has been talking to — not from an unfamiliar number that looks like exactly the kind of message people are told to ignore.

Configure it

Open Settings → Verification. That surface is where verification is set up, and it includes a built-in tester so you can send yourself a code and complete the verify step before exposing it to customers.

Test on the channel you intend to use in production, not just the most convenient one. The thing that breaks OTP flows is rarely the code — it's delivery timing on a particular channel, or a message that doesn't make it obvious what the six digits are for.

Track it

The verification analytics view reports codes sent, verified and expired. Read them as ratios rather than totals:

• Verified ÷ sent is your completion rate. Low means the flow is confusing, or the code isn't arriving.
• Expired ÷ sent is a delivery-speed and UX signal. A code that lands after the customer gave up is a cost with no benefit.
• A sudden spike in sends with flat verifications is worth investigating — it can mean a retry loop, or someone probing the endpoint.

Practical notes

• Say what the code is for. "Your Arino verification code is 123456" beats six bare digits, and it reduces support contacts.
• Never ask a customer to read a code aloud to an agent. A passcode that can be social-engineered out of someone isn't a second factor. If you do nothing else here, do this.
• Don't use it for marketing. A verification message is transactional and expected; anything else attached to it isn't, and it undermines trust in the code itself.
• Rate-limit the sensitive action, not just the send. Repeated code requests for the same number are a signal worth acting on.

Verification messages are transactional rather than marketing, but you're still processing personal data — see consent and opt-in for where the line sits, and audit and evidence for what's recorded if you ever have to demonstrate that a verification took place.

Billing

Configuring verification, the tester and the analytics view are included in the flat $50/month instance connection and management fee — Arino charges nothing per passcode. Each code you send is an ordinary outbound message, billed at the channel's rate on your own Infobip account. See billing and plans and usage and message costs — with OTP the retry behaviour matters, because every resend is another billed message.

Steps at a glance

1. Open Settings → VerificationGo to Settings → Verification in your instance. This is where one-time passcode sending is configured and tested.
2. Configure the passcodeSet up how the code is generated and delivered, and the message the customer receives. Codes are time-limited, and the settings surface is where you adjust that behaviour.
3. Send a testUse the built-in tester to send yourself a code on the channel you plan to use, so you see exactly what a customer sees before anyone else does.
4. VerifyEnter the code you received to confirm the verify step works end to end — sending is only half of it.
5. Read verification analyticsOpen the verification analytics view to see codes sent, verified and expired, and use that to watch delivery and completion over time.

Frequently asked