As a follow-up to my post on deploying mobile apps in the US, I am writing this post focusing on SMSs which is also a part of the deployment process.Almost every mobile application makes some use of SMS. The most common case is the use of SMS for the application delivery. If your application is off-deck, the flow of the application download probably starts at your web page, where the user enters his phone number and receives an SMS with a link (WAP Push) to your application (P.S. - Don't even think about asking users to type a WAP link, unless you want to decrease the load on your download server drastically...)
There are other applications who also use SMS in additional ways such as sending messages between users (Either from within the application by using WMA in Java for example, or from a central server), sending system alerts, waking up applications (J2ME's Push Registry/Binary SMS) and there are of course the pure SMS applications (no client) like weather reports, news and other content services. But whatever you're developing you will most likely need SMS as part of your application.
I will focus in this post only on the simple flow I described first: an SMS with a link to a downloadable client application. This should have been an easy case since there are no premium charges associated, no subscription - just a one time SMS requested by the user.
Now how would you go about doing that? The good news is that you can find service providers that can connect you to just about any carrier without you having to connect yourself to each carrier's SMSC. These are the SMS brokers or gateways, which provide with very easy to use APIs (Took us 1 day to get it up and running) so that activating an SMS service in every country on the globe is a snap... well, that is except the US....
To be exact from the technical point of view you can set up an SMS service in the US as easily as in any other country, but there are several regulations that may mean that later on your service will be interrupted if you don't follow these carefully... (Also to be accurate, almost all the carriers worldwide have some kind of regulations but usually they are just a small subset of the US ones like for example special regulations for adult content, obscene language etc.).
Let's get back to our case: suppose you want to use SMS just to deliver your app. This requires what is known as an MT (Mobile Terminated) SMS, meaning from the server to the handset. This is the easier direction as opposed to handset-to-server or MO (Mobile Originated) SMSs.
You probably know MO SMSs from voting in TV shows (text 2 to the number 12345), download flows for media advertised content and registration for various services. MO requires a setup of a shortcode (the 4/5 digit number to which people text) and preferably it has to be recognized by all carriers, and be the same in all carriers in the targeted region(s).
Setuping a shortcode (a service which is also done by the SMS brokers) is quite costly, it usually costs around several hundreds/thousands of dollars per month per country. So if for example you want to launch such a service just in the US you are looking at $2K-$3K/month, add to that just a few countries in Europe and you will get easily to $10K/month.
On the other hand MT SMS does not require any shortcode since the user doesn't need to communicate back. For example in the scenario of sending a WAP link, the user gets the message and presses the WAP link which opens the browser - there is no need to reply to the SMS and as such no shortcode setup is needed.
The costs for MT SMS are rather cheap: Some providers supply such a service with no monthly or setup fees, just pay as you go for messages actually sent. You can also buy bulk packages in advance and pay less per SMS. And you can send messages to wherever your provider is connected too - and some supply a very impressive worldwide coverage.
So what's the catch? Well, in the US if you want to go by the book, then even if you only send MT messages you would have to setup a shortcode. At least that's what the big SMS gateways say. And why is that? The formal reason is to allow a user that received a message to unsubscribe from your service by sending a message to that shortcode ("STOP" is the preferred code, but application providers must recognize also "QUIT", "END", "CANCEL" and "UNSUBSCRIBE" and act upon).
US regulations require that a user can unsubscribe in almost any way from a mobile service, and that includes doing that by SMS. When you think about content services (especially paid ones), that's very understandable - you don't want to get spammed on your phone when you don't really remember how you can unsubscribe. And unlike email, here you might also get charged for each message you receive...
However, in the context of a single message that you specifically requested, and are not charged for (The application provider pays for the SMS with the link) it is not that clear that regulation has to be so harsh, because of the high price the application developer has to pay to follow it. The problem is that carriers don't really know (or care) to differentiate between the two.
The regulations specifics can be found at the Mobile Marketing Association site. They include a whole set of rules and examples of how-to and how-not-to. FYI - the case of SMS for downloading is an easy one - for premium services there are double opt-in procedures needed and exact flows to follow etc. (You can take a look at their Best Practices document). BTW - The MMA also detail what are the restrictions of each individual carrier across the world, so it's worth a visit.
Now don't get me wrong, I think these regulations are very important to protect consumers, especially since we saw a few companies take advantage of that (Remember the Jamster fiasco?). However, I think there should be a way in which cases like this can get authorization to work without a shortcode, since there's no meaning to unsubscribing from a one time message... This would make things easier for application developers that want to deploy in the US.
Luckily for us, even without the formal processes, in the field you can basically bypass that - at least for some time. If you go to a top-tier SMS gateway such as mBlox or NetSize (NetSize actually ceased to work in the US...) they will tell you all of the above, and that you have to buy a shortcode, so even if you're a starving startup and want to deploy a closed beta with a capacity of a few SMSs per month, you will still have to pay around $2K-$3K monthly, mostly for the shortcode, but also for account management and don't forget to add setup fees...
However, if you approach other gateways such as clickatell (which we have successfully tried and integrated with) or redoxygen, they will let you send MT SMSs without a shortcode and pay as you go per SMS. The problem would be that instead of having your own sender ID (which is the shortcode) you actually share your sender ID with other services - and if one of them (or you) spams users or charges them inappropriately, your service might get blocked along with a bundle of other services....
In the reality of things, it actually works pretty well and I know a lot of startups and even established companies that use these providers. But as usual all goes well until something happens, and there's also the question of "why risk it?" - but since we are talking about a lot of money the alternative looks quite attractive. Also if you plan for the worst you can always pre-integrate with 2 such providers and if something happens you can just switch to the alternate one...
So to sum up if you want to be 100% sure - go by the book with the big ones. This also applies if you have a big volume of message, then the big providers can also offer discounts per message that will pay off. But if you can afford being 99% sure (and don't want to spend $3K/month just for that 1%...) go for the pay-per-message providers, there's no reason to pay that kind of money for a closed beta or even for an open one until some point... Good luck!
