Test Generated Purchase Code Before You Touch Sandbox — Automating Refunds, Expiration, and Failures with SKTestSession

Prove That a Purchase Becomes an Entitlement

Start with the path the generated code is most confident about. If this does not hold, there is no point looking further.

func testPurchaseGrantsEntitlement() async throws {
    // No entitlement before purchase
    let before = await EntitlementStore.shared.isSubscribed()
    XCTAssertFalse(before, "Entitlement granted before purchase")
 
    // Drive the purchase from the session, bypassing the UI
    try await session.buyProduct(identifier: "com.example.pro.monthly")
 
    // Call your app's own entitlement logic
    let after = await EntitlementStore.shared.isSubscribed()
    XCTAssertTrue(after, "No entitlement after purchase")
}

The expected outcome is not simply a green test. It is confirmation that EntitlementStore actually goes through Transaction.currentEntitlements. If the generated code writes a flag to UserDefaults on purchase completion and reads only that flag afterward, this test still passes — and the next one fails.

That is exactly the point.

Move Time Forward to Test Renewal and Expiration

timeRate is the most useful property in StoreKitTest. It compresses the subscription timeline so renewals happen in seconds instead of a month.

func testExpirationRevokesEntitlement() async throws {
    session.timeRate = .oneSecondIsOneDay
 
    try await session.buyProduct(identifier: "com.example.pro.monthly")
    let granted = await EntitlementStore.shared.isSubscribed()
    XCTAssertTrue(granted)
 
    // Stop renewing and expire it outright
    try session.expireSubscription(productIdentifier: "com.example.pro.monthly")
 
    let revoked = await EntitlementStore.shared.isSubscribed()
    XCTAssertFalse(revoked, "Entitlement survived expiration")
}

With expireSubscription(productIdentifier:) you do not even need to wait on timeRate. Advance time when you care about behavior after several renewals have fired; when you just want an expired state, expire it directly. It is faster and the test is steadier.

forceRenewalOfSubscription(productIdentifier:) triggers the other direction. If you run work on every renewal — syncing to a server, re-sending a receipt — this is how you find out it fires twice.

Why the Expiration Test Comes First

Missing entitlement grants get reported. The customer who paid will tell you. Revocation is different: nobody tells you. Users you failed to cut off keep using the app quietly, and users you cut off too aggressively leave quietly.

Write the test for the failure that never reaches you.

Reproduce a Refund — the Path Generated Code Misses

Refunds are the path AI-generated billing code nearly always drops, for a simple reason: they are not downstream of the purchase flow. A refund is not a user action. It arrives later, from the App Store.

func testRefundRevokesEntitlement() async throws {
    try await session.buyProduct(identifier: "com.example.pro.lifetime")
    XCTAssertTrue(await EntitlementStore.shared.isSubscribed())
 
    // Grab the most recent transaction and refund it
    let transactions = session.allTransactions()
    guard let target = transactions.first else {
        return XCTFail("No transaction found")
    }
    try session.refundTransaction(identifier: target.identifier)
 
    // Give Transaction.updates a moment to land
    try await Task.sleep(nanoseconds: 300_000_000)
 
    let stillHasAccess = await EntitlementStore.shared.isSubscribed()
    XCTAssertFalse(stillHasAccess, "Entitlement survived a refund")
}

When this test fails, the cause is almost always the same: the app is not observing Transaction.updates, or it starts observing too late.

The Trap Is Where the Listener Starts

Transaction.updates has to be running from app launch. Generated code often creates the listener when the purchase button is tapped. That design drops any refund that arrives while the app is closed.

// Once, at launch. Not when a button is tapped.
@main
struct MyApp: App {
    @State private var updatesTask: Task<Void, Never>?
 
    var body: some Scene {
        WindowGroup {
            ContentView()
                .task {
                    updatesTask = Task.detached {
                        for await result in Transaction.updates {
                            guard case .verified(let transaction) = result else { continue }
                            await EntitlementStore.shared.refresh()
                            await transaction.finish()
                        }
                    }
                }
        }
    }
}

refundTransaction exposes that structural flaw in a few hundred milliseconds. Issuing a refund from App Store Connect and waiting for the notification is a different sport entirely.

Client-side reaction to refunds is a display-layer patch, though. In production, keep the source of truth on a server and let the device do nothing but render the answer. If your source of truth for entitlements lives on a server, you also need to verify the path covered in Verifying StoreKit 2 Signed Transactions in a Cloudflare Worker, along with the server notification side.

Fail a Purchase On Purpose

What does the generated code do when a purchase fails? Swallow it with try? and dismiss the sheet as if nothing happened?

setSimulatedError(_:forAPI:) lets you fail one specific StoreKit API.

func testPurchaseFailureSurfacesToUser() async throws {
    // Fail only the purchase API
    session.setSimulatedError(.generic(.unknown), forAPI: .purchase)
 
    let viewModel = PaywallViewModel()
    await viewModel.purchase(productID: "com.example.pro.monthly")
 
    // Is the failure visible to the user?
    XCTAssertNotNil(viewModel.errorMessage, "Purchase failure never reached the user")
    XCTAssertFalse(viewModel.isPurchasing, "Loading state was never cleared")
 
    // No entitlement from a failed purchase
    let granted = await EntitlementStore.shared.isSubscribed()
    XCTAssertFalse(granted, "Failed purchase granted an entitlement")
 
    // Clean up
    session.setSimulatedError(nil, forAPI: .purchase)
}

That isPurchasing assertion looks trivial and earns its keep. A paywall with a spinner that never stops is indistinguishable from a broken app, and it costs you conversions directly. You will never find that bug without somewhere to trigger failure deliberately.

forAPI: also accepts .loadProducts. Use it to check that a failed product fetch does not leave your paywall rendering as a blank sheet — the exact moment a reader's intent to pay is highest.

Fold Ask to Buy and Storefronts Into One Test

Family Sharing's "Ask to Buy" returns purchases in a deferred state. Reproducing that on a device means setting up family accounts.

func testAskToBuyPendingState() async throws {
    session.askToBuyEnabled = true
 
    try await session.buyProduct(identifier: "com.example.pro.monthly")
 
    // No entitlement before approval
    let beforeApproval = await EntitlementStore.shared.isSubscribed()
    XCTAssertFalse(beforeApproval, "Entitlement granted before approval")
 
    // Approve as the parent would
    let pending = session.allTransactions().filter { $0.state == .deferred }
    guard let target = pending.first else {
        return XCTFail("No deferred transaction")
    }
    try session.approveAskToBuyTransaction(identifier: target.identifier)
    try await Task.sleep(nanoseconds: 300_000_000)
 
    let afterApproval = await EntitlementStore.shared.isSubscribed()
    XCTAssertTrue(afterApproval, "No entitlement after approval")
}

Swap storefront and the same structure covers region-specific product availability. Whether your pricing display survives a jump between Japan and the US no longer needs two physical devices.

I keep both of these lower in priority. Nail refunds and expiration first.

Where to Draw the CI Line

None of these tests need a device. They run in the simulator with no outbound traffic, which means they belong in CI.

That said, be selective about what runs every time.

Run timeRate tests on every commit and you lose the ability to tell "broken" from "did not finish in time." Time-dependent tests blur what red and green mean, and blurred tests eventually get ignored.

I would make those four a required CI job. They run fast, and when one goes red there is almost nothing to blame but the billing code.

In a workflow where the code gets rewritten on every generation, these four tests are the difference between regenerating with confidence and regenerating with a held breath. When you ask Rork Max to rebuild a screen, the billing layer is the one place you want left alone. These four draw that boundary.

What Stays in Sandbox

The limits are clean.

Server-side signature verification will not pass: transactions issued by SKTestSession are not signed with Apple's production keys. App Store Server Notifications V2 never fire. Real charges and real localized prices do not appear.

So if your entitlement design involves a server, Sandbox stays necessary to the end. Anything driven by store-side state transitions — recovery from a failed payment, for instance — lives in the territory covered by When You Revoked Access, They Were Still Willing to Pay — Implementing Billing Grace Periods and Entitlement Retention, and that sits outside SKTestSession entirely.

The Sandbox-side setup traps are collected in Testing Rork Subscriptions in Sandbox — Where Apple and Google Trip You Up.

The division of labor: SKTestSession is the tool for doubting your own code, Sandbox is the tool for doubting your connection to Apple. Reverse that order and you will burn hours on the wrong question.

One more quiet advantage: SKTestSession runs without a $99 Apple Developer Program membership. Even before you have decided whether to ship the app Rork Max built, you can move the billing logic forward.

One Next Step

Write testRefundRevokesEntitlement and nothing else. Trigger one refund.

If it goes green, your Transaction.updates observer is wired correctly. If it goes red, go find where the listener starts. It is probably inside the purchase button.

I shipped generated code to the App Store once, trusting it as written, and found the hole in the refund path only afterward. I had verified that people could buy, and stopped there. Tests, I learned quietly that day, are also a tool for showing you what you never checked.