In App Purchases and Receipt Postback

In-App Purchases are a wonderful, wonderful thing, and have in a few short years created a multi-billion dollar industry of their own. They’re convenient, they’re fast and, most of all, they stop you from having to type out your card details every time you want to buy something.

That all said, we know that there are a number of situations in which In-App Purchases (IAPs) just don’t really make sense. Perhaps access to content is bundled as part of a bigger membership package, or perhaps you don’t fancy Apple, Google and Amazon taking their 30% commission from your sales.

ANOTHER WAY TO PAY?

So, what are your alternatives if you don’t want to run your content purchasing through IAPs? Apple makes your options for iOS pretty clear: there are none. Here’s the official wording:

“If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase. Apps may not use their own mechanisms to unlock content or functionality, such as license keys, augmented reality markers, QR codes, etc. Apps and their metadata may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than in-app purchase.”

Trying to circumvent this is a very fast way to get your app rejected. Spotify are a notable example of how closely developers have to hew to these guidelines. Tapping the “Premium” button on iOS will take you to a lovely screen detailing the benefits of premium alongside the line “Spotify Premium can’t be purchased in this app”. No URL, no hint of where one might be able to subscribe, no nothing.

Google and Amazon, pleasingly, don’t have any such restrictions and you’re free to allow your users to purchase their subscriptions using whatever payment gateway and method you like.

Perhaps, though, you’re looking for a deeper relationship with your customers, and your real goal is to bring them fully into your ecosystem without sacrificing the ease of IAPs. With that goal in mind we’ve integrated with one of Apple’s newest services to allow you to harness the ease of In-App Purchases while still allowing you to create and maintain a record of your user and their subscriptions.

THE BEST OF BOTH

iOS receipt postback follows a relatively simple flow. Once a user has successfully purchased a subscription via IAP, we immediately present them with a simple screen encouraging them to create an account with you, the publisher. They can follow the prompts there and then to create this account, which we’ll securely send to your subscription system.

To avoid being too onerous for users (and to stay on the good side of the App Store Review Guidelines) this process can be dismissed at any time. However, we’ve also made it accessible from the settings so that unregistered users can launch the sign-up flow at any point.

         

          Our default receipt postback user flow

Now that the user exists in your database, you need to know a little more about them. Specifically, you need to know what kind of subscription they’ve purchased and whether it’s still valid or not. We can provide you with the information needed to securely validate the user’s subscription with the app store. This will enable you to check what kind of subscription the user has purchased, whether it’s still active and when it’s due to expire.

Your subscription system can then validate the receipt again when necessary. This is in tandem with the validation we already perform to ensure a user has the correct access.

Setting up receipt postback isn't quite plug-and-play, it requires a little custom work to hook up to your desired system and theme correctly, and it will require an app release to enable the feature for new and existing users.

WHAT ABOUT ANDROID?

Unfortunately Google and Amazon don’t offer as fully-featured receipt verification tech as Apple do, or at least not yet. On these platforms we're able to verify a user's current subscription status, but nothing prior to that. This means that while it works for "all-or-nothing" access scenarios, it's of limited use when determining precisely what content a user should have access to. 

We’re always monitoring the latest developments with our supported OS’s and should we become able to add the same support on Android as we can on iOS we’ll look at adding it to our roadmap.

As mentioned above, though, the freedom to direct users to your own payment gateway means you're still able to bring users into your own ecosystem by directing them to your own registration gateway from within the app.

If you've got any questions about subscriptions, receipts, or anything else for that matter, don't hesitate to get in touch at [e-mail]