Doubts about subscriptions states

Question

bediasantel OP

Created Jun ’20

Replies 3

Boosts 0

Participants 2

Hi,

we have developed an app including subscription services but we have some questions about how the Apple system works.

To be exact, we'd like to know what happens in the following cases:

- An user purchases a one month subscription for accessing to some contents by few days later he ask for a refund to Apple.

- An user purchases a one month subscription for accessing to some contents by few days later Apple rejects the payment.We have a real case of a subscriber and if we validate the receipt of the purchase against Apple we receive this in the inapp list{

quantity: '1',

product_id: 'com.xxxxx.ITmonth',

transaction_id: '210000703677576',

original_transaction_id: '210000703677576',

purchase_date: '2020-05-09 01:19:13 Etc/GMT',

purchase_date_ms: '1588987153000',

purchase_date_pst: '2020-05-08 18:19:13 America/Los_Angeles',

original_purchase_date: '2020-05-09 01:19:14 Etc/GMT',

original_purchase_date_ms: '1588987154000',

original_purchase_date_pst: '2020-05-08 18:19:14 America/Los_Angeles',

expires_date: '2020-06-09 01:19:13 Etc/GMT',

expires_date_ms: '1591665553000',

expires_date_pst: '2020-06-08 18:19:13 America/Los_Angeles',

web_order_line_item_id: '210000251170503',

is_trial_period: 'false',

is_in_intro_offer_period: 'false'

}and this in the last_receipt{

quantity: '1',

product_id: 'com.xxxxxx.ITmonth',

transaction_id: '210000703677576',

original_transaction_id: '210000703677576',

purchase_date: '2020-05-09 01:19:13 Etc/GMT',

purchase_date_ms: '1588987153000',

purchase_date_pst: '2020-05-08 18:19:13 America/Los_Angeles',

original_purchase_date: '2020-05-09 01:19:14 Etc/GMT',

original_purchase_date_ms: '1588987154000',

original_purchase_date_pst: '2020-05-08 18:19:14 America/Los_Angeles',

expires_date: '2020-06-09 01:19:13 Etc/GMT',

expires_date_ms: '1591665553000',

expires_date_pst: '2020-06-08 18:19:13 America/Los_Angeles',

cancellation_date: '2020-05-19 17:35:07 Etc/GMT',

cancellation_date_ms: '1589909707000',

cancellation_date_pst: '2020-05-19 10:35:07 America/Los_Angeles',

web_order_line_item_id: '210000251170503',

is_trial_period: 'false',

is_in_intro_offer_period: 'false',

cancellation_reason: '0',

subscription_group_identifier: '20556029'

}As you can see, the same transaction in both cases but on is active an the other is canceled.Thanks in advance.

Boost

Answer 1

PBK OP

Jun ’20

The receipt indicates that the user cancelled the purchase. Such cancellations are rare but you've found one.

- An user purchases a one month subscription for accessing to some contents by few days later he ask for a refund to Apple.

This is what your receipt indicates.

- An user purchases a one month subscription for accessing to some contents by few days later Apple rejects the payment.

Apple rarely rejects a payment a few days later. But I would assume that if they did, it would generate a cancellation_date field in a new receipt.

0

Answer 2

bediasantel OP

Jun ’20

Thanks for your answer.

The point is that we receive contradiction information in the same receipt, I mean, the subscription is active in the inapp list but canceled in the last_receipt part.

Unfortunately we are using the most popular library for checking Apple receipts ( https://www.npmjs.com/package/in-app-purchase ) , and in fact we have used it for years for handling purchases

in our backend. This library doesn't expect this behaviour since it's a contradiction and honestly, we don't want to change all the code of our backend in order to fix with a workaround that behaviour.

Any ideas on how to proceed with this issue?

Thanks in advance

0

Answer 3

PBK OP

Jun ’20

> we don't want to change all the code of our backend in order to fix with a workaround that behaviour.

Any ideas on how to proceed with this issue?

Cancellations are rare. And usually a cancellation means the user is no longer trying to use the subscription anyway. If you don't want to change your code, ignore them, take a risk that some users may be stealing, and move on to something more important. It is unlikely that Apple will let them steal more than once or twice.

0