Hi, I'm new to AppStore Connect, and I'm learning how subscriptions work. I'm finalizing my first app, but on my TF, I'm having some issues with the price: it's always displayed in US dollars on my paywall. When I tap "subscribe," the Apple sheet correctly offers the price in euros. I'm using Product.displayPrice to display the price in my paywall. The documentation did mention it is The localized string representation of the product price, suitable for display. So, is it normal in my case for the price in dollars to be displayed and not the price in euros like the Apple sheet? Thank you in advance for your help.

Hi all, I've received emails from other apps after making a purchase, with content like: You have purchased {App Name} on {Date & Time} and acknowledged that if you download or use this in-App Purchase within fourteen days of buying it, you will no longer be eligible to cancel this purchase. Do anyone know under what circumstances Apple sends a Purchase Confirmation Letter to the user's email after they purchase our digital products via IAP? Is this something developers can control? Additionally, I've seen pop-up reminders before making a payment in apps, with content similar to the above message. Are these reminders provided by Apple, or can developers create their own guidance to help users avoid accidental purchases? Kindly, Vanto

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?

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?

I'm working on adding a single Non-Consumable In-App purchase to my app. Essentially a "try before you buy" type thing. Limited functionality unless the app is purchased. I am currently testing this using Xcode and the Manage StoreKit Transactions window. So far most everything appears to be working except for declined pending transactions. If I set Ask to Buy to Enabled, the Ask Permission (for parent or guardian) dialog appears. After pressing the Ask button, I see a transaction listed as Pending Approval. If I Approve the transaction, then my app is notified and all is well. However, if I Decline the transaction then my app is not notified. Is that normal? Also, how do I (i.e. the app) know that there is a pending transaction?

Currently, I have an app running locally on my computer, and there is also a web app. To create an account, users need to pay through the web app, which handles the payment process smoothly. My question is: Do I need to implement In-App Purchases (IAP) if the payment is only for account creation? Let me elaborate on my question. I know the typical answer is yes, but what if users in the mobile app cannot create an account or pay within the app itself? Instead, account creation is only possible via the web app, and only users who have paid outside the mobile platform can access and join the mobile app. This approach is similar to what Netflix and Spotify do – they do not allow account creation inside their mobile apps and do not provide any redirects or buttons indicating alternative payment methods (they do not have IAP).

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

You can still renew your membership within the next 8 days and your apps will remain available on the App Store during this time. Open the Apple Developer app on your iPhone, iPad, or Mac. Sign in to your account, tap/click Renew, and follow the prompts. I'm getting this message but renew button is not visible in Developer App or on website. How to to renew?

If a user applies for and is approved for a subscription refund by Apple, we understand that the developer can receive a server notification of "REFUND." However, this notification doesn't include the refund amount. Therefore, we thought about linking the refund amount information output in the financial report "All Countries or Regions (Detailed)" with individual end-user transaction information. However, it seems that this report doesn't have a transaction ID, and the records appear to be aggregated daily. Is there any way we can find out how much was refunded to which user for individual refunds? If a user applies for a subscription refund from Apple, are there cases where only a part of the plan, rather than the full amount, is refunded?

Hi everyone, We operate an online game where all in-app assets are stored server-side and require a logged-in account (no device binding). I’d like guidance on four areas: Do we really need deviceVerification / deviceVerificationNonce? – Because every purchase is tied to an account and we enforce a global transactionId UNIQUE constraint, replay or cross-account reuse appears infeasible. Under these conditions, is omitting device verification acceptable, or are there situations where Apple still recommends it? Permanent rate-limit increase for the App Store Server API – During anniversary events we saw bursts of ~18 000 requests per hour, breaching the current hourly cap on the App Store Server API (verifyTransaction, getNotificationHistory, etc.). Is there a formal process to request a long-term rate-limit expansion (or an alternative tier) from Apple? When is an App Store Server API call required for a StoreKit 2 jwsRepresentation? Docs say “call the API if you’re unsure,” but there’s no clear cut-off. Because we fully validate the JWS signature plus the entire certificate chain (including CRL/OCSP checks) on our server, local cryptographic validation seems sufficient for consumables. For subscriptions we still plan to hit the API to fetch the latest status. Does this separation match Apple’s best practice? If Apple does recommend hitting the API for consumables as well, we’d like a concrete rule of thumb—e.g. “if the item price is USD 50 or higher, always use the API.” Is establishing such thresholds consistent with Apple’s intent? Refund-risk reduction from Send Consumption Info – Adapty reports a 40–60 % refund-rate drop for subscriptions when using Send Consumption Info (blog reference). Can we expect similar reduction for consumable IAP in social/online games? Any real-world results would be helpful. Thanks in advance for any guidance!

Sorry but I'm not good at English. Is the originalTransactionId received for the same subscription by the same user the same in Store Kit v1 and Store Kit 2? Also, will the originalTransactionId be the same even if the subscription price is changed?

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.

Hey everyone, We're looking for the best way to handle App Store Server Notifications in our development setup and would appreciate some guidance. Our Setup: We use a single App Store Connect account for development, which supports multiple environments (e.g., staging1, staging2). Our production app lives in a separate account, so that's not an issue. The Challenge: We have only one configurable sandbox notification URL. This makes it difficult to route notifications to the correct development server (staging1 vs. staging2 vs developments) when a sandbox event occurs. We're considering using a proxy server to catch all notifications and then forward them to the appropriate environment. However, we're not sure how to determine the correct destination. Our Questions: What's the recommended approach for managing a single sandbox notification URL across multiple development environments? If a proxy is the best method, which parameter in the responseBodyV2 payload should we use to route the notification? How can we differentiate between our various dev environments? Is it possible to add custom properties to the App Store Server Notification V2 body to facilitate routing? Any advice or best practices you've implemented would be greatly appreciated.

在沙盒环境下或者TestFlight 测试消费型项目会提示此项目将免费恢复

After I configured a consumable subscription(In App Purchases) on the apple platform, when I change the price in the App's server, is there any existing apple Api support to change the price on the apple platform? Of course, I know I need to resubmit.

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

代码块 让购买结果=尝试等待购买（产品，选项：[选项]） //处理支付结果 开关购买结果{ 案例让.success（验证结果）： 如果案例让.verified（交易）=验证结果{ await transaction.finish()case .userCancelled: 自我.取消回调？（） 案例.pending： /// 交易可能在未来成功，通过Transaction.updates进行通知。 打印（“苹果支付中待定”） 默认： 打破 } } 抓住 { 自我失败回电话？（”产品购买失败：\(错误)") 打印（“产品购买失败：\（错误）”） } 凭证相关信息如下： transactionid：1230000065994257 appAccountToken：D613C126-4142-4BFF-9960-00AE3F5A6F83 "jwsInfo": ["header": "eyJhbGciOiJFUzI1NiIsIng1YyI6WyJNSUlFTURDQ0E3YWdBd0lCQWdJUWZUbGZkMGZOdkZXdnpDMVlJQU5zWGpBS0JnZ3Foa2pPUFFRREF6QjFNVVF3UWdZRFZRUURERHRCY0hCc1pTQlhiM0pzWkhkcFpHVWdSR1YyWld4dmNHVnlJRkpsYkdGMGFXOXVjeUJEWlhKMGFXWnBZMkYwYVc5dUlFRjFkR2h2Y21sMGVURUxNQWtHQTFVRUN3d0NSell4RXpBUkJnTlZCQW9NQ2tGd2NHeGxJRWx1WXk0eEN6QUpCZ05WQkFZVEFsVlRNQjRYRFRJek1Ea3hNakU1TlRFMU0xb1hEVEkxTVRBeE1URTVOVEUxTWxvd2daSXhRREErQmdOVkJBTU1OMUJ5YjJRZ1JVTkRJRTFoWXlCQmNIQWdVM1J2Y21VZ1lXNWtJR2xVZFc1bGN5QlRkRzl5WlNCU1pXTmxhWEIwSUZOcFoyNXBibWN4TERBcUJnTlZCQXNNSTBGd2NHeGxJRmR2Y214a2QybGtaU0JFWlhabGJHOXdaWElnVW1Wc1lYUnBiMjV6TVJNd0VRWURWUVFLREFwQmNIQnNaU0JKYm1NdU1Rc3dDUVlEVlFRR0V3SlZVekJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCRUZFWWUvSnFUcXlRdi9kdFhrYXVESENTY1YxMjlGWVJWLzB4aUIyNG5DUWt6UWYzYXNISk9OUjVyMFJBMGFMdko0MzJoeTFTWk1vdXZ5ZnBtMjZqWFNqZ2dJSU1JSUNCREFNQmdOVkhSTUJBZjhFQWpBQU1COEdBMVVkSXdRWU1CYUFGRDh2bENOUjAxREptaWc5N2JCODVjK2xrR0taTUhBR0NDc0dBUVVGQndFQkJHUXdZakF0QmdnckJnRUZCUWN3QW9ZaGFIUjBjRG92TDJObGNuUnpMbUZ3Y0d4bExtTnZiUzkzZDJSeVp6WXVaR1Z5TURFR0NDc0dBUVVGQnpBQmhpVm9kSFJ3T2k4dmIyTnpjQzVoY0hCc1pTNWpiMjB2YjJOemNEQXpMWGQzWkhKbk5qQXlNSUlCSGdZRFZSMGdCSUlCRlRDQ0FSRXdnZ0VOQmdvcWhraUc5Mk5rQlFZQk1JSCtNSUhEQmdnckJnRUZCUWNDQWpDQnRneUJzMUpsYkdsaGJtTmxJRzl1SUhSb2FYTWdZMlZ5ZEdsbWFXTmhkR1VnWW5rZ1lXNTVJSEJoY25SNUlHRnpjM1Z0WlhNZ1lXTmpaWEIwWVc1alpTQnZaaUIwYUdVZ2RHaGxiaUJoY0hCc2FXTmhZbXhsSUhOMFlXNWtZWEprSUhSbGNtMXpJR0Z1WkNCamIyNWthWFJwYjI1eklHOW1JSFZ6WlN3Z1kyVnlkR2xtYVdOaGRHVWdjRzlzYVdONUlHRnVaQ0JqWlhKMGFXWnBZMkYwYVc5dUlIQnlZV04wYVdObElITjBZWFJsYldWdWRITXVNRFlHQ0NzR0FRVUZCd0lCRmlwb2RIUndPaTh2ZDNkM0xtRndjR3hsTG1OdmJTOWpaWEowYVdacFkyRjBaV0YxZEdodmNtbDBlUzh3SFFZRFZSME9CQllFRkFNczhQanM2VmhXR1FsekUyWk9FK0dYNE9vL01BNEdBMVVkRHdFQi93UUVBd0lIZ0RBUUJnb3Foa2lHOTJOa0Jnc0JCQUlGQURBS0JnZ3Foa2pPUFFRREF3Tm9BREJsQWpFQTh5Uk5kc2twNTA2REZkUExnaExMSndBdjVKOGhCR0xhSThERXhkY1BYK2FCS2pqTzhlVW85S3BmcGNOWVVZNVlBakFQWG1NWEVaTCtRMDJhZHJtbXNoTnh6M05uS20rb3VRd1U3dkJUbjBMdmxNN3ZwczJZc2xWVGFtUllMNGFTczVrPSIsIk1JSURGakNDQXB5Z0F3SUJBZ0lVSXNHaFJ3cDBjMm52VTRZU3ljYWZQVGp6Yk5jd0NnWUlLb1pJemowRUF3TXdaekViTUJrR0ExVUVBd3dTUVhCd2JHVWdVbTl2ZENCRFFTQXRJRWN6TVNZd0pBWURWUVFMREIxQmNIQnNaU0JEWlhKMGFXWnBZMkYwYVc5dUlFRjFkR2h2Y21sMGVURVRNQkVHQTFVRUNnd0tRWEJ3YkdVZ1NXNWpMakVMTUFrR0ExVUVCaE1DVlZNd0hoY05NakV3TXpFM01qQXpOekV3V2hjTk16WXdNekU1TURBd01EQXdXakIxTVVRd1FnWURWUVFERER0QmNIQnNaU0JYYjNKc1pIZHBaR1VnUkdWMlpXeHZjR1Z5SUZKbGJHRjBhVzl1Y3lCRFpYSjBhV1pwWTJGMGFXOXVJRUYxZEdodmNtbDBlVEVMTUFrR0ExVUVDd3dDUnpZeEV6QVJCZ05WQkFvTUNrRndjR3hsSUVsdVl5NHhDekFKQmdOVkJBWVRBbFZUTUhZd0VBWUhLb1pJemowQ0FRWUZLNEVFQUNJRFlnQUVic1FLQzk0UHJsV21aWG5YZ3R4emRWSkw4VDBTR1luZ0RSR3BuZ24zTjZQVDhKTUViN0ZEaTRiQm1QaENuWjMvc3E2UEYvY0djS1hXc0w1dk90ZVJoeUo0NXgzQVNQN2NPQithYW85MGZjcHhTdi9FWkZibmlBYk5nWkdoSWhwSW80SDZNSUgzTUJJR0ExVWRFd0VCL3dRSU1BWUJBZjhDQVFBd0h3WURWUjBqQkJnd0ZvQVV1N0Rlb1ZnemlKcWtpcG5ldnIzcnI5ckxKS3N3UmdZSUt3WUJCUVVIQVFFRU9qQTRNRFlHQ0NzR0FRVUZCekFCaGlwb2RIUndPaTh2YjJOemNDNWhjSEJzWlM1amIyMHZiMk56Y0RBekxXRndjR3hsY205dmRHTmhaek13TndZRFZSMGZCREF3TGpBc29DcWdLSVltYUhSMGNEb3ZMMk55YkM1aGNIQnNaUzVqYjIwdllYQndiR1Z5YjI5MFkyRm5NeTVqY213d0hRWURWUjBPQkJZRUZEOHZsQ05SMDFESm1pZzk3YkI4NWMrbGtHS1pNQTRHQTFVZER3RUIvd1FFQXdJQkJqQVFCZ29xaGtpRzkyTmtCZ0lCQkFJRkFEQUtCZ2dxaGtqT1BRUURBd05vQURCbEFqQkFYaFNxNUl5S29nTUNQdHc0OTBCYUI2NzdDYUVHSlh1ZlFCL0VxWkdkNkNTamlDdE9udU1UYlhWWG14eGN4ZmtDTVFEVFNQeGFyWlh2TnJreFUzVGtVTUkzM3l6dkZWVlJUNHd4V0pDOTk0T3NkY1o0K1JHTnNZRHlSNWdtZHIwbkRHZz0iLCJNSUlDUXpDQ0FjbWdBd0lCQWdJSUxjWDhpTkxGUzVVd0NnWUlLb1pJemowRUF3TXdaekViTUJrR0ExVUVBd3dTUVhCd2JHVWdVbTl2ZENCRFFTQXRJRWN6TVNZd0pBWURWUVFMREIxQmNIQnNaU0JEWlhKMGFXWnBZMkYwYVc5dUlFRjFkR2h2Y21sMGVURVRNQkVHQTFVRUNnd0tRWEJ3YkdVZ1NXNWpMakVMTUFrR0ExVUVCaE1DVlZNd0hoY05NVFF3TkRNd01UZ3hPVEEyV2hjTk16a3dORE13TVRneE9UQTJXakJuTVJzd0dRWURWUVFEREJKQmNIQnNaU0JTYjI5MElFTkJJQzBnUnpNeEpqQWtCZ05WQkFzTUhVRndjR3hsSUVObGNuUnBabWxqWVhScGIyNGdRWFYwYUc5eWFYUjVNUk13RVFZRFZRUUtEQXBCY0hCc1pTQkpibU11TVFzd0NRWURWUVFHRXdKVlV6QjJNQkFHQnlxR1NNNDlBZ0VHQlN1QkJBQWlBMklBQkpqcEx6MUFjcVR0a3lKeWdSTWMzUkNWOGNXalRuSGNGQmJaRHVXbUJTcDNaSHRmVGpqVHV4eEV0WC8xSDdZeVlsM0o2WVJiVHpCUEVWb0EvVmhZREtYMUR5eE5CMGNUZGRxWGw1ZHZNVnp0SzUxN0lEdll1VlRaWHBta09sRUtNYU5DTUVBd0hRWURWUjBPQkJZRUZMdXczcUZZTTRpYXBJcVozcjY5NjYvYXl5U3JNQThHQTFVZEV3RUIvd1FGTUFNQkFmOHdEZ1lEVlIwUEFRSC9CQVFEQWdFR01Bb0dDQ3FHU000OUJBTURBMmdBTUdVQ01RQ0Q2Y0hFRmw0YVhUUVkyZTN2OUd3T0FFWkx1Tit5UmhIRkQvM21lb3locG12T3dnUFVuUFdUeG5TNGF0K3FJeFVDTUcxbWloREsxQTNVVDgyTlF6NjBpbU9sTTI3amJkb1h0MlFmeUZNbStZaGlkRGtMRjF2TFVhZ002QmdENTZLeUtBPT0iXX0", "payload": "eyJ0cmFuc2FjdGlvbklkIjoiMTIzMDAwMDA2NTk5NDI1NyIsIm9yaWdpbmFsVHJhbnNhY3Rpb25JZCI6IjEyMzAwMDAwNjU5OTQyNTciLCJidW5kbGVJZCI6ImNvbS5taWd1LmNsb3VkYXZwIiwicHJvZHVjdElkIjoibWlndS52aXNpb24uTW92aWUuOCIsInB1cmNoYXNlRGF0ZSI6MTc0NDgwNzYzMjAwMCwib3JpZ2luYWxQdXJjaGFzZURhdGUiOjE3NDQ4MDc2MzIwMDAsInF1YW50aXR5IjoxLCJ0eXBlIjoiTm9uLVJlbmV3aW5nIFN1YnNjcmlwdGlvbiIsImRldmljZVZlcmlmaWNhdGlvbiI6IjdIdUtPRUhRdVd2L0hKZjdLdlBzQnJOWUNoc2V3c3k3enpPZ2k1YjE3UW8wVnd2clhhQ3B5TTNmZTN3cFBqRUwiLCJkZXZpY2VWZXJpZmljYXRpb25Ob25jZSI6ImQ3YzgwOWI2LTFjNDMtNDIwOC1iZWVmLWVhZDUwYzY1ZGIwZCIsImFwcEFjY291bnRUb2tlbiI6ImQ2MTNjMTI2LTQxNDItNGJmZi05OTYwLTAwYWUzZjVhNmY4MyIsImluQXBwT3duZXJzaGlwVHlwZSI6IlBVUkNIQVNFRCIsInNpZ25lZERhdGUiOjE3NDU4MjM1MTU5OTUsImVudmlyb25tZW50IjoiUHJvZHVjdGlvbiIsInRyYW5zYWN0aW9uUmVhc29uIjoiUFVSQ0hBU0UiLCJzdG9yZWZyb250IjoiQ0hOIiwic3RvcmVmcm9udElkIjoiMTQzNDY1IiwicHJpY2UiOjgwMDAsImN1cnJlbmN5IjoiQ05ZIiwiYXBwVHJhbnNhY3Rpb25JZCI6IjcwNDQxMzM2NTEzNjUyNzAzMyJ9", "signature": "SXieZGabBt6xHoSaBsZ1k4AexqkNYzwZel0BEhGqc3mxrd4kzOR5wERRATXySqbqfT3WJzkDAsr9jmCdoz_7-g"], "status": "normal", "transactionId": "1230000065994257"]","Band_Phone_Num":"18653588566","Platform":"124","Oper_Time":"1745823519","verification_time":"1745823519115"},"ISP":"移动","OETM":"1745823519116","CLIENTID":"","CPURATE":"0.257","AMBERUDID":"1f72113ecc704ce4a4cc135e8af71ee6","ANAME":"","MEMRATE":"0.02346919","CITY":"北京","PROMOTION":"\\","CLIENTIP":"192.168.31.74","CLIENTIPV6":"fe80::4e3:40a8:51c3:dbf5","DB":"Apple","APN":"com.migu.cloudavp","ETM":"2025-04-28 14:58:39 116"} 请帮我查一下 是这个订单没关闭成功吗？为什么出现购买新的产品 返回的永远是这个支付凭证。

I am shown as being subscribed to our service in the Subscriptions list in settings yet when going to the Storekit2 page in my app it shows me as NOT being subscribed and is unresponsive. I select Restore Subscription, that grays briefly, asks for a password, then returns to blue and nothing else happens. Bouncing back and forth between monthly and yearly likewise gives no response. The Transaction.currentEntitlements seems to be empty so it thinks the user is not subscribed. I have unsubscribed, and resubscribed via the Settings page to no avail.

Hi everyone, I'm encountering an issue with StoreKit 2 and subscriptions that I hope someone can help clarify. Here's the scenario: A user purchases a subscription. The user cancels the subscription in their Apple ID settings (it remains active until the end of the billing period). While the subscription is still active, the user reopens the app and tries to repurchase the same subscription. The problem: The purchase() method start well a new billing flow, but once confirmed throws a StoreKitError.unknown. Despite this error, the subscription gets re-enabled and appears active again in the currentEntitlements. So my question is why the purchase method throw an error and how to deal with this case ? I precise I'm currently only working in sandbox, maybe the behavior is different in production (but even in that case there is still a bug in Sandbox that should not happen). Also in that case the Apple Server Notification API send the webhook with type DID_CHANGE_RENEWAL_STATUS (and subtype AUTO_RENEW_ENABLED), which is expected. Thanks for help, Gregoire.

Hi, I've been reported, and I've experienced myself, extremely slow responses from StoreKit 2 on boot. I can reproduce the issue quite consistently with the iPhone, sometimes Transaction.currentEntitlements hangs for minutes even after the device has attained full Internet access. My app is a VPN client, so there's certainly a chicken-and-egg situation, but I'm performing a basic test without the in-app validation in the packet tunnel provider. The tunnel starts fine on boot (on-demand), whereas the app takes ages to return from AppTransaction.shared and Transaction.currentEntitlements. I guess this is caused by some network call inside the framework (maybe spoiled by the on-demand VPN?), but with no timeout, exceptions, logging, or future-proof fallback (appStoreReceiptURL is deprecated), I'm poking in the dark. It goes without saying, keeping the users waiting minutes to be credited for their purchases is a no-go. I still can't find a reasonable workaround, but the frustrating part is that StoreKit 2 was supposed to make these things straightforward. At times, it doesn't feel "ready" and I spend on it a lot of time that I'd rather invest in the product. Does this sound familiar to anybody? Thanks in advance Davide