How to Stop SMS Pumping and Cut OTP Costs with the WhatsApp Business API

Sending one OTP message costs almost nothing. Sending a few hundred thousand fake ones overnight costs a great deal.

That is how SMS pumping shows up on the finance side. Messaging spend climbs while signups and logins stay flat. The risk team faces a different problem: in a SIM swap, a real customer's phone number ends up with a criminal, and every code sent to it goes to the wrong person.

Both attacks work because authentication depends on one channel with no checks around it. If your first attempt goes through the WhatsApp Business API, with voice and SMS as controlled fallbacks, fraudsters earn less and account takeover gets harder. This post covers how each attack works, what a multi-channel setup changes, what to build, and what to ask a CPaaS provider before you sign.

What Is SMS Pumping and Why Fintechs Get Targeted

SMS pumping, sometimes called artificially inflated traffic, is a scheme where bots trigger large volumes of messages to numbers the fraudster controls or profits from.

The payout comes from international revenue share fraud (IRSF). When an SMS terminates on certain foreign carriers, the carrier earns a fee, and part of that fee flows back to whoever arranged the traffic. The fraudster's script hits your "Send OTP" or "Resend code" button thousands of times. You pay your provider for each message, and someone else collects the revenue share.

Fintechs and banks are easy to hit for three reasons. Their apps send an OTP message at signup, login, and payment confirmation, so there are many endpoints to abuse. Many of those endpoints have to be public, because a new user requests a code before an account exists. And a rising OTP bill can look like healthy growth, so the abuse can run for weeks before anyone questions it.

Any public endpoint that triggers a message through a bulk SMS API is exposed unless something sits in front of it.

Warning signs to look for in your logs:

• Volume spikes to country codes where you have no customers
• Many sends with very few successful verifications
• Sequential or patterned phone numbers
• Traffic clustered at odd hours or from a handful of IPs or devices
• A sudden jump in "resend code" requests

Picture a lending app whose OTP requests triple overnight. Nearly all of them go to numbers in one country where the company has no customers, and almost none of the codes are ever entered. No customer data was stolen, yet the invoice still arrives.

SIM Swap Fraud: Why SMS-Only 2FA Falls Short

SMS pumping attacks your budget. SIM swap fraud attacks your customer.

In a SIM swap, the attacker persuades a mobile operator, through social engineering or an insider, to move the victim's number onto a SIM they hold. Calls and texts for that number now reach the attacker. If your only second factor is an OTP message sent by SMS, the attacker can reset passwords, approve payments, or register a new device. The real customer notices only when their phone loses service.

One caveat before going further: switching channels does not fix SIM swap by itself. SMS and voice both depend on control of the phone number. WhatsApp accounts are also registered to a number, so someone who takes over the SIM may be able to re-register there as well. Channel choice is one layer of defence. It works best alongside SIM-change signals, device binding, and step-up checks on risky actions, all covered in the playbook below.

How the WhatsApp Business API Cuts Pumping Risk and OTP Cost

The WhatsApp Business API gives you an authentication channel that behaves differently from SMS in ways that matter for fraud.

There is no carrier termination fee to collect. IRSF pays because carriers earn money when an SMS lands on their network. WhatsApp messages travel over data, so that revenue share does not exist, and fraudsters lose their main reason to target the channel.

The recipient needs an active WhatsApp account. A bot can generate or rent thousands of numbers and send SMS to every one of them. Reaching them on WhatsApp requires accounts that actually exist, which shrinks the pool of usable targets. Pumping can still be attempted, so rate limits still apply, but the attack is harder to run and pays less.

Delivery and trust improve. Authentication messages use Meta-approved templates and a verified business profile, so users see a sender they recognise. A copy-code or one-tap button also cuts typing errors and drop-off at login.

Spend is easier to control. Meta prices authentication messages per template, and rates differ by country, so your costs track real verification attempts more closely than an open SMS route that bots can drain. For a breakdown of how Meta's rates and provider markups work, read our guide to WhatsApp Business API pricing.

The channel has limits. Users need WhatsApp installed and a data connection, which is why it works best as the first attempt with fallbacks behind it. To see how it works in practice, visit Zapim's WhatsApp Business API page.

Using a Voice Call API as a Fallback and Step-Up Channel

When a WhatsApp message fails or the user has no data, a voice call API is a practical second route. A spoken code reaches people with weak connectivity, older handsets, or accessibility needs. It also suits high-value actions where you want one more confirmation.

Voice can be abused too. Premium-rate and high-cost destinations can be hit with automated calls just as they can with SMS. Give it its own limits:

• Cap voice OTP attempts per number and per session
• Restrict calling to the countries you serve
• Trigger voice only after a defined WhatsApp failure or timeout, or as a step-up check on risky events

If your users are mostly on Android, RCS can act as another branded fallback, though coverage varies by device and region.

Keeping SMS as a Controlled Fallback, Not the Default

Dropping SMS altogether is rarely realistic. Some users do not have WhatsApp, and some regulators expect SMS alerts for certain transactions. What changes is its position in the flow. SMS becomes a fallback you trigger on purpose instead of the first thing sent.

When you do send by SMS, use direct operator routes with registered templates and sender IDs. In India that means DLT-registered routes, which keep messages from being blocked and keep senders identifiable. Then protect the bulk SMS API endpoint with the same controls you would place on any other channel.

A Fraud-Aware OTP Flow: Practical Playbook for SMS Pumping Prevention

Channel mix helps, but most of the protection comes from the checks around it. Here is a workable order of operations:

1. Rate-limit at every level. Set limits per phone number, IP address, device, and session, including on "resend code."
2. Allow only the countries you serve. If you operate in India, there is little reason to accept OTP requests for numbers in a dozen other markets.
3. Add friction before the send. A CAPTCHA or device attestation on the request endpoint stops most simple bots before they cost you anything.
4. Watch send-to-verify conversion by destination. A country with high sends and near-zero verifications is your clearest pumping signal. Alert on it, and block it automatically if you can.
5. Route by priority. Send through WhatsApp first. If there is no delivery within a set time, fall back to voice or SMS. A clean WhatsApp Business API integration matters here, because fallback logic relies on accurate delivery status through webhooks.
6. Step up on risk. A new device, a new beneficiary, or a recent SIM change should trigger a stronger check than a routine login.
7. Review reports on a schedule. Per-message delivery data is what lets you catch a pattern early.

In short: the request arrives, risk checks run, the OTP goes out on WhatsApp, fallback fires only on failure, and the user verifies.

Why One CPaaS Provider Beats Stitching Vendors Together

A Communication Platform as a Service (CPaaS) lets you send messages across several channels through one set of APIs, instead of building and maintaining separate carrier connections. For OTP security, the practical gain is visibility. When WhatsApp, voice, and SMS each sit with a different vendor, you end up with three dashboards, three billing models, and no single view of which channel or country is losing money. Fallback logic gets harder to build and slower to debug.

A single CPaaS provider removes most of that. Zapim runs WhatsApp, SMS, Voice, RCS, and Email through one API and one dashboard. It offers per-message delivery reports, DLT-registered SMS routes, Meta-approved WhatsApp templates, and encryption in transit. Banks and NBFCs already use it to send OTP alerts and transaction confirmations across voice, SMS, and WhatsApp. For teams running enterprise messaging across several products, an omnichannel platform also puts cost per verification by channel in one place.

Questions to ask any provider you evaluate:

• Can I see delivery and verification data per message, per country, and per channel?
• Can fallback between channels be configured through the API?
• Are the SMS routes direct and registered, and are the WhatsApp templates official?
• What controls exist for capping or blocking traffic to specific destinations?

Metrics That Show Your OTP Strategy Is Working

Track a few numbers every week and the picture stays clear:

• Delivery rate and time to deliver, by channel
• Send-to-verify conversion, by country
• Cost per successful verification. This beats cost per message sent, because pumped traffic inflates the second and hides inside the first.
• Fallback rate. A rising rate can point to a WhatsApp delivery problem or an attack in progress.
• Fraud and account-takeover incidents linked to authentication

Protect Your OTP Budget with Zapim

SMS pumping is a cost problem. SIM swap is a customer risk problem. No single control solves both, but each gets harder to pull off when verification runs in layers: the WhatsApp Business API first, a voice call API for fallback and step-up, and SMS held under tight limits behind them. Add rate limits, country rules, and conversion monitoring around that flow, and fraud pays less while your OTP message spend becomes easier to forecast.

To see how this could work on your own traffic, request a demo and the Zapim team will walk you through OTP routing for your use case. Teams in banking and lending can also read more on the financial services page.

FAQ

Q1 What is SMS pumping, and how do I detect it?
SMS pumping is fraud where bots trigger large volumes of messages, often OTPs, to numbers that earn the fraudster a revenue share. In your logs, look for spikes to unfamiliar countries, many sends with few verifications, and patterned phone numbers.

Q2 Is an OTP message on WhatsApp more secure than SMS?
It lowers pumping risk, since there is no carrier termination fee and the recipient needs an active WhatsApp account. It does not stop SIM swap on its own, because WhatsApp accounts are also tied to a phone number.

Q3 Can a voice call API be used for OTP verification?
Yes. It works well as a fallback or a step-up check, as long as you cap attempts and restrict destinations.

Q4 Does multi-channel OTP delivery stop SIM swap fraud?
Not by itself. Pair it with SIM-change signals, device binding, and step-up authentication for high-risk actions.

Q5 What should I look for in a CPaaS provider for fintech?
Delivery reporting by channel and country, configurable fallback, direct and registered SMS routes, official WhatsApp access, and controls for limiting traffic to specific destinations.