David Harvey for Blooio – iMessage API

Posted on Jun 28

SMS Pumping Is Draining Your 2FA Budget — and Mobile-Originated iMessage 2FA Fixes It

#tutorial #googlesheets #imessages #ios

If you send SMS one-time codes, there's a decent chance you're paying scammers to phone-spam themselves on your dime. It even has a name: SMS pumping. And it's not a rounding error — Elon Musk claimed Twitter was losing ~$60M/year to fake 2FA traffic before they killed SMS 2FA for free accounts.

Here's how the scam works, why SMS 2FA is structurally expensive, and why flipping the direction — mobile-originated (MO) 2FA, taken to its logical end over iMessage — fixes both the cost and the fraud at once.

What is SMS pumping?

SMS pumping (also called AIT — Artificially Inflated Traffic, or SMS toll fraud) is a scheme where bad actors abuse a form that sends SMS one-time codes. They pump thousands of phone numbers — usually premium ranges they secretly control with a telecom — into your "send me a code" endpoint.

You pay for every one of those messages. A cut of that termination fee flows back to the fraudsters via the carrier. The "users" never log in. They were never users. The entire point was to make your verification endpoint dial a meter that pays them.

The structure that makes this possible is simple: you, the company, send (and pay for) the message. Every code is revenue for someone in the delivery chain — so there's a direct financial incentive to trigger as many as possible.

Why SMS 2FA is expensive even without fraud

Even with zero abuse, application-to-person (A2P SMS) is a bad cost curve:

You pay per message. Volume spikes — a launch, a bot attack, an international audience — turn into surprise bills.
International is brutal. Cross-border A2P carries steep carrier surcharges that vary wildly by destination.
Carrier fees and registration overhead. In the US you're funneled through A2P 10DLC registration, brand vetting, and per-segment fees before you send a single legit code.

So your 2FA line item is pay-per-event, unpredictable, and exploitable. Three bad properties for something that's supposed to be boring infrastructure.

The Twitter/X case

This isn't theoretical. When X announced it was removing SMS 2FA for non-paying users, the stated reason was fraud at scale:

A company that size could "fix" it by paywalling a security feature. Most teams can't — and shouldn't have to make 2FA a paid tier just to dodge a billing exploit.

The fix: flip the direction (mobile-originated 2FA)

Here's the key insight. SMS pumping only works because the company sends the message. That outbound, pay-per-code flow is the thing being gamed.

So flip it. In mobile-originated (MO) 2FA, the user sends a message to you to prove possession of their device. There's no outbound code to pump, no per-message payout to harvest, and nothing for a bot farm to monetize. The incentive that powers the entire scam disappears.

MO verification has been around (think shortcodes), but shortcodes are clunky, region-locked, and still cost money to provision. The modern version is much nicer.

Taking it further: reverse 2FA over iMessage

We built a live demo of this. Instead of us texting you a code to type back, you text a one-time code to us from your own iMessage — and we verify you the instant the message lands.

👉 Try it: demo.blooio.com/2fa

The flow:

Your app generates a short one-time code and a deep link that opens Messages with that code pre-filled.
The user hits send from their iMessage.
Blooio delivers an inbound message.received webhook. You match the code and read who sent it — verified.

Because the user sends from their own Apple ID over end-to-end-encrypted iMessage, it's spoof-resistant (unlike trivially-faked SMS sender IDs) and phishing-resistant (the user proves real possession instead of reading digits back to an attacker). And there's no outbound message to pump.

The code is almost embarrassingly small

Start a challenge, then let a webhook flip it to verified:

// 1. Start a challenge: generate a code + an iMessage deep link
app.post("/2fa/start", async (c) => {
  const code = newCode(); // short, unambiguous one-time code
  await store.create(code); // status: "pending"
  return c.json({
    code,
    // opens Messages to your Blooio number with the code pre-filled
    link: `https://start.msg.new/<your-handle>?text=${code}`,
  });
});

// 2. Blooio calls your webhook when the user texts the code in
app.post("/webhook/blooio", async (c) => {
  const event = await c.req.json();
  if (event.event === "message.received") {
    const code = extractCode(event.text);
    if (code) {
      // event.sender is the verified identifier (phone/email)
      await store.verify(code, event.sender);
    }
  }
  return c.json({ ok: true });
});

That's the whole trick: no outbound SMS, no per-code billing, no A2P registration. Just an inbound webhook and a string match.

SMS 2FA vs. reverse iMessage 2FA

	Reverse iMessage 2FA	Traditional SMS 2FA
Pricing	Flat monthly rate, predictable	Pay per message — spikes = surprise bills
Abuse	Can't be pumped (users message you)	Wide open to SMS pumping / AIT fraud
Cost at scale	Cheap, especially cross-border	Steep international + carrier surcharges
Security	E2E encrypted, tied to Apple ID	Sender IDs spoofable; SIM-swap exposure
Anti-phishing	User proves real possession	Codes get phished or relayed
Speed	Instant over WiFi/data	Often delayed, sometimes never delivered

How this actually saves you money

Predictable cost, not pay-per-event. A flat rate means a bot storm can't author your invoice.
Fraud incentive removed. No outbound code = nothing to pump = the $60M-style leak can't happen.
No A2P 10DLC / DUNS / carrier registration tax to start sending.
Cheaper internationally, where SMS surcharges hurt the most.

Try it / build it

Play with the live reverse-2FA demo: demo.blooio.com/2fa

If you want to build it into your own auth flow, Blooio is an iMessage API for developers — REST API, webhooks, and SDKs. Start free — no credit card, no A2P registration, no DUNS.

DEV Community