a UK-based user is having trouble completing an in-app purchase.
after going through the typical purchase flow (tapping the button to trigger the in-app purchase sheet, completing Face ID) they see this verification sheet appear over my app and have to go to their banking app to approve the purchase.
after approving the purchase from their banking app, they tap "Payment confirmed on Mobile App" to close the sheet, but then see an alert that suggests the result is .userCancelled.
the purchase does not seem to have completed. the user reports not being charged (despite numerous attempts). plus, i have a "restore purchases" function on App init that would've restored a purchase if it existed.
i have implemented what i think is a typical Storekit.purchase() method (again, the message the user sees is for the .userCancelled case):
func purchase(productId: String) async -> (Bool, String?) {
guard let product = subscriptionProducts.first(where: { $0.id == productId }) else {
return (false, "Product not found")
}
do {
let result = try await product.purchase()
switch result {
case .success(let verification):
switch verification {
case .verified(let transaction):
await transaction.finish()
hasSubscription = true
return (true, nil)
case .unverified:
return (false, "Transaction verification failed")
}
case .userCancelled:
return (false, "No worries, take your time. 😌")
case .pending:
return (false, "Purchase is pending")
u/unknown default:
return (false, "Error purchasing product. If this keeps happening, please contact [email].")
}
} catch {
return (false, "Error purchasing product: \(error.localizedDescription)")
}
}
has anyone dealt with this issue? i was seeing an unusually high number of .userCancelled purchase events from users outside the US, and i'm wondering if some of them were genuine purchase attempts that were blocked by this verification step. 😕
StoreKit
RSS for tagSupport in-app purchases and interactions with the App Store using StoreKit.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
App is approved and on App Store but Subscription is in review and localizations rejected. no way to edit.
anyone here that go this flow resolved and how?
Hey guys,
This is a general question, but I have been working on an app for a while and I would like to to introduce IAP to the app. I have no clue where to start and chat GPT is no help. I also tried to vibe coding the IAP function and that didn't work out well. Any material or advice would help.
Topic:
App & System Services
SubTopic:
StoreKit
Some users cannot repurchase a subscription SKU after it has expired.
Flow:
User previously subscribed.
User canceled and the subscription fully expired.
After weeks, user reinstalls the app and taps the same SKU.
StoreKit does not create a new purchase transaction.
Instead, StoreKit always returns the old expired transaction in updatedTransactions.
Therefore, the user is permanently unable to purchase the SKU again.
We have already tried:
Adding payment observer at app launch
Calling finishTransaction for all transactions
Clearing queue at startup
SKReceiptRefreshRequest
Server-side verifyReceipt
Ensuring subscription is truly expired (not in grace/retry)
Not calling restoreCompletedTransactions
None of these resolved the issue. StoreKit still only sends the old transaction and never generates a new one.
Expected behavior:
A new purchase transaction should be created when user taps the expired subscription SKU.
Actual behavior:
StoreKit repeatedly pushes the old expired transaction, blocking new purchases.
We can provide:
Some users cannot repurchase a subscription SKU after it has expired.
Flow:
User previously subscribed.
User canceled and the subscription fully expired.
After weeks, user reinstalls the app and taps the same SKU.
StoreKit does not create a new purchase transaction.
Instead, StoreKit always returns the old expired transaction in updatedTransactions.
Therefore, the user is permanently unable to purchase the SKU again.
We have already tried:
Adding payment observer at app launch
Calling finishTransaction for all transactions
Clearing queue at startup
SKReceiptRefreshRequest
Server-side verifyReceipt
Ensuring subscription is truly expired (not in grace/retry)
Not calling restoreCompletedTransactions
None of these resolved the issue. StoreKit still only sends the old transaction and never generates a new one.
Expected behavior:
A new purchase transaction should be created when user taps the expired subscription SKU.
Actual behavior:
StoreKit repeatedly pushes the old expired transaction, blocking new purchases.
We can provide:
Affected user’s base64 receipt
verifyReceipt full response
Transaction logs (transactionIdentifier, original_transaction_id, productIdentifier, state)
Please help investigate why StoreKit is not allowing a new subscription purchase.
Affected user’s base64 receipt
verifyReceipt full response
Transaction logs (transactionIdentifier, original_transaction_id, productIdentifier, state)
Please help investigate why StoreKit is not allowing a new subscription purchase.
Topic:
App & System Services
SubTopic:
StoreKit
We have 2 monthly subscription tiers that are part of a subscription group, and always have been part of this group. Both are configured with a 1 month trial introductory offer. According to the documentation for auto-renewable subscriptions,:
Users can subscribe to one subscription product per group at a time.
And yet several users have managed to start trials of both products in this group simultaneously, which converted to paid subscriptions after the expiration of the trials, and now are being concurrently billed by Apple for both. How do we completely prevent this from happening?
会员等级进行升级?需要按天计算费用,像爱奇艺这样是怎么做的?
Topic:
App & System Services
SubTopic:
StoreKit
Tags:
StoreKit
In-App Purchase
App Store Server API
Advanced Commerce API
关于通过Advanced commerce API 创建SKU,有几个问题:
1、通过Advanced commerce API创建的自动续费订阅的SKU是否支持推介优惠、促销优惠?如果可以,是在苹果connect设置吗?
2、已订阅通过connect创建的SKU的用户,是否可以重复订阅通过Advanced commerce API创建的SKU?还是要通过Advanced commerce API变更订阅?
3、Advanced commerce API创建的SKU ,用户订阅成功后,续费的扣款是否仍由苹果发起?还是由开发者自行发起?
1)What's the relationship between ""Texas, child, 16-17, significant change declined" from my 11:03 screenshot below and "revoking"? ie what situation could someone decline but not revoke or vice versa, what is the purpose of the distinction in testing or legally or implications/implementation
2) What is a cause besides a typo to receive the "Can't trigger notification" titled message after using "Revoke"? you can see by my screenshot by comparing the left and right half there is no title.
3) Even if i find a workaround perhaps my info will help someone else or be an opportunity for improved documentation
see:
see my 5:54pm second screenshot
Hello,
I would like to ask about an Apple ID authentication behavior during in-app purchases.
Our app uses a StoreKit 1 (SKPaymentQueue-based) implementation, and there are no differences in the in-app purchase logic between the TestFlight build and the App Store production build.
However, we have observed that some users are prompted to enter their Apple ID password during in-app purchases.
The observed behavior is as follows:
On the first in-app purchase, the system prompts for the Apple ID password
After the password is entered once, subsequent purchases proceed normally using Face ID (double side-button press)
Even after deleting and reinstalling the app, or switching between TestFlight and App Store builds, the password prompt does not reappear if authentication has already occurred
This behavior can occur even when the Apple ID already has an active auto-renewable subscription
The only confirmed change on our side is:
The app is now built with Xcode 26 instead of Xcode 18
Based on this, we are currently considering the following possible causes:
A change in purchase authentication behavior due to the Xcode version update
Expiration of the Apple ID purchase authentication session after a long period without purchases
In addition to these points, we would like to ask:
Are there any other common conditions or security policies in iOS or the App Store that may cause the system to require Apple ID password input during in-app purchases?
Is this behavior considered expected under certain circumstances?
We would appreciate your clarification on whether this is expected system behavior or if there are any implementation aspects we should further review.
Thank you for your support.
Hello,
I would like to ask about an Apple ID authentication behavior during in-app purchases.
Our app uses a StoreKit 1 (SKPaymentQueue-based) implementation, and there are no differences in the in-app purchase logic between the TestFlight build and the App Store production build.
However, we have observed that some users are prompted to enter their Apple ID password during in-app purchases.
The observed behavior is as follows:
On the first in-app purchase, the system prompts for the Apple ID password
After the password is entered once, subsequent purchases proceed normally using Face ID (double side-button press)
Even after deleting and reinstalling the app, or switching between TestFlight and App Store builds, the password prompt does not reappear if authentication has already occurred
This behavior can occur even when the Apple ID already has an active auto-renewable subscription
The only confirmed change on our side is:
The app is now built with Xcode 26 instead of Xcode 18
Based on this, we are currently considering the following possible causes:
A change in purchase authentication behavior due to the Xcode version update
Expiration of the Apple ID purchase authentication session after a long period without purchases
In addition to these points, we would like to ask:
Are there any other common conditions or security policies in iOS or the App Store that may cause the system to require Apple ID password input during in-app purchases?
Is this behavior considered expected under certain circumstances?
We would appreciate your clarification on whether this is expected system behavior or if there are any implementation aspects we should further review.
Thank you for your support.
Topic:
App & System Services
SubTopic:
StoreKit
I’m testing auto-renewable subscription purchases in the sandbox environment.
When I buy a subscription package using a sandbox test user, I don’t receive any App Store Server Notifications from the sandbox.
However, when I use the “Request Test Notification” option in App Store Connect, the notification is received successfully.
My sandbox server notification URL is configured correctly and publicly accessible.
I also call finishTransaction() after purchase, and the receipt is verified successfully with the sandbox verification endpoint.
To further debug, I used the getNotificationHistory API to fetch notifications for yesterday and today (Nov 3–4, 2025).
Apple’s API response does not include any notifications or transaction IDs for my today’s purchases (Nov 4, 2025) — even though I can confirm from logs that those transactions were completed and verified successfully.
It looks like sandbox purchase notifications are not being sent or logged, even though test notifications work fine.
Could someone from Apple please confirm if there’s currently an issue with sandbox server notifications for auto-renewable subscriptions?
Topic:
App & System Services
SubTopic:
StoreKit
Tags:
Subscriptions
App Store Connect
In-App Purchase
Hello,
I seem to have a strange bug when testing 2 of my Apps that calls SubscriptionStoreView(groupID: storekitmanager.groupID), where storekitmanager is using @Observable, with groupID from the Subscription Group in App Store Connect.
They have the following: Yearly, Biannually, and Monthly. Their productIDs and groupIDs have been configured in each app with the correct IDs.
In my main Apple ID, when the SubscriptionStoreView is presented, selecting Monthly, tap Subscribe, and nothing happens. Selecting either Yearly or Biannually, tap Subscribe and the Confirmation Dialog that triggers faceID/touchID will appear correctly. This happens in both Apps for TestFlight.
I have a Manage Subscriptions button that uses:
manageSubscriptionsSheet(isPresented:subscriptionGroupID:)
I can change the subscription to Monthly in that manage subscriptions.
However, if I switch to a Sandbox Apple Account, the "bug" described above does not happen. The Sandbox account when selecting Monthly and tap Subscribe will trigger the Confirmation Dialog (in both Apps). Not sure if my main account is "stuck" in some loop where it is trying to purchase Monthly in TestFlight but it is not completed.
Has anyone ever encountered such a bug?
Honestly, don't know how to test it in sandbox. I'm confused on if I need a sandbox to actually test out my in app purchase. Do I need to download something? Someone please help.
Topic:
App & System Services
SubTopic:
StoreKit
In Getting started with In-App Purchase using StoreKit views and the corresponding sample project, Store simultaneously enumerates Transaction.unfinished and Transaction.updates.
Since, "if your app has unfinished transactions, the updates listener receives them once, immediately after the app launches," it appears that Transaction.unfinished would also receive the same unfinished transactions causing handle(updatedTransaction:) to be called for twice for each transaction, causing consumables to be double-counted.
Is this a bug in the sample? Is there more information on concurrent execution of unfinished and updates?
Description
SKTestSession.setSimulatedError() does not throw the configured error when testing StoreKit with the .loadProducts API in iOS 26.2. The simulated error is ignored, and products load successfully instead.
Environment
iOS: 26.2 (Simulator)
Xcode: 26.2 beta 2 (Build 17C5038g)
macOS: 15.6.1
Framework: StoreKitTest
Testing Framework: Swift Testing
base project: https://developer.apple.com/documentation/StoreKit/implementing-a-store-in-your-app-using-the-storekit-api
Expected Behavior
After calling session.setSimulatedError(.generic(.notAvailableInStorefront), forAPI: .loadProducts), the subsequent call to Product.products(for:) should throw StoreKitError.notAvailableInStorefront.
Actual Behavior
The error is not thrown. Products load successfully as if setSimulatedError() was never called.
Steps to Reproduce
Create an SKTestSession with a StoreKit configuration file
Call session.setSimulatedError(.generic(.notAvailableInStorefront), forAPI: .loadProducts)
Call Product.products(for:) with a valid product ID
Observe that no error is thrown and the product loads successfully
Sample Code
import StoreKitTest
import Testing
struct SKDemoTests {
let productID: String = "plus.standard"
@Test
func testSimulatedErrorForLoadProducts() async throws {
let storeKitConfigURL = try Self.getStoreKitConfigurationURL()
let session = try SKTestSession(contentsOf: storeKitConfigURL)
try await session.setSimulatedError(
.generic(.notAvailableInStorefront),
forAPI: .loadProducts
)
try await confirmation("StoreKitError throw") { throwStoreKitError in
do {
_ = try await Self.execute(productID: productID)
} catch let error as StoreKitError {
guard case StoreKitError.notAvailableInStorefront = error else {
throw error
}
throwStoreKitError()
} catch {
Issue.record(
"Expect StoreKitError. Error: \(error.localizedDescription)"
)
}
}
#expect(session.allTransactions().isEmpty)
}
static func execute(productID: String) async throws {
guard
let product = try await Product.products(for: [productID]).first(
where: { $0.id == productID })
else {
throw NSError(
domain: "SKDemoTests",
code: 404,
userInfo: [NSLocalizedDescriptionKey: "Product not found for ID: \(productID)"]
)
}
_ = product
}
static func getStoreKitConfigurationURL() throws -> URL {
guard
let bundle = Bundle(identifier: "your.bundle.identifier"),
let url = bundle.url(forResource: "Products", withExtension: "storekit")
else {
fatalError("StoreKit configuration not found")
}
return url
}
}
Test Result
The test fails because the expected StoreKitError.notAvailableInStorefront is never thrown.
Question
Is this a known issue in iOS 26.2 / Xcode 26.2 beta 2, or is there a different approach required for simulating errors with SKTestSession in this version? Any guidance would be appreciated.
Feedback Assistant report: FB21110809
Need to vent a bit before relaxing for Christmas...
WatchOS IAP using Storekit 2 is such a mess...is nobody actually using this or does Apple just not care for the user experience here?
Lots of users experience after the purchase confirmation double tap on the side button an instant return to the purchase screen with nothing actually happening. No error message whatsoever. There is just one remedy: users need to unpair and re-pair their watch, including restoring a backup and setting up their wallet again. Nobody really wants to do this, or doesn't believe me and think this is just typical support BS, because their watch is paired and most things just work as they expect. And it turns away a customer, often leaving a bad review. And I can't do anything about it.
Other errors in the purchase process are reported, but like "process interrupted" in case the payment is not setup correctly (credit car no longer valid or sth.). How should the user know? There must be better ways of letting him know what exactly the problem is.
You need to implement a "Restore Purchase" function, otherwise you're not passing the review. But it really asks every time for the AppStore password, and users with crazy passwords -- that they rightfully should have! -- have almost no chance of typing them successfully on the tiny AW keyboard. Why is it not also just a side button double tap like for purchase? At the very least you would need access to the keychain PWs or allow pasting of sth. copied on the paired iPhone.
Promo Codes for IAP on AW-only apps just don't work. AW has no redemption at all, and on the iPhone the AppStore will try to talk to a companion app (which AW-only doesn't have) and the end up in a dead-end installation effort.
This all feels like never really tested in the field, and people are of course blaming the 3rd party dev. for all these issues. And opening a ticket is just leading nowhere -- at best it's closed after months with the hint "duplicate" but w/o any chance for me to see that one that they then actually work on and track progress.
It's all so frustratingly broken...
I tried to apply a promotional offer to a subscribed user.
When I tested it in the Sandbox environment, it did not show the promotional payment popup but returned a “restored” status.
However, when I tested it in the Xcode environment, it correctly displayed the payment popup, but after I tapped the Subscribe button, it showed an “Unable to Purchase” popup like this:
And in the console I could see this error:
Received error that does not have a corresponding StoreKit Error: Error Domain=AMSErrorDomain Code=305 "Server Error The server encountered an error" UserInfo={AMSURL=http://localhost:56862/WebObjects/MZBuy.woa/wa/inAppBuy, AMSDescription=Server Error, NSDebugDescription=Server Error The server encountered an error, AMSServerErrorCode=3903, AMSStatusCode=200, AMSServerPayload={
"cancel-purchase-batch" = 1;
dialog = {
defaultButton = ok;
explanation = "Contact the developer for more information.\n\n[Environment: Xcode]";
initialCheckboxValue = 1;
"m-allowed" = 0;
message = "Unable to Purchase";
okButtonString = OK;
};
dsid = 17322632127;
failureType = 3903;
jingleAction = inAppBuy;
jingleDocType = inAppSuccess;
pings = (
);
}, AMSFailureReason=The server encountered an error}
Could someone help me resolve this issue? I’ve been struggling with it for two days and feeling exhausted...
is there a way to make a test subscription in-app purchase expire immediately, for faster testing? it seems exceedingly complicated to test subscriptions if we have to a) wait until the next day for expiry, or b) keep on creating new apple ids to get into a fully unsubscribed state? it is still kind of madness testing this stuff, after all the years it has been available.
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.
Topic:
App & System Services
SubTopic:
StoreKit
Tags:
App Store Server Notifications
App Store Server API
I’m implementing StoreKit External Purchase Custom Links (EU) and so far it is really painful. I am running into a strange, device-specific issue. On 3/4 devices it works. On one device I never get a token at launch nor before a transaction. isEligible is true everywhere. All devices have versions 18.5 and are located in Germany.
Info.plist: SKExternalPurchaseCustomLinkRegions is set to EU storefront codes and I have followed every step in the documentation: https://developer.apple.com/documentation/storekit/externalpurchasecustomlink
Good device: At launch → ACQUISITION = nil, SERVICES = token present. Works consistently.
Faulty device: At launch → ACQUISITION = nil, SERVICES = nil. Same before transaction. No token ever reaches my server from this device.
isEligible is true on both devices.
Any experts or help on the matter?
Topic:
App & System Services
SubTopic:
StoreKit