Sandbox purchase
A full store checkout made with test money, so you can prove the paywall and entitlement flow work without charging anyone.
See it
What it is
A sandbox purchase runs the store's real checkout flow with test money. Your app still fetches products, opens the Apple or Google purchase sheet, receives a transaction, grants an entitlement, and finishes or acknowledges it. The card is not charged and the sale never enters production accounting.
Use it to exercise every billing path before release: first purchase, renewal, cancellation, pending approval, restore, and a failed payment. Apple provides sandbox accounts and StoreKit Testing in Xcode. Google Play provides license testers and test payment methods for builds installed through a test track. Apple's sandbox also compresses subscription periods, so a monthly plan renews every few minutes and you can watch renewal, cancellation, and expiry in one sitting.
Gotcha: a green test purchase proves your code handled that scenario, not that production is configured. Product IDs, agreements, store availability, signing, and server notification endpoints can still differ. Keep sandbox and production transaction data separate, and make entitlement grants idempotent because the same transaction may be delivered again.
Ask AI for it
Build an end-to-end sandbox purchase test for this app using StoreKit 2 and Google Play BillingClient. Use the existing product IDs, fetch their metadata from each test store, complete one non-consumable and one subscription purchase, verify the transaction on the server, grant the entitlement idempotently, and call Transaction.finish() or acknowledgePurchase only after the grant succeeds. Add cases for cancelled, pending, restored, and duplicate delivery states. Document the Apple sandbox account and Google Play license tester setup, and make the test fail if any production charge path or production credential is used.