Hi everyone, I’m seeing a consistent one-day discrepancy between the expiresDate returned by the App Store Server API and the “Expires on” date shown in the iOS Settings / App Store subscription list. I’d like to confirm whether this behavior is expected or if I’m misunderstanding the way Apple rounds dates. Reproduction steps Step Action Result 1 Purchase a 1-month auto-renewable subscription on 23 June 2025 14:00 JST (UTC+9) Transaction succeeds 2 Immediately fetch the transaction with GET /inApps/v1/subscriptions/{transactionId} Response contains "expiresDate": "2025-07-23T05:00:00Z" (= 23 July 2025 14:00 JST) 3 On the same device open Settings › Apple ID › Subscriptions (or App Store › Account › Subscriptions) UI shows Expires on: 22 July 2025 The same happens for every monthly renewal and on multiple devices. Region is Japan, device time zone Asia/Tokyo. What I understand so far (and my hypothesis) Apple’s docs say a monthly subscription renews “on the same calendar date” of the next month, so renewal in this example is 23 July. If the renewal is scheduled for 23 July at 14:00 JST, the subscription is fully usable until the end of 22 July in calendar terms, because the new billing period starts the moment the 23rd begins in Apple’s canonical time zone. Therefore, it might be intentional for the UI to display 22 July—i.e., “you can keep using it through the 22nd; on the 23rd it renews.” This hypothesis makes sense internally, yet it still looks confusing to end users who read “Expires on 22 July” and assume access ends at 00:00 on the 22nd, a whole day earlier than in reality. Questions Is showing the day before the renewal date the official/expected behavior? If so, could Apple clarify that the “Expires on” label represents the last full calendar day rather than the exact expiry timestamp? Which value should we surface in-app when telling users “Your subscription is valid until …”? The server’s expiresDate (precise to the second, converted to user time zone), or A UI-style date that’s one day earlier, matching Settings / App Store? Does Apple have a public document describing this rounding/visual convention? Have other developers encountered user confusion about the apparent 1-day “shortening” and, if so, how did you word your in-app messaging? Any insight from Apple engineers or fellow developers would be greatly appreciated. Thank you!

Good morning, I am configuring in backend the sending of reports regarding purchases made in app with external platform (Stripe) as per documentation. To be clear I am talking about ExternalPurchase. However, when I make the call it returns "Apple responded with status 401". I verified the token on jwt.io as per documentation and it is working. I don't understand where I am going wrong. Below is the code: const express = require("express"); const bodyParser = require("body-parser"); const jwt = require("jsonwebtoken"); const fs = require("fs"); const app = express(); const https = require("https"); const APPLE_KEY_ID = "***"; const APPLE_ISSUER_ID = "***-***-***-***-***"; const APPLE_PRIVATE_KEY = fs.readFileSync("AuthKey_***.p8", "utf8"); const APPLE_AUDIENCE = "appstoreconnect-v1"; function generateAppleJwt() { const now = Math.floor(Date.now() / 1000); const payload = { iss: APPLE_ISSUER_ID, iat: now, exp: now + (5 * 60), aud: APPLE_AUDIENCE }; return jwt.sign(payload, APPLE_PRIVATE_KEY, { algorithm: "ES256", header: { alg: "ES256", kid: APPLE_KEY_ID, typ: "JWT" } }); } app.post('/webhook', bodyParser.json({ type: 'application/json' }), async (req, res) => { let eventType = req.body.type; const relevantEvents = [ "invoice.paid" ]; if (relevantEvents.includes(eventType)) { try { const data= req.body.data; const platform = data.object.subscription_details.metadata.platform; if (platform === "IOS") { const token = generateAppleJwt(); const applePayload = { appAppleId: "***", bundleId: 'com.***.***.test', externalPurchaseId: data.object.id, purchaseTime: new Date(data.object.created * 1000).toISOString(), purchaseAmount: { amount: (data.object.total / 100).toFixed(2), currencyCode: data.object.currency.toUpperCase() }, purchaseLocation: { isoCountryCode: "IT" } }; const jsonString = JSON.stringify(applePayload); const agent = new https.Agent({ keepAlive: false }); const response = await fetch( "https://api.storekit-sandbox.apple.com/externalPurchase/v1/reports", { method: "PUT", headers: { Authorization: `Bearer ${token}`, "Content-Type": "application/json", "Accept-Encoding": "identity", }, body: JSON.stringify(applePayload), } ); if (!response.ok) { const errorText = await response.text(); throw new Error( `Apple responded with status ${response.status}: ${errorText}` ); } console.log("✅ Notifica inviata ad Apple con successo"); } else { if(!canSendNotification){ console.log("Non è una Sub. Nessuna notifica inviata."); }else{ console.log("Customer non iOS. Nessuna notifica inviata."); } } } catch (err) { console.error("Errore durante l’invio ad Apple:"); if (err.response) { console.error("Status:", err.response.status); console.error("Headers:", err.response.headers); console.error("Data:", err.response.data); } else { console.error("Message:", err.message); } } } res.status(200).send("OK"); }); exports.checkSubStripe = functions.https.onRequest(app);

Good morning, I am configuring in backend the sending of reports regarding purchases made in app with external platform (Stripe) as per documentation. To be clear I am talking about ExternalPurchase. However, when I make the call it returns "Apple responded with status 401". I verified the token on jwt.io as per documentation and it is working. I don't understand where I am going wrong. Below I share the code with you: const express = require("express"); const bodyParser = require("body-parser"); const jwt = require("jsonwebtoken"); const fs = require("fs"); const app = express(); const https = require("https"); const APPLE_KEY_ID = "XXXXX"; const APPLE_ISSUER_ID = "***-***-***-xx-xxxxxx"; const APPLE_PRIVATE_KEY = fs.readFileSync("AuthKey_xxxxx.p8", "utf8"); const APPLE_AUDIENCE = "appstoreconnect-v1"; function generateAppleJwt() { const now = Math.floor(Date.now() / 1000); const payload = { iss: APPLE_ISSUER_ID, iat: now, exp: now + (5 * 60), aud: APPLE_AUDIENCE }; return jwt.sign(payload, APPLE_PRIVATE_KEY, { algorithm: "ES256", header: { alg: "ES256", kid: APPLE_KEY_ID, typ: "JWT" } }); } app.post('/webhook', bodyParser.json({ type: 'application/json' }), async (req, res) => { let eventType = req.body.type; const relevantEvents = [ "invoice.paid" ]; if (relevantEvents.includes(eventType)) { try { const data= req.body.data; const platform = data.object.subscription_details.metadata.platform; if (platform === "IOS") { const token = generateAppleJwt(); const applePayload = { appAppleId: "xxxx", bundleId: 'com.***.***.test', externalPurchaseId: data.object.id, purchaseTime: new Date(data.object.created * 1000).toISOString(), purchaseAmount: { amount: (data.object.total / 100).toFixed(2), currencyCode: data.object.currency.toUpperCase() }, purchaseLocation: { isoCountryCode: "IT" } }; const jsonString = JSON.stringify(applePayload); const agent = new https.Agent({ keepAlive: false }); const response = await fetch( "https://api.storekit-sandbox.apple.com/externalPurchase/v1/reports", { method: "PUT", headers: { Authorization: `Bearer ${token}`, "Content-Type": "application/json", "Accept-Encoding": "identity", }, body: JSON.stringify(applePayload), } ); if (!response.ok) { const errorText = await response.text(); throw new Error( `Apple responded with status ${response.status}: ${errorText}` ); } console.log("✅ Notifica inviata ad Apple con successo"); } else { if(!canSendNotification){ console.log("Non è una Sub. Nessuna notifica inviata."); }else{ console.log("Customer non iOS. Nessuna notifica inviata."); } } } catch (err) { console.error("Errore durante l’invio ad Apple:"); if (err.response) { console.error("Status:", err.response.status); console.error("Headers:", err.response.headers); console.error("Data:", err.response.data); } else { console.error("Message:", err.message); } } } res.status(200).send("OK"); }); exports.checkSubStripe = functions.https.onRequest(app);

I try to call Get Transaction Info from App Store Server API, and the transactionId is for a Non-consumable type product, but it is odd that there are so many different transactionId and they have a same originalTransactionId { "bundleId": "${bundleId}", "environment": "Production", "inAppOwnershipType": "PURCHASED", "originalPurchaseDate": 1691220528000, "originalTransactionId": "${originalTransactionId}", "productId": "${productId}", "purchaseDate": 1691220528000, "quantity": 1, "signedDate": 1692590989925, "storefront": "USA", "storefrontId": "143441", "transactionId": "${originalTransactionId}", "transactionReason": "PURCHASE", "type": "Non-Consumable" } the defination of Non-Consumable is can only purchase once for same apple account. But why there would have originalTransactionId?

Hello, I am encountering an issue where I receive an App Store Server Notification V2 upon the purchase of a consumable item. I have configured the App Store Server Notification V2 endpoint to handle notifications related to subscription products. However, I did not expect to receive notifications for consumable purchases. The notification includes the following signedPayload decoded into the ResponseBodyV2DecodedPayload object with the following values: notificationUUID: 3cd6410b-0c89-4247-aba5-20710e79895e notificationType: null subtype: null The transaction information decoded from the ResponseBodyV2DecodedPayload object is as follows: transactionId: 2000000633622618 webOrderLineItemId: null productId: heart_2 To debug, I called the Get Notification History API of the App Store Server API, and the mentioned notification for the consumable product purchase is not included in the history. Only notifications related to subscription product purchases are retrieved. According to the notification type documentation, there is no explanation for cases where both notificationType and subtype are null, nor is there any mention of receiving notifications for consumable purchases. Therefore, I am uncertain how to interpret and handle this notification. Could you please provide an explanation or guidance on this issue? Thank you. References: https://developer.apple.com/forums/thread/737592 https://developer.apple.com/documentation/appstoreservernotifications/notificationtype

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?

We are experiencing an issue with our iOS TestFlight builds where in-app purchase (IAP) products are not being retrieved as expected. We are using Unity IAP to handle our purchases, and despite having all the products correctly configured and approved in App Store Connect, we consistently receive errors such as: UnityIAP: Received 0 products Unavailable product [product_id] We have thoroughly verified that: The product identifiers are correctly configured in App Store Connect. The bundle ID mappings are correctly set on both Unity and our backend. The same setup works on the live App Store build, where purchases are fetched and validated correctly for the same set of In App products. Sandbox test accounts are being used during TestFlight testing. This issue only started appearing recently and affects the TestFlight builds only. Note: My App ID and Product ID are correct, the IAP is live on the App Store, and the product is recognized in sandbox. Looking forward to your support on this matter.

Hello everyone, I’d like to ask for your input regarding best practices for implementing In-App Purchases (IAP) across both the frontend and backend. Here’s our current flow: -Frontend (Mobile) The user opens a specific page. We initiate a payment request using react-native-iap. After the user completes the payment, we send the purchase data (receipt) to our backend. Backend: Accept the purchase receipt from the app. Validate the receipt with Apple’s server. (GET https://api.storekit.itunes.apple.com/inApps/v1/transactions/{transactionId}) If the receipt is valid and the response indicates success, we mark the payment status as PAID. We store the transaction ID in our payment module. The Issue: We recently encountered a situation where Apple returned a valid receipt, so we marked the transaction as PAID. However, later we realized that the payment status was actually Pending. { transactionId: '70002676245699', originalTransactionId: '70002676245639', bundleId: '', productId: '', purchaseDate: 1745560404000, originalPurchaseDate: 1745560404000, quantity: 1, type: 'Consumable', inAppOwnershipType: 'PURCHASED', signedDate: 1745981078460, environment: 'Production', transactionReason: 'PURCHASE', storefront: 'SGP', storefrontId: '', price: 5000, currency: 'SGD', appTransactionId: '' } This raised a few questions: Does a Pending status always resolve to Paid, or is there a risk that Apple may later mark it as Failed or Unpaid? Is there a specific field in Apple's receipt response that reliably indicates whether the purchase is truly active? Should we hold off on granting access or product delivery until the status transitions from Pending to Paid? We’d really appreciate any insights or recommendations on how to handle this edge case to avoid granting access prematurely. Thanks in advance!

Hi everyone, We operate an online game where all in-app assets are stored server-side and require a logged-in account (no device binding). I’d like guidance on four areas: Do we really need deviceVerification / deviceVerificationNonce? – Because every purchase is tied to an account and we enforce a global transactionId UNIQUE constraint, replay or cross-account reuse appears infeasible. Under these conditions, is omitting device verification acceptable, or are there situations where Apple still recommends it? Permanent rate-limit increase for the App Store Server API – During anniversary events we saw bursts of ~18 000 requests per hour, breaching the current hourly cap on the App Store Server API (verifyTransaction, getNotificationHistory, etc.). Is there a formal process to request a long-term rate-limit expansion (or an alternative tier) from Apple? When is an App Store Server API call required for a StoreKit 2 jwsRepresentation? Docs say “call the API if you’re unsure,” but there’s no clear cut-off. Because we fully validate the JWS signature plus the entire certificate chain (including CRL/OCSP checks) on our server, local cryptographic validation seems sufficient for consumables. For subscriptions we still plan to hit the API to fetch the latest status. Does this separation match Apple’s best practice? If Apple does recommend hitting the API for consumables as well, we’d like a concrete rule of thumb—e.g. “if the item price is USD 50 or higher, always use the API.” Is establishing such thresholds consistent with Apple’s intent? Refund-risk reduction from Send Consumption Info – Adapty reports a 40–60 % refund-rate drop for subscriptions when using Send Consumption Info (blog reference). Can we expect similar reduction for consumable IAP in social/online games? Any real-world results would be helpful. Thanks in advance for any guidance!

Issue Description I am experiencing persistent 401 Unauthorized errors when attempting to access the App Store Server API using JWT authentication. Despite following Apple's documentation and regenerating keys, I am unable to successfully authenticate. Implementation Details I'm implementing JWT authentication for the App Store Server API to retrieve transaction information from the following endpoint: https://api.storekit.itunes.apple.com/inApps/v1/transactions/{transactionID} My JWT generation code (in PHP/Laravel) follows Apple's documentation: php$kid = '6W6H649LJ4'; $header = [ "alg" => "ES256", "kid" => $kid, "typ" => "JWT" ]; $iss = 'b8d99de7-b43b-4cbb-aada-546ec784e249'; // App Store Connect API Key Issuer ID $bid = 'com.gitiho.learnCourse'; // Bundle ID $payload = [ "iss" => $iss, "iat" => time(), "exp" => time() + 3600, "aud" => "appstoreconnect-v1", "bid" => $bid ]; $pathFileAuthKeyP8 = "AuthKey_6W6H649LJ4.p8"; $contentFileAuthKey = \File::get(base_path($pathFileAuthKeyP8)); $alg = "ES256"; $jwt = \Firebase\JWT\JWT::encode($payload, $contentFileAuthKey, $alg, null, $header); Steps Taken to Troubleshoot Verified that the Issuer ID is correct and in UUID format Confirmed that the Key ID matches the private key filename Regenerated the key with proper App Store Server API permissions Ensured the private key file is properly formatted with correct headers and footers Verified that the JWT is being properly encoded using the ES256 algorithm Confirmed the bundle ID is correct for our application Checked that the API endpoint URL is correct Additional Information This implementation previously worked correctly We started experiencing 401 errors recently without changing our implementation We are using the Firebase JWT library for PHP to encode the JWT Request Could you please help identify what might be causing these authentication failures? Is there any recent change in the authentication requirements or endpoint URLs that might be affecting our integration? Thanks for support me.

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!

Hi Apple Developer Support, I’m working on a Node.js script to fetch all apps listed under the Education category and Reference subcategory from the US App Store, where the app name includes "exam prep". My goal is to list these apps in descending order of their earned revenue (including both paid apps and those with subscriptions). To proceed, I’m looking for guidance or code-level support on: Accessing App Store metadata programmatically via Apple-approved APIs. Filtering apps by category, subcategory, and keywords in the app name. Sorting the result set by revenue (paid and subscription earnings). Is there any recommended API or service (official or via App Store Connect) that I should be using to achieve this? Appreciate any direction, documentation, or sample code that can help. Thanks in advance!

Regarding App Store Server Notifications V2,we are currently using Notifications V2 in a production environment. It is set up so that if the server receives the notification successfully, it returns 200 after about 30 seconds, and if an error occurs, it returns 400 or 500. However, the notification is being resent multiple times from Apple's server, at 1 hour, 12 hours, and 24 hours. Is it necessary to return the notification using Apple's API?

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!

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?

Hi, I have deployed my app on Test Flight, I have two subscriptions, monthly and yearly. User can have one of them at a time and upgrade, downgrade to the other. Upgrade, downgrade, cancel from the Apple Settings worked fine in the sandbox environment when testing locally. Now when I have deployed the app on TestFlight, I was able to purchase the subscription successfully from my app. Now when I want to cancel my subscription from the Apple Settings it gives me the following error after confirming cancellation, 'Your request is temporarily unable to be processed. Please try again later.' Also the other subscription offer (yearly) is also not shown to which I could upgrade, even though in the sandbox I was able to upgrade downgrade from the settings. Another thing I have noticed is that the app Icon or name is not shown anywhere in settings with the subscription. Instead of app icon only empty square is shown. Even though app icon shows fine everywhere else. Can someone please help me figure out this issue?