Hi, In an auto-renewable subscription scenario, I receive a transaction from Product.Purchase and then send the transaction ID (e.g., 500000000738201) to my API server. After receiving the response, I called transaction.finish(). The account has purchased the subscription before and expired. So it's re-subscribe. And then, I received a RESUBSCRIBE notification from Apple’s server to my API server. I noticed a discrepancy where the transaction ID in the notification is decreased by one (e.g., 500000000738200 instead of 500000000738201). I’m wondering why this discrepancy occurs and how it happens. Best regards, RoyHuang

I am unable to sign in to a Sandbox Apple Account, where this issue occurs only via Simulator. Under Settings > Developer, I tap "Sign In" under Sandbox Apple Account. I enter my account credentials, and after bringing me back to the Developer page, the Sign In button briefly appears as disabled, before being re-enabled, without signing in to the account. (The account credentials are also recognized as correct, as I will receive an alert popup if incorrect.) See screenshots below: After signing in, Sign In button appears disabled... ... then is re-enabled without actually signing in to the account. I have now tried setting up multiple sandbox accounts via App Store Connect with various permutations (no confirmation of Apple Account email, confirming Apple Account email, logging in to iCloud and accepting terms of service), running different device simulators, running simulators on different Mac computers... none of which yield a different result. By contrast, I can sign in to the Sandbox Apple Account without issue on a physical device. The problem occurs only via Simulator.

I have consumable IAPs in my app. Currently there is no way for me to test refunds for them as Xcode testing doesn't allow refunds option for my Purchases. According to this official documentation on Transaction.all , i should be getting my refunded consumables in Transaction's all property. But there is no way for me to know what kind of data is in the refunded transaction object. Will there be a 'revocation date' like in the case of non-consumables?

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!

Hi all, I’m testing Subscription in my Flutter app on a real iOS device (iPhone 16 Pro with iOS 18) via TestFlight. I’ve set everything up as required, but I still get this error: flutter: Found products: [] If everything works perfectly when StoreKit configuration is used in Xcode, but not via TestFlight. All my Subscriptions are approved with the same ID.

Hello Apple Support Team, We're a developer team that has created an app with subscription-based features, and we've been using App Store Server Notifications to receive updates about user subscription status changes. I'm reaching out to inquire about potential modifications to the App Store Server Notifications approach that might have improved notification delivery times for my app. So on our appstore app, when a user purchases a subscription, the apple server notifications reach our server and send us the complete detail of that user’s purchase for eg he upgraded or downgraded etc. And then based on the data we receive from app store server notifications, we save it in our database, along with updating the users subscription table in the database. Previously, we experienced delays in receiving the real time notifications from apple on our server, sometimes taking a few minutes, while other times they would arrive immediately. And because of this issue, the users faced delay in seeing their subscription updates, as our db was updated only after the app store server notification reached our server. However, recently, we've noticed a significant improvement, and notifications are now being delivered still in real-time, but without any noticeable delays. I'm wondering if Apple has made any changes to the App Store Server Notifications system that might have resolved the delay issue. Could you please confirm if any modifications were made in 2025, specifically from January onwards, that might have improved notification delivery times? Additionally, I'd like to know if these changes apply to both sandbox testing and production environments. If possible, could you please provide more information about the changes or direct me to a resource that might explain the updates? I'd appreciate your assistance in confirming this information, and I'm looking forward to hearing back from you.

I have an app that works by being able to map IAP transactions to a predefined user ID. This means when I consume events from Apple's App Store Server Notifications endpoints I have to do a reverse lookup in order to assign permissions within my app. Workflow: User purchases subscription within the app via IAP. The app persists the subscriptionID from the Apple IAP library in my cloud database (Firestore). Cloud function receives the event from App Store Server Notifications endpoint and looks up the user ID containing the persisted transactionID (with retries to avoid race condition). Question: This workflow works but it seems an improvement would be to allow dev's to append metadata, like the user ID, to the transaction submitted to IAP that we can access within the signedTransactionInfo of the event from the App Store Server Notifications endpoint in order to facilitate a direct lookup of the user document needing it's permissions updated. This would greatly simplify workflows that use non-Apple systems as a source of truth for app permissions. Does this actually exist already? If not, is there a feature request platform?

What is the expected behavior for App Receipts and ASSN v2 notifications when a subscription is set to "Remove from Sale"? I tried to test this in Sandbox, but the "Remove from Sale" setting in App Store Connect doesn't seem to affect the Sandbox environment. For existing subscribers, what happens in the receipt? Does auto_renew_status change to 0 and is expiration_intent populated immediately? Also, which notificationType is sent via ASSN v2?

Hi Team, I’ve successfully implemented the subscription flow for my app. However, I’m currently facing challenges related to testing the cancellation behavior for auto-renewable subscriptions. Specifically: I’m unable to locate the correct payload structure for the following test endpoint: https://api.storekit-sandbox.itunes.apple.com/inApps/v1/notifications/test I’m also unclear on how to simulate or complete the full lifecycle of a subscription (including cancellation) using Apple’s sandbox environment or APIs. Could you please guide me on how to: Retrieve or construct the proper payload for the test notification API? Simulate a cancellation flow end-to-end in the sandbox for auto-renewable subscriptions?

Hello all, We developed an iOS app which we started advertising now. In our iOS app we already implemented the updatePostbackConversionValue(_:completionHandler:) to send in-app events in increasing numbers (first open -> 1, lead ->2, conversion -> 3). From our understanding this should be enough for alle ad networks (Apple Ads, Google Ads, Meta Ads, Microsoft Ads and Reddit Ads) to receive those numbers - at least they receive the app installs from the SKAN already. Is this correct or do we miss something here in the integration? We currently really struggle to assure that everything is working and we do not see any conversions coming in - even though two weeks of advertising have passed already. I look forward for any feedback or discussion and I am also happy to share more details if needed. Best regards, Manuel

I've been trying to make my app available on the App Store for a month now, but I can't because the signatures I created don't appear in the sandbox app. I did all the configuration in the store and in the app. I tested the same code in another app with signatures and it was loaded, but the signature for that specific app doesn't appear. I've tried contacting Apple support, but they can't help me. It almost seems like it's on purpose. I'm treated like crap and they don't even give me an explanation about what's happening. Can anyone help me?

I'm trying to understand the IAP development process. I created my first Product on App Store Connect and am trying to build my app to use it. However it keeps failing with "Invalid product ID.". From what I've read, this is because the product has not yet gone through review. But what I don't understand is, of course it hasn't gone through review yet, because trying to use it in any capacity fails, even though I'm using a real physical device and using a Sandbox User. Is this the correct workflow? It seems very backwards that I have to submit the product for review, even before I know how it's going to be used. I'm still building the screen for the product page, and haven't even started touching any backend APIs, yet it's asking for screenshots. Am I misunderstanding something here?

I'm encountering an issue with the App Store Server API where the appAccountToken is not preserved when users migrate their Apple ID email addresses. I've submitted Feedback Assistant ticket FB18709241 but wanted to check if anyone else has experienced this and get community input on best practices. The Issue When a user migrates their Apple ID from one email to another (e.g., from olduser@example.com to newuser@icloud.com), the App Store creates a new subscription transaction with a different originalTransactionId, but the appAccountToken is not carried forward from the original transaction. What I'm Seeing note: these values are fake When querying /inApps/v1/subscriptions/{originalTransactionId} with the either post-migration transaction ID or the pre-migration transaction ID, the API returns both transactions: Pre-migration transaction (status: 2 - inactive): originalTransactionId: "12345678910111" Contains: "appAccountToken": "abc123-def456-ghi789" Post-migration transaction (status: 1 - active): originalTransactionId: "67891011121314" Missing: appAccountToken entirely The Problem The appAccountToken is our only way to link App Store subscriptions to user accounts. Without it on the new transaction: Users lose access to premium features despite having valid subscriptions Server-side renewal notifications can't be matched to user accounts Manual support intervention is required for each affected user Questions for the Community Has anyone else encountered this issue with Apple ID migrations? What's the recommended approach for handling this scenario? Is there an alternative mechanism to maintain the subscription-to-user linkage across migrations? Questions for Apple Engineers Is this the expected behavior, or should the appAccountToken be preserved? Are there any planned improvements to handle this migration scenario? What's the best practice for developers to handle this case? Interestingly, both the old and new transaction IDs return the same JSON response from the App Store Server API, suggesting Apple maintains internal linkage between these transactions, but the appAccountToken isn't carried forward to the active transaction. Any insights or similar experiences would be greatly appreciated! Thank you!! Feedback Assistant: FB18709241

Hi All, We are trying to integrate Promotional Offer in our app, We have a React Native app and are using react-native-iap for handling our in app purchases, as per the documentation we are generating signature in our BE and passing the proper details to the function as well, but for subscription request which have offer applied we are getting the apple pop up properly as well with offer details but when trying to subscribe it gives us SKErrroDomain: 12, for subscription without applying offer the subscription goes through but when we apply the offer we get the above error. Our app is currently in Development Stages and has not been sent for review sam for our subscription plans as well. Please let me know what could be the probable cause for this and help us resolve the issue. This is the code snippet of ours for the front end : export const buySubscription = async (subscriptionData: any) => { try { if (subscriptionData.offer_id) { const response = await getSubscriptionSignature( subscriptionData.productId, subscriptionData.offer_id, ); const offerData = response?.data; const offer = { identifier: offerData?.offer_id, keyIdentifier: offerData?.key_id, nonce: offerData?.nonce, signature: offerData?.signature, timestamp: Number(offerData?.timestamp), }; await requestSubscription({ sku: subscriptionData.productId, withOffer: offer, }); } else { await requestSubscription({ sku: subscriptionData.productId }); } } catch (err) { logger.error('Subscription error: ' + JSON.stringify(err)); throw err; } }; and 
from my python Backend which generates the signature:

def generate_signature(self, product_id: str, offer_id: str) -> dict: """ Generate signature for Apple StoreKit promotional offers. Args: product_id: The product identifier from App Store Connect offer_id: The promotional offer identifier Returns: dict: Contains signature and required metadata Reference: https://developer.apple.com/documentation/storekit/in-app_purchase/original_api_for_in-app_purchase/subscriptions_and_offers/implementing_promotional_offers_in_your_app """ try: # Generate UUID without dashes and use as nonce nonce = str(uuid.uuid4()) timestamp = get_current_time_ms() # milliseconds # Create the payload string in exact order required by Apple payload_components = [ self.bundle_id, # App Bundle ID self.key_id, # Key ID from App Store Connect product_id, # Product identifier offer_id, # Promotional offer identifier nonce, # UUID without dashes str(timestamp) # Current timestamp in milliseconds ] payload_str = "\u2063".join(payload_components) # Use Unicode separator logger.debug(f"Signing payload: {payload_str}") # Create SHA256 hash of the payload digest = hashes.Hash(hashes.SHA256()) digest.update(payload_str.encode('utf-8')) payload_hash = digest.finalize() # Sign the hash using ES256 (ECDSA with SHA-256) signature = self.private_key.sign( data=payload_hash, signature_algorithm=ec.ECDSA(hashes.SHA256()) ) # Encode signature in base64 signature_b64 = base64.b64encode(signature).decode('utf-8') logger.info(f"Generated signature for product {product_id} and offer {offer_id}") return { "key_id": self.key_id, # Changed to match Apple's naming "nonce": nonce, # UUID without dashes "timestamp": timestamp, # As integer "signature": signature_b64, # Base64 encoded signature "product_id": product_id, # Changed to match Apple's naming "offer_id": offer_id # Changed to match Apple's naming } except Exception as e: logger.error(f"Failed to generate signature: {str(e)}") raise HTTPException( status_code=500, detail=f"Failed to generate signature: {str(e)}" )

In the app we're distributing, we've identified a user where the Get All Subscription Statuses API returns two original transaction IDs in the data response. This user has gone through cancellations and re-subscriptions since their initial purchase. Meanwhile, despite maintaining a continuous subscription, a notification suddenly arrives on the renewal date with original_transaction_id2. +---------------------------+---------------------------+---------------------+ | original_transaction_id | notification_type | subtype | +---------------------------+---------------------------+---------------------+ | original_transaction_id1 | SUBSCRIBED | INITIAL_BUY | ~ Repeated cancellations and re-subscriptions ~ | original_transaction_id1 | SUBSCRIBED | RESUBSCRIBE | | original_transaction_id2 | SUBSCRIBED | INITIAL_BUY | +---------------------------+---------------------------+---------------------+ Although it can be inferred from the interface definition of the API itself that multiple original transaction IDs may be returned, what causes multiple original transaction IDs to be returned? Furthermore, is it possible to reproduce the case where multiple original transaction IDs are returned in the sandbox environment provided by Apple? As for this app, it: Uses subscriptions through in-app purchases. Does not offer upgrades, downgrades, or crossgrades, having only one product. Has never undergone price increases or decreases. Is distributed exclusively in Japan.

No matter what I do whether I delete the app or reset my phone it still prompts me to log in to the previous sandbox test account. I'm not even signed into that account on my phone or in the App Store.

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.

For testing purposes, I log out of media and purchases to use sandbox ID's to test in app purchases. Once I log out of media and purchases in device settings, in app purchases is still using my real apple ID, I'm not being prompted anymore to log into a sandbox ID for purchases.

Hi, We have a app with some auto-renewing subscription in a group of subscriptions. When a user upgrade from a subscription to another, the "user receive a refund of the prorated amount of their original subscription" (https://developer.apple.com/app-store/subscriptions/). How is the prorated calculated ? Example : subscription to 14,99$ / month. If subscriber upgrade after 10 days, is the refund calculated 10/30 of 14,99$ (so ~5$) ?

Dear community, Context My company operates in the European Union, where not so long ago there appeared the possibility to accept an ["Alternative Terms Addendum for Apps in the EU"] (https://developer.apple.com/contact/request/download/alternate_eu_terms_addendum.pdf), which, among others, gives us the possibility to use an alternative payment provider, other than Apple's In App Purchase PSP system (ref: Apple docs). My company did accept it and was granted the StoreKit External Purchase Entitlement (com.apple.developer.storekit.external-purchase) entitlement, with which we integrated a different PSP, so now we want to incorporate the reporting to Apple's External Purchase Server API. We are currently integrating with the External Purchase Server API and have encountered a couple of issues I would appreciate clarification on: Question 1 Is there a way to retrieve an overview or summary of the current subscription states on Apple’s servers as a result of the submitted reports to External Purchase Server API? Specifically, I would like to verify the expected outcomes before the monthly invoice is issued by Apple and to understand the subscription states for the test users I used during this process and for future reference as well. Question 2 In one scenario, I initiated a one-year subscription, and in the middle of its period, I submitted a RENEWAL for one month with a higher price. I expected the request to fail due to overlapping periods and/or pricing conflicts, but both submissions were accepted without error. Do you have an idea about: What happens at the end of the renewed month? Will the subscription continue with the renewed (higher) amount, revert to the original (lower) annual rate, or be canceled? Where can I view the final state and billing plan for that subscription? Thank you for your assistance, we are looking forward for any kind of help or information regarding this topic.