Hi all, We’re implementing in-app subscriptions in our iOS app using App Store Server Notifications V2 in the production environment. Everything is generally working well — we receive notifications such as DID_CHANGE_RENEWAL_STATUS, CANCELLATION, etc., and we log all incoming notifications into our own database. However, we've encountered a single case where the INITIAL_BUY notification was not received for a specific user. Interestingly, we did receive the later notifications (DID_CHANGE_RENEWAL_STATUS and CANCELLATION) for that same user. Here is our setup: App Store Server Notifications V2 Notification endpoint is stable and functioning normally (receives and logs other notifications) Notifications are reliably stored in our database The issue occurred only once for one user Environment: Production We've already contacted Apple Developer Support, but were informed that this issue is out of scope for direct support, and were directed to the Developer Forums. Our questions: Under what conditions might the INITIAL_BUY notification fail to be sent or delivered? Is there any known behavior or scenario where Apple may skip the INITIAL_BUY notification? Any recommendations on how to further investigate or verify whether it was sent from Apple’s side? We’ve confirmed that the notification never hit our server (no logs, no DB record), and our system was healthy at the time. Any insight would be greatly appreciated. Thank you!

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

i'm integrating In-App Purchases in our Flutter app using the official in_app_purchase plugin. We are currently testing consumable purchases and facing issues with the way events are delivered from StoreKit to the app. Implementation details I initiate the purchase with: await InAppPurchase.instance.buyConsumable(purchaseParam: purchaseParam); I listen for purchase updates with: final Stream<List> purchaseUpdated = inAppPurchase.purchaseStream; _subscription = purchaseUpdated.listen((purchaseDetailsList) { _handlePurchaseUpdates(purchaseDetailsList); }, onError: (Object error) { updateApplePaymentStatus(isSuccess: false, response: jsonEncode(error.toString())); }, onDone: () { _subscription.cancel(); }); Issues Observed Control on purchase button event As soon as the user taps the purchase button, the App Store purchase sheet is shown. Question: Is there a way to intercept control at this point (before showing the sheet) to perform additional checks or logging? Cancelled payment after UPI intent In our testing with UPI payment flows (UPI intent triggered from Apple Pay/linked payment method), if the user cancels the payment from the external flow, we don’t see a clear event in purchaseStream. Question: How can we reliably capture this cancellation status on the app side? Event timing after successful purchase Currently, the purchaseStream event is only triggered after the StoreKit purchase confirmation popup has been dismissed by the user. Question: Is there a way to capture the event earlier (i.e., right after StoreKit confirms payment success), so we can update our backend and UI without waiting for popup dismissal? Request We would appreciate guidance on: Best practices for intercepting purchase initiation before the StoreKit sheet. Recommended way to detect and handle cancelled payments (especially in UPI flows) managed on frondend side. Whether it is possible to receive successful purchase events without waiting for the user to dismiss the confirmation dialog. Thank you for your support.

Withouth authorization Bearer token: public static JWKSet getApplePublicKeys(String token) throws Exception { URL url = new URL("https://api.storekit.itunes.apple.com/inApps/v1/jwsPublicKeys"); HttpURLConnection conn = (HttpURLConnection) url.openConnection(); conn.setRequestMethod("GET"); conn.setRequestProperty("Accept", "application/json"); int status = conn.getResponseCode(); InputStream stream = (status >= 200 && status < 300) ? conn.getInputStream() : conn.getErrorStream(); String body = new BufferedReader(new InputStreamReader(stream)) .lines() .reduce("", (acc, line) -> acc + line); System.out.println("HTTP " + status + ": " + body); // load JWKSet from JSON string try (InputStream in = new ByteArrayInputStream(body.getBytes(StandardCharsets.UTF_8))) { return JWKSet.load(in); } } With authorization Bearer token: public static JWKSet getApplePublicKeys(String token) throws Exception { URL url = new URL("https://api.storekit.itunes.apple.com/inApps/v1/jwsPublicKeys"); HttpURLConnection conn = (HttpURLConnection) url.openConnection(); conn.setRequestMethod("GET"); conn.setRequestProperty("Accept", "application/json"); conn.setRequestProperty("Authorization", "Bearer "); int status = conn.getResponseCode(); InputStream stream = (status >= 200 && status < 300) ? conn.getInputStream() : conn.getErrorStream(); String body = new BufferedReader(new InputStreamReader(stream)) .lines() .reduce("", (acc, line) -> acc + line); System.out.println("HTTP " + status + ": " + body); // load JWKSet from JSON string try (InputStream in = new ByteArrayInputStream(body.getBytes(StandardCharsets.UTF_8))) { return JWKSet.load(in); } } Below is the my production and sandbox URls: Sandbox: https://api.storekit-sandbox.itunes.apple.com/inApps/v1/jwsPublicKeys Production: https://api.storekit.itunes.apple.com/inApps/v1/jwsPublicKeys Kindly help me with this. If I am doing anything wrong, please let me know. I tried using the token in the URL, and it gives me a 404. If I hit the endpoint without the token, it returns a 401. Please assist me.

I am developing a Flutter app for food delivery (a multivendor e-commerce restaurant app). In the vendor app (Android), I successfully implemented a background notification that stays active until the vendor responds with either Accept or Decline. This works fine on Android, but I cannot get the same functionality working on iOS. My requirements: Vendor should receive a background notification. The notification should include action buttons (Accept / Decline). It should remain active until the vendor takes action. My questions: Is this possible to implement in iOS with Flutter? If yes, what is the recommended way (e.g., firebase_messaging, flutter_local_notifications, flutter_foreground_task, or native iOS integration)? Are there any iOS restrictions I should consider compared to Android background services? I built this for Android using firebase_messaging + flutter_foreground_task + flutter_local_notifications. On iOS, I tried setting up firebase_messaging and flutter_local_notifications, but I’m unable to keep the notification persistent with Accept/Decline action buttons. I expected similar behavior to Android, but it seems iOS has more restrictions around background services and notification handling. Dependencies I am using (relevant ones): firebase_core: ^3.8.0 firebase_messaging: ^15.1.5 flutter_local_notifications: ^17.2.2 flutter_foreground_task: ^8.17.0 get: ^4.7.2 shared_preferences: ^2.3.2

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.

I’m reaching out regarding our existing in-app subscription implementation that currently uses App Store Server Notifications version 1 (v1). Our live application has a significant number of active recurring subscriptions that are being managed through the v1 webhook integration. We have now developed a revamped version of our application, which uses the same Apple Developer Account and App Store Connect setup, but in this new app version, we’ve implemented App Store Server Notifications version 2 (v2). Before moving forward with the migration, I would like to clarify the following points to ensure a smooth transition and avoid any disruptions to ongoing subscriptions: Backward Compatibility: Will existing active subscriptions (originally created and managed via v1 notifications) continue to work seamlessly once we switch to v2, or do we need to maintain both v1 and v2 endpoints during the transition? Notification Delivery: If both webhook versions are configured simultaneously, will Apple send notifications to both endpoints, or only the one currently configured in App Store Connect? Migration Strategy: What is Apple’s recommended best practice for migrating from v1 to v2 in a scenario where the live app still has active subscriptions tied to the v1 webhook? Potential Risks or Considerations: Are there any known limitations, delays, or issues that we should prepare for during this migration (for example, differences in payload structure or event types between v1 and v2 that could affect subscription lifecycle management)? I would greatly appreciate your guidance or documentation links that outline the correct migration steps and recommended approach for ensuring continuity of service for all existing subscribers.

I’m implementing App Store subscriptions using StoreKit 2 and testing in the Sandbox environment. Until about a week ago everything worked fine, but recently the Settings > Subscriptions screen shows this message for my test account: “Your current payment method is not available.” The behavior: • Using a Sandbox tester account (not a production Apple ID) • Purchase flow works successfully — the transaction completes, and I receive server notifications • However, the system Settings app still displays that message under the subscription entry • No code changes were made since it last worked Questions: 1. What exactly does this message mean in the Sandbox environment? 2. Could this be related to any Apple system issue or recent backend update? 3. Has anyone else seen the same behavior in recent days? Environment: • Xcode 15.4 • iOS 17.5 (physical device) • StoreKit 2 / Swift 5.10 • Sandbox tester (Japan region) Thanks in advance for any insights or confirmations from others who are testing subscriptions in Sandbox!

Hey! We're implementing In-App Purchase Subscriptions and we were able to receive "App Store Server Notifications" on our "Sandbox Server URL". But the last event we received 22 hours ago. We are able to verify transactions and finish them, but receive no webhooks. We changed nothing on our server or its configurations but the notifications stoped to come. We consulted the API (https://api.storekit-sandbox.itunes.apple.com/inApps/v1/notifications/history) and it says the same as we see - the last event was 22hrs ago. I checked all the advices from here as well (https://developer.apple.com/forums/thread/805806?answerId=864483022#864483022). Is there any Status page for the Store Kit Sandbox services? Was there any outage? Sincerely, Konstantin

Hi Team, We are building oru subscrption app and want to rely on server side purchase / subscription related notifications. We went through https://developer.apple.com/documentation/appstoreservernotifications/enabling-app-store-server-notifications We wanted to understand the reliability and latency for server side notifciations provided by Appstore.

We are in the process of preparing our app to support the new Texas law (SB2420) that takes effect 1/1/2026. After reviewing Apple's recent announcements​/docs concerning this subject, one thing isn't clear to me: how to associate an app install with a​n App Store Server RESCIND_CONSENT notification​ that could be delivered to our server. Our app is totally free so there isn't an originalTransactionId​ or other similar transaction IDs that would be generated as part of an in-app purchase (and then subsequently sent as part of the payload in the notification to our server during an in-app purchase scenario). So my question is: How do I associate an app (free app) install with an App Store Server RESCIND_CONSENT notification​ that is sent to our server​?

I’m updating a legacy application that used Apple Pay v1 token format, and in my new revamped version I’m now receiving the newer Apple Pay v2 format. The old (v1) payload looked like this: php { "version": "EC_v1", "data": "...", "signature": "...", "header": { "ephemeralPublicKey": "...", "publicKeyHash": "...", "transactionId": "..." } } In the new revamp (v2), Apple Pay returns this instead: php { "signedTransactionInfo": "eyJhbGciOiJFUzI1NiIsIng1YyI6WyJNSUlF..." } From what I understand: v1 tokens were elliptic-curve encrypted JSON objects containing a header and signature. v2 tokens seem to be JWS (JSON Web Signature) strings using the ES256 algorithm, possibly containing transaction and subscription details inside. Questions Is there any official Apple documentation or migration note explaining the move from EC_v1 → signedTransactionInfo? How should I verify or decode the new signedTransactionInfo payload? Should the verification now use Apple’s public keys instead of the legacy Merchant ID certificate? Are there any example implementations or SDKs that can handle both v1 and v2 formats during migration? Is there a recommended way to maintain backward compatibility while transitioning existing users? Goal Ensure that my revamped app can handle Apple Pay v2 tokens securely while keeping the legacy v1 integration functional until all users are migrated.

I'm an app developer, and I recently launched a monthly subscription product in my app on the App Store. However, I'm having trouble understanding the App Store's renewal date calculation policy. According to the official documentation, if a subscription is purchased on December 1st, the next renewal date should be January 1st. But the expiresDate is set to December 31st instead. At first, I thought this might be a timezone issue, but even after it became December 1st in UTC, the renewal date was still set to December 31st. Is the timezone used to calculate renewal dates not UTC+0? Or is there documentation on the renewal cycle policy that I might have missed? Any clarification would be greatly appreciated. Thanks in advance!

Hello — quick question about App Store Server Notifications migration. We have a live app using Production V1 notifications for recurring in-app subscriptions. We plan to switch the Production webhook to V2. After the switch: Will notifications for existing subscriptions be delivered in V1 format, V2 format, or will it depend (e.g., queued V1 retries vs new V2 deliveries)? If V1 retries are queued, how long should we expect overlap/retries to continue? Any recommended cutover best practices (support both formats, revert process, etc.)? Happy to share additional details. Thanks.

Dear App Store Engineering Team, I am writing to request official confirmation regarding the behavior of App Store Server Notifications when migrating a live application from V1 to V2. Context: Our application has been live since 2008 and currently utilizes App Store Server Notifications V1. We have a large database of existing legacy subscribers. We are preparing to switch our Production environment setting in App Store Connect from "Version 1" to "Version 2". Our Questions: When we change the setting in App Store Connect to Version 2: Global Format Switch: Does this setting apply immediately to ALL notifications, including those triggered by subscriptions that originated years ago (legacy users)? Payload Consistency: Will renewals for existing legacy subscriptions continue to arrive in the JSON V1 format, or will they immediately start arriving in the V2 JWS (signedPayload) format? Our expectation is that the switch is global and all future notifications (regardless of subscription age) will be sent as V2 JWS payloads, but we require official confirmation to ensure our backend handles the migration without service interruption. Thank you for your assistance.

Hello, We have completed the Age Rating confirmation form and submitted it successfully. Additionally, we increased the app version, rebuilt, and uploaded a new build as recommended. However, we still received the email stating that “Your app requires additional information”. Could you please confirm whether any further action is required on our side, or if this is a known issue on App Store Connect? Thank you.

Scenario User is actively subscribed to Monthly Package From the Device App (Manage Subscriptions), user upgrades to Yearly Package Purchase completes successfully on device Issue Do not receive any server notification for this action Month Package Purchase Date: 2025-11-11 19:06:45.537 +0600 Month to Yearly Upgradation Date: 2025-12-11 paymentReferenceId: 510002270528780

Hi all, I'm encountering an issue with auto-renewable subscription upgrades in the App Store. Here's my setup: Context: Plan A: Base Plan (yearly auto-renewable subscription) Plan B: Pro Plan (monthly auto-renewable subscription) B is configured as an upgrade from A. Issue: When a user with an active Plan A subscription upgrades to Plan B, I correctly receive an App Store Server Notification v2 with DID_CHANGE_RENEWAL_PREF and UPGRADE subtype. According to Apple's documentation, a prorated refund is issued automatically in this scenario, and no separate REFUND event is sent, the refund information should be retrievable through the upgrade event itself. Testing in Sandbox: In my sandbox tests, Plan A has a 1-hour duration and Plan B has a 5-minute duration. After the user upgrades to Plan B, I immediately cancel the subscription to prevent auto-renewal. Expected vs. Actual Behavior: After the 5 minutes expire, Plan A still appears as the active current entitlement. I initially thought this might be because the prorated refund hadn't been processed yet. However, even after waiting the full hour (the original duration of Plan A), it continues to show as an active entitlement—which shouldn't be the case. As a result, when I attempt to restore purchases, Plan A is still identified as valid and the subscription gets reactivated. Question: Is this behavior expected in the sandbox environment, or am I missing something in how the prorated refund and entitlement expiration should be handled?

Hi everyone. I'm trying to use https://developer.apple.com/documentation/appstoreserverapi/get-transaction-info to retrieve order information. How can I get the refund status of an order through this API? Also, Apple's webhook notification for refunds includes fields like revocationReason and revocationType. Can these be retrieved through the API? I've noticed that some refund orders have these fields when retrieved using get-transaction-info api, but others don't. I don't know the reason for these differences. Could you please explain? Thank you very much.

I am currently testing the Declared Age Range / Parental Consent flow in the Sandbox environment, and I am experiencing an issue where the RESCIND_CONSENT App Store Server Notification is not being delivered to my server. 🔍 Test Environment iOS version: iOS 26.2 (Sandbox environment) App Store Server Notifications: Sandbox environment 🔄 Test Scenario App Settings > Developer > Sign in with a Sandbox account Launch the app In App Settings > Developer > Sandbox Account > Management > Revoke App Consent, enter the app’s Bundle ID, tap the Revoke Consent button, and confirm that the revocation completion popup message is displayed Check whether App Store Server Notifications are received by the server Confirm that the RESCIND_CONSENT notification is not received by the server ✅ Expected Result The App Store Server sends a RESCIND_CONSENT notification to the Sandbox endpoint The notification payload includes appTransactionId The server can block app access based on the corresponding appTransactionId ❌ Actual Result No RESCIND_CONSENT notification is received in the Sandbox environment ❓ Questions Is this behavior an intended limitation of the Sandbox environment, or is it a known issue or bug? Is it possible that RESCIND_CONSENT notifications will only be delivered starting January 1, 2026? Additionally, when a RESCIND_CONSENT server notification is received, I currently update my database with the appTransactionId and the registration date. When a minor attempts to access the app, I check the latest appTransactionId status, and if the most recent state indicates consent has been revoked, I block app access and prompt the user to request parental consent again using PermissionKit.