My app is in "Pending Developer Release" status, and I have created Promo codes for app download and for auto-renewable subscriptions. When I recently redeemed one of the subscription codes I did not receive an app store server notification to my server. Does anyone know whether promo code redemption triggers an app store server notification or not? What are the conditions that must be met for an app store server notification to happen for promo code redemption? Thanks

Hi, Sometimes I get tons of errors 21104 and 21107 in a row when I try to validate new subscriptions and renew existing subscriptions from our server side by using the endpoint verifyReceipt: POST https://buy.itunes.apple.com/verifyReceipt https://developer.apple.com/documentation/appstorereceipts/verifyreceipt The response of this endpoint doesn't give any extra information: { 		"environment": "Production", 		"status": 21107, 		"is_retryable": true } I noticed that those subscriptions are renewed on the second try after waiting a bit (in a different hour/day). The documentation only indicates that the status codes 21100-21199 are internal data access errors but it doesn't specify each one: https://developer.apple.com/documentation/appstorereceipts/status I understand that it's an error on the Apple side so there is nothing I can do but if someone could give us more information about those errors (21104 and 21107).

We encountered a bug receiving a duplicated DID_RENEW notification for the same transactionId with different notificationUUID and signedDate after decoding it. We received them in a 98ms time lapse, so it seems there is a bug on Apple side. So far it is happening in the Sandbox environment, but maybe the Production environment is affected (we cannot confirm it because we already don't change to V2 in Production). There is an example of decoded notifications to illustrate the error: Notification extract #1 { "decodedTransaction": { "signedDate": 1695733544660, // Notice it is different "transactionId": "2000000422429312", // Notice it is the same "environment": "Sandbox", "expiresDate": 1695737117000, "purchaseDate": 1695733517000, "transactionReason": "RENEWAL", "originalPurchaseDate": 1695729871000, ... }, "notificationType": "DID_RENEW", "notificationUUID": "693c67fd-f507-49cd-b0cb-c244e94fe874" // Notice it is different } Notification extract #2 { "decodedTransaction": { "signedDate": 1695733544758, // Notice it is different "transactionId": "2000000422429312", // Notice it is the same "environment": "Sandbox", "expiresDate": 1695737117000, "purchaseDate": 1695733517000, "transactionReason": "RENEWAL", "originalPurchaseDate": 1695729871000, }, "notificationType": "DID_RENEW", "notificationUUID": "7e69c544-5ba0-42a0-88f4-ddae211563b5" // Notice it is different }

I have a question about REFUND_REVERSED, which is one of the types in Notification V2 for subscriptions. In the documentation, REFUND_REVERSED is described as a refund reversal and states that the content or service should be restored if it has been cancelled. However, when I check the actual received notification of this type, the status of the subscription is shown as 5, indicating that the subscription has been refunded. Furthermore, when I query the final status of this subscription using the getSubscriptionStatus API, it returns status=5 instead of status=1. I would like to know if this is the intended direction. If so, I would like to know how to confirm the refund cancellation status via the Appstore Connect API.

Can App Store Server Notifications v2 be used for in-app purchases of consumable products, because I failed when I tried it, but when I tried subscription purchases it was successful?

Does anyone know if a transaction can be refunded again if it has been has had REFUND and then REFUND_REVERSED occur to it? Basically can a transaction go PURCHASED -> REFUND -> REFUND_REVERSED -> REFUND etc..?

On my production application, renewalInfo.expirationIntent and renewalInfo.offerType is missing on notification data. On this examples, the signedRenewalInfo is decoded and set as renewalInfo and the signedTransactionInfo is decoded and set as transactionInfo. Example 1 It is expiration notification. However, renewalInfo.expirationIntent does not exists { "notificationType": "EXPIRED", "subtype": "VOLUNTARY", "notificationUUID": "REDACTED", "data": { "appAppleId": 123456789, "bundleId": "REDACTED", "bundleVersion": "16", "environment": "Production", "status": 2, "transactionInfo": { "transactionId": "REDACTED", "originalTransactionId": "REDACTED", "webOrderLineItemId": "REDACTED", "bundleId": "REDACTED", "productId": "REDACTED", "subscriptionGroupIdentifier": "REDACTED", "purchaseDate": 1693220511000, "originalPurchaseDate": 1693220512000, "expiresDate": 1693479711000, "quantity": 1, "type": "Auto-Renewable Subscription", "appAccountToken": "REDACTED", "inAppOwnershipType": "PURCHASED", "signedDate": 1693479743547, "offerType": 1, "environment": "Production", "transactionReason": "PURCHASE", "storefront": "PHL", "storefrontId": "143474" }, "renewalInfo": { "originalTransactionId": "REDACTED", "autoRenewProductId": "REDACTED", "productId": "REDACTED", "autoRenewStatus": 0, "isInBillingRetryPeriod": false, "signedDate": 1693479743547, "environment": "Production", "recentSubscriptionStartDate": 1693220511000, "renewalDate": 1693479711000 } }, "version": "2.0", "signedDate": 1693479743603 } Example 2 It is an initial buy subscription notification. transactionInfo.offerType is 1, however there is no renewalInfo.offerType. { "notificationType": "SUBSCRIBED", "subtype": "INITIAL_BUY", "notificationUUID": "REDACTED", "data": { "appAppleId": 123456789, "bundleId": "REDACTED", "bundleVersion": "16", "environment": "Production", "status": 1, "transactionInfo": { "transactionId": "REDACTED", "originalTransactionId": "REDACTED", "webOrderLineItemId": "REDACTED", "bundleId": "REDACTED", "productId": "REDACTED", "subscriptionGroupIdentifier": "REDACTED", "purchaseDate": 1693475274000, "originalPurchaseDate": 1693475276000, "expiresDate": 1725097674000, "quantity": 1, "type": "Auto-Renewable Subscription", "appAccountToken": "REDACTED", "inAppOwnershipType": "PURCHASED", "signedDate": 1693475283052, "offerType": 1, "environment": "Production", "transactionReason": "PURCHASE", "storefront": "ESP", "storefrontId": "143454" }, "renewalInfo": { "originalTransactionId": "REDACTED", "autoRenewProductId": "REDACTED", "productId": "REDACTED", "autoRenewStatus": 1, "signedDate": 1693475283052, "environment": "Production", "recentSubscriptionStartDate": 1693475274000, "renewalDate": 1725097674000 } }, "version": "2.0", "signedDate": 1693475283075 }

We are implementing IAP in our React-Native app, currently only on IOS, specifically subscriptions. We have configured the Sandbox Server URL to an endpoint on our Dev server, and the Production Server URL to an endpoint on our Production server. In addition, we are using the Apple App Store Server Node.js Library on our Backend to verify receipts, getting transactions history, etc. We are using the Sandbox environment on our Dev backend, and the Production environment on our Production backend. We are not sure if that is the correct setup, although that is what we understood from multiple sources. While testing with TestFlight, with production apple accounts, we were expecting to receive the server notifications on our Production server, but they were all were received on our Development server (Sandbox endpoint). Is that the correct behavior or are we missing something? We figured the Sandbox endpoint was for testing purposes and because of that should be on our Development backend while we develop.

Hi, We are using V2 App Store Server Notifications but can't figure out where to get the following subscription info: the price of the subscription (can't find anywhere) billing period duration e.g. "P1M" for monthly subscription Google Play billing has these properties so we expect that these properties also exist in the app store.

Hi, we have an auto-renewable subscription with an introductory offer configured. The introductory offer is a 7 days free trial. We're observing a possibly wrong behavior and we wanted to make sure we're not missing anything. We suspect that our server is not receiving notifications from the App Store when the free trial period starts, we only receive notifications when the user starts paying. To double-check, we've tested the same subscription in sandbox with a brand new test account with a 3 minutes renewal frequency: the behavior is exactly the same, we only get 1 notification every 3 minutes for the renewals, we get no notification when the free trial starts. So we have 2 main questions: does "free trial" work in sandbox too? If so, what's the duration of free trial in sandbox if it's set to 7 days in production? do we get a notification when the free trial period starts or we only get one when and if the user starts paying after 7 days? Thanks

I'm trying to implement an IAP subscripton and I am not receiving DID_RENEW/EXPIRED webhook calls. Looking through previous forum posts this may just be breaking randomly, is there something currently broken or is there likely some setup I'm missing? Note: I'm using ngrok to test this locally, and I successfully get the initial subscription and DID_CHANGE_RENEWAL_STATUS events.

I have found such information on documentation: Upgrade. Someone purchases a subscription that offers a 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. Also, To identify whether a subscription has been refunded, look for the cancellation_date field in the receipt. However, when looking at users that has upgraded subscriptions, where we get "is_upgraded": "true" There is no cancellation_date field, so the question is, has these users been refunded? If so, how do we calculate partial refunds without the date?

In notification version1, there is an field called is_trial_period, is useful for us to identify this transaction is in free trial, and we can judge the user's payment status and recomand some feature for him. but, in notification version2 the filed is not appear, in this scenari, how can I identify this user is in free trial period ?

Hello I've problem with transaction payload. If I receive POST App Store notification v2 to my server. In the decoded transaction body is missing appAccountToken field. In the iOS app I've just set token like this: let result = try await product.purchase(options: [ .appAccountToken(UUID.encodeIntAsUUID(Auth.shared.user.idUser)), .simulatesAskToBuyInSandbox(true) ]) Where is the problem?

HI. After changing notifications v2 We received "REFUND_DECLINED" notifications But, we didn't do anything about refund. Also, we didn't send consumption information. Below is description of "REFUND_DECLINED" REFUND_DECLINED Indicates that the App Store declined a refund request initiated by the app developer. Can I know when we are getting this notification?

Hello I want to know about App Store server notification type after subscription started with offer code, question is when someone starts a subscription with an offer code, only type OFFER_REDEEMED[subtype INITIAL_BUY] is send to server? or both type OFFER_REDEEMED[subtype INITIAL_BUY] and type SUBSCRIBED[subtype INITIAL_BUY] are send to server?

I'm testing subscription IAP app store server notifications. In the case of subscription payment, when the user cancels the subscription, you can check through the server notification. However, if the cancellation is made before the expiration of the subscription period, can we receive server notifications even when the subscription expires?

Cause in sandbox env I notice a receipt like this { "environment": "Sandbox", "unified_receipt": { "status": 0, "environment": "Sandbox", "latest_receipt_info": [ { "quantity": "1", "product_id": "3monthplan", "expires_date": "2023-07-25 04:50:29 Etc/GMT", "purchase_date": "2023-07-25 04:41:29 Etc/GMT", "transaction_id": "2000000375156349", "expires_date_ms": "1690260629000", "is_trial_period": "false", "expires_date_pst": "2023-07-24 21:50:29 America/Los_Angeles", "purchase_date_ms": "1690260089000", "purchase_date_pst": "2023-07-24 21:41:29 America/Los_Angeles", "in_app_ownership_type": "PURCHASED", "original_purchase_date": "2023-07-25 03:20:41 Etc/GMT", "web_order_line_item_id": "2000000032603282", "original_transaction_id": "2000000375122102", "is_in_intro_offer_period": "false", "original_purchase_date_ms": "1690255241000", "original_purchase_date_pst": "2023-07-24 20:20:41 America/Los_Angeles", "subscription_group_identifier": "20572434" }, .... { "quantity": "1", "product_id": "3monthplan", "expires_date": "2023-07-25 04:03:49 Etc/GMT", "purchase_date": "2023-07-25 03:54:49 Etc/GMT", "transaction_id": "2000000375136003", "expires_date_ms": "1690257829000", "is_trial_period": "false", "expires_date_pst": "2023-07-24 21:03:49 America/Los_Angeles", "purchase_date_ms": "1690257289000", "purchase_date_pst": "2023-07-24 20:54:49 America/Los_Angeles", "in_app_ownership_type": "PURCHASED", "original_purchase_date": "2023-07-25 03:20:41 Etc/GMT", "web_order_line_item_id": "2000000032600544", "original_transaction_id": "2000000375122102", "is_in_intro_offer_period": "false", "original_purchase_date_ms": "1690255241000", "original_purchase_date_pst": "2023-07-24 20:20:41 America/Los_Angeles", "subscription_group_identifier": "20572434" }, { "quantity": "1", "product_id": "monthlyplan", "expires_date": "2023-07-25 03:38:37 Etc/GMT", "purchase_date": "2023-07-25 03:35:37 Etc/GMT", "transaction_id": "2000000375127458", "expires_date_ms": "1690256317000", "is_trial_period": "false", "expires_date_pst": "2023-07-24 20:38:37 America/Los_Angeles", "purchase_date_ms": "1690256137000", "cancellation_date": "2023-07-25 04:38:50 Etc/GMT", "purchase_date_pst": "2023-07-24 20:35:37 America/Los_Angeles", "cancellation_reason": "0", "cancellation_date_ms": "1690259930000", "cancellation_date_pst": "2023-07-24 21:38:50 America/Los_Angeles", "in_app_ownership_type": "PURCHASED", "original_purchase_date": "2023-07-25 03:20:41 Etc/GMT", "web_order_line_item_id": "2000000032600434", "original_transaction_id": "2000000375122102", "is_in_intro_offer_period": "false", "original_purchase_date_ms": "1690255241000", "original_purchase_date_pst": "2023-07-24 20:20:41 America/Los_Angeles", "subscription_group_identifier": "20572434" }, ... ] }, "auto_renew_status": "false", "cancellation_date": "2023-07-25 04:38:50 Etc/GMT", "notification_type": "CANCEL", "cancellation_date_ms": "1690259930000", "auto_renew_product_id": "3monthplan", "cancellation_date_pst": "2023-07-24 21:38:50 America/Los_Angeles", "web_order_line_item_id": "2000000032600434", "original_transaction_id": 2000000375122102 } plan is keeping renew. What if I refund in prod env, and after refund agree, is that my subscription would auto turn off?

We are attempting to monitor subscription events via App Store Server Notifications. The URL we have configured (with v1 or v2) continually gets invoked with GET requests instead of POST requests, we do not get any POST with request data at all and cannot process subscription changes. Why might this be happening? What could we have misconfigured? configuration: requests: