Post

Replies

Boosts

Views

Activity

Clarification about product with status "Developer Removed from Sale"
Summary After setting a single auto-renewable subscription product (not the app) to "Developer Removed from Sale" in App Store Connect, the next scheduled renewal for an existing active subscriber failed with DID_FAIL_TO_RENEW v2 and expirationIntent = 5 ("expired for some other reason"). I expected expirationIntent = 4 ("product wasn't available for purchase at the time of renewal"), since the product was, in fact, not available for purchase. I would like to confirm whether 5 is the documented/expected value for this scenario, and how to deterministically distinguish "developer removed product from sale" from other renewal failures using the notification payload. Reproduction / observed sequence Day 15: Changed product annual_promo (auto-renewable subscription) status from "Approved" to "Developer Removed from Sale" in App Store Connect. The app itself remained Approved and on sale. Other subscription products in the same group remained Approved. Day 16: An existing active subscriber on that product had a scheduled automatic renewal date. Result: Renewal did not occur. We received a DID_FAIL_TO_RENEW v2 notification. Payload (relevant fields): JWSRenewalInfoDecodedPayload.expirationIntent = 5 JWSRenewalInfoDecodedPayload.autoRenewStatus = 0 Questions Is expirationIntent = 5 the correct/expected value when a renewal fails because the developer removed the product from sale? Or should it have been 4 ("product wasn't available for purchase at the time of renewal")? If 5 is intentional, what is the engineering rationale for not using 4 in this scenario? Given that expirationIntent = 5 is documented as a catch-all ("some other reason"), which other fields in the DID_FAIL_TO_RENEW payload (e.g., subtype, autoRenewStatus, gracePeriodExpiresDate, signedTransactionInfo) should we inspect to deterministically classify the failure cause and isolate "developer removed product from sale" from billing failure / customer cancel / price-increase not accepted / etc.? Context I'm aware of the docs page In-App Purchase statuses and Set availability for an auto-renewable subscription, but they describe the status semantics, not the resulting notification payload. Product has been reverted to "Approved" to avoid further impact on subscribers while this is clarified. Thanks in advance.
0
0
39
3d
Clarification about product with status "Developer Removed from Sale"
Summary After setting a single auto-renewable subscription product (not the app) to "Developer Removed from Sale" in App Store Connect, the next scheduled renewal for an existing active subscriber failed with DID_FAIL_TO_RENEW v2 and expirationIntent = 5 ("expired for some other reason"). I expected expirationIntent = 4 ("product wasn't available for purchase at the time of renewal"), since the product was, in fact, not available for purchase. I would like to confirm whether 5 is the documented/expected value for this scenario, and how to deterministically distinguish "developer removed product from sale" from other renewal failures using the notification payload. Reproduction / observed sequence Day 15: Changed product annual_promo (auto-renewable subscription) status from "Approved" to "Developer Removed from Sale" in App Store Connect. The app itself remained Approved and on sale. Other subscription products in the same group remained Approved. Day 16: An existing active subscriber on that product had a scheduled automatic renewal date. Result: Renewal did not occur. We received a DID_FAIL_TO_RENEW v2 notification. Payload (relevant fields): JWSRenewalInfoDecodedPayload.expirationIntent = 5 JWSRenewalInfoDecodedPayload.autoRenewStatus = 0 Questions Is expirationIntent = 5 the correct/expected value when a renewal fails because the developer removed the product from sale? Or should it have been 4 ("product wasn't available for purchase at the time of renewal")? If 5 is intentional, what is the engineering rationale for not using 4 in this scenario? Given that expirationIntent = 5 is documented as a catch-all ("some other reason"), which other fields in the DID_FAIL_TO_RENEW payload (e.g., subtype, autoRenewStatus, gracePeriodExpiresDate, signedTransactionInfo) should we inspect to deterministically classify the failure cause and isolate "developer removed product from sale" from billing failure / customer cancel / price-increase not accepted / etc.? Context I'm aware of the docs page In-App Purchase statuses and Set availability for an auto-renewable subscription, but they describe the status semantics, not the resulting notification payload. Product has been reverted to "Approved" to avoid further impact on subscribers while this is clarified. Thanks in advance.
Replies
0
Boosts
0
Views
39
Activity
3d