The SMS.ac Messaging Interface
The SMS.ac service provides two ways to interact with their subscribers using SMS: via the xPML <(Msg)>
tag and via their messaging API, available through a SOAP interface.
When you register your pod, you can provide a two-way messaging keyword and a URL to which any SMS messages should be sent which contain that keyword. Once you do this, any SMS messages received by SMS.ac to their short code containing that keyword will be sent to your application server for processing by invoking the URL you specify along with the contents of the query and the subscriber unique ID of the originator of the message. Thus, a subscriber sending the message "map to sandy's house" would generate a URL to the service registered with the map keyword that looked like this:
To send a response, you should include the <(Msg text="")>
xPML tag in your response to this URL, like this:
<(Msg text="Take route 236 north out of town to Gulch Road, turn left, stop at 1212 Gulch Road.")>
tag lets you provide simple responses to user queries, but if you need to originate messages to pod users without a corresponding request, it's time to call in the heavy artillery. The SMS.ac service provides a simple SOAP API with two methods, GetPodInfo
. While the details of integrating a SOAP request with your application are out of the scope of this article, it's enough to know that it's possible to do, and once that's done, it's very easy to use the SOAP interface with SMS.ac. Simply issue a SendMessage
call over HTTPS including your unique ID, password, and the ID of your pod, and the recipient unique ID of the recipient, and SMS.ac does the rest.
All of this is well and good, but what about the bottom line? In practice, SMS.ac is an SMS aggregator. To generate revenue, SMS.ac uses premium SMS to bill their subscribers; consequently it's easy for consumers to access the service and pay to use your pod. The widespread adoption of premium SMS by most carriers has generated an environment where micropayments can be truly commonplace; SMS.ac leverages their relationship with hundreds of carriers as an aggregator to aggregate those micropayments on behalf of developers such as you and me.
Once you publish your podby listing the description, URLs, and so forth with SMS.ac and pass their acceptance criteriaSMS.ac users can sign up to use your pod. In doing so, they generate premium SMS traffic to their mobile handsets, resulting in payments from the userscarriers to SMS.ac. These, in turn, are collected by SMS.ac and funneled back to developers. At present, the SMS.ac service has a Web-based transaction reporting interface that lets you monitor how your pod is being used as well as what SMS.ac will pay you for your pod's use; SMS.ac pays developers in US dollars on a regular basis at the close of the carrier billing cycle. It's reminiscent of the Qualcomm BREW Delivery System model, in which subscribers pay carriers, carriers pay Qualcomm, and Qualcomm pays you; the difference is that instead of subscribers having to manage additional line items on their mobile service bill, payment is handled via premium SMS. It's a novel way to manage the billing process, and it keeps independent developers from having to hassle with each carrier or SMS aggregator in search of recurring revenue.
With xPML, SMS.ac has introduced some interesting ways to generate revenue from mobile consumers. While billing via premium SMS isn't new (it is, of course, the sole purpose of premium SMS!) tying it to a template-based Web language for fixed and mobile browsers is. And with the simplicity of xPML, it's easy to create small applications funded by micropayments from subscribers on hundreds of networks around the world.