The way you describe using RVS (your server to RVS server) is the way it is intended to work. Remember you need to send (and therefore store) three parameters when you call RVS: user ID, purchase token, and developer secret. Unfortunately the use case you describe (expired subscriptions) is not yet supported in the SDK Tester -- we are working on improvements to the tool, keep your eyes open for updates. :)
Hi Steve, thanks for your help! I'm developing server to server purchase token verification. I've a system that store the token and length of a subscription, and try to verify them every week/month/ecc.ecc. (according to subscription length). I would like to check when a subscription is cancelled not using my app, but from a verification with Receipt Verification Service. For this, I think, you should implement a feature in Receipt Verification Service Sandbox that return a non-null endDate on validate subscription. Is correct?
The RVS Sandbox will process tokens generated by the SDK Tester. The current version of the SDK Tester allows for cancelled subscriptions, but not expired subscriptions. Here's the difference: 1. Cancelled Subscriptions: These are subscriptions that are revoked. The SKU for the subscription would appear in the "Revoked SKUs" part of getPurchaseUpdatesResponse(). To Cancel a subscription in SDK tester, tap "Cancel" from the Active Subscription page. 2. Expired Subscriptions: These are subscriptions that had auto-renew turned off before the next billing cycle. Currently the SDK Tester does not simulate this condition. Hope that helps