Question IAP capturing auto-renewel subscriptions that occur externally of app

Apologies if this has been asked/resolved recently. I've gone through a bunch of previous forum posts and cannot find a clear solution (or one which works with the ever-updating Unity IAP package)

Our general account/user setup:
- For the sake of reading, I'll refer to our backend CRM customer's account as GameAccount (as opposed to their Google/Apple store account)
- Our app creates a single GameAccount, managed on our backend, using the user's email addresses for identification.
- Each GameAccount can have multiple users, which we call 'students'. The 'student' users have their own profiles and login credentials to enter the game (through the app's GamePortal, requiring their own unique un/pw to access).
- Each GameAccount has a single 'parent' user which can be logged into via an AdminPortal. Here, they can purchase subscipritons to a premium service. This service will unlock perks which become available to all 'student' users on that GameAccount.
- The student user can therefore access the app using their personal un/pw credentials on any device/platform that is supported by our app (currently iOS, Android, UWP).

Scenario:
- The scenario I'm working with here is where the GameAccount parent/administrator has purchased a auto-renewable Monthly subscription via the PlayStore.
- We record the token/id/expirationDate etc in our GameAccount for future identification/validation.
- A month rolls over and the the subscription renews for a second cycle (with a new expiration date)

Problem(s):
- It seems to me that the only way for the GameAccount to be updated with new expiration date is for the administator to log into their Admin Portal and run the IAP initialiser.
- Until this check and refresh is done, the student user on a different device (with a different Google account) will have their services blocked (even if the auto-renewel went through) as we have not had a chance to check and update those services on the GameAccount (because the GameAccount administator has not accessed the Admin Portal, and thus run IAP initialiser to refresh subscription data).
- In the PlayStore test environment, the getExpireDate() received from the SubscriptionManager does not seem to refresh. When initally purchased the expiration date returns PurchaseDate + 24hrs for Monthly subscriptions (runs for 5min in realtime). This "PurchaseDate + 24hrs" carries on on subsequent auto-renewed subscriptions (i.e. never gets updated).
- The app displays available subscriptions options (upgrade/downgrade/new) based on the received data from the GameAccount and the IAP package. For instance, if the original purchase was done through PlayStore but then user logs into GameAccount on an iOS device, we can display a 'You must use original Android device to edit any current subscriptions'. This is easy enough to handle. The issue becomes when a user logs into GameAccount on a device with a different Google Account.

So... my questions are:
1) How can we ensure that when subscriptions are renewed automatically (and externally, on the Stores' side) that new expiry dates can be captured and updated in our GameAccount?

2) Is the only way of checking if a subscription has been renewed done by initialising IAP when the user is on a device logged into the same Google account that the original subscirption was first purchased? If so, any suggested best practices here would be appreciated as this seems quite limiting.

3) Is the incongruency with the expiration date (for PlayStore) just a test environment 'bug'? i.e. when in production, will the expiration date be updated with the new date? The AppStore kind of covers itself by giving the history of receipts (and original transaction ID) so we can work around that and make a calculation as to what has been updated. purchasing

4) What is the best method (outside of OAuth linking) of linking a store account (i.e. AppStore/PlayStore) to an external CRM? I know this one's a bit out of scope but hopefully you can see the connection to my primary problems here. I can open a separate chat for this if preferred.

 

Thanks for the reply but I think you've misunderstood most of my questions. Perhaps I was too detailed and should be more concise and to-the-point next time.

I know the way it 'generally' should work which is why I went into detail describing my outlier scenario - although I can't imagine I'm the only person with this issue. I do use the SubscriptionManager to get expiration date when I can. My scenario was when the device is not in the account of the original subscription purchaser.

I've seen references around Pub/Sub services to work with PlayStore by checking the status of the subscription token but that looks like a whole can o' worms I need to explore (if I need to explore it...?). I was hoping someone might be able to push me in the right direction on how to get started and save me some time.

Also, I mentioned that the expiry data from the Google in test mode is not accurate and doesn't update with renewels - so the SubscriptionManager check solution doesn't work for me here. I know this is Google's data and therefore not controlled by Unity IAP package but Unity might have an idea on what buggy data to ignore in test mode. Surely this has come up before...? I'm hesitent to push this into Production and just hope that Google's expiry date gets updated.

I've been though the Sample IAP (v3) as well as all of the additional Sample codes that are in the IAP package (currently using v4.1.4). None of them seem to clarify what I was after.

 

Hi @omnibaker,

I'm replying to your last post - getting most recent and up-to-date subscription status requires server-side receipt validation and tracking user inventory in a database, per user / device identifier. The SubscriptionManager is suitable for local validation at the time of purchase and for getting the current subscription's expiration date, but it does not magically update on renewals or is a definitive way to always validate the most recent receipt. Even more important, it does not work on iOS at all, since the app receipt does not update without making an additional purchase in-game.

You've mentioned the Pub/Sub service and that is indeed the way to go. Google Play will send subscription update notifications to your server's endpoint including the user's purchaseToken, so you will be able to match a previous subscription with the new notification data. There is work happening to facilitate requesting subscription data in later billing library versions on the client side, however Google and Apple still recommend using server-side validation and notifications (RTDN on Google, App Store Server Notifications on Apple) as best practice.

Now, my usual final sentence (#advertising) - I've been working on a platform that handles all of this for more than a year. A package using Unity IAP is available as well. If you're interested, please see here and here.

 

Thanks for the feedback and confirmation. All good with the product plug - we gots ta get paid somehow

 

At the moment the user logs into an Administrator portal with their un/pwd credentials and there they will (in theory) purchase subscriptions. We aren't currently doing any purchase features at the moment while we figure this out. Our working plan is to link the subscription token/transactionID to that account - and then locking them to that platform (AppStore/PlayStore) for the duration of that subscription to accomodate subscription upgrades.

If the device the user is using is different than what we have on record (i.e. iOS device when the subscription was purchased on an Android) we display a "Sorry, wrong platform..." message. If it's the correct platform BUT there is a discrepancy between any purchase IDs we have stored in our backend and what is coming from the devices Store account (when initialising Unity IAP) then we assume that the Apple/Google account is in the wrong name so we will display another "This is the wrong Google account on this device..." message.

My main issue was making sure our backend details for each subscription was up-to-date for any cancellations/upgrades that may have occured outside of the app. The updating solution we've gone for is the messenging services from the AppStore/PlayStore as summarised here:
https://medium.com/@jmn8718/in-app-purchases-notifications-4408c3ee88eb