Google Play Test Subscription Lengths (SubscriptionInfo)

Hi,

We've been working through the upgrade of an app to Unity IAP 1.19.0. In previous versions we would adjust subscription and trial periods to match the test environment. This wasn't an issue since we were doing all of the calculations ourselves.

With the upgrade we noticed that the new SubscriptionManager/SubscriptionInfo doesn't seem to adjust the time periods returned by Google by default. Is there some way to enable this functionality?

Since we don't have access to the calculations going on inside SubscriptionInfo or a way to override the time periods on the SubscriptionInfo object we don't really have a way to accurately test subscriptions.

 

@mbaker These subscription periods are set by Google, and we have no control over them. The periods are defined here:

https://developer.android.com/google/play/billing/billing_testing

 

@JeffDUnity3D I understand that but when testing a build locally or through Google Play's Alpha/Beta channels the subscription periods are reduced to predictable, short periods documented at the link in your last post.

However, Google IAB and Unity IAP will still return the original subscription periods. For example, a 1 month subscription, when testing, the receipt will expire in 5 minutes BUT Unity IAP will report that the subscription expires in 1 month. Not taking into account it is operating on the testing version of Google Play.

What I was hoping is that there is a flag I can set or something that causes Unity IAP to adjust all of the subscription periods to the values that Google will expire on.

Previously we had our own logic that we'd manually enable, when testing, which would map production times to test times. The rest of our time to expire logic would then work as expected.

 

Sorry, there is no such flag. These are not settings that Unity has control over, and Google may change them. You mention "previously we had our own logic", what has changed?

 

OK, thanks. I guess my best bet is to either modify the Developer Payload JSON before running it through SubscriptionManager or doing some math on the expiration dates that SubscriptionInfo returns. Will have to think on this one.

Previously, we calculated the expiration dates ourself. We stepped forward from the purchase date in increments of subscription periods until we were at or past DateTime.UtcNow. When running on the test Google Play environments we'd enable a #define that would remap Google's subscription periods right before doing the calculation described above.

This worked well but with 1.19.0 we wanted to switch over to the SubscriptionManager for easier maintenance and making use of established solutions instead of rolling our own.

Since SubscriptionInfo does all of its math and deserialization internally we can't easily adjust the subscription periods to the test environment values without either adjusting the values that come out of SubscriptionInfo or deserializing the developer payload, modifying the periods, and re-serializing the payload before sending it through SubscriptionManager.

 

May I ask, what are you trying to test? Why do you need the absolute subscription duration? Perhaps to test logic like "We see your subscription will expire in one week, please act now!" or similar?

 

There are a few uses for being able to predict an expiration date and/or renewal time:
- Expiring a subscription if the user is offline and autorenew == false
- Debug panel to help our QA understand how much time is left on a subscription
- End of free trial messaging

I haven't verified whether this is still valid in 1.19.0 but I'm pretty sure it is
- Expiration of receipts during a single play session. During a single run instance Unity IAP will never stop returning a receipt, even if it is no longer provide by Google Play. The app needs to be restarted. The native inventory object, with regard to subscriptions, is only ever additively updated. A subscription receipt is never removed.

 

I just noticed this too in SubscriptionInfo

this.subscriptionPeriod = XmlConvert.ToTimeSpan(s1);

Isn't that an oversimplification?

if s1="P1M" the TimeSpan returned will be 30 days. Since not all months have 30 days the calculation for SubscriptionInfo.subscriptionExpireDate will be incorrect for many months.

 

I suspect (and need to check) that subscriptionPeriods are just 1 month, 3 months, 6 months etc, likely based on 30 days in the month, and probably not using this exact duration in calculations. And we are not calculating the subscriptionExpireDate, Google would handle that. I am confirming with the IAP team.

 

Turns out that we do calculate the expire date for Google (Apple does give the expire date in the receipt), so you are correct, the oversimplification that you refer to is indeed critical. We are looking into this.

 

Thanks Jeff. Looking forward to a fix.

 

Hello @JeffDUnity3D, I'm on IAP version 1.21 and I can confirm this still persists. Google provides shortened waiting time on test accounts for subscriptions as seen here https://developer.android.com/google/play/billing/billing_testing. But Unity IAP returns the actual waiting times(a week, a month) and it doesn't really renew the subscription since it is renewed every 5 minutes by google. Is there any workaround on this issue ? I need the new receipt when the subscription auto renews itself so I can validate the new receipt through our server to make sure that user has a valid auto-renewed subscription.

 

Please test with the latest version 1.20.1 (yes, more recent than 1.21). Are you not getting a receipt after the 5 minutes? Unity IAP doesn't renew the subscription, this is done by the store (Google).

 

I see the google renewing the receipt every 5 minutes in console. But Unity IAP doesn't seem to be getting them(atleast in 1.21). Can you confirm that this situation has been handled by Unity IAP 1.20.1(and also, why 1.20.1 is more recent? Don't you think it's a bit confusing?)

 

Yes, 1.20.1 is more recent, and is a bit confusing. Please test with 1.20.1

 

I tested this with 1.20.1 and the issue described above still persists.

 

Please provide specific steps to reproduce

 

Steps:
1. Purchase a subscription with a Google Play test account.
2. Create a SubscriptionManager with the purchased subscription.

SubscriptionManager p = new SubscriptionManager(loadedProduct, null);

3. Get SubscriptionInfo.

SubscriptionInfo info = p.getSubscriptionInfo();

4. Get the ExpirationDate.

info.getExpireDate()

5. The expiration date appears to be the date of a live subscription not of a test subscription. (In our case: The expiration date is 1 month in the future but it should be 5 minutes in the future)

 

What version of IAP are you using? The latest is 1.22

 

I can confirm the issue still happens on 1.22. Unity IAP shows incorrectly that subscription length is one week as it's defined in Google Play. However while testing IAPs the correct length for 1 week subscription is 5 minutes and 3 minutes for free trial (https://developer.android.com/google/play/billing/billing_testing#testing-renewals).

This makes testing very hard because I would have to wait for full week in order the IAP plugin would show "expired" status. Also the first time I purchase the subscription the length is few seconds so basically right after purchasing and validating with backend the subscription shows "expired" status. I would have to rely on hacks to do testing of any kind (one week wait time is unacceptable).

Issues:
1. Should show 5 minute subscription length instead of 1 week while testing
2. After initial purchase of the subscription, length is incorrectly ~4 seconds -> immediately shows "expired" because native popups, backend validation etc. takes longer than the subscription is actually active.

 

Can you describe why this impacts your testing? You should only be checking for Expired, which seems to be working regardless of the time frame?

 

Because we only care about the "expiration date" value, which is synchronized to backend. If we should be only checking the isExpired(), you should definitely add that to the documentation. I think it is pretty logical to trust that the subscription status does not change until the expiration date. For example if we give server-side daily rewards for subscription users and user does not login after cancel to sync with server server has wrong information.

1. Start the app
2. Purchase subscription
3. Exit app
4. Cancel subscription, wait until cancel time is reached (few minutes)
5. Start the app again
6. item.receipt is null (cannot get subscription data) and latest information is that one week left for subscription

So what I did not take into consideration is that if subscription has ended, you cannot even get subscription data for the purchase, which is very misleading since the incorrect time period.

It would make a lot more sense that the subscription system can retrieve the sub status even though the subscription has ended. Now we have multiple conditions to check which is counter-intuitive.

 

I believe we have the same problem. Subscription expires before ProcessPurchase method being called.
The method isValidPurchaseState(AppleReceipt appleReceipt, string id) from AppleStoreImpl class, marks our subscription as expired, and finish transaction before we get ProccessPurchased() called. And the most interesting it happens only on ONE testing apple device iPad 5th generation, ios 12.3.1, rest of our testing devices shows normal behavior. Struggling the whole week with this issue. Need help.

FOUND FIX.
It was wrong ios datetime settings. My clock was in automatically update mode, when I had turned it off, it showed me wrong time (clock few minutes fast). After toggle auto mode on, I get normal clock date time, and my subscription works perfect as usual. I think Unity team need somehow rework
isValidPurchaseState() method in AppleStoreImpl class, because it drops valid subscription if device has wrong time.

 

Subscriptions only last a few minutes in testing, you need to have your device time set correctly, we have no control over this.

 

same behavior i am getting, was this solved?
i want the exact expiry date, since its required to show in the UI for the users like a counter, time remaining for renewal
but since the receipt returned wrongly displays 7 days instead of 5 min, my timer also shows 7 days till renewal

i checked the mail for google play reciepts, those were proper, got renewed for every 5 min, then after 6 time it got cancelled, after this mail when i launched the game, subscription info class from subscription manager was null, which i suppose is alright.
but during the renewals, the information like expiry date returned by the subscriptioninfo class does not match the receipt i got in mail

 

Please do not multipost, this has been answered in your other posts.

 

Hi,

I am getting the same issue in 2.1.1.

The reason I need to know the exact expiry time for testing is so I can test auto renewals. @JeffDUnity3D we recently spoke about ProcessPurchase not being reliably called on an auto renewable subscription https://forum.unity.com/threads/pro...on-subscription-renewal.1015999/#post-6716959. My workaround is to store the expiry of a subscription and check it against the latest SubscriptionInfo expiry every time the app starts. If the sub hasn't been cancelled/expired and the latest expiry is later than the stored one, I can presume that a renewal has happened and award the player with their monthly items.

I can't test the behaviour if the expiry time is not correct, it shows an expiry a month away, rather than the 5 min test times used by Google licensed users. This would be fine if the expiry updated when the subscription was actually renewed every 5 mins, but it doesn't, it remains 1 month away from the original purchase date.

If I can't use ProcessPurchase, and I can't test using the provided SubscriptionInfo, what do you recommend doing to get around this issue?

 

Nothing would be expected to change between versions. We set it this way due to many customer requests, apparently we can't please everyone. You would need code during testing which maps 1 month to 5 minutes, and make assumptions.

 

The recommendation is to just check for the existence of a receipt or not. No receipt, no subscription.