Subscription status mismatch

Question

nicolas1 OP

Created Jan ’24

Replies 3

Boosts 0

Views 1k

Participants 2

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.

Answered by App Store Commerce Engineer in 778250022

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.

Boost

Answer 1

nicolas1 OP

Jan ’24

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".

0

Answer 2

App Store Commerce Engineer OP

Apple

Jan ’24

Accepted Answer

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.

1

Answer 3

nicolas1 OP

Jan ’24

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?

0