How to Test In-App Purchases (Android + iOS, 2026)

In-app purchases (IAP) touch revenue directly — a broken IAP flow is an immediate, measurable loss. They also touch three systems (your app, store services, your backend), each with its own sandboxes

In-app purchases (IAP) touch revenue directly — a broken IAP flow is an immediate, measurable loss. They also touch three systems (your app, store services, your backend), each with its own sandboxes and edge cases. This guide covers what to test, how to reproduce edge cases, and what ships broken most often.

What IAP actually is

A user taps "Buy." Your app shows the store's native purchase sheet (Google Play Billing / Apple StoreKit). The store validates payment, returns a signed receipt. Your app verifies (ideally server-side), grants access, stores state. Four steps, four places to fail.

What to test

Product catalog

1. Products load from Play Console / App Store Connect
2. Localized prices display in user's currency
3. Subscription terms (trial, renewal, price) shown clearly
4. Missing / inactive products handled gracefully

Purchase flow

1. Sheet opens on tap
2. Successful purchase — receipt received
3. Receipt verified server-side
4. Entitlement granted within 5 seconds
5. UI updates (button changes, feature unlocks)
6. User cancels at sheet — no charge, no error
7. Payment declined — clear error, entry preserved

Restore purchases

1. Restore button visible (required by Apple)
2. Returning user restores access
3. Restored subscription verified as active
4. No duplicate entitlements granted

Subscriptions

1. Free trial starts correctly (if offered)
2. Trial countdown visible
3. Auto-renewal billed on schedule
4. Cancel-in-trial does not charge
5. Grace period after failed renewal
6. Account hold state detected, user prompted

Edge cases

1. Purchase while offline — queued and replayed
2. Force-close mid-purchase — state recovered
3. Receipt validation fails → entitlement not granted (secure fail)
4. Receipt validation times out → retry with backoff
5. Race: two devices purchase simultaneously
6. User refunds via store → app detects and revokes (if required)
7. Subscription pause (Play) → entitlement respects pause
8. Upgrade / downgrade mid-subscription — prorated correctly

Family sharing (iOS) / shared library (Play)

1. Shared subscription grants access to family members
2. Revocation from primary account propagates

Receipts and server

1. Server verifies receipt with Apple / Google
2. Server stores transaction ID for dedup
3. Server refuses duplicate transaction IDs
4. Server tolerates replay with same receipt (idempotent)
5. Server rejects receipts from different product

Accessibility

1. Purchase buttons labeled with price and product
2. Subscription terms readable at 200% font size
3. Screen reader announces subscription periodic cost

Content restrictions (Apple)

1. Auto-renew terms visible before confirmation
2. "Manage subscription" link accessible
3. Terms of Service and Privacy Policy linked

How to test manually

Android:

• Play Console → License Testing → add test accounts
• Test accounts purchase with sandbox cards; charges do not go through
• Uninstall + reinstall to test restore
• Change system locale to test localized prices

iOS:

• App Store Connect → Users and Access → Sandbox Testers
• Sandbox Apple IDs purchase; no real charges
• StoreKit Configuration file (Xcode 15+) for fully local testing
• Simulator StoreKit testing does not actually reach Apple — useful for UI, not end-to-end

Automated testing

Purchase state automation is constrained — you cannot fully automate the store purchase sheet. What you can automate:

• Product catalog load: assert products present, price format correct
• Server-side receipt validation: feed known receipts, assert outcomes
• UI states post-purchase: mock PurchasesUpdatedListener / SKPaymentTransactionObserver callbacks
• Restore flow: mock receipts and assert entitlement restored

Dedicated libraries (RevenueCat, Qonversion, Purchasely) abstract IAP and provide test mocks. Worth the dependency if IAP is complex.

How SUSA handles IAP

SUSA detects purchase-sheet screens and can:

• Complete test purchases in sandbox mode (if credentials are configured)
• Cancel the sheet and verify the app handles cancellation
• Verify restore flow
• Flag screens where purchase fails to grant entitlement (entitlement still locked after successful payment)

susatest-agent test myapp.apk --iap-test-mode sandbox --iap-account test@example.com

Common production bugs

1. Receipt validated client-side only — jailbroken device can fake receipts. Always validate server-side.
2. Entitlement not persisted after purchase — user uninstalls, reinstalls, loses access. Fix: server is source of truth.
3. Duplicate charges on retry — idempotency by transaction ID.
4. Subscription renewal misses grace period — user locked out for 1-3 days after failed payment that eventually succeeded.
5. Price displayed wrong after currency change — app caches old price.

IAP is one of the highest-ROI test surfaces. A single broken release can cost thousands in lost revenue. Automate what you can, sandbox-test everything manually, verify on real devices before every release.