We are using receipt verification service outside the app for subscription that is having 2 types of period. On sandbox When the subscription is purchased, and we check the receipt by calling the RVS using the war file, we get the sku as "xxx.xxx.parentsku.monthly" When we just verify the subscription and check the receipt by calling the RVS using the war file, we get the sku as "xxx.xxx.parentsku" On live environment whether we check the receipt of first time purchase or the receipt of verifying the subscription, we get the sku as "xxx.xxx.parentsku" Is this is how it works? we will never get the period in the sku using RVS. Why is it different in sandbox rvs war file?
Ok. There are couple of things. First, you should know there are couple of limitations in our sandbox environment and SDK tester. In sandbox you will get child SKUs back in onPurchaseResponse() and that would not happen in the live environment. SDK Tester cannot test displaying multiple subscription periods (e.g. weekly/monthly/annual) SDK Tester cannot test accurately calling the parent sku for multiple subscription periods (it picks one period seemingly at random) SDK Tester cannot test a subscription which has been cancelled and re-started SDK Tester does NOT return currency symbol unless it is explicitly entered in the price string value in the JSON file SDK Tester cannot test returning different price/currency based on the marketplace that a user is registered to RVS war takes purchase token as input and decrypt it, get the SKU and return this SKU value as response. Now Purchase token contain the parent SKU though the SDK return it's child SKU (monthly or weekly what ever). That's also an issue. We are aware about these issues and defects. In future these will be fixed. What you should follow in your app in live? IAP SDK/RVS would return you the parent SKU always. You would not come to know which child was bought actually. You are supposed to check periodically whether the subscription is still valid or expired from in client (onPurchaseResponse()) or RVS response (by checking the end date field) from the app back end to lock/unlock the item for the same user. We intentionally hide the subscription complexity from developer so that they can easily adopt the system. So for a subscription when we receive a success callback in the onPurchaseResponse() with the parent SKU as an identifier and a purchase token, we are supposed to deliver (or unlock) the content in the app client and persist the purchase token along with the user id (the one returned by IAP SDK) in the app back end (if the app has one). Now we can check the validity of subscription periodically in the client from onPurchaseUpdatesResponse and from RVS response from app back end. If the item is found out of the subscription period, we would invalidate the item for that user.
Is this still the latest status of the RVS? From our perspective, not being able to see the child SKU, billing period and expiration date for subscription accomplishes the exact opposite of "easy adoption". In fact it makes the API impossible to use because we are selling a cross-platform service. It's not sufficient make the client verify the subscription, the backend needs to be able to verify it independently of whether the client is active or not. Hiding complexity from the developer until it hides functional details, then it makes things 10x worse. In this day and age it's irresponsible to offload this much business logic in the client, because everyone expects cross-platform support from serious apps. The backend must be able to query entitlements or the service is crippled from the get-go. Google and Apple get this right, and I would expect Amazon to at least be better than Apple when it comes to web services.
Using latest RVS you will not be able to see the child SKU, billing period and expiration date for a given receipt id. You will only be able to know whether the subscription is active or canceled. Amazon manages the periodic recurring charge. You do not need to do anything outside of initiating the purchase. Amazon provides a cancelDate when the subscription is no longer active. If the cancelDate is null, the subscription is still active for the customer (even if the subscription auto renewed). If the customer cancels and then renews again, the app will receive multiple receipts. The first subscription that was canceled will have a cancelDate and the new subscription will have a purchaseDate and null cancelDate.