https://developer.apple.com/documentation/appstoreserverapi/send_consumption_information If the customer provided consent, respond by calling this API and sending the consumption data in the ConsumptionRequest to the App Store. If not, respond by calling this API and setting the customerConsented value to false in the ConsumptionRequest; don't send any other information. Since our server would be receiving CONSUMPTION_REQUEST server notifications and will be the one calling the Consumption API, how do we know if the user has provided consent? That info doesn't seem to be in the server notification or anywhere else.

Hello, Having bad times with Development Postback copies receival on our custom server. Current setup: App is configured to be advertised (https://developer.apple.com/documentation/adattributionkit/configuring-an-advertised-app) AdAttributionKit - Opt in for Reengagement Postback Copies ✅ AdAttributionKit - Postback Copy URL ✅ AdAttributionKit - Ad Network Identifiers ✅ Configured backend https://{name}.com/.well-known/appattribution/report-attribution/ (POST) ✅ Devices with iOS 18.4 (with Postaback Development tool and AdAttribution developer mode Enabled) Tried different Postback setup combinations, with different app builds (debug, release installed from xcode/testflight) and with AdAttribution developer mode Enabled/Disabled - doesn't make any difference. Console log: Found 0 postbacks eligible for transmission for environments: Any advise is very much appreciated

this error occurred during the StoreKit1 payment process. Could you please tell me the reason? SKErrorDomain Code=0 "发生未知错误\" UserInfo= {NSLocalizedDescription=发生未知错误，NSUnderlyingError=0x17652ee50 {Error Domain=ASDErrorDomain Code=500"(null)\"Userlnfo={NSUnderlyingError=0x17652d530 {Error Domain=AMSErrorDomain Code=203 "(null)" Userlnfo= {NSUnderlyingError=0x17652c3c0 {Error Domain=AMSErrorDomain Code=203"(null)\"UserInfo=0x1663e5940(not displayed)}}}

I'm developing an app and I think I've implemented what I need to in the swift code. However, when I click the Purchase button in my app, I see "Cannot connect to App Store" when the App Store app opens. Attached are images showing how I've configured the Sandbox user. What am I doing wrong? I expect to be able to do a fake purchase to test subscription activation in the app, but it doesn't work.

Hi, We're currently experiencing an issue with consumable In-App Purchases on our production iOS app. Until the end of May, everything was working as expected, but starting in early June, our app no longer receives any products when calling queryProductDetails() using Flutter’s in_app_purchase plugin (which utilizes StoreKit). Here’s what we’ve confirmed so far: The product IDs are correctly configured in App Store Connect, and all items are marked as “Approved.” No recent changes have been made to the bundle ID or the product IDs. The “Base Territory” setting was updated for each IAP item in early May. After that change, product retrieval and purchases were working normally through the end of May. This issue is happening on real devices in production, and multiple users are affected. The same functionality continues to work correctly on Android. All requested product IDs are being returned in the notFoundIDs list of the queryProductDetails() response. We're quite puzzled by this issue as no clear cause has been identified so far. Any thoughts on this issue would be much appreciated. Thank you!

Hello, I use Storekit2 to test the purchase of subscription products. After purchasing a subscription product in the sandbox, it will automatically renew 12 times, and then it will no longer automatically renew. When I click to purchase again, calling the try await product.purchase() method does not pop up the purchase pop-up window. In fact, it will directly go to the case let .success(.verified(transaction)): step, and the Transaction.currentEntitlements is empty

As a developer I have a question I would like cleared up. We offer two tiers of annual subscriptions in our apps. These subscriptions are under the same subscription group in App Store connect. My question is, if a user purchases tier 1 of the annual subscription for $10.00, and uses it for 6 months; then chooses to upgrade to tier 2 which costs $20.00 per year. Would the user be pro-rated the difference in price i.e. charge only another $10.00 at the time of the upgrade., or are they charged $20.00 and then refunded the difference in their remaining lower tier subscription? I keep finding inconsistent answers across the Apple community forums on this.

Question: In the sandbox environment, I attempted to perform an In-App Purchase within an IME (Input Method Extension) using a sandbox test account. The purchase flow completed successfully, and I received the success callback. However, I encountered an issue: no receipt file is generated. I tried checking with both the main app’s bundle and the IME’s bundle, but the receipt file was not found in either case. When I attempted to refresh the receipt using SKReceiptRefreshRequest, it failed with an exception (error code: 0). I would appreciate any guidance on how to resolve this issue.

I am developing and testing Apple Promotional Offers and encountered issues during implementation. Purchase Failure When using the following API, the promotional purchase sheet is displayed, but after attempting payment, the transaction fails. API: public static func promotionalOffer( offerID: String, keyID: String, nonce: UUID, signature: Data, timestamp: Int ) -> Product.PurchaseOption Observed behavior: Alert shows: Unable to Purchase [Environment: Xcode] Not Eligible for Offer Console logs: AMSErrorDomain Code=305 ASDErrorDomain Code=3903 Discount Not Applied When calling this API, there are no errors, but the promotional price is not applied, and the user still sees the original price. API: public static func promotionalOffer( _ offerID: String, compactJWS: String ) -> [Product.PurchaseOption] Questions Does Promotional Offers support testing with .storekit files in Xcode? Can Promotional Offers be tested with sandbox accounts using real offers configured in App Store Connect? How should I troubleshoot and resolve the above issues? • Could it be related to the subscription history of the sandbox account? • Do I need to use TestFlight instead of Xcode to test certain scenarios? • Could this be caused by signature parameters or StoreKit configuration?

We are currently using App Store Server Notifications V2 in a production environment, but occasionally encounter the error "Failed to parse signedTransactionInfo in the notification payload. status=VERIFICATION_FAILURE." What could be the cause of this error? Also, is there a way to resolve this error? After the notification from Apple was received on the server side, it was passed to the Apple library and an error occurred in the Apple library when decryption was performed.

Hey guys, I am developing a habit tracker app right now. I know it's basic but it's my first app and I wanted an easy start but this is more of a struggle than I thought. So I am trying to publish my app fully on the App Store however everytime I do there is some kind of bug with it. But when I test it, it works perfect for me. Anyways, in this case the reviewer said when they go to the pro page of my app to purchase a pro subscription and try to press upgrade to pro nothing pops up. It pops up normally for me on my iPhone but not other devices. I wanted to make sure if this was normal or if there is something I am supposed to fix. Any help is appreciated. Thank you.

We’re encountering a problem with StoreKit in the sandbox environment. During an SKProductsRequest, some or all of the product identifiers provided are being returned in the invalidProductIdentifiers array of the SKProductsResponse, despite being valid and already approved. This behavior began occurring since last 2 days only and appears to be intermittent—in some cases, a product identifier that initially fails will succeed after one or two retries, without any changes on our end. What we've verified: All product identifiers are correctly configured and approved in App Store Connect. No recent changes have been made to our product configuration. The same product identifiers have previously worked without issue. We would appreciate any assistance in identifying the root cause of this behavior. Please also let us know if there is a known issue currently affecting StoreKit sandbox services. Thank you for your support.

Description of the Issue We are encountering issues with App Store Server Notifications, where the notification type received does not align with our expectations for subscription changes. Specifically, we receive DID_RENEW notifications in scenarios involving downgrades or intra-tier upgrades, which disrupts our backend subscription management logic and may lead to incorrect user subscription states and billing errors. Below are two reproducible scenarios with associated transaction data. Scenario 1: Downgrade from Premium Yearly (with 7-Day Trial) to Standard Yearly Steps to Reproduce: A user purchases the Premium Yearly subscription with a 7-day free trial (initial transaction ID: 700002116066502). On the day before the trial ends, the user downgrades to the Standard Yearly subscription via the App Store’s subscription management interface. Expected Behavior: We expect to receive a DID_CHANGE_RENEWAL_STATUS or a similar downgrade notification (e.g., DID_CHANGE_RENEWAL_PREF) to indicate the subscription plan has been downgraded, enabling immediate updates to the user’s subscription status. Actual Behavior: Upon downgrade, our server receives a DID_RENEW notification instead of a downgrade-specific notification. This causes our system to incorrectly interpret the action as a renewal of the Premium subscription rather than a downgrade to Standard, with no subsequent downgrade confirmation received. Relevant Transaction Data: New Transaction ID: 700002122810952 Notification Type: DID_RENEW Notification UUID: 26de9b0e-5d61-4893-b679-0bd18ae3d208 Original Transaction ID (Trial): 700002116066502 Scenario 2: Intra-Tier Upgrade from Standard Monthly to Standard Yearly Steps to Reproduce: A user purchases the Standard Monthly subscription. On the day before the monthly subscription expires, the user switches to the Standard Yearly subscription via the App Store’s subscription management interface. Expected Behavior: The original Monthly subscription expires normally, with a DID_EXPIRE notification received. Upon expiration, we expect a DID_RENEW or SUBSCRIBED notification for the new Yearly subscription to confirm its activation, allowing seamless transition of the user’s subscription plan. Actual Behavior: Immediately after the upgrade, our server receives a DID_RENEW notification for the new Yearly plan. No further notifications are received, including no DID_EXPIRE for the original Monthly subscription. This leaves our system unable to confirm the expiration of the Monthly plan, potentially resulting in duplicate active subscriptions in our records. Relevant Transaction Data: Transaction ID: 70002902074491 Notification Type: DID_RENEW Notification UUID: 3d35bc2f-e769-4549-bf50-d84d41b10342 Impact These notification discrepancies disrupt our subscription lifecycle management, potentially causing incorrect user entitlements, over-billing, and a degraded user experience. Requested Assistance Please confirm the correct notification types for these scenarios as per Apple’s documentation (e.g., App Store Server Notifications V2). Provide guidance on handling these edge cases, including any recent changes to notification logic. If this is a backend issue, please investigate the provided transaction IDs and Notification UUIDs. Thank you for your prompt assistance. We look forward to your response to help resolve this issue for our users. 问题描述： 我们在处理 App Store 订阅变更通知时发现，服务器接收到的通知类型与预期不符，具体表现为降级或同级升级场景下错误接收到 DID_RENEW 通知。这影响了我们后端订阅管理的逻辑，可能导致用户订阅状态和计费出现偏差。以下是两个可重现的场景及相关交易数据。 场景 1：高级年费（含 7 天试用）降级至标准年费 重现步骤： 用户购买高级年费订阅并开启 7 天免费试用（初始交易 ID：700002116066502）。 在试用期结束前一天，用户通过 App Store 的订阅管理界面降级至标准年费订阅。 预期行为： 我们预期会收到 DID_CHANGE_RENEWAL_STATUS 或类似的降级通知（如 DID_CHANGE_RENEWAL_PREF），以表明订阅计划已降级，从而允许我们立即更新用户订阅状态。 实际行为： 降级后，服务器立即收到 DID_RENEW 通知，而非降级相关通知。这导致系统误认为高级订阅仍在续订，而非降级为标准订阅，且后续未收到任何降级确认通知。 相关交易数据： 新交易 ID：700002122810952 通知类型：DID_RENEW 通知 UUID：26de9b0e-5d61-4893-b679-0bd18ae3d208 原始交易 ID（试用）：700002116066502 场景 2：标准月费订阅升级为标准年费订阅 重现步骤： 用户购买标准月费订阅。 在月费订阅到期前一天，用户通过 App Store 的订阅管理界面切换至标准年费订阅。 预期行为： 原月费订阅正常到期，预期收到 DID_EXPIRE 通知。 月费到期后，预期收到新年费订阅的 DID_RENEW 或 SUBSCRIBED 通知，以确认年费订阅开始，方便我们无缝切换用户订阅计划。 实际行为： 升级后，服务器立即收到新年费订阅的 DID_RENEW 通知。 后续未收到任何通知，包括原月费订阅的 DID_EXPIRE 通知。这导致我们无法确认月费订阅的到期状态，可能在记录中出现重复的活跃订阅。 相关交易数据： 交易 ID：70002902074491 通知类型：DID_RENEW 通知 UUID：3d35bc2f-e769-4549-bf50-d84d41b10342 影响： 这些通知异常干扰了我们的订阅生命周期管理，可能导致用户权益错误、潜在的重复计费以及用户体验下降。 请求协助： 请确认根据 Apple 文档（例如 App Store Server Notifications V2）在上述场景中应返回的正确通知类型。 请提供处理此类边缘场景的指导，包括通知逻辑的任何最新变更。 如果这是后端问题，请调查提供的交易 ID 和通知 UUID。 感谢您的及时协助，期待您的回复以帮助我们为用户解决问题。

Over the past two days, we've observed an unusual spike in requests from some iOS users to our server endpoint responsible for verifying App Store purchase receipts. After sampling and analyzing the data, we found that the cause is related to the behavior of StoreKit2.Transaction.updates. Specifically, when listening for transaction updates, the system returns a large number of historical transactions — some dating back as far as one year. These callbacks are interpreted as "new" transactions, which in turn trigger repeated calls to Apple’s receipt verification servers, leading to an abnormal surge in traffic and putting pressure on our backend services. This behavior is ongoing and is something we've never encountered in our previous experience. It appears to be outside of expected behavior, and we suspect it may be due to some kind of abnormality or unintended usage scenario. We would appreciate guidance on the following: Is this a known behavior or issue with StoreKit2? Are there specific device states or conditions that could cause the system to emit historical transactions in bulk? Are there any recommended practices for mitigating or filtering such transaction floods? We have attached logs for reference. Any help identifying the root cause or suggestions for investigation would be greatly appreciated. 2025-07-24 12:39:58.594 +0400 listenForTransactions :{ "appTransactionId" : "704289572311513293", "environment" : "Production", "inAppOwnershipType" : "PURCHASED", "originalPurchaseDate" : 1713445834000, "originalTransactionId" : "430001791317037", "purchaseDate" : 1713445834000, "quantity" : 1, "signedDate" : 1753346396278, "storefrontId" : "143481", } 2025-07-24 12:39:58.594 +0400 listenForTransactions :{ "appTransactionId" : "704289572311513293", "deviceVerificationNonce" : "c4f79de2-a027-4b34-b777-6851f83f7e64", "environment" : "Production", "inAppOwnershipType" : "PURCHASED", "originalPurchaseDate" : 1713445849000, "originalTransactionId" : "430001791317270", "purchaseDate" : 1713445849000, "quantity" : 1, "signedDate" : 1753346396278, "storefrontId" : "143481", "transactionId" : "430001791317270", } 2025-07-24 12:39:58.594 +0400 listenForTransactions :{ "appTransactionId" : "704289572311513293", "deviceVerificationNonce" : "02f305d7-0b2d-4d55-b427-192e61b99024", "environment" : "Production", "inAppOwnershipType" : "PURCHASED", "originalPurchaseDate" : 1713511999000, "originalTransactionId" : "430001792218708", "purchaseDate" : 1713511999000, "quantity" : 1, "signedDate" : 1753346396278, "storefrontId" : "143481", "transactionId" : "430001792218708", } 2025-07-24 12:39:58.598 +0400 [INFO] [MKPaymentService:23]: [XLPay] listenForTransactions :{ "appTransactionId" : "704289572311513293", "deviceVerificationNonce" : "5ca85907-1ab6-4160-828e-8ab6d3574d6f", "environment" : "Production", "inAppOwnershipType" : "PURCHASED", "originalPurchaseDate" : 1713512034000, "originalTransactionId" : "430001792219189", "purchaseDate" : 1713512034000, "quantity" : 1, "signedDate" : 1753346396278, "storefrontId" : "143481", "transactionId" : "430001792219189", } 2025-07-24 12:39:58.599 +0400 listenForTransactions :{ "appTransactionId" : "704289572311513293", "deviceVerificationNonce" : "04869b50-b181-4b69-b4ff-025175e9cf14", "environment" : "Production", "inAppOwnershipType" : "PURCHASED", "originalPurchaseDate" : 1713512049000, "originalTransactionId" : "430001792219440", "purchaseDate" : 1713512049000, "quantity" : 1, "signedDate" : 1753346396278, "storefrontId" : "143481", "transactionId" : "430001792219440", }

We are seeing an issue with a potential duplicate charge issue regarding our app. We have received two transactions with the same originalTransactionId but different transactionIds: Order A: TransactionId: [Redacted_TID_1] OriginalTransactionId: [Redacted_OID_A] ProductId: weekly_subscription PurchaseDate: [Redacted_Timestamp_1] SignedDate: [Redacted_Timestamp_2] Price: [Redacted_Price] CAD Order B: TransactionId: [Redacted_TID_2] OriginalTransactionId: [Redacted_OID_A] ProductId: weekly_subscription PurchaseDate: [Redacted_Timestamp_1] SignedDate: [Redacted_Timestamp_3] Price: [Redacted_Price] CAD Both transactions share the same originalTransactionId, productId, and expiresDate, but the transactionIds are different. We wanna confirm: Were customers charged once or twice for this subscription renewal? If only one charge was made, how should we programmatically determine the “valid” transaction among multiple records with the same originalTransactionId to avoid confusion in our server-side receipt validation? We appreciate any clarification so we can handle this correctly in our backend.

Hello, Is anyone else seeing Purchase.PurchaseResult.UserCancelled, despite a successful transaction? I had a user notify me today that he: Attempted a purchase Entered payment credentials Was asked to opt in to email subscription notifications Opted In Was shown my app's "User Canceled Purchase" UI Attempted to repurchase Was alerted that he was "Already Subscribed" I have adjusted my code to check Transaction.currentEntitlements on receiving a .userCancelled result, to avoid this in the future. Is this logically sound? Here is my code - please let me know if you see any issues: func purchase(product: Product, userId: String) async throws -> StoreKit.Transaction { let purchaseUUID = UUID() let options: Set<Product.PurchaseOption> = [.appAccountToken(purchaseUUID)] let result = try await product.purchase(options: options) switch result { case .success(let verification): guard case .verified(let tx) = verification else { throw PurchaseError.verificationFailed // Show Error UI } return try await processVerified(tx) case .userCancelled: for await result in Transaction.currentEntitlements { if case .verified(let tx) = result, tx.productID == product.id, tx.revocationDate == nil { return try await processVerified(tx) } } throw PurchaseError.cancelled // Show User Cancelled UI case .pending: throw PurchaseError.pending // Show Pending UI @unknown default: throw PurchaseError.unknown // Show Error UI } } @MainActor func processVerified(_ transaction: StoreKit.Transaction) async throws -> StoreKit.Transaction { let id = String(transaction.id) if await transactionCache.contains(id) { await transaction.finish() return transaction // Show Success UI } let (ok, error) = await notifyServer(transaction) guard ok else { throw error ?? PurchaseError.serverFailure(nil) // Show Error UI } await transaction.finish() await transactionCache.insert(id) return transaction // Show Success UI } The only place the "User Cancelled Purchase" UI is displayed on my app is after the one instance of "throw PurchaseError.cancelled" above. This happened in Production, but I have also seen userCancelled happen unexpectedly in Sandbox. Thank you for your time and help.

A purchase can result in success with verificationResult .unverified. Is there a list of reasons for which the transaction might be unverified and how should i handle it in my app? From my understanding, a successful unverified transaction means the user has already paid for the purchase. So, do i just ignore the unverified transaction or do i provide content to the user anyways?

Issue Description When using the App Store Server API endpoint GET v2/history/{transactionId} to retrieve transaction history for a specific transaction, I'm observing unexpected changes in the appTransactionId field across related transactions in the same subscription group. Important Context: This is a "clean" auto-renewable subscription with no user intervention - the user has had continuous auto-renewals without any upgrades, downgrades, cancellations, or resubscriptions. The subscription has been renewing automatically and successfully throughout the entire period. API Call GET v2/history/1000000000000001 Response Data The API returns the following transaction history, where I notice the appTransactionId values are inconsistent across what should be a straightforward auto-renewal sequence: Note: The data below has been sanitized for privacy protection (IDs, bundle identifiers, etc. have been replaced with example values), but the logical relationships, date sequences, and the core issue remain identical to the original data. Array ( [0] => Array ( [transactionId] => 1000000000000001 [originalTransactionId] => 1000000000000001 [webOrderLineItemId] => 1000000000000001 [bundleId] => com.example.myapp [productId] => MonthlySubscription [subscriptionGroupIdentifier] => 20000000 [purchaseDate] => 1743784032000 [originalPurchaseDate] => 1743784034000 [expiresDate] => 1746376032000 [quantity] => 1 [type] => Auto-Renewable Subscription [inAppOwnershipType] => PURCHASED [signedDate] => 1751868174651 [environment] => Production [transactionReason] => PURCHASE // Original purchase [storefront] => USA [storefrontId] => 143441 [price] => 100000 [currency] => USD [appTransactionId] => 700000000000000001 // Different value ) [1] => Array ( [transactionId] => 1000000000000002 [originalTransactionId] => 1000000000000001 [webOrderLineItemId] => 1000000000000002 [bundleId] => com.example.myapp [productId] => MonthlySubscription [subscriptionGroupIdentifier] => 20000000 [purchaseDate] => 1746376032000 [originalPurchaseDate] => 1746347349000 [expiresDate] => 1749054432000 [quantity] => 1 [type] => Auto-Renewable Subscription [inAppOwnershipType] => PURCHASED [signedDate] => 1751868174651 [environment] => Production [transactionReason] => RENEWAL // First auto-renewal [storefront] => USA [storefrontId] => 143441 [price] => 100000 [currency] => USD [appTransactionId] => 700000000000000002 // Same for renewals ) [2] => Array ( [transactionId] => 1000000000000003 [originalTransactionId] => 1000000000000001 [webOrderLineItemId] => 1000000000000003 [bundleId] => com.example.myapp [productId] => MonthlySubscription [subscriptionGroupIdentifier] => 20000000 [purchaseDate] => 1749054432000 [originalPurchaseDate] => 1749025657000 [expiresDate] => 1751646432000 [quantity] => 1 [type] => Auto-Renewable Subscription [inAppOwnershipType] => PURCHASED [signedDate] => 1751868174651 [environment] => Production [transactionReason] => RENEWAL // Second auto-renewal [storefront] => USA [storefrontId] => 143441 [price] => 100000 [currency] => USD [appTransactionId] => 700000000000000002 // Same as previous renewal ) [3] => Array ( [transactionId] => 1000000000000004 [originalTransactionId] => 1000000000000001 [webOrderLineItemId] => 1000000000000004 [bundleId] => com.example.myapp [productId] => MonthlySubscription [subscriptionGroupIdentifier] => 20000000 [purchaseDate] => 1751646432000 [originalPurchaseDate] => 1751617840000 [expiresDate] => 1754324832000 [quantity] => 1 [type] => Auto-Renewable Subscription [inAppOwnershipType] => PURCHASED [signedDate] => 1751868174651 [environment] => Production [transactionReason] => RENEWAL // Third auto-renewal [storefront] => USA [storefrontId] => 143441 [price] => 100000 [currency] => USD [appTransactionId] => 700000000000000002 // Same as previous renewals ) ) Questions Is this behavior expected? Should the appTransactionId change between the original purchase and subsequent renewals within the same subscription group, especially when there are no user actions (upgrades/downgrades/cancellations/resubscriptions)? What determines the appTransactionId value? The documentation doesn't clearly explain when this identifier might change or what triggers a new value. This is particularly puzzling since this is a straightforward auto-renewal scenario. How should we handle this in our backend logic? Should we treat transactions with different appTransactionId values as separate entities, or should we rely on originalTransactionId for grouping related subscription transactions? Is this a known issue? We've seen similar concerns in the community regarding transaction ID inconsistencies, but this specific case involves a clean auto-renewal flow without any complicating factors.

I set both production and sandbox App Store Notification server. In sandbox, my server can receive all kinds of app store notification, including subscription and non-consumable in-app-purchase. But in production, my server only receive subscription notification. I can see some non-consumable in-app-purchase done in log, but the server didn't receive expected notification. Anyone know why? I really need the notification cause I need to know who made refund.

We are running into exceptions when trying to parse Purchase Date and Original Purchase Date from the base64 encoded receipt. Expected RFC 3339 format of ASN.1 Field Value is: yyyy-MM-ddTHH:mm:ssZ but we end up getting back 2025-04-22T19.49.03Z. Started to happen on 3rd Dec 2024.