phone-verif.comReverse OTP phone identity infrastructure
Stop sending codes.
Start receiving proof.
Phone-Verif runs verification in reverse: your user sends one WhatsApp message and you receive their proven phone number.
No SMS to pay for, no mistype, no hijack possible
Scan with your phone for a real demo
0.0%
Full-flow conversion
Phone capture included
0.0s
Median time to verified
No number or code typed
0€
SMS spend, forever
The message is sent from the user
0+
Countries covered
Anywhere WhatsApp works
Measured on real production traffic, end to end (methodology)
How it works
Three steps. Zero friction.
Classic OTP pushes a secret to the user and hopes it comes back. Phone-Verif pulls the verified phone number from the user.
The message travels securely toward your servers and can't be intercepted or forged.
Why it’s different
The OTP, reversed.
Twilio-era verification sends a secret to your user and bills you whether it arrives or not. We think it should work the other way around: the user sends, you receive, and you are only billed on success.
the incumbent pattern
Push a code
User types their phone number
typos, wrong-country formats
You pay a carrier to send a code
$0.01–$0.40 per attempt, delivered or not
The code crosses the SS7 network
interception, SIM swap, AIT pump fraud
User waits, app-switches, memorizes
the drop-off moment
User types six digits back
mistype → resend → repeat billing
You compare strings and hope
a forwarded code passes this test
the reverse pattern
Pull a proof
User taps the link or scans the QR
number captured automatically
User presses send in WhatsApp
proof arrives, session flips to verified
A code can be phished, forwarded or pumped for fraud. A message sent from the number itself cannot. You’re not checking that someone knows a secret, you’re watching the phone speak for itself.
from 0.01€ per successful verification.
Failed attempts cost nothing, credits never expire.
Steps to verified
Secrets in transit
Typing required from user
Developer workflow
The entire API fits in your head.
Two endpoints: open a session, read the proof. No webhook contortions, no vendor SDK lock-in, no 40-page console. If you can call an HTTP API, you already know how this works.
# 1 — open a verification sessioncurl "https://api.phone-verif.com/start-verification" \-H "x-api-key: pv_live_9f2…"# 2 — show the returned QR or deep link, then read the proofcurl "https://api.phone-verif.com/check-verification-status?session_id=b7e1-44c0" \-H "x-api-key: pv_live_9f2…"# → { "status": "verified", "validated_phone_number": "+33612345647" }
Test mode included - run the full flow without spending a credit.
Read the integration guideBuilding blocks
Every surface, already built.
Web, mobile, kiosk, backend or no backend at all — each session exposes every surface at once. Start with one, adopt the rest without changing your integration.
REST API
Two endpoints: one starts a session, one checks it. JSON in and out, key in a header. Everything below is built on this.
POST /start-verification
Signed webhooks
Every status change is pushed to your backend the moment it happens, signed so you can verify it came from us. No polling loops.
X-Webhook-Signature: sha256=…
Three flows, one integration
The same two endpoints run phone verification, passwordless login and 2FA. Switching use case is a query param, not a rewrite.
?flow=phone | login | 2fa
QR code + deep link
Every session ships a ready-to-render QR image URL for desktop and a deep link that opens WhatsApp pre-filled on mobile.
<img src={session.qr_code} />
Hosted flow
A verification page we run for you. Pass a callback URL, get the user redirected back verified. Works with zero backend.
?callback_url=…
Stable user identity
Each verified number resolves to a stable user_id you can link to your own IDs — recognize returning users on every login after the first.
"is_new_user": false
Use cases
One primitive, every flow.
Proven possession of a phone number is the atom of digital identity. Everything you build on top of it is a composition.
Security & performance
Nothing to intercept. Nothing to leak.
Most verification security is about protecting the secret in flight. Ours is simpler: we removed the secret.
No code to phish
Phishing an OTP requires an OTP. The proof message travels from your user to us — an attacker has nothing to ask their victim for.
Possession, actually proven
The message originates from a WhatsApp account bound to the number over an end-to-end encrypted channel — not a string somebody typed into a form.
No secrets at rest
There is no OTP table to breach. Sessions store status, timestamps and the validated number. API keys are stored as hashes, never in the clear.
Minimal by design
We keep exactly what verification requires and nothing else — no contact upload, no address book access, no profile scraping.
measured in production
Case study
Thousands of students, verified over WhatsApp.
Emy, an AI-powered learning platform, onboards Brazilian students for a national financial-literacy olympiad — every account phone-verified, no passwords, no SMS.
“If your users are on WhatsApp, it's a no-brainer. The integration is dead simple — two API endpoints — the UX is far superior to SMS codes, and you get verified phone numbers as a bonus for your CRM. We went from zero to production in a day.”
Pedro Gaya
Lead Developer, Emy
63%
verification-to-registration conversion
against the 50% the team expected
1 day
from first API call to production
~100 lines of backend code in total
≈0
fraud attempts and login tickets
with cash prizes on the line
Your first proof is
five minutes away.
Run the live demo against your own phone, grab a key, and delete the phone-number field from your signup form for good.