Hi all, I’ve noticed an inconsistency regarding the revocationDate in a refunded transaction and I’m trying to understand why this happens. Here are the details: Transaction ID: 390001625798742 In the refund notification, the revocationDate was: 1741095496000 However, when querying the same transaction later using the Transaction ID, the returned revocationDate was: 1742077082000 Why would the revocationDate change over time? Is this expected behavior, or does it indicate an issue with how the refund is being processed or queried? Thanks in advance for any insights!

I am currently using the App Store Server API Get All Subscription Statuses in the app I am in charge of. Please let me confirm the following regarding Get All Subscription Statuses. ■Prerequisites The language used is Objective-c, and I am using both XCode 15 and 16. I also have an App Store Connect account. ■Questions Is it possible to set and test each status of the App Store Server API Get All Subscription Statuses with TestFlight?

Dear Apple Support Team, Hello! I am currently developing the in-app subscription functionality using Apple IAP API and have encountered a serious technical issue while processing subscription data. I would like to report this issue to you. Issue Description: When calling the subscription API endpoint, the same OriginalTransactionId returns inconsistent results. Specifically, a particular transaction ID (let's call it TransactionId_A) should belong to the subscription order with OriginalTransactionId_A, but it is currently incorrectly associated with OriginalTransactionId_B. This issue severely affects our ability to accurately manage and process subscription data. Here are the relevant log details for your reference: API Endpoint Requested: https://api.storekit.itunes.apple.com/inApps/v1/subscriptions/{TransactionId_A} (Note: The link is a placeholder for the actual API endpoint.) Log Information on February 21, 2025, at 09:40:09: { "AppAccountToken": "{AppAccountToken}", "BundleId": "{BundleId}", "Currency": "CNY", "Environment": "Production", "ExpiresDate": {ExpiresDate}, "InAppOwnershipType": "PURCHASED", "IsUpgraded": false, "OfferDiscountType": "", "OfferIdentifier": "", "OfferType": 0, "OriginalPurchaseDate": {OriginalPurchaseDate}, "OriginalTransactionId": "{OriginalTransactionId_A}", "Price": {Price}, "ProductId": "{ProductId}", "PurchaseDate": {PurchaseDate}, "Quantity": 1, "RevocationDate": 0, "RevocationReason": 0, "SignedDate": {SignedDate}, "Storefront": "CHN", "StorefrontId": {StorefrontId}, "SubscriptionGroupIdentifier": "{SubscriptionGroupIdentifier}", "TransactionId": "{TransactionId_A}", "TransactionReason": "PURCHASE", "Type": "Auto-Renewable Subscription", "WebOrderLineItemId": "{WebOrderLineItemId}" } Log Information on March 21, 2025, at 09:38:49: { "AppAccountToken": "{AppAccountToken}", "BundleId": "{BundleId}", "Currency": "CNY", "Environment": "Production", "ExpiresDate": {ExpiresDate}, "InAppOwnershipType": "PURCHASED", "IsUpgraded": false, "OfferDiscountType": "", "OfferIdentifier": "", "OfferType": 0, "OriginalPurchaseDate": {OriginalPurchaseDate}, "OriginalTransactionId": "{OriginalTransactionId_B}", "Price": {Price}, "ProductId": "{ProductId}", "PurchaseDate": {PurchaseDate}, "Quantity": 1, "RevocationDate": 0, "RevocationReason": 0, "SignedDate": {SignedDate}, "Storefront": "CHN", "StorefrontId": {StorefrontId}, "SubscriptionGroupIdentifier": "{SubscriptionGroupIdentifier}", "TransactionId": "{TransactionId_A}", "TransactionReason": "PURCHASE", "Type": "Auto-Renewable Subscription", "WebOrderLineItemId": "{WebOrderLineItemId}" } From the above logs, it is evident that the same transaction (TransactionId_A) returns different OriginalTransactionId values at different times, which is clearly not expected and severely impacts our ability to correctly process and manage subscription data. I hope you can address and investigate this issue as soon as possible. If you need any further information or assistance, please feel free to contact me. Thank you for your support! Best regards!

Dear Apple Support Team, Hello! I am currently developing the in-app subscription functionality using Apple IAP API and have encountered a serious technical issue while processing subscription data. I would like to report this issue to you. Issue Description: When calling the subscription API endpoint, the same OriginalTransactionId returns inconsistent results. Specifically, a particular transaction ID (let's call it TransactionId_A) should belong to the subscription order with OriginalTransactionId_A, but it is currently incorrectly associated with OriginalTransactionId_B. This issue severely affects our ability to accurately manage and process subscription data. Here are the relevant log details for your reference: API Endpoint Requested: https://api.storekit.itunes.apple.com/inApps/v1/subscriptions/{TransactionId_A} (Note: The link is a placeholder for the actual API endpoint.) Log Information on February 21, 2025, at 09:40:09: { "AppAccountToken": "{AppAccountToken}", "BundleId": "{BundleId}", "Currency": "CNY", "Environment": "Production", "ExpiresDate": {ExpiresDate}, "InAppOwnershipType": "PURCHASED", "IsUpgraded": false, "OfferDiscountType": "", "OfferIdentifier": "", "OfferType": 0, "OriginalPurchaseDate": {OriginalPurchaseDate}, "OriginalTransactionId": "{OriginalTransactionId_A}", "Price": {Price}, "ProductId": "{ProductId}", "PurchaseDate": {PurchaseDate}, "Quantity": 1, "RevocationDate": 0, "RevocationReason": 0, "SignedDate": {SignedDate}, "Storefront": "CHN", "StorefrontId": {StorefrontId}, "SubscriptionGroupIdentifier": "{SubscriptionGroupIdentifier}", "TransactionId": "{TransactionId_A}", "TransactionReason": "PURCHASE", "Type": "Auto-Renewable Subscription", "WebOrderLineItemId": "{WebOrderLineItemId}" } Log Information on March 21, 2025, at 09:38:49: { "AppAccountToken": "{AppAccountToken}", "BundleId": "{BundleId}", "Currency": "CNY", "Environment": "Production", "ExpiresDate": {ExpiresDate}, "InAppOwnershipType": "PURCHASED", "IsUpgraded": false, "OfferDiscountType": "", "OfferIdentifier": "", "OfferType": 0, "OriginalPurchaseDate": {OriginalPurchaseDate}, "OriginalTransactionId": "{OriginalTransactionId_B}", "Price": {Price}, "ProductId": "{ProductId}", "PurchaseDate": {PurchaseDate}, "Quantity": 1, "RevocationDate": 0, "RevocationReason": 0, "SignedDate": {SignedDate}, "Storefront": "CHN", "StorefrontId": {StorefrontId}, "SubscriptionGroupIdentifier": "{SubscriptionGroupIdentifier}", "TransactionId": "{TransactionId_A}", "TransactionReason": "PURCHASE", "Type": "Auto-Renewable Subscription", "WebOrderLineItemId": "{WebOrderLineItemId}" } From the above logs, it is evident that the same transaction (TransactionId_A) returns different OriginalTransactionId values at different times, which is clearly not expected and severely impacts our ability to correctly process and manage subscription data. I hope you can address and investigate this issue as soon as possible. If you need any further information or assistance, please feel free to contact me. Thank you for your support! Best regards!

We are currently listening to App Store Server Notifications V2 and have encountered an issue with notification ordering. Specifically, there are instances where Apple sends the DID_CHANGE_RENEWAL_STATUS notification before the INITIAL_BUY notification. This leads to a situation where we are unable to process the cancellation of a transaction that is unknown to us at the time of the renewal status change. Could you please clarify why this occurs? If this is a bug, could you kindly address it and implement a fix? Below, I have included examples that illustrate the issue. These examples I obtained using the Notification History API, which may help in troubleshooting. bundleId: com.picsart.studio case 1: originalTransactionId 350002410***633 DID_CHANGE_RENEWAL_STATUS - ‘2025-03-05T00:47:05.900Z’ INITIAL_BUY - ‘2025-03-05T00:47:40.728Z’ case 2: originalTransactionId 420002297***345 DID_CHANGE_RENEWAL_STATUS - ‘2025-03-03T11:43:54.006Z’ INITIAL_BUY - ‘2025-03-03T11:43:56.437Z’ case 3: originalTransactionId 150002224***082 DID_CHANGE_RENEWAL_STATUS - ‘2025-03-02T05:15:36.610Z’ INITIAL_BUY - ‘2025-03-02T05:15:52.666Z’

I confirm that the configured callback address is accurate and can be called using Postman. The server receives notification messages from IAP

We are distributing an application using in-app-purchase with subscription. In order to expand customer support and more optimally timed marketing activities, We want to retrieve the billing status and number of billing users managed on the Apple side and regularly verify that the data we are aware of on the server side is up-to-date. Currently, the App Store Server API provides a way to retrieve status using individual original_transaction_id, but there seems to be no official way to retrieve original_transaction_id for a specific period at once. The same was also true for App Store Server Notifications. Is there a way to specify a period of time, the Apple ID of an app, etc., and obtain the original_transaction_id or transaction_id for a specific period of time?

Signed renewal info from 'Get Subscription Statuses' or in server notifications never has the offerType or offerDiscountType even when the corresponding transaction does have those values set. Our offer is a free trial. Do these properties refer to something different in JWSRenewalInfoDecodedPayload than they do in transactions? I'm trying to determine whether a subscription (identified by originalTransactionId) is currently in a free trial based on server notifications. The status doesn't tell us if the subscription is currently in free trial and the signedTransactionInfo may be for an older transaction.

We are running auto-renewing subscriptions with StoreKit2 and the “get all subscription statuses” API is behaving unexpectedly. record the originalTransactionId from the iPhone to the server side when purchasing a subscription with Storekit2. query the get all subscription statuses API from the server side with the originalTransactionId recorded. get all subscription statuses returns a response, but there is no data in the response that matches the originalTransactionId. I have an error on my system because I have built my system on the assumption that all subscriptions including originalTransactionId will be returned.

When using the AppStoreServerAPI to retrieve user purchase information or decode a Payload, The following responses occur multiple times throughout the day. If there is no error, the process is completed successfully. HTTP response code: 502 for URL What is the cause of this error occurring repeatedly? Is there still a problem with Apple's server status? The following APIs are used to acquire and decode user purchase information. 　AppStoreServerAPIClient.getAllSubscriptionStatuses 　SignedDataVerifier.verifyAndDecodeTransaction 　SignedDataVerifier.verifyAndDecodeRenewalInfo

https://developer.apple.com/documentation/appstoreservernotifications/app-store-server-notifications-changelog#June-10-2024 ONE_TIME_CHARGE notify type running in a sandbox environment for almost a year, the feature is not yet available for production environment. The notification is already available in Google subscriptions. Our services often miss orders because of the absence of this notification. Can you give us an approximate time range?

When the user's purchase information was retrieved from Japan using the AppStoreServerAPI, I was able to obtain it with the status ‘1: The auto-renewable subscription is active.’, However, the expiry date in the Payload was the previous day. How can this be the case? Example: when the purchase information was retrieved on 10/02/2025 at 21:00:00, the expiry date for status ‘1’ was ‘2025/02/09’.

Please let me ask you about the following status code obtained from the AppStoreServerAPI. 3: The auto-renewable subscription is in a Billing retry period. 4: The auto-renewable subscription is in a Billing Grace Period. 5: The auto-renewable subscription is revoked. the App Store refunded the transaction or revoked it from Family Sharing. For these status codes 3 to 5, would this mean that the service has not been purchased? And will they change to a status of ‘2: The auto-renewable subscription is expired’ after a certain period of time without the payment issue being resolved?

Hi, all! I have an AppStore Server-side question. User sends up an AppReceipt that I am validating. What's the best way to tell the receipt belongs to said user? I want to make sure that the source of the AppReceipt was actually the original purchaser of the item. Is fetching Transaction + AppAccountToken the only way? AppAccountToken can only be utilized if the original purchase used it, and it is associated with the user's data. Is there another way?

For the subscription API, we’re using the Get All Subscription Statuses API to replace the deprecated verifyReceipt method. To determine if a user has canceled their subscription, we’re using the expirationIntent key from JWSRenewalInfo data. However, we’ve noticed that we sometimes receive this key and other times not. We’re also facing an issue with the offertype key. We use this key to determine if a user is currently in the introductory offer, the promotion offer, or neither. To obtain this key, we’re using JWSTransaction, but we occasionally receive it and other times not. Note: These issues are being tested in the sandbox environment. Thank you.

App Store Server Notifications Not Working in Production Environment Environment App Bundle ID: com.fanmuay.app Environment: Production Implementation Date: 28/01/2025 Last Successful Sandbox Test: 29/01/2025 Issue Description I'm experiencing issues with App Store Server Notifications in the production environment. The notifications work perfectly in sandbox, but they stop working completely after moving to production. What Works Server notifications are properly received in sandbox environment All purchase events successfully trigger notifications in sandbox Notification payload is correctly processed by our server in sandbox What Doesn't Work No notifications are being received from production environment No error messages are being logged Same implementation that works in sandbox yields no responses in production Questions Are there any additional configuration steps needed when moving from sandbox to production for server notifications? Is there a different certificate or authentication process required for production notifications? Is there a way to verify if our production endpoint is correctly registered? Are there any common issues that could cause notifications to work in sandbox but fail silently in production? Technical Details Our server is properly configured to receive notifications and can successfully process them in the sandbox environment. The same exact setup is used for production, but we receive no responses. We've verified our server is running and accessible. Any guidance or suggestions would be greatly appreciated. If you need any additional information, please let me know. Thank you for your help!

I encountered a scenario involving a subscription and need to determine if it's a problem or an expected outcome. Here are the details: My service received a notification from Apple of type DID_CHANGE_RENEWAL_STATUS with subtype AUTO_RENEW_DISABLED. The status field received on the payload was equal to 1 - Active. (2024-12-19T15:34:53.801) My service again received a DID_CHANGE_RENEWAL_STATUS with subtype AUTO_RENEW_DISABLED. But the status field received was 2 - Expired. (2024-12-19T23:34:57.527) My service received an EXPIRED with subtype VOLUNTARY notification. (2024-12-19T23:35:01.669) Is the event 2 an inconsistent event? Since we are receiving a notification that means the auto renew was disabled when the subscription was already expired.

I get this error: Verification failed with status INVALID_APP_IDENTIFIER we use this method: payload = signed_data_verifier.verify_and_decode_notification(notification_data) I use Production environment (this is automatically set in our server) and use my device (connected to Mac) to test the purchase. When trying to purchase I get the Sandbox environment in the Widget. This works when manually setting the environment to Sandbox before calling the function. The time it works because it does not check the apple app id (because of the environment). Now my question is: Which is the apple app id? Is it the App Id "Apple-ID" in the app store connect? Or is it the TeamId+BundleId? Could it be that my function doesnt work because the Payment was done in Sandbox and the environment is Production?

https://developer.apple.com/documentation/appstoreserverapi/get-v2-history-_transactionid I would like to inquire about the detailed triggers for updating receipts in this API specification. Recently, I was using this API with sort=DESCENDING&revoked=false to retrieve the expiration date of the most recent receipt and determine the subscription status. However, for some reason, an old receipt with an earlier expiration date appeared as the first receipt, and I would like to know the reason for this. Can you provide information on what specific events or actions trigger the updating of receipts in this API? Also, regarding https://developer.apple.com/documentation/appstoreserverapi/status, will statuses 3 and 4 not be returned in the response unless the billing grace period is enabled in the App Store?

https://developer.apple.com/documentation/appstoreserverapi/get-v2-history-_transactionid I would like to inquire about the detailed triggers for updating receipts in this API specification. Recently, I was using this API with sort=DESCENDING&revoked=false to retrieve the expiration date of the most recent receipt and determine the subscription status. However, for some reason, an old receipt with an earlier expiration date appeared as the first receipt, and I would like to know the reason for this. Can you provide information on what specific events or actions trigger the updating of receipts in this API? Also, regarding https://developer.apple.com/documentation/appstoreserverapi/status, will statuses 3 and 4 not be returned in the response unless the billing grace period is enabled in the App Store? -- Japanese こちらのAPI仕様ですが、どのようなトリガーでレシートが更新されるのか詳細に伺いたいです。 先日このAPIを使用してsort=DESCENDING&revoked=falseで一番最初のレシートの有効期限を取得して課金状態か判断していたのですが、どういったわけか一番最初のレシートに古い有効期限のレシートが入ってきたので理由を知りたいです。 また、https://developer.apple.com/documentation/appstoreserverapi/status のステータスはAppleStoreで請求猶予期間を有効化しないと3,4はレスポンスされませんか？