Hi all,
I've been debugging a persistent sandbox StoreKit issue for a while now and have ruled out everything I can check from my end. Posting the full picture here in case anyone recognizes this pattern or has advice — genuinely stuck.
The core problem
AppTransaction.shared (StoreKit 2) consistently fails with:
Error Domain=SKServerErrorDomain Code=-1 "(null)" UserInfo={storefront-country-code=AUS, client-environment-type=Sandbox}
A real purchase attempt separately fails with:
Error Domain=ASDServerErrorDomain Code=3504 "This item cannot be found." UserInfo={storefront-country-code=AUS, AMSServerErrorCode=3504, client-environment-type=Sandbox}
What's confirmed working (so I can rule these out as the cause)
Product catalog/pricing fetch — real price, title, currency load correctly every time canMakePayments → true getStorefront → AUS, correctly App Store Connect account: Paid Apps Agreement Active, Free Apps Agreement Active, bank account Active, all 3 tax forms Active (ABN/GST, Certificate of Foreign Status, W-8BEN) The IAP itself: correctly configured (com.subwizard.subwizard.unlock, Non-Consumable, "Ready for Review" status) App code: verified twice independently — product ID, type, and registration are all correct, no bugs found Xcode's local StoreKit Configuration file (fully simulated, no network): confirms my purchase/entitlement code works correctly end-to-end when StoreKit cooperates — so this isn't a code bug
What's confirmed failing — identically, across every method I've tried
Raw Xcode Debug build, installed directly to a real device TestFlight (Internal Testing) install A fresh Xcode Release-configuration run
Same error, same domain, same code, every single time: AppTransaction.shared fetch, receipt refresh, Restore Purchases, and the actual purchase attempt (different code, 3504, but same underlying pattern).
The pattern that stands out
Everything that's a simple read of the public catalog (what does this app sell, what's the price) works. Everything requiring Apple's servers to process something tied to my specific account's transaction/commerce state (transaction history, an actual purchase) fails.
My leading theory
This is a brand-new Individual Apple Developer account. The Paid Apps Agreement only went Active 5 days before I started testing this. First-ever IAP product, first-ever real purchase attempt on the account. I'm wondering if this is a propagation/settling delay on Apple's commerce backend that the "Active" UI status doesn't fully reflect — I found a few other forum threads where Apple's own response to error 3504 specifically was to double check the Paid Apps Agreement/tax/banking, even in cases where it already showed as complete.
What I've already ruled out
App Store submission status — per Apple's TN3186 doc and other DTS-engineer forum replies I found, sandbox purchases shouldn't require app/IAP submission or approval at all A raw Xcode install lacking a "real acquisition record" that TestFlight would have — tested directly, TestFlight failed identically Sandbox tester account misconfiguration — sign-in works fine, tester accounts are valid and usable
Where things stand right now
Given everything above checked out clean, I went ahead and submitted the app + this IAP for App Review, partly just to see whether that changes anything, and partly because I need to actually ship at some point regardless. If it gets approved and the purchase works for the reviewer, that would at least tell me production is fine even if sandbox stays broken — I can live with that. But if it comes back rejected specifically because the purchase doesn't work, I'm genuinely out of ideas on what else to check from my side.