In this case, I used my project project to export the ipa to testflght. The tester installed the app on the test device, started the app, and received the payment voucher information pushed by storekit. At this time, the test device did not log in to the sandbox account. Of course, The test device has previously logged into the sandbox account and successfully paid for the subscription. When I used the same test device, connected to Xcode, clicked run, and ran the app, I did not receive the payment voucher information pushed by storekit. I am very confused, why does testflight receive the certificate information pushed by storekit?

I have problems with review process for new app. Review team getting error "SKErrorDomain Code=0 unknown error" while purchase subscription. They using iPad/iPhone with iOS 17/18. Problem is not reproducible on my devices. Also on devices of testers team. I have tested debug builds from Xcode and production builds from TestFlight. So strange that same purchase code was reviewed successfully on 2 other my apps. Review team getting error only on one new app. On screenshots from review I can see product prices. I loading it via StoreKit on fly. It is mean that app found products for purchase but can't purchase. "SKErrorDomain Code=0 unknown error" how I see is not app error. It is StoreKit error. Most popular advice in internet is just resubmit build. I tried it but get back same message from review team. That should I do in this case?

Hi, I have a project in React Native, and I am using react-native-iap to load subscription products. When I use Xcode to run my app in debug mode, it lists all my subscriptions, and I am able to subscribe successfully. However, the receipt I receive is not getting validated. When I release the app on TestFlight, it does not list my subscriptions, and I am getting an empty array. I am using the useIAP hook from react-native-iap to fetch the list of subscriptions. Additionally, my app and subscriptions are not yet approved because the subscriptions are not being listed correctly.

I have simple non-consumable IAPs set up for an app on macOS. Testing in development with a local .storekit configuration file, everything works as expected. Testing in development with a remote Sandbox, everything also seems to work fine. Product names and prices fetch correctly, I am able to make purchases with a Sandbox account (both US and UK). Once I upload a build into TestFlight, IAPs no longer work. The tester would download the Beta app from TestFlight. They open a license manager and can see all the product names, descriptions and prices are pulled from Apple servers correctly (with the correct local currency as well!). So far so good. When trying to purchase any of the IAP, the following error appears: This is TestFlight so testers are using their real Apple ID. My understanding is that they should continue using their production credentials and a TestFlight Sandbox would be configured behind the scenes automatically. This error always says the users cannot purchase from a US store and must switch to [whatever user’s actual store location is] store. For example, my account is based in the UK, has got a UK billing address and a UK payment method, and the error tells me to switch to the UK store. People in Canada get a similar error - you must switch from the US store to Canadian. The error makes no sense, the account is already in the desired country. Clicking on the “Change Store” button opens the App Store app and displays another error: “Cannot Connect to App Store”. Clicking Retry just results in this errors showing again and again. Clicking OK takes us back to the failed IAP purchase and the final error message appears: “Purchase Error - Unable to Complete Request”. Things I’ve done / checked: IAPs are configured in App Store Connect and available for all regions prices are set for all regions in App Store Connect IAP name and description localisation in English (UK) IAP status is Ready to Submit, I don’t think I can go past that unless I make a production release (which I can’t until we fix the problem) IAP capabilities added in xcode the problem is not account, machine, or location dependent - every beta tester testing my app on TestFlight has the same issue, they each use a different account and have accounts in different countries double checked the App Store account location in the App Store settings - it is definitely matching the store this error is asking to switch to application exits at startup with error 173 if app receipt cannot be found - this one was suggested by the review team, I could not really find any documentation for it review team also suggested I should add com.apple.security.network.client to enable IAP connectivity. I did add that to one of the builds and it did not help. I am not really convinced this is necessary Any suggestions on what to check and what to try? I have run out of ideas.

Hello, About a month ago me and my team allocated a sprint to migrate the App Store Server Notifications service and the StoreKit library from v1 to v2. Once the implementation was completed, we started testing using the sandbox environment (which was supposed to provide greater stability and maturity in v2). The testing session went well, we managed to test various scenarios without noticing any issue (successful payment, failed payment, renewal etc). This week, before doing the production deployment, a final testing session was scheduled. Out of nowhere, we started to encounter all kinds of strange behaviours such as: StoreKit2 error (in Xcode) Received error that does not have a corresponding StoreKit Error: Error Domain=ASDErrorDomain Code=825 "No transactions in response" UserInfo={NSDebugDescription=No transactions in response} Purchase did not return a transaction: Error Domain=ASDErrorDomain Code=825 "No transactions in response" UserInfo={NSDebugDescription=No transactions in response} In some cases the transaction id resulting from the payment was retuned "" or nil, causing our server to raise an exception. Newly created sandbox account that was raising an error that says "there is already a subscription made on this apple id". Delays in the payment processing Today, without doing any code changes, we managed to test all the scenarios without encountering any issue. Due to the oscillating experience we had in the sandbox environment, we are considering postponing the release and maintaining StoreKit 1 for now, but even in this case, the fact that App Store Connect does not offer the possibility of rolling back the Notification Service to v1, causes inconvenience. Has anyone encountered something similar? Is migrating to v2 a good choice?

I'm using my sandbox account to subscribed to something. I am now trying to open the subscribed item in Settings > Apple ID > Subscriptions > Click on the active sandbox subscription > Cannot Connect. Has anyone else encountered this? How were you able to get around it?

I'm testing subscription downgrade and upgrade cycles in sandbox, and seeing a behavior I can't explain. Code is generally similar to WWDC sample code for StoreKit2, including listening to incoming transactions. Three entitlement levels, say, Standard, Plus, Pro Corresponding subscription plans all same duration (quarterly) I go through this purchase sequence quickly, Purchase the Pro plan Before the Pro plan expires, purchase the Standard plan Still before the Pro plan expires, purchase the Plus plan Transaction.currentEntitlements after each of the purchases (logged in transaction listener), After step 1: { Pro plan } After Step 2: { (only) Pro plan } After Step 3: { Plus plan , Pro plan } I was expecting to see {Standard, Pro } in entitlements after step 2 (user entitlement calculated from the set is still correct -- Pro). If that's not the case then why after step 3 entitlements includes both Plus and Pro plans?

Hellow. I have integrated the In-App Purchase feature into my app using StoreKit2. I execute the product purchase request using Product.purchase(options:). https://developer.apple.com/documentation/storekit/product/3791971-purchase The development is complete, and testers are currently testing the app. They are not using Xcode. They are testing either with a sandbox test account by distributing the archive through debugging methods, or by downloading the app from TestFlight. I would like to test the scenario where Product.purchase(options:) returns .pending on a sandbox test account or TestFlight. I understand that Product.purchase(options:) returns .pending if the "Ask to Buy" option is enabled on a child account. However, there is no "Ask to Buy" option in the sandbox test account settings. When I test with a child account that has "Ask to Buy" enabled on TestFlight, Product.purchase(options:) does not return .pending but instead returns .userCancelled. I am wondering how I can test the case where Product.purchase(options:) returns .pending in a sandbox test account or on TestFlight. Thank you.

We have not been receiving notifications for Apple's recurring monthly charges and user refunds since 4 PM on October 10th. apple Id:1325419855 server notification endpoint: https://xyks-open.yuanfudao.com/leo-cm-third-pay/api/apple-iap/pay-sub-notify/2 Server notification version: version1 Additionally, we have another app, which is also using server notification version1, and it is able to receive notifications.

Hello, I am currently integrating with the iTunes Sandbox environment, specifically with APIs like: https://sandbox.itunes.apple.com/inApps/v1/subscriptions/12345 However, I consistently receive a 503 - Http/1.1 Service Unavailable error in response. Below is the typical response I get: <html><body><b>Http/1.1 Service Unavailable</b></body></html> I've tried sending requests from different IP addresses and servers, but all attempts result in the same 503 error. Could anyone provide guidance on whether this is a temporary issue with the sandbox environment or if there is something I need to adjust in my setup? Any help would be greatly appreciated! Thank you.

The in-app payment system is confusing. In-app payment is initially reviewed without being attached (however, in-app purchase is applied) Once the review is complete (up to in-app payment), the in-app payment module is attached for testing It is reviewed with the attached module Isn't this the logic? If there is another logic, please let me know. Thank you.

My server receives App Store Server Notification v2 notifications. Recently, it has been receiving notifications for offer codes under offers that have been deactivated. The custom code value may be the same in the active offer as the deactivated offer. When a user redeems the custom offer code for a deactivated offer, the notification payload's offerIdentifier value now contains the UUID associated with that offer in the URL in App Store Connect (like https://appstoreconnect.apple.com/apps/my-app-id/distribution/subscriptions/my-subscription-id/pricing/offer-codes/offer-uuid) The notification payload contains: {"offerIdentifier": "offer-uuid"} instead of {"offerIdentifier": "<My offer identifier from App Store Connect>"} Is it possible for a deactivated offer to be redeemed? If not, is this a known issue? We need the actual offer identifier to understand which offers users are redeeming. Is this replacement with a UUID a known issue?

I have 6 Mac App Store apps. They're all upfront paid, with no IAP, and they've all used the same on-device Mac App Store receipt validation code for years, which returns 173 in main() if there's not a valid receipt. Incidentally, the apps are entirely Objective-C. I've just learned that if I compile an app with Xcode 16 and the macOS 15 SDK, I get the alert "exit(173) Not Available" when the app returns 173 on macOS 15 Sequoia. The rest of the alert text says, "The exit(173) API is no longer available. You can use Transaction.all or AppTransaction.shared to verify in-app purchases instead." I have several questions: Why was this done? Where is this behavior change documented? What are my options, given the above description of my apps?

Hello, We have received three CONSUMPTION_REQUEST notifications for the same transactionId. We sent a response to each CONSUMPTION_REQUEST notification to the API and received a 202 Accepted response. Why do we receive multiple CONSUMPTION_REQUEST notifications even though we have sent a ConsumptionRequest to the Apple Store Server API? Do we need to respond to each CONSUMPTION_REQUEST for the same transactionId? Thanks

The error below started today 10/17/2024 (on iOS 18.1 beta 5/6/7 at least) in StoreKit sandbox testing. Outside code/app, I can't even login to the test account in settings->AppStore->Sandbox Account (goes through email/phone confirmation and then silently fails). Tried a different password for a new sandbox test account with no success...Anyone experiencing this? P.S. Status page (https://developer.apple.com/system-status/) shows some related outage from two days ago, but no current problem. Error: Purchase did not return a transaction: Error Domain=ASDErrorDomain Code=530 "(null)" UserInfo={NSUnderlyingError=0x3009ca040 {Error Domain=AMSErrorDomain Code=100 "Authentication Failed The authentication failed." UserInfo={NSMultipleUnderlyingErrorsKey=( "Error Domain=AMSErrorDomain Code=2 "Password reuse not available for account The account state does not support password reuse." UserInfo={NSDebugDescription=Password reuse not available for account The account state does not support password reuse., AMSDescription=Password reuse not available for account, AMSFailureReason=The account state does not support password reuse.}", "Error Domain=AMSErrorDomain Code=306 "Reached max retry count Task reached max retry count (3 / 3);" UserInfo={AMSDescription=Reached max retry count, AMSURL=..., NSDebugDescription=Reached max retry count Task reached max retry count (3 / 3);, AMSFailureReason=Task reached max retry count (3 / 3);, AMSStatusCode=200}" ), AMSDescription=Authentication Failed, NSDebugDescription=Authentication Failed The authentication failed., AMSFailureReason=The authentication failed.}}, storefront-country-code=USA, client-environment-type=Sandbox}

We have an application that currently supports iOS 16, and in order to disable Streamlined Purchasing, the latest approved binary must include the necessary StoreKit APIs. The StoreKit API includes the PurchaseIntent, which is available from iOS 16.4. Our question is: Can we disable Streamlined Purchasing for our app? If yes, how will it work for devices running iOS versions earlier than 16.4?

Hello team, why do I occasionally encounter (java. lang. TimeException: com. apple. itunes. storekit. verification. Verification Exception: Verification failed with status INVALID_CHAIN) when calling (BaseAppStoreServerAPIClient. getTransactionInfo) using (app-store-ser-library 3.1.0) in Java

It seems that subscription status gives different results with XCode testing and Sandbox testing. I am using StoreKit2 to implement an IAP of an autorenewable subscription. I want to determine whether the subscription has been cancelled, so that the UI reflects that the subscription will stop after the expiry date and not be renewed. the 'willAutoRenew' property of the subscription status renewalInfo seems to do exactly what is required, and works fine in XCode testing. My setup is very similar to the StoreKit demo associated with the WWDC21 session available here: https://developer.apple.com/documentation/storekit/in-app_purchase/implementing_a_store_in_your_app_using_the_storekit_api/ To demonstrate its use, add: print(renewalInfo.willAutoRenew) after line 79 of the SubscriptionsView in the demo project. When you run the app, and purchase a Standard Navigation assistance subscription, the console shows 'true'. If you then cancel the subscription in XCode (Debug:StoreKit:Manage Transactions), the console will show 'false' as expected So far so good. My problem is that when I move to Sandbox testing, and cancel the subscription in another way (eg using the .manageSubscriptionsSheet view modifier, or in Settings:App Store:Sandbox Account), the willAutoRenew property remains true, even though the subscription is in fact cancelled (ie it disappears after the expiry date) Does anyone know a workaround to determine cancellation status?

We have subscriptions for our app that are in the "waiting for review" state. The subscriptions page has the message "Your first subscription must be submitted with a new app version. Create your subscription, then select it from the app’s In-App Purchases and Subscriptions section on the version page before submitting the version to App Review." However I don't see any section in the app to enter this. It seems to be a similar issue to what is being described at https://stackoverflow.com/questions/73098652/app-store-connect-in-app-purchase-and-subscriptions-section-missing?rq=2, but I have all requirements fulfilled; all compliance and tax forms have been completed, and I have made changes to my subscriptions in response to app review. I did add these subscriptions to my app in a previous round in the approval process, and I thought that was why it wasn't appearing now. However, my app is now live and users are not seeing the subscriptions options when they try to enter the app (which had previously worked in sandbox mode)

I am currently exploring the implementation of win-back offer in my app to encourage lapsed subscribers to re-subscribe. I plan to use the automatic win-back offer sheet that display to eligible customers upon app launch, as described in the documentation. However, I am unclear about the specific iOS version requirements needed to support this feature effectively. Could someone clarify the minimum iOS, iPadOS, and macOS versions required for these automatic win-back offer sheet?