Thursday, September 07, 2006


I've been doing some research lately on SMS. At PocoPay, we had technology for sending SMS to our customers. For example, if you signed up online you werre sent a pin to verify your cell phone via SMS.

For sending SMS, we paid for a service from Clickatell. We would send them an email and they would then generate an SMS based on the contents of the email. Kind of primitive, but very cheap. PocoPay never made any money so cheap was important!

My latest research has been on receiving SMS. If you're a cell phone user, it is free to receive an SMS, though you must pay to send them. However, for an application provider, receiving SMS is a lot trickier.

SMS is very fragmented, especially in the United States. In the U.S., people like to use short codes for sending SMS. Thus if you want to receive SMS, you need a short code. Only problem is that short codes belong to service providers. So you must pay for the short code from each provider.

Next you still need to receive the SMS. Various service providers will relay the SMS to you either by email or by HTTP POST. Other providers give acess to SMPP networks where you can poll for your messages.

A more primtive route is to do things like cell phone users. This involves hooking your application directly to either a cell phone or a cell modem. Then you can simply receive the SMS on your phone, like an end user would, and then download the SMS to your server. This seems like a good "getting started" option. It's not as expensive, but it does not scale (that's ok for getting started.) Of course you have to connect your phone to a server and need code for interfacing with it, but there are lots of options for this, including some open source ones.

technorati tags:,

Blogged with Flock

No comments: