3

i've got an android app with in-app subscriptions. After the user has purchased a subscription, i request the "validUntilTimestampMsec" and "initiationTimestampMsec" through our backend by the Google API.

The returning timestamp "initiationTimestamp" is correct and represents the time the user has made the purchase, but the returning timestamp "validUntilTimestamp" has always a difference of +12 hours to the real valid-until time i need. The function i use to retrieve the date is simmilar to both timestamps.

Where does the 12 hours come from and how can i get the correct time. The expire date will also be displayed wrong for the user inside Google Play.

Example for a monthly subscription:

Is:
initiationTimestamp: 1374433559436 (7:05pm)
validUntilTimestamp: 1377155159436 (7:05am) -> init-time + 1 month + 12 hours

Needed:
initiationTimestamp: 1374433559436 (7:05pm)
validUntilTimestamp: 1377111959 (7:05pm) -> init-time + 1 month without the 12 hours

Charles
  • 50,943
  • 13
  • 104
  • 142
0xPixelfrost
  • 10,244
  • 5
  • 39
  • 58
  • Where do you get validUntil from? I can't seem to locate it which api call that rerurns it. That said it very puzzling as google only support monthly and annual. – Warpzit Jul 31 '13 at 14:02
  • https://developers.google.com/android-publisher/v1_1/purchases#resource. As you can see, google returns the expire time since epoch, but with the delay of 12 hours for me – 0xPixelfrost Jul 31 '13 at 15:16
  • 1
    Interestingly it was asked here: http://stackoverflow.com/questions/15354249/google-play-store-is-giving-extra-credits-to-user but was closed as off topic, but he mentions 6 hours, so you might try asking if he got an answer for it, but I would think the additional time is a grace period for cancellations, retry requests etc. – Vrashabh Irde Aug 04 '13 at 05:02
  • Thanks for your hint Slartibartfast. I am really annoyed by the Google Support. I posted the same question 3 times to the corresponding Google Group without getting unlocked by a moderator. The Android Bugtracker guided me to the Google Play Service Support and the Support answered: It is a developer Problem, please ask the Google Group. – 0xPixelfrost Aug 05 '13 at 07:05

2 Answers2

2

I dont see this anywhere mentioned, but I think Google maintains the 6 hours in v1 from Shrinath's example and 12 hours now in v1_1(looks like from your example) to basically to keep a time buffer to withdraw funds from the account of the client(a really important transaction that google is accountable for), and for cancellations and retry requests. I dont see a way around it, other than showing a warning saying it may take upto 12 hours to see new stuff or something like that.

Vrashabh Irde
  • 14,129
  • 6
  • 51
  • 103
  • I have recently changed the version from v1 to v1_1. The difference was/is the same for me. I'm just wondering that there is no official statement about this behavior. – 0xPixelfrost Aug 06 '13 at 18:14
  • Same as in 6 hours for you as well? Or was it changed to 12? Yeah I dont see it anywhere on any google site/forum – Vrashabh Irde Aug 07 '13 at 01:49
  • I would think this really is a timeout time if you will, large scale companies generally keep it when it involves payment liabilities because of the inherent nature of the system . Just another thought that maybe there is some timezone difference involved somewhere that might cause this :) But I don't think you will get an official answer until the bounty runs out unfortunately. – Vrashabh Irde Aug 07 '13 at 04:23
  • Thanks for your commitment Slartibartfast! 1) Both v1 and v1_1 got the +12 hours 2) I retrieve the initiationTimestamp correct, so i imply that there is no conversation issue on my side 3) Apple is also a large company and returns the expire-time without extras for subscriptions. I would prefer to to have the choice myself :/ – 0xPixelfrost Aug 07 '13 at 08:07
  • Ohk.Interestingly I looked around and saw a lot of developers in other countries say 6 hours for v1(had a link to a russian android developer forum which on translation, the dev complained that he was finding 6 hours difference), so maybe there is some difference. True with apple, but I would think Android/google play problems multiply exponentially with the amazing fragmentation of android implementations, the different versions and devices that implement different versions, and is a complete difference from iphone,ipad and ipad mini :D . Update the answer here if you find a solution :) – Vrashabh Irde Aug 07 '13 at 08:34
1

Write a function which calculates the validity time that "is right". If Google's reply doesn't match, use the one you calculated, otherwise, use the one that Google gave.

Also, observe that Google always adds additional time, not other way. So if your function returns "greater than" Google's then consider Google's time, else your function's time.

Thats how I solved it in app's backend.

Shrinath
  • 7,888
  • 13
  • 48
  • 85
  • Calculating the expire date manually is not the problem, but it does not solve the problem. After the item expires for the backend, it still remains in the play store for a couple of hours (in my case the +12 hours). The user will not be able to extend the subscription (he would get the message: "already bought") and thus to use the respective content. – 0xPixelfrost Aug 05 '13 at 12:49
  • Fire a subscription cancel as soon as you detect the expiry? :) We built a CRON too, that runs every 15 minutes and resets the subscription of users who were bound to expire. That way you are at most 15 minutes delaying the users' purchase. – Shrinath Aug 07 '13 at 09:24
  • Are you sure? I think, cancelling a subscription does not mean that the subscription is not longer available immediately. Cancelling means: The subscription will be available until the regular expire time has been reached but will not prolonged automatically. – 0xPixelfrost Aug 07 '13 at 10:55
  • It does allow you to make another subscription after you cancel it though. This was the desired effect, so we chose to go with it. – Shrinath Aug 12 '13 at 11:23