Ask HN: How to send SMS cheaper than Twilio?

61 points by ShrigmaMale ↗ HN
Not spam, all double opt-in. Even with 10DLC it's too much $, even on cheap providers like SignalWire. Email to text is unreliable and can't do above certain volumes (unless there's some way to get whitelisted I don't know?)

How can I do this for cheaper?

Here are some numbers:

Pricing varies by carrier but with my carrier mix it is between $0.0065 - $0.007 for 1 message on average. I need to send ~250k each month for now and also need lots of room to send more. These prices are SignalWire which is the cheapest I found so far. Bandwidth looks like the same. I think maybe Teli and Telnyx are a small amount cheaper but not so much.

70 comments

[ 2.8 ms ] story [ 126 ms ] thread
You might want to fix your title if you can still edit (sp).
Have you tried talking to a sales rep from Twilio or one of the other providers? Sometimes they can figure out a discount or credit to keep you. Usually they will at least try.
I will give it a try, hopefully there is something there.
To do high volume SMS, I think you need a dedicated, business toll free number so they can easily track and block your account if you start spamming. This is the "white listing" process.
No carriers all want 10DLC now not toll-free.
Ok, thanks for the feedback.

But from what I read, toll free still allows for higher volume.

Carriers are now actively penalizing toll free A2P with higher fees and some are straight up filtering them. They all want 10DLC where volume is dependent on trust score.
If you're willing to commit to a significant monthly spend the providers will offer lower rates. Contact several of them and collect competing bids.
... and this is true for basically every vendor, once you have any amount of scale. Including credit card processors. Yes, even that one with the really nice API. CDNs. Supposedly big cloud providers, but I've not used them at a scale where it was really worth negotiating (for either party).

Quick way to see if you can probably get one: email one of their competitors (a sales email address) and tell them what your average monthly spending with [current vendor] looks like, what your rates with them are, and emphasize that you're otherwise happy with them but feel like it might be worth moving if you can do significantly better on price. If you get back an offer lower than their sticker prices, ask your current vendor to match (assuming you're otherwise happy with them). Even someone who doesn't like and is kinda bad at negotiating can do that.

If they come back with no or trivial movement on price (a 5% discount or something can often be had if you just ask) and trying to sell you on features instead, you're probably too small still. Otherwise, enjoy the savings.

Have you thought about buying a cheap cell phone with a plan? You can turn an Android phone into an SMS gateway.
Although finding a carrier that is ok with this type of use is more difficult. Most have fairly low rate limits and will consider kicking you off the network.
Won't work in practice. We tried that, and (scum)phone companies apply arbitrary filters to SMS sent with 'unlimited plans', not delivering messages which they don't like. Experiments have shown that SMSs with random text arrive in 80-90% of cases, but if they contain words like 'verification', 'code', 'код', еtc, only about 10% do reach the recipients.

Of course, these same operators offer commercial rates for delivering 'branded' messages at a far higher rates.

Have you tried cheating their regexes with mixing Cyrillic and Latin script? E.g. кoд ( the o is Latin, the rest Cyrillic). It's the same letter visually but a different character. Even Google Translate used to trip up with this.

PS: funny, HN bolds Cyrillic characters

Mixing helps bypass the screen, and simply sending the numbers helped. But still, we decided to ditch this number verification thing via SMS altogether and start torturing users by missed calls.
The reason this doesn't work is because of the pressure phone carriers have gotten about reducing the amount of spam phone calls and SMS (from Congress, state governments and regulatory bodies like the FCC). These arbitrary filters on consumer level plans are typically about blocking spam from spoofed numbers and non-compliant businesses. If you think about it, its EXACTLY how email works today. You _can_ try to send millions of emails per a second from your gmail account, but a) your emails will likely be caught by spam filters due to the high volume and b)gmail will notice suspicious activity and shut your account down.
I have this bookmarked from a few weeks ago found on HN [1].

[1] How to send text messages for free using Python | Use Python to send text messages via email https://www.alfredosequeida.com/blog/how-to-send-text-messag...

Not usable for these high volumes tho.
I have tried email to sms, it doesn't work at my scale.
If you have rough estimates for what the upper limits of this approach are (based on your tests), I'd love to get a datapoint to keep in mind. I use this at low-moderate volumes.
(comment deleted)
You could set up a dedicated Android phone with SMSSync [0]. It isn't maintained but I use it for my own personal use and would think it could scale up to meet this kind of demand. I don't know the legality of using a cell phone service for this kind of service though, might violate their terms of service.

[0] https://github.com/ushahidi/SMSSync

This obviously violates every carrier's terms of service, at least in the United States. There are industry-wide accepted rules about this; regular local long codes are not allowed for A2P messaging. Your A2P texts will be blocked long before you get to 250,000 texts in a month. I would bet that you don't even survive the first day. You're just flying under the radar right now because your volume is low.
Thank you, that's good to know! My messages currently sync to a database which has a frontend that I can view and respond to messages from. I haven't ever set up any automated messages though.
You get rate limited pretty quickly from what I've heard. Normal carriers don't want you doing this.
That will get blocked past a few 100s messages each day.
That is a huge number of SMS messages...what on earth would you need that many for with out the revenue to back it?
This.

If you're sending 250,000 double opt-in SMS messages and can't cover $0.007/message you've got a serious pricing problem

Totally. Here was me thinking my 2c per SMS was cheap!
Revenue can cover it but I prefer to increase margin with some cheaper solution if possible.
(comment deleted)
From someone who's done a fair amount of SMS sending here are some things to think about.

- You'll need TCPA compliant opt-ins for US sending. There's a cottage industry of people who look for vendors that aren't compliant and sue them. The fines range from $500-1500 a SMS or call. Sounds like you've already gotten that covered, but definitely go over the requirements with a lawyer that specializes in it.

- SMS is throttled per a phone number. This is throttled at both the provider and the carrier. That means that even if Twilio sends something at 10am it might not be sent by Verizon until 11am. This absolutely impacts off-hour SMS sending.

- SMS is pricier than email and even at the highest volumes has a relatively high floor per a text. I think the floor might be $0.004X-$0.005. This is offset by having better response rates that email. And as others have mentioned the providers will give you better pricing as your volumes go up, but you'll need to talk to account reps about that.

- At a certain size (1M+/month?), you can also consider integrating directly with the carriers, although that's a longer process to get set up.

- You'll need to manage SMS bounce/spam rates like you would for email bounce spam rates. You'll end up maintaining a block list of known bad phone numbers

Edited for formatting

Thanks. I understand limits these days are based on 10DLC trust? Do those throttling still apply even with staying under those limits?

I think the floor is 0.0025 to 0.003 based on network access fees and depending on carrier. With margin I suppose yes I won't get much cheaper.

If I scale to that level I will look at direct integration, thanks. Do I still need blacklist if I have double opt in and users can opt out? Requiring confirmation would remove the need for that?

Yes, you'll still encounter throttling even with 10DLC trust, it will just be less. If I remember correctly 10DLC is supposed to have a send rate of 15 text message segments per a second, although you can get that bumped up after vetting. But for example if you try to send 250K SMS at 10:05 am EST, those messages will be queued up and will be received by clients at varying times. This is something you'll want to monitor. If I remember correctly Twilio (and presumably other vendors) will show the actual sent time, so you'll be able to compare when you triggered a send with the actual send date. Unfortunately I don't think you'll see when clients actually receive the SMS unless you've got a personal phone number on your send list that you use to monitor. There are also daily send limits, which again can be increased after vetting. From a software engineering perspective SMS sending is really a series of queues. Twilio has its own queue per a number and a queue per a carrier. Each carrier maintains their own sending queues. As such, you'll want to monitor SMS sending the same way you'd monitor a queue ie by measuring throughput, and number of items in the queue.

Oh and I forgot to mention that if your SMS includes emojis, they get converted to MMS, which typically are more expensive. The companies I worked at, did tests and found that emojis didn't really impact response rates, although its worth testing your specific use-case.

With the double opt in, you probably don't need a blacklist, although you may want one for customers that reply with expletives, etc (assuming you're supporting 2-way).

> Oh and I forgot to mention that if your SMS includes emojis, they get converted to MMS, which typically are more expensive

Technically it's more than just emojis, anything outside of GSM-7 [0] will result in fallback to UCS-2 and you get about half the number of characters per segment.

FWIW Twilio does allow status callbacks so you can see that twilio sent the messaage and when(/if, sometimes they don't) carrier acknowledged delivery success/failure.

[0] https://en.wikipedia.org/wiki/GSM_03.38#GSM_7-bit_default_al...

> Oh and I forgot to mention that if your SMS includes emojis, they get converted to MMS, which typically are more expensive.

This might happen, but it really shouldn't. Sending emoji as utf-16 surrogate pairs in a message marked as UCS-2 generally works, even if it's technically invalid. Of course, using UCS-2 means 70 symbols? max, instead of the 160 you get from a 7-bit GSM encoding (or 140 with an 8-bit encoding, if there's a useful one). Emoji that are one unicode code point will take up two symbols if they need to be sent as surrogage pairs, and if you use any of the combining character based emoji, that's going to use your message length budget real quick. Pushing you into multiple messages or MMS, both of which are expensive.

That throttling bit me hard last week. DHL's delivery message didn't come until hours after a package was delivered and by the time I got it the message the package was already stolen. Doesn't help that DHL didn't forward my delivery instructions to whatever third party last mile service they used (GSL US). Doesn't help that GSL didn't even make it to my address and dumped it behind the mailbox 2.5 miles from my house on a public road even though there is a secure drop box at the actual house address/location. Yesterday told me they'd pay out the claim, today they're fighting me over it.

I guess it'll be another month before I can get another PineNote developer kit delivered to me (between CNY and international shipping). :(

Jokes on whoever stole it. It's a paperweight unless you know what to do with it. A pawn shop wouldn't give them anything for it.

> even if Twilio sends something at 10am it might not be sent by Verizon until 11am. This absolutely impacts off-hour SMS sending.

Suppose my business is software for restaurants to notify customers their table is ready via text. How would I mitigate this?

Yeah same type problem here, notification is time sensitive and I haven't figured out how to make sure delivery is fast.
For time-sensitive SMS, one solution is to have basically a fast queue and a normal speed queue. Essentially have a phone number (or numbers) that are reserved for the fast SMS and only use it for time-sensitive requests like OTP. Everything else goes through a normal speed phone number. Alternatively, if all your SMS messages are time-sensitive, you'll likely want to use several phone numbers and try to load balance requests so that the queue size for each phone number is always small/at or near 0.

There's also an outside chance that your SMS provider may have an option to pay for faster delivery like email providers do. I don't recall seeing that option, but I have to imagine that at least one provider has this.

Just browsing through AWS documentation, it looks like you can set the SMSType to Transactional for critical messages that support customer transactions. I'm not sure if other providers have this option but looking for an SMS Type you can set may be a good place to start.

The link to where I found the information is below. They don't talk too much about it. They use the example of an OTP so that should work for your use case as well.

https://docs.aws.amazon.com/sns/latest/dg/sms_publish-to-pho...

Make a mobile app so you can send push notifications to most customers instead. It seems like this is the way most businesses go, the massive proliferation of one-off apps on customer phones notwithstanding.
Call their phone programmatically if you send a text with a request to confirm and don't receive the confirmation back within X minutes.
It wasn't clear from the context whether you wanted to mitigate throttled delivery or off-hours delivery. If its the former I responded below to ShrigmaMale. If its the latter, consult your legal team but you'll likely need to ensure that you're marked as type transactional. I wouldn't be surprised if you needed some specific language in your opt-ins. There's clearly a distinction between seamless sending you a text off hours because of an action you did, and say Geico sending a transactional SMS saying your new ID cards are ready.
This throttling burned me today. Capital One’s mandatory SMS 2FA didn’t deliver codes for 2-3 hours after they were requested. Needless to say I grabbed my AMEX instead.

Repeat: SMS is a trash 2FA system

I am always surprised when a financial services firm doesn't support 2FA using their app versus SMS, or support fallback to a voice call to a phone number registered to your account.
Tangential, but have you thought about offering customers the option for emails instead? I'd much rather give you my email address, I'd much rather receive email, and it will cost you less as well!
Customers want SMS notifications or similar, I have email also. Long term maybe i switch to a mobile app.
You should speak to Twilio and Sinch since they're now the two main players after their acquisitions of Syniverse and SAP respectively. They definitely have pricing power and should be able to help out.

Disclosure: My company was acquired by Sinch. (I can try to intro you to someone on the inside if you'd like.)

Thanks, I will reach out about Sinch. I looked at them but didn't see pricing and wanted to avoid sales run-around, but it's probably worth while.

Update: I created an account and managed to find pricing, it's almost 2x what I pay other providers.

If you don’t contact sales then you can’t get discounts for things that might not be a big deal to you but are to them. Committing to staying with them for a period, minimum spends for that period, paying up front. These things can generally get you discounts.
Dealing with this now, agree that if you're not generating revenue to cover the costs, you're barking up the wrong tree. Yes, SMS is easier for the users, but it's also not very secure. And that impacts the use cases of your platform.

At a previous employer, the solution was to move off SMS and onto internal messaging via native mobile apps. This will shift your cost focus, but that levels out as the volume of SMS transactions decrease.

Yes I am generating enough revenue but I prefer to increase margins with some cheaper provider if I can. Long term you are probably right, a mobile app is much cheaper, just takes time.
Does a mobile app alone solve this problem though?

My understanding is that fake users can still download an app (or call the API the app would have called), but a phone number is harder to continually spoof/generate.

I've been working on http://parrot.dev, it uses an Android phone to enable sending messages from an API, while it's still new it's currently in use with a collection of customers.

At 250k it might not meet your needs because whatever phone provider you're using might have a problem. It is possible to pair it to multiple phones as well.

My existing customers are using it to send ~200 messages a day to their subscribers. It supports SMS replies, so you can implement stop codes, depending on your needs.

If you want to discuss it more, feel free to reach out (contact on profile).

This is brilliant.

Do you know what sort of limits mobile service providers impose on phones?

I think it varies heavily, most of my customers are in Australia (where Twilio is even more expensive) and it seems to be working fine for them currently. But they're not sending huge volumes, they're also not sending anything mission critical (there is a sweet spot).
Carriers won't give you an exact limit, most just specify "personal use". And they may not catch on right away but once they do, they will likely ban your number.

Personal opinion, you're going to have all kinds of issues with this in the USA.

It's an important consideration, and one that I've thought about but really lack any ability to gather data on. I built this originally to meet the needs of my brother's business and his customers.

It has proved useful for him and his customers, and has expanded beyond that, but I don't really know how much to pursue building it further based off risks like this.

We purchased a shortcode with Twilio for 3k a quarter, then with their bulk pricing discounts, we are able to send text messages with a 70% discount off the ticket price.

Source: We send many millions of messages a month via Twilio.

I'm not sure but I've always suspected you could get cheaper if you went with a modem like this[0] and prepaid sims. You'd have to test for shadowbans and swap out bad cards, but I bet you could get it to work. However how much cheaper this is once you factor in time running around buying prepaid sims? it's probably not worth it.

[0] <"38400 MMS one hour"> https://www.alibaba.com/product-detail/4G-Voip-Gateway-LTE-A...

That could easily run afoul of 10DLC unless you go through the process of registering your number with the carriers for A2P traffic (something Twilio or the another aggregator normally does for you.)
You could integrate "Verify With Snapchat" and push users towards that instead (requires users to have a Snapchat account)

https://snapkit.com/login-kit (scroll down to "Never Pay for SMS Verifications Again")

That definitely looks like a good idea, that saves at least some on cost. Largest SMS cost is still sending notification messages though, so bringing that down is the hope.
Are you paying listed pricing or do you have a discounted enterprise contract? That might be a starting place.
(comment deleted)