Question

Incorrect expiry date being returned from RevenueCat

  • 6 April 2022
  • 2 replies
  • 235 views
J
Badge +6

Date problem….

The date/time here in the UK is currently 04/06/13:02.

Here is the json for a subscriber that is reporting an issue:

    "entitlements": {

      "TPBDCore": {

        "expires_date": "2022-05-06T18:06:16Z",

        "grace_period_expires_date": null,

        "product_identifier": "TPBDInNoMonthly",

        "purchase_date": "2022-04-06T18:06:16Z"

      },

      "tpbdinad": {

        "expires_date": "2022-05-06T10:26:58Z",

        "grace_period_expires_date": null,

        "product_identifier": “TPBDInAdMonthly",

        "purchase_date": "2022-04-06T10:26:58Z"

      },

      "tpbdinno": {

        "expires_date": "2022-05-06T18:06:16Z",

        "grace_period_expires_date": null,

        "product_identifier": “TPBDInNoMonthly",

        "purchase_date": "2022-04-06T18:06:16Z"

      }

    },

As you can see, the TPBDInNoMonthly subscription is showing a purchase date in the future. As a consequence it is incorrectly overriding the TPBDInAdMonthly subscription the customer moved to this morning.

The customer has checked on their iTunes account and only the TPBDInAdMonthly is showing as active, as far as Apple is concerned the TPBDInNoMonthly subscription was cancelled automatically when the customer upgraded to TPBDInAdMonthly (correctly), but RevenueCat has TPBDInNoMonthly as still active because it’s got the purchase and expiry time set incorrectly.

Restore subscriptions doesn’t resolve the issue - as far as I can tell lApple is sending RevenueCat the correct information but RevenueCat is setting the time wrongly.

2 replies

ryan
Rank
Userlevel 5
Badge +9

Hey @JamesO!

Renewals from Apple will usually come with a timestamp in the future. This is because Apple starts attempting to charge the customer ~24hrs before the renewal date, as soon as the charge goes through the renewal is processed and added to the receipt, and picked up by RevenueCat.

I looked up this transaction and did see it was a renewal (not an initial purchase) so we’d expect the timestamp to be in the future, and the dates in json post you shared correspond with the validated Apple receipt for both products.

 

J
Badge +6

Thanks Ryan, useful to know, but I’m now even more confused.

“Crossgrade. Someone switches to a new subscription of the equivalent level. If the subscriptions are the same duration, the new subscription begins immediately.”

For one, this was a subscriber crossgrading within the same subscription tier from a subscription with a lower price to one with a higher price, both monthly, it therefore isn’t really a renewal. But the new subscription ISN’T starting immediately.

What seems to have happened is that the end date that should have been applied to the subscription being moved TO was instead applied to the subscription being moved FROM, rendering the cross grade useless.

Secondly, we’ve never seen this before, but moving between subscriptions (up, down and cross) in our app is commonplace and frequent, as our users change the levels at which they compete quite often, and the subscription tier design accommodates this (and has remained unchanged for more than 3 years now). If the behaviour seen is correct this would happen to us frequently (and render our whole subscription design obsolete).

Thirdly, if this is now normal Apple crossgrade behaviour then crossgrades will fail for everyone if they happen close to an expiry date, this would effect millions customers across may apps, not just us.

If the data is all correct from your POV then I guess I need to raise this with Apple???

Thanks, James

Reply


Terms & ConditionsCookie settings