Hi, We want to handle the Refund Notification in our webhook as we saw here: https://developer.apple.com/documentation/storekit/original_api_for_in-app_purchase/handling_refund_notifications However this part is not clear for us: "Refunded transactions are not present in the JSON response when you call the verifyReceipt endpoint with a receipt that contains refunded transactions, except for auto-renewable subscriptions." Does this mean that we should not send the received REFUND notification to the https://buy.itunes.apple.com/verifyReceipt endpoint for verification? We have tried to verify some REFUND notifications which we received in our webhook(for not auto-renewable products) and after sending it to the /verifyReceipt endpoint we got back the same data, the refunded transactions were present in the response. As a conclusion, is it ok to verify these refund receipts too?

Hi, We are working on handling refunds for one time products on apple devices. In our scenario, we have two purchased products and we start refunding them, refund for item 1, then refund for item 2( in an interval of 2-3 minutes). We expect to get two apple receipts, first receipt containing both products, one active(item2) and one refunded(item1, cancellation properties set). The second receipt containing both products, both being refunded(having the cancellation_date_* properties set). This is not happening, we get the 2 receipts, both containing the same data about the refunded products, so both receipts have the cancellation dates set for both products. Is this a normal behavior? Should we assume that the processing of the refunds and sending out the notifications/receipts happens async, resulting in having both refunds already processed in the moment when the receipts/messages are sent out? Thanks, David

Hi, We manage in-app purchases/subscriptions and their notifications in an server-to-server setup. We currently updated one of our devices to iOS 17. The sandbox subscription management is still not working, we encountered the same issue on iOS 16. When trying to access the sandbox subscription management menu, the authentication steps works correctly, but after that we get a error screen with the message: Cannot Connect. There is a retry button, but the same error message is prompted, after it is pressed We have this working on devices which have iOS 15.x versions. Are there any investigations or updates on this subject? Are there any workarounds to make this work? Thanks, David

We have a server to server setup for subscription management for the Apple subscriptions. Lately we observed that we are getting a lot of DID_RENEW notification, after decoded with the /verifyReceipt endpoints, these notifications have no purchase in them. We are in the Production environment. The original_purchase_date is set to "1970-01-20 11:45:27 Etc/GMT" and we can se also the preorder_date field set to the date when we receive the notification. All our products are approved and released at the moment(nothing to be released). There are no other "usable" details for us in the decoded notification(data to identify user). Can somebody please help explaining this scenario? Why are we receiving these notifications? Thanks, David.

Hello, We have a few FAMILY_SHARED subscriptions which received a DID_RENEW notification, with all the cancellation fields completed, the expiration date in the future and no pending_renewal_info array in it. We are not sure why did we get the DID_RENEW notification with the cancelation details, shouldn't we get a REVOKE notification? We found this in the Apple documentation: The pending_renewal_info array is returned only for app receipts that contain auto-renewable subscriptions. If customers voluntarily cancel a subscription renewal while in the grace period, the App Store pauses billing retry, and removes the transaction from pending_renewal_info. The subscription is in the grace period if the key grace_period_expires_date_ms is present and the expiration date hasn't passed. We do not handle any cancelation related logic for the DID_RENEW notification. Should we adjust the logic for this scenario or there should be a different notification type sent out. This is how the latest element looks like from the lattest_recipt_info: "auto_renew_status": "true", "unified_receipt": { "status": 0, "environment": "Production", "latest_receipt_info": [{ "quantity": "1", "product_id": "product_id", "transaction_id": "transaction_id", "purchase_date": "2023-11-07 23:01:41 Etc/GMT", "purchase_date_ms": "1699398101000", "purchase_date_pst": "2023-11-07 15:01:41 America/Los_Angeles", "original_purchase_date": "2021-10-07 22:01:42 Etc/GMT", "original_purchase_date_ms": "1633644102000", "original_purchase_date_pst": "2021-10-07 15:01:42 America/Los_Angeles", "expires_date": "2024-11-07 23:01:41 Etc/GMT", "expires_date_ms": "1731020501000", "expires_date_pst": "2024-11-07 15:01:41 America/Los_Angeles", "web_order_line_item_id": "web_order_line_item_id", "is_trial_period": "false", "is_in_intro_offer_period": "false", "original_transaction_id": "original_transaction_id", "cancellation_date": "2023-11-07 15:37:03 Etc/GMT", "cancellation_date_ms": "1699371423020", "cancellation_date_pst": "2023-11-07 07:37:03 America/Los_Angeles", "cancellation_reason": "0", "in_app_ownership_type": "FAMILY_SHARED", "subscription_group_identifier": "subscription_group_identifier" }