Hi everyone, I’ve been receiving App Store Server Notifications (webhooks) normally for a specific transaction. Everything was working fine — I could use the original_transaction_id to query transaction history, and transaction_id to look up specific transactions. However, starting recently, all API calls for that transaction (both Get Transaction Info and Get Transaction History) now return not found. • The webhooks used to arrive normally for this transaction. • I am sure I’m querying the correct environment (production vs sandbox). • The IDs I’m using are exactly the ones from the last webhook payload. • I haven’t changed my integration code. My questions: 1. Under what conditions does Apple’s API return “not found” for original_transaction_id that previously worked? 2. Can Apple actually purge transaction records (in production)? 3. Could this happen due to refunds, revocations, or other account actions? 4. Is this expected behavior, or should I file a DTS (Technical Support Incident)? Any insight would be appreciated. Thanks in advance!

アプリに課金を実装しようと思うのですが、もし不正利用された場合、アプリ側は基本的にApp Storeを通じて対応するよう案内するのが一般的と思いますが、Apple ID不正利用時とクレジットカード不正利用時で、アプリ側が行う標準的な対応プロセスは変わるのか教えていただきたいです。 また下記内容は標準的な対応プロセスとして問題ないでしょうか？
 ■Apple ID不正利用時 → ユーザー自身がAppleサポートに連絡し、パスワード変更・二段階認証の設定・不正購入の返金申請などを行うよう案内する。 ■クレジットカード不正利用時 → まずカード会社への連絡を促すが、アプリ内決済に関してはAppleのカスタマーサポート経由で返金や調査手続きを案内する 不正利用されたユーザーへの対応に備えて、アプリ側が考慮すべきことがあれば教えてください。

We are considering a price change for the auto-renewing subscriptions we currently offer in a Production environment and have made system modifications to our servers. We would like to implement a price change for purchases made through our SANDBOX Apple account in order to test if our system is capable of handling the price change.

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

我正在通过集成app-store-server-library-java来实现 iap服务端校验。我参照了官网提供的Verification Usage 的代码，运行的时候异常信息如下： at com.apple.itunes.storekit.verification.ChainVerifier.verifyChainWithoutCaching(ChainVerifier.java:98) at com.apple.itunes.storekit.verification.ChainVerifier.verifyChain(ChainVerifier.java:71) at com.apple.itunes.storekit.verification.SignedDataVerifier.decodeSignedObject(SignedDataVerifier.java:186) at com.apple.itunes.storekit.verification.SignedDataVerifier.verifyAndDecodeTransaction(SignedDataVerifier.java:72) 我的代码如下： import com.apple.itunes.storekit.model.ResponseBodyV2DecodedPayload; import com.apple.itunes.storekit.verification.SignedDataVerifier; import com.apple.itunes.storekit.verification.VerificationException; import com.auth0.jwt.JWT; import com.auth0.jwt.interfaces.DecodedJWT; import java.io.FileInputStream; import java.io.FileNotFoundException; import java.io.InputStream; import java.util.Base64; import java.util.Set; public class ExampleVerification { public static void main(String[] args) throws FileNotFoundException { String bundleId = "com.example"; Environment environment = Environment.SANDBOX; Set<InputStream> rootCAs = Set.of( new FileInputStream("AppleRootCA-G3.cer"), new FileInputStream("AppleRootCA-G2.cer") ); Long appAppleId = null; // appAppleId must be provided for the Production environment SignedDataVerifier signedPayloadVerifier = new SignedDataVerifier(rootCAs, bundleId, appAppleId, environment, true); String appTransactionJWS = "eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6IkFwcGxlX1hjb2RlX0tleSIsIng1YyI6WyJNSUlCeXpDQ0FYR2dBd0lCQWdJQkFUQUtCZ2dxaGtqT1BRUURBakJJTVNJd0lBWURWUVFERXhsVGRHOXlaVXRwZENCVVpYTjBhVzVuSUdsdUlGaGpiMlJsTVNJd0lBWURWUVFLRXhsVGRHOXlaVXRwZENCVVpYTjBhVzVuSUdsdUlGaGpiMlJsTUI0WERUSTFNRFl3TXpFeE1UQXdNRm9YRFRJMk1EWXdNekV4TVRBd01Gb3dTREVpTUNBR0ExVUVBeE1aVTNSdmNtVkxhWFFnVkdWemRHbHVaeUJwYmlCWVkyOWtaVEVpTUNBR0ExVUVDaE1aVTNSdmNtVkxhWFFnVkdWemRHbHVaeUJwYmlCWVkyOWtaVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCTnZZZ3o1MW1CbEMweE5McW9rMUJCcithRWJEb1ZEeVkyaVRsejZsK1JjYVR4QStVY2ptMjBESTNncFFlM280a2doRGxSbGowdEo1enBGUHgyQWR2VCtqVERCS01CSUdBMVVkRXdFQlwvd1FJTUFZQkFmOENBUUF3SkFZRFZSMFJCQjB3RzRFWlUzUnZjbVZMYVhRZ1ZHVnpkR2x1WnlCcGJpQllZMjlrWlRBT0JnTlZIUThCQWY4RUJBTUNCNEF3Q2dZSUtvWkl6ajBFQXdJRFNBQXdSUUloQU40bUJWTHBoZkpjYjdweHF2b09XcjkyK1czYU5LRG9pazV5Vk9BT0NEVmxBaUFYWVF0czJubWZGMStGYzlSODJHXC96QWhaVU00aDNTXC9VdFE4Q1lPS2p3ZlE9PSJdfQ.eyJhcHBsaWNhdGlvblZlcnNpb24iOiIxIiwib3JpZ2luYWxQdXJjaGFzZURhdGUiOjAsImJ1bmRsZUlkIjoiYnJpZ2h0LnVuaWhhbmQuY24iLCJhcHBUcmFuc2FjdGlvbklkIjoiMCIsImRldmljZVZlcmlmaWNhdGlvbiI6IlRYdGRvMWZtNDhQVDdXUUh5cHU4K2l3TW55YmNoTTNNeG5XUnhOR1JqSFhQQnVqMXdUaldcL05zN3JtUmJlQTd3IiwicmVjZWlwdFR5cGUiOiJYY29kZSIsIm9yaWdpbmFsQXBwbGljYXRpb25WZXJzaW9uIjoiMSIsInJlcXVlc3REYXRlIjoxNzYxMDM1OTMzNTE3LCJvcmlnaW5hbFBsYXRmb3JtIjoiaU9TIiwicmVjZWlwdENyZWF0aW9uRGF0ZSI6MTc2MTAzNTkzMzUxNywiZGV2aWNlVmVyaWZpY2F0aW9uTm9uY2UiOiI1ZDhmNzM5Mi01N2YwLTQyM2YtOTMzNy1hZDQ0YTk5MDM4Y2EifQ.2ZO5xsx-yywP4IyaDz4KQ3mq181ZGwlX2uANSm-kHq50KIdMMUDveMsCrcZmHdzLH2rpfPsXKaIMdM25Hdcuuw"; DecodedJWT unverifiedJWT = JWT.decode(appTransactionJWS); String header = unverifiedJWT.getHeader(); System.out.println(new String(Base64.getDecoder().decode(header))); try { signedPayloadVerifier.verifyAndDecodeTransaction(appTransactionJWS); } catch (VerificationException e) { e.printStackTrace(); } } } 查看了ChainVerifier.java 源代码，发现 private static final int EXPECTED_CHAIN_LENGTH = 3; // <--- 关键常量 // ... PublicKey verifyChainWithoutCaching(String[] certificates, boolean performRevocationChecking, Date effectiveDate) throws VerificationException { // ... 解析证书代码 ... if (parsedCertificates.size() != EXPECTED_CHAIN_LENGTH) { throw new VerificationException(VerificationStatus.INVALID_CHAIN_LENGTH); // <--- 抛出异常点 } // ... 后续验证代码 ... } appTransactionJWS是来自客户端的沙盒环境。 我发现沙盒环境的jws总是包含一个证书，而后端验证又必须要求三个证书，请问这个问题如何解决。

Unsure if this has been reported before, but I'm seeing a specific scenario where Apple is sending back faulty information in App Store Server Notifications. When users have payment failures that result in the membership expiring, and then reactivate later on with a different subscription, they are given a new originalTransactionId, yet we have three cases where we receive messages about the old originalTransactionId, indicating that after the user recovers their subscription, Apple is resurrecting the old subscription and treating it as if it is active BUT ultimately decides to deactivate it. Here is a sample screenshot of an impacted user. We only have three month and annual plans. Timeline: March 21st: This user signed up for a 3 Month Plan June 21st: This user fails to pay July 7th: After our 16 day grace period, this user loses access July 29th: This user sees they lost access and repurchase Augsut 19th: Their membership is deactivated (long before their 3 Month Subscription is up) For further verification I've also attached a record of all the payloads we've received from Apple for this user. Please let me know if you need any more details to fix this bug OR if it has already been fixed! Thank you. user_webhook_data_sanitized.csv

The same store kit configuration file works in iOS and iPadOS, but not in macOS for the same multi platform application project with a single scheme. Here’s a more detailed write up with the sample code and screenshots. When the simple app is run on https://www.reddit.com/r/SwiftUI/s/KJsYcggWOa EDIT: I’m using Xcode 16.4

My server is able to receive notifications for successful purchases. However, we are experiencing an issue where we do not receive any server notifications when a consumable product is refunded. Could you please help us verify if this behavior is expected? Also, is there a way to trigger a test refund notification for consumable products in the sandbox environment, so we can ensure our server is correctly set up to handle it?

Hello everyone, For example, our app currently has one subscription group in App Store Connect with 5 plans (2 annual, 2 monthly, and 1 quarterly). By default, users can go into Apple Subscriptions in Settings and freely switch between all of these plans. However, our business requirement is to only allow users to stay on one annual plan and one quarterly plan. We don’t want them to switch to the other plans. My questions are: Is there any best practice or recommended approach to restrict subscription switching within the same group? Would removing the unwanted products from sale be the correct approach, or are there any risks/downsides with this method? Has anyone faced a similar situation and found a practical solution? Any guidance or shared experience would be greatly appreciated. Thanks!

We're planning on increasing the price of our ios in-app subscription. We will select the option "Keep the current price for existing subscribers" Reading this https://aninterestingwebsite.com/help/app-store-connect/manage-subscriptions/manage-pricing-for-auto-renewable-subscriptions/, it's not clear if existing subscribers will be notified of the change in pricing (even though that change won't impact them) or not?

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://aninterestingwebsite.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.

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!

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.

I'm using the SwiftUI view SubscriptionStoreView (https://aninterestingwebsite.com/documentation/storekit/subscriptionstoreview/) with a subscription group that has 2 subscriptions. I set up a free trial offer in App Store Connect (https://aninterestingwebsite.com/help/app-store-connect/manage-subscriptions/set-up-introductory-offers-for-auto-renewable-subscriptions/). The storekit file in Xcode is synced with the App Store. In debug build, this works and appears correctly, showing the free trial offer: But in release build, the free trial offer is not shown: The code is very simple: SubscriptionStoreView(productIDs: [ "[PRODUCT ID FOR ANNUAL SUBSCRIPTION]", "[PRODUCT ID FOR BIMONTHLY SUBSCRIPTION]" ]) Does anyone have a solution? Thank you. (Xcode 16.3, macOS 15.5, iOS 18.5)

Strange issue with currency display in subscription products Hi everyone, I'm facing a strange issue in my app where I use a subscription-based in-app purchase model. The products I created in App Store Connect are all in "Approved" status. I've tested with both RevenueCat and StoreKit, but the result is the same. Here are the products being loaded: Product loaded: weekly_product_id Display name: Weekly Pro Description: Weekly Pro Subscription Price: ₺229,99 Product loaded: annual_product_id Display name: Annual Pro Description: Annual Pro Subscription Price: ₺1.799,99 Even though I can see the correct prices and currency (Turkish Lira) in the Xcode debug console, on my real device the currency appears as Philippine Peso, as shown in the attached screenshot. Interestingly, in the iOS simulator, it's displayed in USD. I've double-checked and my device's region settings are set to Turkey. Any ideas on what could be causing this? And more importantly, how can I fix it? Thanks in advance!

I am trying use SKOverlay to promote an app, and I currently have the campaignToken field populated. However, even when installs happen from the SKOverlay, nothing shows up under that campaign token in App Store Connect. Is there something that I'm missing? I don't have the providerToken set.

Hello! I am trying to get my app set up to support external payments. The snag I am hitting at the moment is it seems that relevant pages are not accessible? There is this old EU doc https://aninterestingwebsite.com/support/apps-using-alternative-payment-providers-in-the-eu/ But the more updated US doc titled "Distributing apps in the U.S. that provide an external purchase link - Support" is not available where it should be https://aninterestingwebsite.com/support/storekit-external-entitlement-us/ In addition the link for requesting the entitlement seems to be broken https://aninterestingwebsite.com/contact/request/storekit-external-entitlement-us/ Any idea how one can access these? Perhaps this is just a temporary error?

Hi everyone, I've been going back and forth with Apple’s review team for over 10 days now, and I'm still unable to get my first In-App Purchase (IAP) working correctly. Here's what’s happening: ✅ The IAP works perfectly when I build and run directly from Xcode. ❌ However, when I test the app via TestFlight, tapping the purchase buttons does nothing—the IAP sheet doesn't appear. Key issue (I think): I believe the IAP hasn't been submitted properly for review. On App Store Connect, I cannot select the IAP under the “In-App Purchases” section of the version submission page. It's grayed out or not listed at all. As a result, Apple keeps rejecting my binary due to the IAP not being included in the review. What I’ve already done: Created the IAP (non-consumable) Set pricing and cleared all errors Checked Bundle ID, Product ID, and entitlements Added In-App Purchase capability to the app target Uploaded the binary via Xcode Waited multiple times for status updates My questions: What’s the correct process to link the IAP to a specific app version if it doesn't show up in the version page? Could this be an issue with App Store Connect metadata or approval timing, or am I missing something in Xcode/build settings? Is there any way to force re-sync the IAP so it appears when submitting the build? Has anyone resolved a similar issue recently? This process has been incredibly frustrating, and the feedback from the review team so far has been very vague. I would really appreciate any detailed insight or steps to ensure the IAP is submitted correctly and works on TestFlight. Thank you in advance!

For years I've been using Receigen for receipt verification for the Mac App Store build of my application. However, with the deprecation of exit code 173, I am moving to StoreKit-based verification and have a couple of questions. I have followed the instructions from https://aninterestingwebsite.com/documentation/storekit/apptransaction/shared and have something like this (simplified): Swift: @objc class ValidateReceipt: NSObject { @objc func validate() async -> Bool { do { let verificationResult = try await AppTransaction.shared switch verificationResult { case .verified(_ /*let appTransaction*/): // StoreKit verified that the user purchased this app and // the properties in the AppTransaction instance return true; default: // The app transaction didn't pass StoreKit's verification return false; } } catch { // Handle errors return false; } } } Objective-C: ValidateReceipt *validateReceipt = [[ValidateReceipt alloc] init]; [validateReceipt validateWithCompletionHandler:^(BOOL result) { if (result) { // Successful app purchase validation } else { // App purchase validation failure } }]; Thing is, I always get a valid result, i.e., in ValidReceipt.validate(), the case .verified block always runs. Even when exporting a new release build of my app and running it (without any _MASReceipt). When using exit code 173, an .app without a _MASReceipt would prompt for app store login. Nothing of the sort happens now. Am I misunderstanding the documentation / doing something wrong / missing something obvious?

I'm developing storekitV2, my app is providing the way to refund some product, and I use method below. func beginRefundRequest(in scene: UIWindowScene) async throws -> Transaction.RefundRequestStatus however when i call the method, the modal view presented but the view shows error with message 'cannot connect'. when I select retry button, something done with indicator and get same result. how can I solve this problem?