Month
November 2012
Since it was first introduced in iOS 3.0, in-app purchase has emerged as an important tool that iOS developers can use to bolster their revenue and stay in the black. In-app purchase only helps, however, when money actually changes hands. To that end, Apple has invested a lot of effort to give developers the tools they need to ensure that the in-app purchase requests they receive are legitimate and not spoofed.
The most important tool that developers can use to ensure the legitimacy of an in-app purchase is the digital receipt that’s received from the App Store when a transaction is completed. This receipt is cryptographically signed and can be verified as genuine by submitting it to a special server that Apple provides. The trick is, this receipt has to be submitted in a particular way. As Apple points out in its documentation, developers should submit in-app purchase receipts from a separate server that they control in order to avoid opening doors for those who would steal their work.
Many developers have gotten sloppy with their receipt checking, though. Despite Apple’s advice, many developers don’t bother to submit receipts for verification from their own server. Instead, they simply send the receipts to Apple’s verification system directly from the iOS device that was used to purchase the product. Developers that take this shortcut are leaving themselves vulnerable to what’s known as a “man in the middle” attack, which can be used to trick the app into delivering in-app purchase products for free. This vulnerability was exploited in a big way in July, 2012, when a hacker set up a server that took advantage of sloppy receipt verification and allowed owners of iOS devices to receive, for free, digital goods that should have required an in-app purchase.
It’s easy to see why developers would take shortcuts. Setting up a separate server for in-app purchases is a pain. Since a receipt verification server would be handling purchases, a developer would want it to have high availability, with very little down time. That means that most common, low cost, shared web hosting providers are ruled out. Many alternatives to shared web hosting providers aren’t very attractive either. Most require either much higher fees, or expertise in tuning and maintaining a server, or both. In addition to these problems, writing the server-side code that interfaces with the iOS app and Apple’s receipt verification server isn’t necessarily easy. The languages and technologies used in server-side scripting are very different than those that are used to write iOS apps, so many developers have an additional learning curve to overcome.
Fortunately, several “backend as a service” (or BAAS) providers have sprung up recently, including companies like StackMob, Parse, and Kinvey. These BAAS providers essentially offer their customers a database that can be accessed over the web, but some of these providers offer additional services as well. For instance, one of StackMob’s selling points is that it allows customers to run their own code on the StackMob servers. This provides an opportunity for app developers to validate their in-app purchase receipts using StackMob as their Apple-recommended “separate server that the developer controls.”
Using StackMob as a receipt verification server offers a developer several benefits compared to other options. StackMob provides a professionally managed enterprise-ready platform. Since StackMob handles all the system administration responsibilities, the developer doesn’t have to worry about scaling, hardware configuration, and other similar headaches. Best of all, StackMob recently changed their pricing structure. Instead of charging per API call as they used to (and as most of their competitors continue to do), they now offer a package of basic functionality for free and then charge extra for add-ons. One of the features of their basic free plan happens to be custom server code. StackMob’s pricing can change at any time, of course, but as of today it appears that the only thing preventing StackMob from becoming a free in-app purchase receipt verification platform for all iOS developers is the lack of the custom server code needed to actually validate the receipts.
And so I offer my StackMobIAPReceiptVerification project, which is now available on GitHub. StackMobIAPReceiptVerification is an in-app purchase receipt verification routine I wrote to run on StackMob’s custom server code platform. Once installed, it accepts in-app purchase receipts, validates them on Apple’s servers, and responds with a success code and the information contained in the receipt (if the receipt is valid). Since the routine has a RESTful interface, it can be called using NSURLConnection (and related methods), or using StackMob’s iOS SDK. For all the details, check out the project’s page on GitHub.
I hope that other iOS developers find this project useful. I know that there are many out there who haven’t bothered to set up receipt verification only because of the nuisance of it all. Hopefully StackMobIAPReceiptVerification will remove some hurdles and make it easier to ensure that you’re being paid for your work.