fix(appstore): modify JWSRenewalInfoDecodedPayload, JWSTransaction field type

[Daydaylw3]

Try to resolve the issue #232

[richzw]

There is NO zero value of expirationIntent and offerType , maybe it could be better to keep the original type rather than *int32

[Daydaylw3]

There is NO zero value of expirationIntent and offerType , maybe it could be better to keep the original type rather than *int32

great suggest!! already modified it

[Daydaylw3]

I think that there are 3 condition that isInBillingRetry should show:

• Never in billing retry
• In billing retry, attempt to retry
• In billing retry, not attempt to retry

So I modify it

[richzw]

I think that there are 3 condition that isInBillingRetry should show:

• Never in billing retry
• In billing retry, attempt to retry
• In billing retry, not attempt to retry

So I modify it

Since the JWSRenewalInfoDecodedPayload contains subscription renewal information for an auto-renewable subscription, this struct JWSRenewalInfoDecodedPayload is only for the subscription. The state Never in billing retry you mentioned could be invalid. There could be only two values of isInBillingRetryPeriod, one is retry, the other is not.

[richzw]

I think the type of IsInBillingRetryPeriod could be bool, since there could be two values: true or false.

[Daydaylw3]

Since the JWSRenewalInfoDecodedPayload contains subscription renewal information for an auto-renewable subscription, this struct JWSRenewalInfoDecodedPayload is only for the subscription. The state Never in billing retry you mentioned could be invalid. There could be only two values of isInBillingRetryPeriod, one is retry, the other is not.

I get your point, but it seems that Never in billing retry is exist.

1. When subscription can be renewal normally, the subscription is out of billing retry.
2. But when subscription occur some issue, such as no money, etc. The subscription will go into billing-retry state, this state will up to 60 days. So this field would become true, which indicate that subscription is in billing-retry.
3. And if after specify of days, apple not attempt to make retry, this field would become false, that mean the subscription is expired totally.
4. And if during billing-retry, user resolve their billing issue(such as pay their credit card billing so they have enough quota), and apple try to charge them and succ, the subscription become normal again and out of billing-retry state. So the is_in_billing_retry_period is gone

Relative doc

And Apple say that this field should use conjunction with expiration_intent, expires_date, etc

Relative doc

I would make a demo to test if is real tomorrow. compare the old and new api to see whether their are different :)

[richzw]

Since the JWSRenewalInfoDecodedPayload contains subscription renewal information for an auto-renewable subscription, this struct JWSRenewalInfoDecodedPayload is only for the subscription. The state Never in billing retry you mentioned could be invalid. There could be only two values of isInBillingRetryPeriod, one is retry, the other is not.

I get your point, but it seems that Never in billing retry is exist.

1. When subscription can be renewal normally, the subscription is out of billing retry.
2. But when subscription occur some issue, such as no money, etc. The subscription will go into billing-retry state, this state will up to 60 days. So this field would become true, which indicate that subscription is in billing-retry.
3. And if after specify of days, apple not attempt to make retry, this field would become false, that mean the subscription is expired totally.
4. And if during billing-retry, user resolve their billing issue(such as pay their credit card billing so they have enough quota), and apple try to charge them and succ, the subscription become normal again and out of billing-retry state. So the is_in_billing_retry_period is gone

Relative doc

And Apple say that this field should use conjunction with expiration_intent, expires_date, etc

Relative doc

I would make a demo to test if is real tomorrow. compare the old and new api to see whether their are different :)

Based on my previous knowledge. There could be two values for the field IsInBillingRetryPeriod . I am looking forward to your testing result.

[Daydaylw3]

Since the JWSRenewalInfoDecodedPayload contains subscription renewal information for an auto-renewable subscription, this struct JWSRenewalInfoDecodedPayload is only for the subscription. The state Never in billing retry you mentioned could be invalid. There could be only two values of isInBillingRetryPeriod, one is retry, the other is not.

I get your point, but it seems that Never in billing retry is exist.

1. When subscription can be renewal normally, the subscription is out of billing retry.
2. But when subscription occur some issue, such as no money, etc. The subscription will go into billing-retry state, this state will up to 60 days. So this field would become true, which indicate that subscription is in billing-retry.
3. And if after specify of days, apple not attempt to make retry, this field would become false, that mean the subscription is expired totally.
4. And if during billing-retry, user resolve their billing issue(such as pay their credit card billing so they have enough quota), and apple try to charge them and succ, the subscription become normal again and out of billing-retry state. So the is_in_billing_retry_period is gone

Relative doc

And Apple say that this field should use conjunction with expiration_intent, expires_date, etc
Relative doc
I would make a demo to test if is real tomorrow. compare the old and new api to see whether their are different :)

Based on my previous knowledge. There could be two values for the field IsInBillingRetryPeriod . I am looking forward to your testing result.

hi, @richzw , good afternoon, here is my demo test case:

Grace Period Demo.pdf

Fyi. I delete some not necessary part in IAPRespone.

[richzw]

LGTM. Thank you very much for your details explanation.