I just boxed up AppTransaction API. In the debug environment it appears to always return a VerificationResult that is .verified Unlike Storekit1 calling AppTransaction.shared does not seem to cause a sandbox receipt to actually get written on the app bundle in Derived data. I was trying to purposefully mess with the receipt in order to get AppTransaction to fail so I can test how my app behaves when errors occur but there is no receipt to mess with. I tried using the old exit(173) API and it does cause a receipt to be fetched but that seems to be completely ignored by AppTransaction, it validates even if you trash or tamper with the receipt given by exit(173). Is there a good way to test receipt validation failure using the high level Storekit2 API?

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?

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://developer.apple.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?

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?

I have implemented IAP. The purchases are successful. The refresh receipt is working fine, which then calls the requestDidFinish(_ request: SKRequest) delegate. I'm fetching the receipt url through 'Bundle.main.appStoreReceiptURL'. When I convert the receipt data in base64 string and send it to app store's sandbox api and try to validate the receipt, it fails giving status code : 21002.

My Mac app fails to open for some users with the error: "ABC.app does not support the latest receipt validation requirements." I assume this is due to the update of the App Store receipt signing intermediate certificate with one that uses the SHA-256 algorithm. I cannot reproduce this myself and I have trouble figuring out how to address this issue. Below is the code that decrypts the receipt and verifies its signature. How does this code need to be updated to support the new signing certificate? Thanks a lot in advance! inline static void CheckBundleSignature(void) { NSURL *bundleURL = [[NSBundle mainBundle] bundleURL]; SecStaticCodeRef staticCode = NULL; OSStatus status = SecStaticCodeCreateWithPath((__bridge CFURLRef)bundleURL, kSecCSDefaultFlags, &amp;staticCode); if (status != errSecSuccess) { [NSException raise:@"MacAppStore Receipt Validation Error" format:@"Failed to validate bundle signature: Create a static code", nil]; } NSString *requirementText = @"anchor apple generic"; SecRequirementRef requirement = NULL; status = SecRequirementCreateWithString((__bridge CFStringRef)requirementText, kSecCSDefaultFlags, &amp;requirement); if (status != errSecSuccess) { if (staticCode) CFRelease(staticCode); [NSException raise:@"MacAppStore Receipt Validation Error" format:@"Failed to validate bundle signature: Create a requirement", nil]; } status = SecStaticCodeCheckValidity(staticCode, kSecCSDefaultFlags, requirement); if (status != errSecSuccess) { if (staticCode) CFRelease(staticCode); if (requirement) CFRelease(requirement); [NSException raise:@"MacAppStore Receipt Validation Error" format:@"Failed to validate bundle signature: Check the static code validity", nil]; } if (staticCode) CFRelease(staticCode); if (requirement) CFRelease(requirement); } static NSData *DecodeReceiptData(NSData *receiptData) { CMSDecoderRef decoder = NULL; SecPolicyRef policyRef = NULL; SecTrustRef trustRef = NULL; @try { OSStatus status = CMSDecoderCreate(&amp;decoder); if (status) { [NSException raise:@"MacAppStore Receipt Validation Error" format:@"Failed to decode receipt data: Create a decoder", nil]; } status = CMSDecoderUpdateMessage(decoder, receiptData.bytes, receiptData.length); if (status) { [NSException raise:@"MacAppStore Receipt Validation Error" format:@"Failed to decode receipt data: Update message", nil]; } status = CMSDecoderFinalizeMessage(decoder); if (status) { [NSException raise:@"MacAppStore Receipt Validation Error" format:@"Failed to decode receipt data: Finalize message", nil]; } NSData *ret = nil; CFDataRef dataRef = NULL; status = CMSDecoderCopyContent(decoder, &amp;dataRef); if (status) { [NSException raise:@"MacAppStore Receipt Validation Error" format:@"Failed to decode receipt data: Get decrypted content", nil]; } ret = [NSData dataWithData:(__bridge NSData *)dataRef]; CFRelease(dataRef); size_t numSigners; status = CMSDecoderGetNumSigners(decoder, &amp;numSigners); if (status) { [NSException raise:@"MacAppStore Receipt Validation Error" format:@"Failed to check receipt signature: Get singer count", nil]; } if (numSigners == 0) { [NSException raise:@"MacAppStore Receipt Validation Error" format:@"Failed to check receipt signature: No signer found", nil]; } policyRef = SecPolicyCreateBasicX509(); CMSSignerStatus signerStatus; OSStatus certVerifyResult; status = CMSDecoderCopySignerStatus(decoder, 0, policyRef, TRUE, &amp;signerStatus, &amp;trustRef, &amp;certVerifyResult); if (status) { [NSException raise:@"MacAppStore Receipt Validation Error" format:@"Failed to check receipt signature: Get signer status", nil]; } if (signerStatus != kCMSSignerValid) { [NSException raise:@"MacAppStore Receipt Validation Error" format:@"Failed to check receipt signature: No valid signer", nil]; } return ret; } @catch (NSException *e) { @throw e; } @finally { if (policyRef) CFRelease(policyRef); if (trustRef) CFRelease(trustRef); if (decoder) CFRelease(decoder); } }

Hi, we have published a flutter app on the App Store offering additional content via one-time in-app purchases. Everything is working as expected when distributing the app via TestFlight but we're reportedly having issues with users not being able to restore purchases on some devices with the app loaded from the Apple App Store. We noticed the issue when some user were unable to unlock the in-app purchases via promotion codes we supplied for marketing reasons. Most of them were able to unlock the purchases using the promotion codes without a problem. Some had to try several times using a new code each time but for some users (on some of their devices) it's not working at all and we can't seem to find the reason for it. Here is one users case in detail: the user tried to unlock our "complete bundle" using a promo code first code did not seem to work, so I provided a new code it seems that both codes were redeemed correctly because both of the show up in the users purchase history in his App Store profile Now, the user is unable to unlock the content inside our app on his iPhone, he is however able to unlock it on its iPad without a problem. Both devices run the same iOS version, same Apple ID and the exact same app version. Even stranger: when using the TestFlight version of the app, again everything is working correctly even on the users iPhone. I took a look at the device logs and here's what I found: This is a snapshot of the users iPad. As you can see products are found and listed correctly storekitd seems to find and return products in receipt with the correct identifier we get the correct information and are able to restore the correct purchase 14:48:17.032895+0200  Runner  flutter: Found id: de.BUNDLEID.01, title: TITLE 1, price: €29.99 14:48:17.032922+0200  Runner  flutter: Found id: de.BUNDLEID.bundle, title: TITLE Gesamtpaket, price: €59.99 14:48:17.032975+0200  Runner  flutter: Found id: de.BUNDLEID.02, title: TITLE 2, price: €29.99 14:48:17.033001+0200  Runner  flutter: Found id: de.BUNDLEID.extension, title: TITLE Plus, price: €9.99 14:48:20.656702+0200  storekitd  [70D5C079]: Found 2 products in receipt with ID de.BUNDLEID.bundle 14:48:20.667793+0200  Runner  flutter: Called purchaseListener (purchaseDetailsList: 1) 14:48:20.667838+0200  Runner  flutter: Purchase restored 14:48:20.667869+0200  Runner  flutter: Unlock permission TITLE_1 14:48:20.667892+0200  Runner  flutter: Update TITLE_1 with true 14:48:20.672199+0200  Runner  flutter: Unlock permission TITLE_2 14:48:20.672243+0200  Runner  flutter: Update TITLE_2 with true 14:48:20.677849+0200  Runner  flutter: Unlock permission TITLE_3 14:48:20.677897+0200  Runner  flutter: Update TITLE_3 with true 14:48:20.679079+0200  Runner  flutter: Calling completePurchase... Same exact behavior can be observed on the users iPhone when running the TestFlight version of the app. However, running the app from the Apple App Store on the users iPhone (same Apple ID, same OS and app version), the log looks like this: ​14:23:26.150484+0200 Runner flutter: Found id: de.BUNDLEID.bundle, title: TITLE Gesamtpaket, price: €59.99 14:23:26.150513+0200 Runner flutter: Found id: de.BUNDLEID.02, title: TITLE 2, price: €29.99 14:23:26.150619+0200 Runner flutter: Found id: de.BUDNLEID.extension, title: TITLE Plus, price: €9.99 14:23:26.150657+0200 Runner flutter: Found id: de.BUNDLEID.01, title: TITLE 1, price: €29.99 14:23:27.125353+0200 dasd com.apple.icloud.searchpartyd.ProductInfoManager:C25423:[ (name: Thundering Herd Policy, policyWeight: 14:23:27.376336+0200 storekitd [Client] (Runner) Initialized with server Production bundle ID de.ds-infocenter.guk and request bundl 14:23:27.390026+0200 storekitd AMSURRequestEncoder: (7BA6012D] Encoding request for URL: https://mzstorekit.itunes.apple.com/inApps/ 14:23:27.984831+0200 storekitd [7BA6012D]: Found 2 products in receipt with ID de.BUNDLEID.bundle 14:23:27.990235+0200 Runner flutter: Called purchaseListener (purchaseDetailsList: 0) 14:23:27.990271+0200 Runner flutter: Purchase details list is empty! StoreKit seems to return the same exact products but for some reason the purchaseDetails list seems to be empty this time. Here is the code responsible for restoring the purchases. Nothing fancy going on here if you ask me. @override void initState() { super.initState(); db = context.read<Database>(); inAppPurchase = InAppPurchase.instance; inAppPurchase.purchaseStream.listen( purchaseListener, onError: (error) { print('Purchase stream error: $error'); showErrorDialog(); }, cancelOnError: true, ); queryProductInformation().then((value) { if (value == null) { print('value in queryProductInformation is null!'); updateProcessing(false); return; } setState(() { for (var details in value.productDetails) { products[details.id] = details; } }); updateProcessing(false); }); } Future<void> restorePurchases() async { updateProcessing(true); await inAppPurchase.restorePurchases(); } void purchaseListener(List<PurchaseDetails> purchaseDetailsList) async { print( 'Called purchaseListener (purchaseDetailsList: ${purchaseDetailsList.length})'); if (purchaseDetailsList.isEmpty) { print('Purchase details list is empty!'); updateProcessing(false); return; } for (var purchaseDetails in purchaseDetailsList) { switch (purchaseDetails.status) { case PurchaseStatus.purchased: print('Purchase successful: ${purchaseDetails.productID}'); completePurchase(purchaseDetails.productID); break; case PurchaseStatus.canceled: print('Purchase was canceled'); updateProcessing(false); break; case PurchaseStatus.restored: print('Purchase restored'); completePurchase(purchaseDetails.productID); break; case PurchaseStatus.pending: print('Purchase pending'); break; case PurchaseStatus.error: print('Purchase error'); showErrorDialog(); break; } print('Calling completePurchase...'); await inAppPurchase.completePurchase(purchaseDetails); } } Could this be an issue on Apples API or flutters in_app_purchase package?

I am just developing an app,I just config the In App Purchase module in App Store Connect.And I have deployed the related code in flutter, and the Xcode have done the configuration about this. The fetching products is successful, and buyNonconsumable/buyConsumble api could be called successfully ,but whatever install methods I have tried, could not receive the receipt after call the buyNonconsumable/buyConsumbl api.So could you help to solve this problem,I just have stucked for a few weeks , please help. Btw ,my friends have told me that if I want to integrated the In App Purchase function,I need to upload a version to apple store and make it pass the review process.Please help me to confirm these question ,very thankful.

Hi Apple Team, I'm a Nigerian developer building an app for local users, and I’m facing a major challenge: Due to CBN regulations, most Nigerian cards can’t make international payments and do not support Dynamic currency conversion, which means In-App Purchases (IAP) don’t work for most Nigerians. My app involves real-world services with external rewards and users would have to subscribe to be members, yet it’s unclear whether IAP is still mandatory. If I am forced to use IAP, most Nigerian users simply can’t pay, and I lose nearly all revenue. Questions: Can developers targeting Nigeria use local gateways like Paystack or Flutterwave instead of IAP ? Will Apple provide alternatives or guidance for regions where IAP is effectively unusable? This is a critical issue for many local developers. I’d appreciate any official clarification. Thanks, Joseph (Nigerian Developer)

Dear Apple Support Team, We are currently implementing auto-renewable subscriptions in our iOS app and are testing the integration using the sandbox environment. On the iOS app side, the in-app purchase flow completes successfully and displays a "Purchase Successful" message. However, we are not receiving any server notification callbacks on our configured App Store Server Notifications (Sandbox) webhook URL. For your reference, the webhook URL we have set in App Store Connect (Sandbox) is: https://9c0f-182-79-123-254.ngrok-free.app/ios/webhook Despite successfully completing a subscription purchase in the sandbox, there is no evidence that the webhook is being triggered. We would appreciate your guidance in resolving this issue or confirming if there are any additional configurations or steps required on our end.

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?

The majority of our sandbox calls to verifyReceipt end in an ETIMEDOUT error. This is making it very difficult to verify our purchase flow for our pending release. We have not yet migrated to StoreKit 2 and still rely on this API endpoint. The Apple API status page reports no issues. Is anyone else encountering this?

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 all, I am adding the following StoreKit 2 code to my app, and I don't see anything in Apple's documentation that explains the unverified case. When is that case exercised? Is it when someone has tampered with the app receipt? Or is it for more mundane things like poor network connectivity? // Apple's docstring on `shared` states: // If your app fails to get an AppTransaction by accessing the shared property, see refresh(). // Source: https://developer.apple.com/documentation/storekit/apptransaction/shared var appTransaction: VerificationResult<AppTransaction>? do { appTransaction = try await AppTransaction.shared } catch { appTransaction = try? await AppTransaction.refresh() } guard let appTransaction = appTransaction else { AppLogger.error("Couldn't get the app store transaction") return false } switch appTransaction { case .unverified(appTransaction, verificationError): // For what reasons should I expect this branch to be entered in production? return await inspectAppTransaction(appTransaction, verifiedByApple: false) case .verified(let appTransaction): return await inspectAppTransaction(appTransaction, verifiedByApple: true) } Thank you, Lou

In my APP for now contains IAP for one time purchase. By adding to APP auto-renewable subscriptions can I ask from customers(that purchased on App Store and IAP ) to purchase subscription. For customers that purchase IAP, ask to purchase subscription after year from IAP was purchased.

iOS Storekit2 Appstore production environment, some user feedback in app purchase faliure, What our log records is StoreKitError.unknown，please How to solve problem, thanks

Do trial periods carry over during subscription upgrades? For example, if I were to upgrade from subscription A that is currently within its introductory offer (free trial) period days to subscription B that also has the same introductory offer setting, would it be like a regular upgrade where purchaseDate and ExpiresDate remain the same? The reason I'm asking is because from my previous understanding, free trials can only be applied to a subscription within the same subscription group once. So when I do an upgrade like above, I expected the trial offer to be used on subscription A already and hence subscription B should no longer have its offerType = 1. But as far as testing shows in the sandbox environment, after being upgraded subscription B retains the same "trial period". I would like to know if this is the correct behavior, and also if there are other patterns outside of upgrades that would behave the same.

Hello, I hope to find out more about how AppTransaction works on macOS, specifically about its internet connection requirements: if I use this to validate that the app is a legit purchase from the Mac App Store, I would not want it to have an always-on requirement just to validate. Does AppTransaction require the user to always be online for AppTransaction.shared ? When an app is downloaded from the Mac App Store, is the data needed for AppTransaction automatically embedded during that download, or is that data downloaded upon first launch of the app, therefore requiring an internet connection at launch time? Once the data/receipt has been downloaded by AppTransaction, is it cached until the app's next update, or is it cleared at some time during the version's life and needs to be re-downloaded, therefore requiring an internet connection at launch? Where is that receipt/data stored? Also, if you don't mind me sneaking in this non-related but sort of related question, in terms of receipt validation: Does macOS Sequoia's MAC address rotation feature affect receipt validation in any way when using IOKit? Thank you kindly, – Matthias

Over the past month I've been seeing a recent spate of customers suddenly having IAP problems where they are not getting their purchase because Apple is not providing an up to date receipt. To be clear, this is for consumable IAPs. This is super frustrating because nothing has changed from our side. Apple developer support have refused to investigate and say they aren't technical support. Yes I've told the customer to uninstall/restart/reinstall the app from the MAS which should force an up to date receipt but it still doesn't work. One customer went through the Apple support process and was simply given a refund, which is totally unhelpful because we've already had to manually add the purchased product and now we've lost the revenue and it doesn't get the problem fixed. Anyone else having similar problems?

Hello everyone, I am facing an issue with in-app subscriptions while submitting my app for review. I have created subscriptions properly in App Store Connect. Coding-wise, everything is implemented correctly on both the application side and backend side. I have ensured that banking and tax information is complete, and all necessary agreements are active. I followed the correct procedure to create and submit subscriptions for review. Problem: App Review Team Can't See Product IDs When I submitted my first Product ID for review with the new app binary, the app got rejected because the App Review team is unable to see the product IDs in the purchase flow. They are trying to make a purchase using Sandbox, but the SKProducts array is coming back empty from the App Store. Since the product IDs are not activated, the app cannot fetch them, leading to a failed purchase attempt. This is causing a loop where the App Review team can't approve the IAP because they can't see the products. Additional Information: The app is not fetching SKProducts even in the development environment. I have verified the Product IDs in App Store Connect, and they exist in the correct App Bundle ID. There are no pending agreements or missing tax/banking details. The in-app purchases have been submitted along with the app for review. Request for Help: Is there any additional step required to activate the subscriptions for App Review? Why might the SKProducts array be empty even in development? Has anyone faced a similar issue, and how did you resolve it? Any guidance would be greatly appreciated. Thanks in advance!