FB: https://feedbackassistant.apple.com/feedback/22556883 We're seeing a small number of production users where both Transaction.currentEntitlements and Transaction.all return zero transactions for a valid, active, non-refunded non-consumable IAP. This makes it impossible to restore the purchase via any StoreKit 2 API. Environment: Xcode 26.4 (Build 17E192) iOS 26.4.1 Direct call to SK2 Transactions.all & Flutter in_app_purchase package v3.2.3 (uses SK2 on iOS 15+) Non-consumable IAP (one-time purchase) What we observe: AppStore.sync() triggers but the purchase stream returns 0 transactions Transaction.all returns empty Transaction.currentEntitlements also returns empty User is confirmed on the correct Apple ID Issue reproduces on both iPhone and Mac for the same Apple ID Issue appears to have started recently for users who previously had no problems Debug log from affected production user: [2026-04-20T08:50:10.744115Z] init: iapAvailable=true [2026-04-20T08:50:10.744566Z] init: isPremium=false [2026-04-20T08:50:10.744567Z] init: triggering silent restorePurchases [2026-04-20T08:50:45.974566Z] restore: started [2026-04-20T08:50:45.986848Z] restore: sk2Transactions count=0 [2026-04-20T08:50:45.993004Z] restore: sk2Direct isVerified=false active=null [2026-04-20T08:50:45.993011Z] restore: sk2Direct inconclusive — falling back to standard restore [2026-04-20T08:51:16.000851Z] restore: timed out after 30s — fallback isPremium=false [2026-04-20T08:51:16.000910Z] restore: completed — succeeded=false foundPurchase=false Unable to reproduce in sandbox — Transaction.all works correctly there. Appears specific to production for a small subset of users. Has anyone else seen this?

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, We are facing an issue with In-App Purchases (subscriptions) in two iOS apps built with React Native + react-native-iap. Issue Some users receive the error: E_CONNECTION_CLOSED during the purchase flow. However: The payment is successfully deducted via the App Store. The subscription appears in the user's Apple ID subscription list. But on our side: The app does not receive the StoreKit transaction callback No receipt or transaction ID is delivered Our backend cannot validate the purchase. Restore Purchases When affected users try Restore Purchases, StoreKit returns: No purchases found even though the subscription is visible in their Apple ID. Most affected users are from India, and many payments are made via UPI through App Store billing. Has anyone experienced a case where: *the user is charged *the subscription exists in Apple ID *but StoreKit never returns the transaction or receipt? Any suggestions on how to recover these transactions would be greatly appreciated. Thanks!

I hope you are doing well. I am reaching out to inquire about a few aspects of implementing non-renewing subscriptions in our app. Firstly, we have encountered a limitation in App Store Connect where the maximum price tier available for non-renewing subscriptions in Euros is €1199. However, our product is priced at €1799. Could anyone please advise how we can handle this scenario? Is there a way to request custom pricing beyond the available tiers, or is there an alternative approach you would recommend? Additionally, we would like clarification on the following: Promo Codes: Are promo codes supported for each non-renewing subscription product? If so, how can we configure and distribute them? Installment Payments: Is it possible to enable installment-based payments for non-renewing subscriptions? If yes, could you guide us on how to set this up or if there are any prerequisites?

I have a macOS App Store app with a lifetime non-consumable IAP. I can’t do a normal App Store app transfer, so the app will be re-released as a new app under a different Apple Developer Team. That means users’ old purchases won’t automatically carry over. I want to let existing customers keep their lifetime access in the new app, but I want to do it in an Apple-approved way and avoid anything that would look like a custom license-key unlock flow. A few questions: Is there any Apple-supported way for the new app to recognize a user’s purchase from the old app? If not, is the safest App Review-compliant option to make the new app’s equivalent IAP temporarily free or discounted? Would a custom migration/recovery flow for prior customers be allowed, or would that likely violate 3.1.1? Has anyone handled this kind of migration before? Thanks.

Hello, I am blocked on the first auto-renewable subscription submission for my iOS app and I would like to know if anyone has seen this exact App Store Connect behavior. App: SEKA Money Subscription product ID: seka_premium_yearly_ Subscription Apple ID: 6760082026 Current issue: the auto-renewable subscription exists in App Store Connect I am on the correct iOS app version page the “In-App Purchases and Subscriptions” section is visible but my auto-renewable subscription does not appear in the selector only a consumable IAP appears there Important detail: the issue happens directly inside App Store Connect on the app version page this is why I do not think the missing subscription in that selector is caused by the runtime StoreKit code in the app itself I understand app code can affect UI price display, but it should not control whether a subscription appears in the App Store Connect submission selector Other details: this is my first subscription the subscription has already gone through “Waiting for Review” and is now “Developer Action Needed” metadata, screenshot, and localizations have been filled Apple Support already confirmed that I do not need a consumable for this case sandbox / TestFlight purchase behavior has been partially reproducible, but the submission workflow remains blocked because the subscription is not selectable on the app version page My question: Has anyone seen a case where the first auto-renewable subscription exists but does not appear in the app version selector, while another IAP type does appear? If yes, what was the real cause and how did you resolve it? Thank you.

Recently we are seeing 502 errors on the receipt validating API, documented here: https://developer.apple.com/documentation/appstorereceipts/verify-receipt 502 Bad Gateway: "<html><EOL><EOL><head><title>502 Bad Gateway</title></head><EOL><EOL><body><EOL><EOL><center><h1>502 Bad Gateway</h1></center><EOL><EOL><hr><center>Apple</center><EOL><EOL></body><EOL><EOL></html><EOL><EOL>" Here are logs of the occurrences: ・2026/03/20 17:03:21 - 17:04:41：10 cases ・2026/03/22 01:44:33：1 case ・2026/03/22 15:03:02：1 case ・2026/03/24 17:05:08 - 17:20:53：62 cases ・2026/03/25 06:34:56 - 06:37:21：18 cases Has anyone else seen problems like these recently? We are planning to move to the newer (non-deprecated) APIs, but are expecting that to take "a minute".

Hello, I am investigating a case where two different transaction IDs appear to refer to the same purchase, and I would like clarification on whether this behavior is expected. Additional context StoreKit version: StoreKit 1 (SKPaymentTransaction) Environment: Production Product type: Auto-renewable subscription Transaction sources The values are obtained from the following APIs: transaction_id from SKPaymentTransaction https://developer.apple.com/documentation/storekit/skpaymentqueue receipt_data from the App Store receipt https://developer.apple.com/documentation/foundation/bundle/appstorereceipturl Observed behavior After an In-App Purchase completes, the app receives: a transaction_id from SKPaymentTransaction the corresponding receipt_data for the purchase When inspecting the receipt, the transaction_id inside latest_receipt_info differs from the transaction_id received directly from the purchase transaction. For clarity: A = transaction_id received from the purchase flow (SKPaymentTransaction) A' = transaction_id found in receipt_data.latest_receipt_info The two values are different, but they differ only by 1. Additional observation The original_transaction_id for A and A' is identical, which suggests that both transaction IDs belong to the same subscription purchase chain. Pattern observation on the ID difference We have observed that the difference between A and A' is consistently exactly 1 (i.e., A' = A + 1) across multiple transactions, not just a single case. This appears to be a reproducible pattern rather than a coincidence. This observation raises an additional question (Question 6 below). API verification When calling: GET /inApps/v1/transactions/{transactionId} Both A and A' return what appears to be the same purchase record. The response data is effectively identical except for the transactionId field. However, when calling: GET /inApps/v2/history/{transactionId} A does not appear in the transaction history only A' appears in the history response Questions If A does not appear in transaction history, where does this transaction ID originate from? Why does Get Transaction Info (/inApps/v1/transactions/{transactionId}) return a valid response for A even though it is not present in the transaction history? Why do A and A' both resolve to what appears to be the same purchase? In this situation, which transaction ID should be treated as the canonical transaction ID for server-side validation? Is this difference related to how StoreKit 1 (SKPaymentTransaction) and the App Store Server API represent transactions? Is the consistent off-by-one difference between the transaction_id from SKPaymentTransaction and the one recorded in latest_receipt_info an intentional behavior of StoreKit 1's internal transaction ID assignment? Specifically, we are wondering whether StoreKit 1 applies some form of internal offset when delivering the transaction ID to the client, while the App Store server records a different (adjacent) ID in the receipt. If so, is this documented anywhere? Note We are currently in the process of migrating to StoreKit 2, but this behavior was observed while investigating our existing StoreKit 1 implementation. Any clarification would help us better understand the correct transaction model during the migration.

Hello, We are facing an issue with In-App Purchases (subscriptions) in two iOS apps built with React Native + react-native-iap. Issue Some users receive the error: E_CONNECTION_CLOSED during the purchase flow. However: The payment is successfully deducted via the App Store. The subscription appears in the user's Apple ID subscription list. But on our side: The app does not receive the StoreKit transaction callback No receipt or transaction ID is delivered Our backend cannot validate the purchase. Restore Purchases When affected users try Restore Purchases, StoreKit returns: No purchases found even though the subscription is visible in their Apple ID. Most affected users are from India, and many payments are made via UPI through App Store billing. Has anyone experienced a case where: the user is charged the subscription exists in Apple ID but StoreKit never returns the transaction or receipt? Any suggestions on how to recover these transactions would be greatly appreciated. Thanks!

Thanks!

We are implementing promo/offer codes for our iOS app’s subscription in-app purchases and have several technical questions regarding validation, receipt data, and integration. Could you please provide guidance on the following points? Testing/Validating Custom Codes Without Production Release: How can we validate custom promo/offer codes in a non-production environment? Current documentation indicates promo codes only work in production, requiring app submission and future release date setup for testing. Receipt Data for Redeemed Codes: The receipt currently includes only offer_code_ref_name, not the exact redeemed code (e.g., “ABC123”) entered by the user. Is there a way to retrieve the specific offer code used via receipts, App Store Server API, or other endpoints? Server-Side Validation Best Practices: What are the recommended best practices for server-side validation of offer codes, including using App Store Server API for transaction verification? Passing appAccountToken for Coupons: How can we pass an appAccountToken when users redeem coupon/offer codes (e.g., via presentOfferCodeRedeemSheet or redemption flows)? StoreKit purchase options support it for regular purchases but not redemption sheets. Callbacks on Coupon Redemption: Is there a client-side callback or notification (e.g., via updatedTransactions or StoreKit observers) when a user successfully redeems a coupon code in the app? Server notifications are received, but app-side feedback appears unreliable.

Hello everyone, I'm currently waiting for my Apple Developer Program enrollment to be approved and wondering if my timeline is normal. My situation: Payment of $99 USD: ✅ Completed (have invoice and order number) Government-issued photo ID: ✅ Submitted Confirmation email received: ✅ Yes - "Thank you for providing the documents we requested. We will review them and follow up with you within two business days" Days since confirmation email: 3+ business days The email stated they would follow up within two business days, but it's now been more than three business days with no update. My questions: Is it normal for the review to take longer than the stated "two business days"? For those who were approved, did you receive multiple emails throughout the process, or just a final approval email? Has anyone experienced similar delays? What was the outcome? Just want to make sure nothing is stuck or requires additional action from my side. Thanks for any insights!

Hello. Despite making my membership payment (and accidentally twice!), my membership is still not activated even after 62 hours. I contacted their support system but received no response. Does anyone have any suggestions?

Hello everyone, I am facing a very frustrating situation and wondering if anyone else has experienced this or if an Apple engineer can help. My app (App ID: 6756897429) has been stuck in "Waiting for Review" for 13 days (since Feb 12). I had a previous rejection for a Guideline 5.2.1 (Trademark) issue. I completely fixed it, uploaded a new build, and submitted it for review. Since then, total silence. I have tried: Opening a ticket (Case ID: 102820782519) -> No response. Sending follow-up messages via Contact Us -> No response. Uploading a new build to "wake up" the system -> Still stuck in Waiting for Review. I am not asking to skip the line; I just want to know if my app is stuck in a system glitch because 13 days of silence is not normal. Can any Apple representative here please check my App ID or escalate this? I am totally blocked.

My app that's been around since the dawn of the Mac App Store, and which uses its own receipt validation code for 15 years now, recently sometimes triggers a "does not support the latest receipt validation requirements" error message with my app's users. But I cannot reproduce it, even if I freshly install the app on a M4 Mac running macOS 26.2. So I have a hard time testing my fix. Does someone have a sample receipt file they could share with me (including the MAC from "en0" / GUID device ID), or do you know where I can find one that uses the new SHA-256 hash? In fact - when reading https://developer.apple.com/documentation/appstorereceipts/validating-receipts-on-the-device it seems that there's only a SHA-1 after all. So why do some users get the "receipt validation requirements" message at all? I'm only reading the receipt, decoding the ASN.1 fields and then validate the hash from the receipt (field 5) against the SHA-1 from the GUID+receipt, as always, calling libCrypto's SHA1() function. So, what would even trigger the message, as I'm not invoking any higher-level APIs that would verify the receipt for me, and thus would know when something is wrong?!?

Dear Reviewers/Apple Team/Community, We have trying to submit our app continuously for review and being rejected continuously by Apple. Our app works perfectly fine in TestFlight using the same ID apple is using. We have also provided recorded video of the testing in TestFlight to Apple reviewer. However, despite our requests below things are not done: Before testing the in-app purchase subscription are not being approved, despite us requesting the same every time during submissions. At times we are getting snapshots under error category, where everything is correct even from Apple testing. We have no other way but to explain, give snapshots, give videos to Apple to help them understand how to test the app. We have requested the reviewers multiple times for a call, but we got a call only 1 time. We are not sure what is the way we can get to talk with the reviewer and understand from them the issue they are facing. Can anyone please help us out? Below is one example, it was given it us under error category, where even with apple standard, the purchase is successful. Can someone help us out plz.

​ My app has been rejected multiple times during the last few weeks because Apple reviewer is unable to complete the purchase on revenue cat paywall. They gave this error message: Guideline 2.1 - Performance - App Completeness We were still unable to purchase the subscription successfully. Review device details: Device type: iPad Air 11-inch (M2) OS version: iPadOS 26.1 Next Steps When validating receipts on your server, your server needs to be able to handle a production-signed app getting its receipts from Apple’s test environment. The recommended approach is for your production server to always validate receipts against the production App Store first. If validation fails with the error code "Sandbox receipt used in production," you should validate against the test environment instead. Resources Note that in-app purchases do not need to have been previously approved to confirm they function correctly in review. Note that the Account Holder must accept the Paid Apps Agreement in the Business section of App Store Connect before paid in-app purchases will function. Learn how to set up and test in-app purchase products in the sandbox environment. Learn more about validating receipts with the App Store.   The offerings are fetched correctly but they are unable to complete the purchase. I tested on my physical iPhone with real account (not sandbox) and get the same exact error. I have provided screenshot of the paywall screen and my App Store Connect pages below. I think issue might be because my subscriptions on App Store are not approved but I’m not sure. I heard you are supposed to submit them same time when you submit your build. I submitted both but Apple also rejected my subscriptions saying the images were duplicate. Now they say “developer action needed” First of all, it says the images are optional so why does it matter what they are? Second of all, what image am I supposed to provide there then?  Guideline 2.3.2 - Performance - Accurate Metadata We noticed that your promotional image to be displayed on the App Store does not sufficiently represent the associated promoted in-app purchase and/or win back offer. Specifically, we found the following issue with your promotional image: – You submitted duplicate or identical promotional images for different promoted in-app purchase products and/or win back offers. Next Steps To resolve this issue, please revise your promotional image to ensure it is unique and accurately represents the associated promoted in-app purchase and/or win back offer. If you have no future plans on promoting this in-app purchase product, you can delete the associated promotional image in App Store Connect. Resources Learn how to view and edit in-app purchase information in App Store Connect. Discover more best practices for promoting your in-app purchases on the App Store.   Support Reply to this message in your preferred language if you need assistance. If you need additional support, use the Contact Us module. Consult with fellow developers and Apple engineers on the Apple Developer Forums. Request an App Review Appointment at Meet with Apple to discuss your app's review. Appointments subject to availability during your local business hours on Tuesdays and Thursdays. Provide feedback on this message and your review experience by completing a short survey.     ​

Hello, I’m experiencing an issue with StoreKit 2 when passing a new appAccountToken for each purchase request. Case-ID: 15948169 (for DTS reference) Description of the Problem When initiating a purchase, I generate a new UUID to use as the appAccountToken: let serverTransactionId = UUID() let options: Set<Product.PurchaseOption> = [ .appAccountToken(serverTransactionId) ] let result = try await product.purchase(options: options) Expected Behavior: Each new purchase should return the updated appAccountToken that I pass into the purchase options. Actual Behavior: The payload response after success always contains the same appAccountToken from the very first transaction. It ignores subsequent UUIDs I pass and keeps reusing the original one. This causes issues because the same identifier is being reused across multiple transactions, making it difficult to map purchases to the correct user session. Steps to Reproduce Generate a fresh UUID using UUID(). Pass it as .appAccountToken when calling purchase(). Complete the transaction in the sandbox environment. Inspect the payload response → The appAccountToken value is always the same as the first one used, not the newly provided one. Additional Info I do have a focused test project that reproduces this issue. The issue appears specific to appAccountToken persistence across multiple transactions. Has anyone else experienced this behavior with StoreKit 2? Is this expected (Apple caching the first token) or could this be a bug?

Hello all, I am new to implementing payments in an app, and thus completely at sea here. I have created a small app that I have set a one-time (non-consumable) payment for a premium version. In the Xcode simulator (on all platforms) and on any physical test devices I have tried, the payment works as expected. I have a sandbox account and various test accounts, both dummy and actual real accounts (friends and family). Everywhere everything works perfectly fine. Yet, when I submit for review I get a rejection with this contents: We found that your in-app purchase products exhibited one or more bugs which create a poor user experience. Specifically, the app still failed to load the in-app purchase. Please review the details and resources below and complete the next steps. Review device details: Device type: iPad Air (5th generation) OS version: iPadOS 18.6 Next Steps When validating receipts on your server, your server needs to be able to handle a production-signed app getting its receipts from Apple’s test environment. The recommended approach is for your production server to always validate receipts against the production App Store first. If validation fails with the error code "Sandbox receipt used in production," you should validate against the test environment instead. Additionally, note that the Account Holder must accept the Paid Apps Agreement in the Business section of App Store Connect before paid in-app purchases will function. Resources Learn how to set up and test in-app purchase products in >the sandbox environment. Learn more about validating receipts with the App Store. Steps I have done: I have signed all agreements and all bank account details are in order. Everything in the In-app-purchases section of the AppStoreConnect in an Active state. I have triple checked that the configuration of the in-app purchases is correct (product IDs, amounts, etc.) I have created test accounts and tested in sandbox What I don't understand from the reviewer's response is what receipts validation are they talking about? I have no payment servers (the whole concept of using Apple's in-app-purchases service is to not have to deal with my own payment implementation). The StoreKit documentation specifically reads: For each transaction that represents a current purchase, your app delivers the purchased products. To validate purchases, you can verify transactions on your server, or rely on StoreKit’s verification. So now I am confused. The reviewer's response is so vague, and so completely deprived of details that I have no idea what to do... Does the problem concern the product purchase trigger and the that in production environment it does not trigger? Is it that I haven't implemented a receipt validation? Do I need to? Although the documentation mentions that it can be done by StoreKit, I couldn't find anything concerning how to do it :( Can someone give me a hand please? Cheers, Alex

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.