Rosa Gutierrez - The recurring nightmare. Implementing cross platform in-app subscription purchases
3 0 89
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.
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
Additionally, I found this conference recording on Apple/Google/Amazon recurring billing very helpful (though, not for this particular case):
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.
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.