Previous Twitter employees have said that this is incorrect. Because Twitter began as an SMS-only (and then SMS-first) application (remember 40404?), they very early on established direct-connection infrastructure for sending SMS, meaning that they have a marginal cost of literally $0.00/message in most markets. Twitter still has to maintain that infrastructure, because they didn't get rid of SMS 2FA - they just restricted it to Twitter Blue users, so the overhead is still the same.
Almost nobody else who delivers SMS today has that infrastructure, because it doesn't make sense for most services to build.
The only place where Twitter was paying significant amounts for SMS was due to SMS pump schemes, which is a consequence of Twitter gutting its anti-spam detection, resulting in them paying for SMS pumping which was previously blocked.
I am very, very interested to understand how that works, because without more detail or sources I'm calling bullshit. I definitely understand how Twitter could have greatly reduced their per-message fee with telecom providers, but at the end of the day Twitter is not a telecom and is still at the mercy of whoever is that "last mile" for actually delivering the SMS to your phone, so I don't understand how they have no marginal cost here. Happy to be proven wrong.
So sending 1 costs the same as sending a 10 million. It isn't that they are free to send, its that they are charged for access to the system, but aren't charged per message.
This is not how SMS pricing works in many, if not, most countries.
I have no experience directly with foreign telecoms, so I was simply explaining how something with no marginal cost could still be a very expensive system.
For something like Twitter where you could post by SMS, the balance of traffic might have been such that giving Twitter free outbound SMS was balanced by the charges incurred by customers sending to Twitter's shortcode. Or it might just be balanced by increased customer happiness when they can use the product more effectively.
If the carrier doesn't run their own messaging infra, they might be paying their IT provider on a per message basis, and might not be able or willing to set the messaging rate to zero.
For a use case where SMS is used to show control of a phone number, getting a zero cost direct route is a harder sell, but it can happen if the routing through aggregators is poor and the carrier is concerned about that, or if there's some other larger agreement in play.
I ran the engineering side of carrier integrations at WhatsApp. Carriers wanted to sell data plans with special pricing for data with WA and use WA branding in advertising, because it attracted customers that might later convert to a bigger general purpose data plan. As part of that, we would ask for zero rated SMS to their customers for verification. When it was available, it was generally faster and higher success vs sending messages through an aggregator.
We also had some, usually small, carriers approach us asking us to set up direct routes to them for verification, because their customers would not always receive our messages when we sent through an aggregator. Early in my career at WA, we would just send these carriers to our aggregator contacts, and often things would get linked up and then we'd still pay $/message but it would work better. As we got a little bigger and built support for direct routes anyway, it was usually not too hard to set up a direct connection and then there'd be no cost for that carrier. Messing around with IPSEC VPNs and SMPP isn't fun and the GSMA SOAP messaging APIs are way worse, but once you get the first couple implementations done, it becomes cookie cutter (and FB had built way better tools for this, and a 24/7 support team, so I never had to be up, on the phone with telco peeps at 3 am kicking racoon or whatever ipsec daemon we were running until it finally connected)
> If you are drawing as much billable traffic as you are sending
SMS verification traffic is usually unidirectional, so that’s very unlikely to be the case.
In most of the world, SMS is billed per-message, so it's basically no extra effort on the Telecoms side at all. In fact, Telecoms' online charging systems are fast enough to calculate users' data usage by seconds in real time, so they don't even blink at counting SMS.
In general, pricing varies widely by destination (country and sometimes carrier), US and some other places are < $0.01, up to $0.10/message isn't uncommon, and some places are $0.20-$0.30/message. Voice calling was usually mor expensive (Twilio should have a price list somewhere for that too; if you can get 6 or 1 second billing, assume a voice verification call is about 30 seconds, but you might have to pay for a whole minute even if you don't use a whole minute).
Those SMTP -> SMS gateways sometimes work in the US, but they don't work much in other countries, and they're not good enough to rely on if your product requires an SMS during the new user flow. SMS costs are real and it's frustrating, but if it costs too much, you need to use something other than phone numbers for ids; I don't think skirting by with email gateways is going to work. But, if you build dynamic routing, I guess you could try.
Also, you've got the use the right email gateway for the user's carrier, and a carrier lookup is on the order of $0.01, unless you have tons of volume, so for the US, you might as well pay for the SMS.
[1] https://assets.cdn.prod.twilio.com/pricing-csv/SMSPricing.cs...