Subscription status mismatch

Hi, some day ago I got these webhook events for a subscription:

  • 2024-01-06 10:40:47 SUBSCRIBED subtype INITIAL_BUY
  • 2024-01-20 03:02:29 DID_RENEW subtype BILLING_RECOVERY
  • 2024-01-20 03:52:08 DID_CHANGE_RENEWAL_STATUS subtype AUTO_RENEW_DISABLED
  • 2024-01-20 10:41:03 DID_FAIL_TO_RENEW (no subtype was received)

When I get the subscription status form appstore server API, status is 1 (active). We don't have grace period enabled in our app. I'm not sure how to interpret this result; from our perspective we should remove access to the user.

Up vote post of nicolas1 Down vote post of nicolas1
426 views
Posted by
nicolas1
Reply

  • Adding some info, refund history endpoint doesn't return any results, and transaction history endpoint shows a second transaction after the initial trial one, with the price and "transactionReason": "RENEWAL".

    —
    nicolas1
Add a Comment

Accepted Reply

In this case, the DID_FAIL_TO_RENEW notification was sent after the subscription was successfully recovered. When you received the DID_RENEW subtype: BILLING_RECOVERY, that was when the subscription recovered. Shortly after that, auto renew was disabled. The subscription status API is still returning status=1 because the subscription is still active until it expires, and that is also why you see a new transaction in the response from the transaction history endpoint. Based on the information you have shared, refund history should not return anything as nothing was cancelled.

Posted by
Frameworks Engineer
Up vote reply of Frameworks Engineer Down vote reply of Frameworks Engineer
Post marked as solved
Add a Comment

Replies

In this case, the DID_FAIL_TO_RENEW notification was sent after the subscription was successfully recovered. When you received the DID_RENEW subtype: BILLING_RECOVERY, that was when the subscription recovered. Shortly after that, auto renew was disabled. The subscription status API is still returning status=1 because the subscription is still active until it expires, and that is also why you see a new transaction in the response from the transaction history endpoint. Based on the information you have shared, refund history should not return anything as nothing was cancelled.

Posted by
Frameworks Engineer
Up vote reply of Frameworks Engineer Down vote reply of Frameworks Engineer
Post marked as solved
Add a Comment

Thank you for your answer. So to recap, when we receive a DID_FAIL_TO_RENEW event after a DID_RENEW: BILLING_RECOVERY, we must discard the DID_FAIL_TO_RENEW one, is that correct?

Posted by
nicolas1
Up vote reply of nicolas1 Down vote reply of nicolas1
Add a Comment