Let the customer send the verification.

A phone number observed by the provider.

A code alone cannot tell you which phone account sent it. Sendity accepts the phone number supplied through the trusted WhatsApp provider event and binds that evidence to the active challenge.

The claim is specific: the sender controlled the WhatsApp account associated with that provider-observed number at verification time. It does not prove current possession of the SIM, the person’s legal identity or that they will control the number forever. Shared accounts, compromised devices and later account changes remain relevant to your application’s risk decisions.

There is more to it than receiving a message.

Sendity uses the official Meta Cloud API directly. It does not rely on a scraped WhatsApp session, an unofficial client or a forwarded chat screenshot.

• Authenticate the delivery. Verify Meta’s X-Hub-Signature-256 HMAC against the original raw request body using the app secret.
• Accept the intended destination. Match the configured messaging account and business phone number.
• Check freshness and uniqueness. Reject stale messages and deduplicate provider message IDs. A retried webhook must not become a second verification.
• Bind the message to the challenge. Accept a matching, unexpired code and valid sender evidence. Delivery status callbacks do not verify users.
• Validate at your backend. Check the signed result before creating an account, accepting an entry or granting access.

These checks protect distinct parts of the flow. They do not make a code-based flow automatically phishing-proof. A visitor should only send a code for an action they started on a website they trust. Read the security model.

Provider reference: Meta’s webhook payload validation documentation.

A username is not a verified phone number.

WhatsApp may supply a business-scoped user ID without exposing a usable number. Sendity does not turn that identifier, a profile name or an arbitrary contact card into phone proof.

For an active challenge, Sendity can request native contact sharing. The accepted reply must match the pending request, the sender and the business phone, and include consistent provider-observed number evidence. When the required evidence is missing, the flow stays unverified. The visitor may need to share their own number and send the original code again, or explicitly choose SMS if your application allows it.

Provider references: Meta’s business-scoped user IDs and contact message webhooks.

Why the delivery cost can be far lower.

Classic outbound OTP starts with your service paying to deliver a code. Sendity reverses that direction: the user sends the challenge to the business. The ordinary visible-number path does not need a business-sent authentication template to carry the code.

Meta prices delivered template messages by category and destination market. Its published pricing also provides free service replies within the customer service window. See Meta’s pricing and current rate cards.

A managed outbound OTP service can add a verification fee to delivery charges. For example, Twilio Verify publishes a base fee of $0.05 per successful verification plus channel fees. Sendity validates its own inbound challenges, so that external Verify fee is not part of its delivery path. Hosted Sendity has its own charges. Source: Twilio Verify pricing.

A small fee becomes visible at volume.

At the published Twilio Verify base rate, 10,000 successful verifications mean $500 in verification-service fees before channel delivery charges. Sendity’s own inbound challenge validation avoids buying those third-party verifications. That explains how the underlying stack can cost substantially less; it does not mean the hosted Sendity bill is $500 lower. Compare the complete Sendity plan and usage charges against the full alternative.

Twilio’s published WhatsApp messaging rate is $0.005 per inbound or outbound message, in addition to applicable Meta template fees. At that published rate, routing 10,000 inbound messages through Twilio would add $50 in message-handling fees. Sendity’s direct Meta inbound path avoids that particular intermediary fee. Source: Twilio WhatsApp pricing.

These are two separate illustrations of provider cost components, not a combined quote or a forecast of total savings. They assume the stated volume at published list rates, exclude taxes, discounts, additional messages and operating costs, and do not compare Sendity plan charges with Twilio charges.

Pricing references checked 26 October 2026. Provider rates, categories, eligibility and destination-specific charges can change.

Choose the flow your audience can complete.

WhatsApp verification fits journeys where visitors already use WhatsApp and are comfortable sending a message. It can remove contact-entry errors and avoids waiting for a business-delivered code on the ordinary path.

It still requires the visitor to send, switch back to the browser and control a supported account. Offer another appropriate channel for people who cannot use WhatsApp. Where SMS fallback is enabled, the visitor chooses it explicitly; a timeout does not silently lower the channel policy.

Try the live demo, then use the integration guide to connect verification to your own backend.