We are currently integrating In-App Purchases for our app and have configured App Store Server Notifications (v2) in the Sandbox environment. During testing, we observed the following issue: When a transaction is cancelled, declined, or pending (e.g., Ask to Buy flows or authorization pending), No App Store Server Notification is sent to our webhook endpoint. We only receive webhook events where the status is "purchased". This becomes a critical problem for us because our backend must accurately track transaction states including failed and pending purchases, especially for wallet top-up use cases. Additionally, we tried mocking failed transactions (via Xcode local environment and turning off In-App Purchases from Developer Settings) to simulate a technical failure scenario. Even in these cases, no webhook notification was received when the purchase failed server-side. Is it expected behavior in Sandbox that only successful transactions ("purchased") trigger webhooks? Are failed or pending transactions suppressed in Sandbox intentionally? Will webhook behavior be different in Production (i.e., will we receive webhook notifications for failures there)? Is there any extra configuration or entitlement needed to fully test failure scenarios via webhooks in Sandbox?

Regarding the offer codes in https://aninterestingwebsite.com/help/app-store-connect/manage-subscriptions/set-up-offer-codes, I set up some incorrect offer codes by mistake. Currently, I can only deactivate it but I can't delete it. Is it possible to let me delete the incorrect offer codes due to the below reasons? Thank you. I can't recreate the offer code due to error message This reference name is or has been used by another offer in this subscription group. When I use the offer code redemption view in https://aninterestingwebsite.com/documentation/SwiftUI/View/offerCodeRedemption(isPresented:onCompletion:), it shows all the deactivated offer codes. I don't want them to be displayed in the page.

Apple notification description: notificationType： The type that describes the In-App Purchase or external purchase event for which the App Store sends the version 2 notification. App Store Server Notifications 2.0+ string notificationType Possible Values CONSUMPTION_REQUEST A notification type that indicates that the customer initiated a refund request for a consumable In-App Purchase or auto-renewable subscription, and the App Store is requesting that you provide consumption data. For more information, see Send Consumption Information. When the developer receives the refund request notification and sends the refundPreference, they say: GRANT_PRORATED You prefer that the App Store grants a prorated refund. Discussion Use these values in the refundPreference field of a ConsumptionRequest. The following constraints apply to the GRANT_PRORATED option: If the product is a consumable or non-consumable In-App Purchase or a non-renewing subscription, you may include a consumptionPercentage value in the ConsumptionRequest. Question: Requesting a refund for a non-consumable type does not send a notification to the developer. However, when a developer sends a refund preference, they can still send a GRANT_PRORATED request for a non-consumable type.

FB19376771 Transactions monitoring. If I only have subscriptions, do I really need to "bother" with any sort of monitorTransactions() or just rely on subscription status (subscribed, revoked, cancelled ...) ? This is in line with Apple SKDemo and recommendation: // Only handle consumables and non consumables here. Check the subscription status each time // before unlocking a premium subscription feature. switch transaction.productType { ref: [https://aninterestingwebsite.com/documentation/storekit/implementing-a-store-in-your-app-using-the-storekit-api) The "Only handle consumables and non consumables here" recommendation by Apple in ref to the process transaction code above is nuanced and confusing if we know what was with other external experts recommendation saying when using only SK2 Views : "This is where most developers trip up in trying to get an experience that App Review is happy" ... continuing : "Be careful: that Purchase View code alone isn’t enough, because one of the possible completion status is .pending: the purchase is in the process of happening but hasn’t completed yet, so you still need to watch the transaction queue manually to be absolutely sure of handling the process completely." Does this holds true for the new SubscriptionStoreView ? We are not sure with quite obscure Apple documentation what SubscriptionStoreView handles, other than purchase (and now subscribe) function, and we do not know what diverse type of error handling messages it can return. Moreover, Apple documents: "Only handle consumables and non consumables here" ? @Apple can you please share more insights on Purchase button on SubscriptionStoreView e.g A) does it close ( finish). the purchase transaction ? B) What error results can it return ? C) What .onInAppPurchaseCompletion can handle as result ?

The appTransactionID was recently introduced and is documented here: https://aninterestingwebsite.com/documentation/storekit/apptransaction/apptransactionid From the documentation: "The App Store generates a single, globally unique appTransactionID for each Apple Account that downloads your app and for each family group member for apps that support Family Sharing." This seems like a really useful identifier, so I was wondering about some edge cases of when using it: What happens if a user logs out of his AppStore account and keeps using the app? Is it available when the app is installed from Xcode? is it possible to set it to some value using StoreKit testing? Thanks

Starting around October 12, 2025 at 19:51 UTC, we're seeing intermittent failures when verifying StoreKit transaction JWTs. The issue appears to be related to certificate expiration in the x5c chain in the JWT tokens provided by Apple. What We're Seeing Some JWTs are being signed with different certificates. Some work, some fail certificate validation. Old Certificate (Expired - causing failures): Subject: Prod ECC Mac App Store and iTunes Store Receipt Signing Issuer: Apple Worldwide Developer Relations Certification Authority (G6) Serial: 166451396673336810269824643773700992094 Valid From: 2023-09-12 19:51:53 UTC Valid To: 2025-10-11 19:51:52 UTC ❌ EXPIRED New Certificate (Valid - working): Subject: Prod ECC Mac App Store and iTunes Store Receipt Signing Issuer: Apple Worldwide Developer Relations Certification Authority (G6) Serial: 95385247725814954943813376527885434295 Valid From: 2025-09-19 19:44:51 UTC Valid To: 2027-10-13 17:47:23 UTC ✓ VALID Current Status Most JWTs use the new valid certificate. Some JWTs still use the expired certificate. This appears inconsistent/random. I don't know if it's an issue with some of Apple's servers, or an issue with StoreKit on-device cache, but seems to me like a bug on Apple's side either way. Are we missing something? Is this a known issue? Any guidance or timeline from Apple would be greatly appreciated, as this is blocking legitimate paying users.

Is there an API Endpoint that I can call to check if user still have valid subscription? I want to be sure that his subscription renewal was succesful (ie: I dont want to give him another month/year/.. if his latest renewal wasnt successful) Would GET https://api.storekit.itunes.apple.com/inApps/v1/transactions/{transactionId} be the correct API endpoint to call? But I wonder, after subscription auto-renews, do we still use the same transactionId to check whether his subs is still valid?

Transaction can not finish in OS26.2 TestFlight

I want to test the "Remove from Sale" scenario in Sandbox. I set my subscription to "Remove from Sale" for all territories in App Store Connect, but I can still make new purchases and auto-renewals continue in the Sandbox environment. Is this a known limitation? Or is there a specific way to make this work for testing? If it can't be tested, I'd like to know the expected production behavior. What changes occur in the App Receipt and what App Store Server Notification is sent?

Hello All, We continue to receive post backs for campaigns which were run 6 months back. Our understanding is post back window is only 3 months, so checking to see if this is expected or any documentation will help. We are on SKAN4.0

I have setup offer codes and subscriptions for users to purchase, when a user signs up using an offer code outside of the app the offer code does not save into my database where the subscriptions are saved the transaction is successful and validated by store kit but I cant see that that user used an offer code - an example https://apps.apple.com/redeem/?ctx=offercodes&id=6744338284&code=ASKDOM I then setup an edge function in supabase to retrieve the data that store kit sends back and im not sure where to find the offer code as it still doesnt save is there an internal apple reference that they use as apposed to the users offer code i.e offer code askdomSA = P3050 for example how can Identify if an offer code was used thank you

I'm encountering an issue with In-App Purchases on Apple TV (tvOS): When a user initiates an IAP for the first time, the system prompts them to sign in with their Apple ID, and the purchase proceeds normally. However, on subsequent purchase attempts, if the Apple ID session has expired or additional verification is required, the system redirects the user to the Settings app to sign in again. After the user signs in via Settings, the app does not automatically return to the foreground. The user must manually press the Menu button to come back. Is this is the normal behaviour of apple tv for InApp purchase? or did I need any code improvement to solve this? What I'm trying to achieve: I'd like the app to automatically return to the foreground once the user has completed the Apple ID login in Settings. Is this behavior supported on tvOS? If not, is there any known workaround or best practice to guide the user back to the app smoothly? Any advice or guidance from Apple or other developers would be greatly appreciated!

Hi does anyone have trouble using expo store review package for ios apps. for some reason on our app., the review may show for certain people, but when they submit a review, it doesn't update our review count

Hi everyone, We’ve encountered an issue in some of our games where IAP purchases made using UPI are going into a pending state. Since these purchases are for consumable items, the rewards are not granted at the time of purchase. Even after the transactions are eventually confirmed, the rewards still aren't received. We tested this with two separate UPI transactions, and both resulted in the same pending state issue. Interestingly, when we tried making a purchase using Apple Wallet afterward, the transaction completed successfully on the first attempt, without any pending state. This issue seems specific to UPI transactions. Could anyone help us understand why this is happening or if there’s a recommended way to handle such cases? Thanks in advance!

According to the App Store Server API documentation , https://aninterestingwebsite.com/documentation/appstoreserverapi/price the price field "shows the total amount of the transaction for the quantity the customer purchased." However, in actual transaction notifications and responses from App Store Server API, the price field appears to represent the unit price, not the total price. For consumable in-app purchases with quantity > 1, the price field equals the unit price of a single item. The total user payment is only correct after multiplying by the quantity. When quantity > 1, the actual amount paid by the user only matches price × quantity, which contradicts the documentation. Please confirm whether the price field is intended to be: The unit price of a single item (requiring multiplication by quantity), or The total price including all quantities (as currently documented). If the former is correct, please update the documentation to clarify that the value represents the unit price, not the total amount.

Our app server has subscription feature and processes purchase life cycles based on App Store Server Notification v1. Last year, when users purchased subscriptions during the following timeframe, we received "INITIAL_BUY" notifications with "unified_receipt.Latest_receipt_info.purchase_date" set to future date(approx. 1 hour after the actual purchase). 2024-11-03 08:00:00 - 2024-11-03 09:00:00 Etc/GMT (UTC) For example, we received the following v1 notification at 2024-11-03 08:36:33 Etc/GMT. "notification_type": "INITIAL_BUY" "unified_receipt.latest_receipt_info[].purchase_date": "2024-11-03 09:36:02 Etc/GMT" Our server grants subscription entitlement based on "purchase_date" so the users had to wait 1 hour before the subscription features became available. The timeframe coincided with the end of daylight saving time in the U.S., so we assume that it affected the behavior, but our country doesn't adopt daylight saving time. We have some questions regarding this behavior. In countries without daylight saving time, how should we handle such notifications with future purchase date in order to properly grant subscription entitlement? In App Store Server Notification v2, could purchase date be set to future date at the end of daylight saving time in the U.S., just as in v1 notifications? JWSTransactionDecodedPayload.purchaseDate

Hi Friends, I have an iOS app, which uses around 500 in app purchases for various modules. I am using StoreKit for in app purchase, now trying to migrate this to StoreKit 2. I am using Product.products(for:) method to fetch all the products by sending identifiers of all the 500 In app purchases. In response, I am getting details of only 160 products, the method is not returning remaining in app purchases. What could be the reason for this behaviour, how to get rid of the issue? May be is this the issue will happen only on TestFlight? If someone from Apple assures about it, we have plan to submit the app. Please advise, Thank you.

I am trying to launch a PWA as an application on App Store, and got rejected cause of In-App Purchases. Application is about content generation and selling subscriptions for premium content. So thats why needed to implement In-App Purchases. I have created wrapper via PWABuilder. And it is looking great so far, now my question is about How can I implement In-App Purchases in the bundle which is already created. Any suggestions will be appreciated. More clarification:- I have that product running on Web right now, we have integrated Stripe for payment handling for subscriptions. If there is nothing we can do for In-App Purchases then we have to make purchases on website and then user will be able to experience the changes. We tried that, but then we got rejected for showing locked premium content on user's feed. Also can't show any CTA or Subscribe text or button.

I am developing a mobile application using Flutter and plan to implement in-app subscriptions for both iOS platforms. I would like to request guidance on the following: Technical Implementation: Recommended best practices for implementing auto-renewable subscriptions in Flutter apps StoreKit 2 integration requirements and compatibility considerations Server-to-server notification setup and endpoint requirements Testing Procedures: Sandbox environment configuration and testing workflow TestFlight testing requirements for subscription features Recommended testing scenarios before production release Required Documentation and Accounts: Complete list of required agreements (Paid Applications Agreement, etc.) Banking and tax information requirements Privacy policy and terms of service specifications for subscription apps App Review guidelines specific to subscription-based apps Subscription Management: Grace period implementation requirements Handling subscription cancellations and refunds Promotional offers and introductory pricing setup Could you please provide documentation or direct me to the appropriate resources? Additionally, if there are any specific requirements for Flutter-based applications, I would appreciate that information. Application Details: Platform: iOS (Flutter framework) Subscription Type: Auto-renewable subscriptions

Hey everyone, This might be a simple fix that I’m just overlooking, but I’ve been stuck on it for the past 48 hours. The issue is on my subscription screen — after a user completes a successful in-app purchase, the app doesn’t navigate to the main app like it’s supposed to. I’ve added logs, tried various fixes, and even asked AI for help, but nothing has worked. From what I can tell, it seems like my listeners aren’t being registered properly after the transaction. I’ve tried reinitializing them, moving them around, and testing different flows, but still no luck. If anyone has insight into how they’ve set this up or any suggestions I might not have considered, I’d really appreciate it. Thanks in advance!