Feedback: FB25016556 (includes sysdiagnose and device log archives) Since our Apple Developer Program membership lapsed on Sep 26, 2026 (renewed Sep 27), Product.products(for:) returns an empty array for every In-App Purchase of our app, in both production and sandbox. No error is thrown. Customers can't subscribe. App: bundle ID com.thefuntasty.gastromapa, live version 2.2.1 (worked fine until Sep 26, no code changes since). Products (both Approved, available in all countries, priced, localized): com.thefuntasty.gastromapa.subscription.premium (auto-renewable) com.thefuntasty.gastromapa.donation (non-consumable) Verified against TN3186 / TN3188: Membership active, latest Program License Agreement accepted (Account Holder checked) Paid Apps Agreement Active (effective Sep 29, 2026), nothing left to sign Bank account and tax forms Active Product IDs and bundle ID match the app record, In-App Purchase capability enabled on the explicit App ID Sandbox test build signed with a freshly regenerated development profile Apple Developer Support (phone) confirmed account, agreements and products look correct and referred us here storekitd log, identical in production and sandbox: Requesting Media API product batch ["com.thefuntasty.gastromapa.subscription.premium"] ... response_status=200 Media request MediaAPIProductRequest correlation key: KKP646ABIQJTWR5GGC3UBLBJDU Ignoring empty product response Correlation keys: Oct 1, 2026, 14:15 CEST, production, iOS 27.0.1 (24A446): KKP646ABIQJTWR5GGC3UBLBJDU Sep 30, 2026, 15:30 CEST, production, iOS 27.0: 3VRU2QHLFRRMP2UBTYG4ZSIBPQ Sep 30, 2026, 15:45 and 15:51 CEST, sandbox: VF6Y3XNFTZXPBRKX6VCKSJNB3U, V7Q3K5JTJ46PB6D2HGKCY5RINU This looks similar to https://developer.apple.com/forums/thread/845526. Could someone from Apple check whether our In-App Purchases were deactivated in the store catalogue when the agreement expired, and reactivate them? It's blocking all revenue for the app.

I'm trying to submit my app version together with two auto-renewable subscriptions (both in the same subscription group), and one of the two subscriptions will not submit, while the other submits with no issue. Setup One subscription group ("Crucibull Pro") with two subscriptions: Annual — $49.99/year — submits fine Weekly — $1.99/week — fails to submit Both are being submitted together with a new app build in a single review submission. The errors I get (they vary, none are field-specific) "There are errors with one or more of your items. To fix them, you need to remove the items and add them again to your submission." "Sorry, something went wrong. Try your request again." "An unexpected error was encountered when submitting for review. If the issue persists please contact us." Critically, there is no red/field-level error anywhere on the Weekly subscription's page — its status is "Prepare for Submission" and every field is filled. What I've tried (nothing has worked) Verified every field on Weekly: reference name, product ID, 1-week duration, availability (all countries), price ($1.99 with a valid start date), localization (display name + description), tax category, and an App Review screenshot. Compared Weekly side-by-side with Annual (which submits fine) and matched every field. Changed Weekly's Tax Category to "Match to parent app" to match Annual. Removed and re-added the items to the submission (per the error message's advice) multiple times. Configured the subscription group ranking/levels. Deleted the original Weekly subscription and recreated it from scratch with a new Product ID — same result. Confirmed App Store Connect is stable (System Status all green) and still errors. Tried fresh submissions, different browser/incognito, and re-uploading the screenshot. Current state The Annual sub and the app build are ready and submit fine. The Weekly sub is fully configured, identical to Annual, freshly recreated, on a stable platform — and still throws generic submission errors with no indication of what's actually wrong. Question Has anyone seen an auto-renewable subscription that's fully configured (and identical to a working one in the same group) fail to submit with only generic errors and no field-level detail? Is there a known backend/propagation issue, or a hidden requirement I'm missing? Any way to see the actual validation failure? Thanks in advance.

Hello, Our first app submission has been in "Waiting for Review" since September 26, 2026 (5 days now). The submission includes the first app version, our first subscription group with 4 auto-renewable subscriptions, and 3 consumable in-app purchases. We have already contacted App Review through the Contact Us form (Case ID: 102980881885). The demo account in the Review Notes is ready and active. Is there anything we can do from our side to help the review move forward? Thank you.

Hi everyone, I’m stuck with some auto-renewable subscriptions in App Store Connect. I can’t submit them for review, remove them from the submission, or get them out of the “Ready for Review” state. I’m hoping someone has experienced this before. Here’s what happened: I submitted a new app with 4 auto-renewable subscriptions. The app was rejected because 2 of the subscriptions were not being used in the app. I removed those 2 subscriptions from the submission and submitted the app again. The app was eventually approved by Apple. However, I now have the following problem: The 2 subscriptions that were submitted and approved are showing an “Accepted” status instead of “Approved”, so they are not available in my app. The other 2 subscriptions that I removed from the submission are now stuck in “Ready for Review”. I cannot submit those subscriptions for review. I also tried creating new subscriptions, but I ran into the same issue. When I try to add them to the submission, App Store Connect shows this error: "There are errors with one or more of your items. To fix them, you need to remove the items and add them again to your submission." After that, the new subscriptions also become stuck in :Ready for Review", and the "Add for Review" button is disabled. At this point, I have no way to submit the subscriptions for review, which means I cannot get In-App Purchases working in my app. It seems like something may be wrong on the App Store Connect side. Has anyone experienced this issue before? If so, is there a workaround or anything I can do to resolve it? And if there is an Apple engineer or App Store Connect specialist here, I would really appreciate any help. Thanks!

This has happened before with a new app I build that involved subscriptions and it got stuck in a blackhole and i believe it could be a glitch on apples review system. I submitted a new app, the subscription wasnt fully included for review, the reviewer replied to me asking some questions and thiis is when i noticed the sub was not fully linked. So i linked it and now im worried its fallen into the same black hole as before as there has been no movement. Its just sitting waiting to be reviewed. Which is totally fine if the team are just backlogged but i dont want to wait a month or so before knowing this for sure as i cant afford that amount of wasted time. Its related to my WeatherLens app

Hello everyone, I am encountering a persistent date discrepancy between the subscription expiration date returned by the App Store Server API and the date displayed to the user in the native iOS Settings UI. Our app receives the renewal timestamp via the App Store Server Notifications in UTC milliseconds. For a recent transaction, we received renewalDate = 1820988823000, which is September 15, 2027, at 06:13 AM UTC. Following standard practices, our app formats this UTC timestamp to the user's local device timezone. On a device set to India Standard Time (IST, UTC+5:30), the app correctly displays the expiration as September 15. However, on the exact same device, navigating to iOS Settings > Apple ID > Subscriptions shows the expiration date as September 14. Converting 06:13 AM UTC to Pacific Time (PT) results in September 14 at 11:13 PM PDT. This leads me to suspect that the iOS Settings page anchors its display strictly to Cupertino/Pacific Time, completely bypassing the device's local timezone. I noticed another developer raised this exact issue regarding KST back in September 2025 (Thread ID: 800332), but that post remains unanswered. My questions for the community and Apple Engineers: Can anyone officially confirm if the native iOS Settings > Subscriptions screen intentionally displays dates anchored strictly to Pacific Time (PT) rather than the device's local timezone? If so, how are you handling user inquiries when your app correctly displays the local time, but Apple's UI displays the day prior? Any official references or guidance on this behavior would be greatly appreciated to help us clarify this for our QA teams and end-users.

I reached out to Apple Developer Support and they directed me to the forums. This video "Explore Retention Messaging in App Store Connect" shows a "Retention Messaging" section at the 3:21 timestamp of the video, within "Subscriptions" below the "Billing Grace Period" section. For the apps in our account, there is no "Retention Messaging" section available within the Subscriptions area. I am not asking about the API. I do not believe the API is required in order to have the Retention Messaging section show up in App Store Connect. In the video, the speaker says “I'll share an overview of Retention Messaging, and how to set it up in App Store Connect” and she shows how to navigate there. While she explains that “Real-time Retention Messaging is powered by the Retention Messaging API” - she also says that you can “create the same views using real-time Retention Messaging as you can when using retention messages in App Store Connect.” Is there something that we need to do in order to get access to this area of App Store Connect so we can set up Retention Messaging? Thank you so much.

Hello, I'm the developer of FOS Social (Apple ID: 6755471015), a creator-membership marketplace currently in TestFlight. I've submitted the Advanced Commerce API access request form twice and have not received any response, confirmation, or status update. My most recent submission has Request ID: UVQ7FUZVV3. Our use case: FOS Social is a social platform where viewers subscribe to individual content creators through independent auto-renewable monthly subscriptions across three tiers ($10 / $17 / $29). A single viewer must be able to hold concurrent active subscriptions to multiple creators at the same tier — for example, subscribed to Creator A at Gold and Creator B at Gold simultaneously. This matches Apple's stated eligibility model for the Advanced Commerce API: "exceptionally large catalogs of subscription content — apps that include frequently added content from multiple creators, where each creator's offering is merchandised as a single auto-renewable subscription." Why standard StoreKit doesn't work for us: We currently reuse one product ID per tier across all creators (e.g. com.fosssocial.creator.gold.monthly). When a viewer already subscribed to one creator at Gold tries to subscribe to a second creator at Gold, StoreKit returns "already subscribed" and treats it as a renewal rather than a new independent subscription. Pre-creating a separate subscription group per creator in App Store Connect is not feasible since our creator base is dynamic and growing. My questions: Is there any way to check the status of an Advanced Commerce API access request, or a typical response timeframe we should expect? Is there anything that commonly causes these requests to go unanswered (e.g. submission not made by the Account Holder, app still in TestFlight, missing information)? Is there a recommended escalation path when the request form has been submitted multiple times with no reply? I've also opened a support case (Case ID: 102934491974) but wanted to ask here as well in case anyone from the community or Apple has guidance. Thank you!

Hello, We are currently seeing errors when validating receipts for every auto-renewable subscription purchased through both StoreKit 1 and StoreKit 2. Details below. Case 1 — StoreKit 1 Calling https://buy.itunes.apple.com/verifyReceipt with the subscription receipt returns: "status": 21006, "expiration_intent": "5" Case 2 — StoreKit 2 Calling https://api.storekit.itunes.apple.com/inApps/v1/subscriptions and reading the most recent transaction (LastTransactionsItem) returns status 3. Within JWSRenewalInfoDecodedPayload: autoRenewStatus = 1, expirationIntent = 5 Timeline We believe renewals stopped processing for essentially all auto-renewing subscribers of our app as of 2026-09-18 09:30 KST (UTC+9). After resolving an agreement/licensing issue on our side, new purchases and some receipt validations recovered as of 2026-09-21 11:49 KST. However, most existing receipts still return expirationIntent = 5 when we query receipt validation or subscription status. Questions Is any action required on our side — a server-side change, a configuration change in App Store Connect, or a further review of our agreements? Now that the agreement issue is resolved, when are the renewals that were left pending during the outage expected to be processed? Any guidance would be appreciated. Thank you.

Hello everyone 👋 I’m an engineer and self-taught iOS developer. I recently published my app, Nexora AI, on the App Store. The app is designed to help students study smarter using AI-driven features like PDF analysis, instant problem solving, flashcard generation, and study/exam planning. As a solo developer, I’d love to gather feedback on UX/UI flow, performance, and general user experience from the community. If you have a moment to test it out or share any thoughts, I’d greatly appreciate it! 📲 App Store Link: https://apps.apple.com/tr/app/nexora-ai/id6770621015 Thanks for your time and feedback!

We have two unused, dormant subscription groups in our account ("Community Growth Tools 2" and "Community Growth Tools 3") that we cannot delete through either the App Store Connect UI or the App Store Connect API, and they keep causing our app version review to fail under a different guideline each time. Background: In September 2026 we originally designed three subscription tiers as three separate subscription groups. Per App Store Connect's rule that a first subscription must be submitted together with a new app version, all three were submitted for review together with an app version. We later made a business decision to consolidate to a single subscription product. Since we no longer needed the other two groups, we withdrew their items from a pending review submission ("Remove from Submission") instead of deleting the products outright. We did not realize this action has a permanent side effect. What we found: Both unused products now have exactly one entry in their /v1/subscriptions/{id}/versions history, with state DEVELOPER_REJECTED. Attempting to delete either the products or their groups returns: DELETE /v1/subscriptions/{id} -> 409 SUBSCRIPTION_DELETE_NOT_ALLOWED DELETE /v1/subscriptionGroups/{id} -> 409 ("There are active subscriptions in this group") There is no "Delete Subscription" option in the App Store Connect UI for either product (only "Remove from Sale", which we've already done - both show "Developer Removed From Sale"). We confirmed this isn't simply "nothing left to delete": both products still return full live metadata (product ID, pricing, review notes, screenshots) via the API. Group IDs: 22345382 ("Community Growth Tools 2"), 22345495 ("Community Growth Tools 3") Product IDs: com.jinyongpark.CodeChatApp.community_sub_monthly_2 / _3 App: CodeChat, Apple ID 6778284158 Impact: Every time we submit a new app version, App Store Connect appears to re-associate these two dormant groups with the review, even though we never include them as items in the review submission (confirmed via GET /v1/reviewSubmissions/{id}/items, which shows only the app version item). This has caused rejections citing the same root cause under different guidelines each time: Sept 16, 2026: Guideline 3.1.2(b) - "different subscription products should be tiers in one group, not separate groups" Sept 17, 2026: Guideline 2.1(b) - "Community Growth Plan (2)/(3) could not be found in the submitted binary" We already explained this via Resolution Center on Sept 16 and asked Apple to delete these two groups on our behalf, since we have no way to do so ourselves - that explanation does not appear to have carried over to the next review pass. We've also submitted a formal appeal and requested a Meet with Apple App Review consultation, but wanted to ask here as well in case anyone from the App Store Connect team can help directly - I found a similar case (forum thread 751843) where the App Review team was able to manually resolve a comparable stuck-subscription issue after being contacted here with the app name and Apple ID. Would appreciate any guidance on how to get these two orphaned, zero-purchase subscription groups removed or deactivated so they stop blocking our legitimate app version submissions.

To the Apple Review and Developer Support Teams, I am writing to request guidance and assistance regarding a persistent rejection my React Native application is facing under Guideline 2.1 - Performance (In-App Purchases). My app has been rejected multiple times with the following specific note: "The In-App Purchase products in the app still exhibited one or more bugs which create a poor user experience. Specifically, the subscription screen failed to load any subscription plans. Review the details and resources below to troubleshoot this issue." The screenshot provided by the review team shows a completely black screen where our paywall options are intended to populate, indicating that the product array is returning completely empty during the review process. The Dilemma: We are completely unable to reproduce this behavior on our end. Everything functions flawlessly within our TestFlight builds across multiple physical test devices and various sandbox tester accounts. On TestFlight, the paywall renders instantly, local pricing fetches immediately via SKProductsRequest, and test transactions process without a single error. Our Current Implementation & Verification: Product Status: All subscription products are explicitly marked as "Waiting for Review" in App Store Connect with one In-App product Rejected for not being attached with a bin but I've since submitted the app once again. All the subscriptions and the in-app product have been actively attached to this specific app submission version. Agreements: The Paid Apps Agreement is active, signed, and fully up to date within our Agreements, Tax, and Banking configurations. Identifiers: We have strictly verified that the hardcoded product identifiers in our React Native codebase match the App Store Connect product IDs exactly. Because this error only occurs within the App Review environment and never in TestFlight or local sandboxes, we are at a loss for how to debug or resolve this issue. Could the App Review team or the Developer Support technical team please clarify if there is a known environment mismatch, storefront routing discrepancy, or specific network configuration (such as IPv6 handling in the review sandbox) that would cause production-ready StoreKit products to return an empty array exclusively to the reviewer? Any direct guidance, logs, or steps on how we can successfully surface our plans to your review team would be deeply appreciated. Review Environment Submission ID: 5a35279c-1621-4972-b6c6-7c1fb202b2f0 Review date: May 20, 2026 Review Device: iPad Air 11-inch (M3) Version reviewed: 1.0.2 (8) Thank you for your time and assistance.

I’m unable to add several older In-App Purchases and auto-renewable subscriptions to an App Review submission in App Store Connect. The UI only shows: Unable to Add for Review Something went wrong. Try again. However, checking the failed reviewSubmissionItems requests in the browser dev tools shows HTTP 409 responses indicating that the existing IAP/subscription versions use an older format that is no longer supported for review submission. The affected errors include: STATE_ERROR.SUBSCRIPTION_VERSION_NOT_SUPPORTED Subscription version '[REDACTED]' is using an older format that is not supported for review submission. Please update before submitting. STATE_ERROR.SUBSCRIPTION_GROUP_VERSION_NOT_SUPPORTED Subscription group version '[REDACTED]' is using an older format that is not supported for review submission. Please update before submitting. STATE_ERROR.IAP_VERSION_DATA_SCHEMA_NOT_SUPPORTED In-app purchase version '[REDACTED]' is using an older format that is not supported for review submission. Please update before submitting. In my case, this affects: 3 older subscription versions 1 subscription group version 1 older IAP version All required metadata in App Store Connect is complete. The interesting part is that I can create a new IAP today and add it to the same review submission successfully. Only the older IAP/subscription records fail. I can’t find any option in App Store Connect to “update” or migrate these legacy versions to the newer format referenced by the error message. Has anyone found a self-service way to migrate/regenerate these older IAP/subscription versions, or does this require Apple to update the records server-side? I’ve already opened a support case with Apple (ID: 102963040418), but wanted to check whether others are seeing the same issue.

Our build was rejected under Guideline 2.3.2 (Accurate Metadata) over subscription promotional images that were flagged as duplicates of, and too similar to, our app icon. The rejection was against the build, not the subscriptions directly. At the time, all five subscriptions plus the subscription group were in "Submitted for Review" status, which meant they couldn't be edited directly. Troubleshooting steps taken so far: Developer-cancelled each of the five subscriptions to get them out of "Submitted for Review" and into an editable state. Edited each subscription to remove the promotional image that triggered the 2.3.2 flag. Made changes to the Localization and Review Information fields on each subscription to force a new Save action. The Save completed successfully with no errors on any of the five subscriptions. After this, all five subscriptions and the subscription group are showing "Removed" from the Review Status column of our iOS submission. However, "Developer Rejected" status still shows in the Subscriptions section of Monitization (ASC->Distribution). That status hasn't cleared despite the successful edit and save, and I'm not able to reattach the subscriptions to a build for a new review submission from this state. Has anyone run into this — a subscription that was developer-cancelled, corrected, and successfully saved, but remains stuck on "Developer Rejected" instead of returning to a submittable state? Is there a separate action needed beyond edit-and-save (e.g., a distinct resubmit step, or removing and recreating the subscription) to move it forward from here? Any guidance on the correct path would be appreciated — happy to provide additional screenshots or details if useful.

Hi everyone, I'm hoping someone from Apple or another developer has seen this before because I'm completely blocked from submitting my first auto-renewable subscription. Setup First app submission App version: 1.0 (Build 34) One auto-renewable subscription Five consumable IAPs Everything configured in App Store Connect StoreKit works correctly in TestFlight Subscription purchases complete successfully in TestFlight RevenueCat configuration has been verified Subscription review screenshot is uploaded and processed successfully Problem App Store Connect shows: "There are errors with one or more of your items. To fix them, you need to remove the items and add them again to your submission." The draft contains: App Version 5 Consumable IAPs 1 Subscription When I submit through the App Store Connect API I receive: STATE_ERROR.SUBSCRIPTION_SUBMISSION_REQUIRES_GROUP_VERSION A subscription must be submitted with its subscription group version when the group has no prior approved version. That makes sense because this is my first subscription. However, when I attempt to create a subscription group version I receive: STATE_ERROR.ALREADY_EXISTS Version already exists. There is already an inflight version with id: bf2f7b5b-7fbd-44fc-9c67-af1297f3d76a So I then attempted to add that existing SubscriptionGroupVersion to the review submission. Apple responds with: STATE_ERROR.SUBSCRIPTION_GROUP_VERSION_NOT_SUPPORTED Subscription group version bf2f7b5b-7fbd-44fc-9c67-af1297f3d76a is using an older format that is not supported for review submission. Please update before submitting. and also: STATE_ERROR.SUBSCRIPTION_GROUP_VERSION_INVALID_STATE Subscription group version bf2f7b5b-7fbd-44fc-9c67-af1297f3d76a cannot be submitted. Only versions in Prepare for Submission or Developer Rejected can be submitted. The issue I'm now stuck because: Apple says I must submit a SubscriptionGroupVersion. Apple says one already exists. Apple will not allow me to create a replacement. Apple will not allow me to submit the existing one. Apple says the existing one is using an older format. I cannot find any way in App Store Connect to update, replace or delete this SubscriptionGroupVersion. Things I've already verified Build 34 is attached correctly. Subscription Product ID is correct. RevenueCat configuration is correct. StoreKit loads the subscription successfully. Purchases work in TestFlight. Subscription review screenshot exists and is COMPLETE. Localizations, pricing and availability are all configured. The issue occurs both in App Store Connect and when submitting via the App Store Connect API. Question Has anyone encountered this before? Is there a way to regenerate or migrate a SubscriptionGroupVersion into the new format from App Store Connect, or is this something Apple Developer Support has to reset on the backend? Any advice would be greatly appreciated. Thanks!

Hi Apple Developer Community, My app was rejected under Guideline 2.3.2 because I accidentally uploaded the wrong promotional image. I want to remove the image as instructed by App Review, but the IAP is currently Ready for Review, and the image is locked. There is no option to remove or replace it, and the Save/Add for Review buttons are disabled. I have already contacted Apple Developer Support (Case ID: 102955732091) and am waiting for a response. Has anyone faced this issue? Is there a way to unlock the IAP metadata, or does Apple need to remove the image from their side? Thanks!

Issue Description In-app purchase products associated with the app version submitted for review, such as "Basic Diamond Pack", "Standard Diamond Pack", "Premium Diamond Pack", "Silver Weekly Plan", "Silver Monthly Plan", "Silver Quarterly Plan", "Silver Yearly Plan", "Gold Weekly Plan", "Gold Monthly Plan", "Gold Quarterly Plan", "Gold Yearly Plan", "Platinum Weekly Plan", "Platinum Monthly Plan", and "Platinum Quarterly Plan", could not be found in the submitted binary. Next Steps If these In-App Purchase products are not intended to be available at this time, remove them from App Store Connect before resubmitting. AS THERE IS NO OPTION TO DELETE IAP PRODUCTS ONCE YOU SUBITTED TO APP STORE, WE CAN ONLY REMOVE FROM SALE HOW WE CAN DELETE THESE IAP PRODUCTS.

Hi everyone, I set up an auto-renewable subscription introductory offer in App Store Connect with a scheduled start date of September 7 for the Philippines storefront. According to the documentation App Store pricing and availability start times by country or region, scheduled pricing and offer updates are expected to go live based on local regional times. However, the offer did not show up in the Current Introductory Offers in app store connect portal at the documented start time (14:00 Sep 6th UTC). Instead, it stayed in the Upcoming Offers until 7:00 Sep 7th UTC which is 17 hours after the time in the doc. We met a similar situation a few days later when we launch another introductory offer in Thailand. I would appreciate clarification on the following points: What is the underlying reason for the discrepancy between the documented start time behavior and the actual start time observed in production? Can Apple update the App Store pricing and availability start times by country or region reference documentation so that it accurately reflects the practical start time and propagation window for each region? Any insights or shared experiences with offer scheduling in the APAC region would be greatly appreciated.

Hi everyone, As my first experience with uploading an app to App store, I am facing an issue that really exhausted me. I've created a subscription group and added all the details including localization, pricing and other details for the two type of subscription I want to have in the app but the problem is I can't add them for review. You might wonder, why I don't attach it to the app as it said in the screenshot and send it for review. The problem is I don't have that option to attach a subscription group to my app and send it for review. It's so annoying and really frustrated me. Can anyone help?

I'm seeing behavior similar to what was reported in this thread: https://developer.apple.com/forums/thread/816344 I read the discussion in the related thread (816320) as well, but I couldn't determine whether receiving the same transaction multiple times from Transaction.updates is considered expected behavior. In my case, I'm testing an auto-renewable subscription in the Sandbox environment. After successfully processing and calling finish() on a transaction, Transaction.updates sometimes provides another transaction with the same transactionId. I've also observed the same transactionId being delivered multiple times through Transaction.updates itself. I compared the JWS representations of these transactions. They are not byte-for-byte identical, but the transaction information appears to be the same. The only differences I've identified are: signedDate deviceVerificationNonce deviceVerification This looks as though the same transaction is being signed again at a different time. I'd like to clarify the intended way to handle this: Is it expected behavior for Transaction.updates to deliver the same transactionId multiple times in this way? If so, after an app has successfully processed and finished a transaction, is it safe to recognize subsequent transactions with the same transactionId as already processed, skip entitlement-related processing, and simply call finish() on them? In other words, can an app use transactionId to prevent duplicate processing of transactions that it has already successfully handled? I'm specifically interested in whether doing so could cause the app to miss any meaningful update that StoreKit might later deliver using the same transactionId.