Rosa Gutierrez - The recurring nightmare. Implementing cross platform in-app subscription purchases

By: Codemotion

3   0   89

Uploaded on 08/24/2016

We make money out of a subscription model and we want to allow users to subscribe from their mobile devices without leaving our app. Most app stores (iTunes, Google Play, Amazon, Windows Phone Store) let us offer in-app recurring purchases in exchange for a percent of the price but that doesn't come without headaches. Unlike most one-time in-app purchases the backend piece is critical for subscriptions. Trials, expirations, renewals, hacking attempts... In this talk we'll see an overview of what to consider when handling different stores and some quirks and annoyances we'll need to deal with.

Comments (4):

By anonymous    2017-09-20

Yes we see this happen as well. We see this triggered by 'Restore Purchase' button clicks.

If your 'Restore Purchase' button uses the restoreCompletedTransactions API then this will cause your transaction ID's to change. We have confirmed that this with Apple developer support.

Apparently you can call SKReceiptRefreshRequest instead which will just grab the latest receipt instead of replaying all of the transactions. It is my understanding that this will not cause the transaction ids to change.

We have, anecdotally, witnessed that the web_order_line_item_id values do not change across calls to restoreCompletedTransactions. However we only received an ambiguous, at best, response from Apple developer support when we asked for confirmation:

In regards to the web_order_line_item_id field, the value will change on every subsequent renewal.

You can use this, as long as you continue to store the new value as the renewal subscription events come in.

We take this to mean that the web_order_line_item_id is unique per renewal-purchase. Which neither confirms nor denies that it remains constant across calls to restoreCompletedTransactions

Additionally, I found this conference recording on Apple/Google/Amazon recurring billing very helpful (though, not for this particular case):

Rosa Gutierrez - The recurring nightmare. Implementing cross platform in-app subscription purchases

Original Thread

By anonymous    2017-09-20

Well, the server that handles the authorization of the user (that is, your server) should query the Google Subscription API, to check if the current subscription is still valid. Each SubscriptionPurchase Resource contains information about when the subscription expires.

(see https://developers.google.com/android-publisher/api-ref/purchases/subscriptions)

For Apple, the same stuff applies: You will get a receipt, and with that receipt, you can query the server at any time to check if that subscription is still valid.

There is a slide which summarizes these points and the pitfalls very well: https://speakerdeck.com/rosapolis/the-recurring-nightmare-cross-platform-in-app-subscription-purchases

Bottom line: You won't be able to make that happen without a server that does the communication between the two stores. It comes with issues, though, as the slide shows.

Bonus: The talk from which the slides are taken is also on Youtube

Original Thread

Popular Videos 165

Submit Your Video

If you have some great dev videos to share, please fill out this form.