Firstly I thought that the differencies are: latest_receipt_info also contains purchases, which are proceeded after receipt generation, in_app - doesn't. Good for tracking future events. in_app also contains consumable, for which the receipt was generated (I noticed this fact in sandbox environment: consumable was only in response for receipt, which was associated with this consumable purchase), latest_receipt_info - doesn't. Good for validation of random purchase with associated receipt. BUT. I found case, when I have the same transaction in in_app and in latest_receipt_info (it has the same web_order_line_item_id), but transaction_ids differ. Can you explain cases, when this behaviour appear? Or more precisely: Is it possible for any transaction to change transaction_id in latest_receipt_info? Does it happen when user do something with exact transaction (restores on other device etc.)? (found the same question: https://developer.apple.com/forums/thread/84812, didn't find answer)

Does billing issue notification contain unique transaction ID or this transaction ID matches, for example, the last transaction ID in subscription renewal history? I also didn't find info about: Can billing issue notification be produced multiple times? With different transaction ID or the same one?

Hi! TL;DR: The main question is: Is there any [reliable (I can compare expiresDate and purchaseDate of next by date transaction, but that's weird)] way to distinguish partial refund (i.e. upgrade) from simple refund in /verifyReceipt? Details: I know that in notifications I can get information: REFUND and DID_CHANGE_RENEWAL_PREF with subtype (UPGRADE/DOWNGRADE), so I can understand, what is going on. I noticed that in case of upgrade there is partial refund of previos transaction (Upgrade. Someone purchases a subscription that offers higher level of service than their current subscription. They’re immediately upgraded and receive a refund of the prorated amount of their original subscription. If you’d like people to immediately access more content or features, rank the subscription higher to make it an upgrade.) So is there any way to determine partial/full refund using /verifyReceipt if I miss notification for example? The main goal is to count total revenue, so it'll be less than should be, if I won't get information about partial refund and use full refund instead. (Hope that I didn't confuse you..)

I want to track subscriptions of multiple applications and need to choose unique key. Can transactionId from app1 match somehow transactionId from app2? If yes, then Is it possible situation: app1 and app2 have products with same productId (e.g. "com.subscription") and have transactions with same transactionId? So should I use key (appAppleId, productId, transactionId)? (It would be more convinient to use transactionId, but I am not sure about uniqueness)

Hello! I want to parse json, which you send in notifications v2, but have some questions about required and optional fields (actually I may do all the fields, which are non obvious for me optional, but that's not suitable). It would be really amazing if you will update your docs with this info! And it would be cool if you'll add some examples of the whole notification structure (it would be more convinient) with different types (and refer to example for concrete field like here is "revocationDate", it appears in case of "REVOKE" event and may be found here: <example reference> - it would be perfect!) Main questions are: does signedRenewalInfo always appear here or it doesn't if it's consumable notification? does bundleId either always appear or it may not if it is deleted somewhere somehow? do i understand right that "empty subtype" doesn't mean empty string but means absence of field in json? does autoRenewStatus always appear here or it may be absent? do purchaseDate and originalPurchaseDate from here always appear or there are some cases (revocation maybe) when they may be missed? does transactionId field always appear or there are some exceptions (revocation?)? does inAppOwnershipType from here always appear? is quantity (from the same struct) required field? is webOrderLineItemId (from the same struct) a required field?

Hello! I have several questions about in-app purchases article and would be very pleased if you'll help me. If you have an answer for only one question or only subquestion don't be shy to answer, it will help much! How to distinguish a type of in-app purchase from the response? I mean in response to /verifyReceipt query you send JSON object, which also contains (responseBody->Receipt) information about receipt, but there is no some kind of type field and I'm a little bit confused. Maybe there is a difference between non-consumable and auto-renewable subscription (for example non-consumable doesn't have latest_receipt actually) but how to distinguish non-consumable purchase from non-renewable subscriptions? Does in-app array change according to actual active purchases for user? Determine which products the user purchased. Purchases for non-consumable products, auto-renewable subscriptions, and non-renewing subscriptions remain in the receipt indefinitely (from here) Imagine user subscribe for auto-renewable subscriptionA and I get the receipt (receipt1) for this purchase. If subscriptionA auto-renewed then: a. will in-app array contain information for new subscriptionA purchase (actually I need new expiration_date) if I'll send receipt1 request on /verifyReceipt? (Or more generally: Can I track subscriptionA status for some user using one of receipt?) b. will in-app array contain 2 items in this case, or it'll just update date for old object? will multiple puchases of non-renewing subscription (with same productId) appear multiple times? c. Even more generally (a): Can I track all in-app purchases of some user using this receipt1 and scanning in-app array?