Non-renewable subscriptions and verifyReceipt for old receipt data

Hello,


We want to implement In-App Purchase in our application, but there is one case which we cannot find how to handle in Developer Documentation.


We have non-renewable subscriptions which user can buy and after payment this extends subscription for some product for some time (for example 30 days) and this information is stored on our backend. We don't want to use auto-renewable subscriptions because during subscription time, user can extend his subscription for another period of time for a lower price and so on...


The problem which we found is the case when:

1. User bought a subscription

2. Information about transaction is passed in receiptData to backend, which verifyReceipt and prolong subscription on our backend. I want to notice that we are storing receiptData on backend side.

3. User want to refund, so he cancel subscription on Apple Side

4. He is logging out from his Apple ID account (so we are not able to fetch fresh receipt)


My question is, if we use old receiptData which is stored on the backend, does /verifyReceipt endpoint will include cancellation_date, or we want to force user to fetch his newest receipt and then cancellation_date will appear?


So generally i am asking if /verifyReceipt can dynamically send different data for transactions based on same receipt data, or all information are stored in receipt data and this will never change until we fetch fresh receipt.


Can someone know the answer to that ?

Replies

The number of users who 1) ask for a refund for a non-renewing subscription AND 2) are given that refund AND 3) continue to use the rights under the non-renewing subscription are SO SMALL that you are wasting your time worrying about it, IMHO. Add to that - what are your losses anyway?


It is unclear whether or not a new receipt will have a cancellation_date field in it. But to get a new receipt you would need to refresh the receipt requiriung a log in to the App Store which will offend ALL of your users each time they try to use the app. It's not worth it.

Unfortunately this case need to be handled in our app because these are requirements, and i think is not wasting time because some of subscriptions will cost more than 100$, so it is important to handle it.

You need to differentiate "fixed cost" from "variable cost" and you need to differentiate "lost sale" from "no sale".


Most users who scam the system by getting a refund and still using the system are "no sale" not "lost sale". That is, they will not repurchase when you catch them with a cancelled subscription so there is no lost revenue here.


If a thief uses a subscription after a cancellation then are you suffering a "variable cost". If not, then you would have no cost saving by catching the thief and shutting off their subscription.


So, if there is no "variable cost" in a subscription, then you are bothering all your good customers by forcing them to log in and refresh their receipts in order to verify they are not thieves and in exvchange you gain no additional revenue and you save no costs.