AppReviewX Log in

Payment flow testing checklist for mobile apps

Success, cancel, failure, pending and restore paths for purchases.

updated ·4 min read

In this guide

Payment bugs cost money twice: once in lost sales and once in refunds and angry reviews. Most teams test "purchase works" and stop. This list covers every state a purchase can end in: success, cancel, failure, pending and restore. Each item has the expected result, a reason and how to check.

Set up the store's test purchases or test accounts first, and never test with a real card you care about. Store-specific setup differs; check the current documentation of the store you use.

Before the purchase

  1. Price and product info are right. Expected: price, period and what is included match the real offer. Why: a wrong price hurts trust and can cause disputes (not legal advice). How: compare each screen with your store product settings.
  2. Price is localized. Expected: currency and format match the store region. Why: wrong formats look scammy. How: test with accounts in different regions where possible.
  3. Purchase button is disabled while loading. Expected: a loading state, then the button works. Why: tapping before products load causes errors. How: slow the network and open the paywall. See how to test your paywall.
  4. Product list fails to load. Expected: clear message and retry, not an empty paywall. Why: store calls fail. How: go offline and open the screen.

Success

  1. Complete a purchase. Expected: access unlocked at once, confirmation shown. Why: the core promise. How: buy with a test account and use the feature.
  2. Access survives restarting the app. Expected: still unlocked. Why: unlock held only in memory vanishes. How: kill and reopen.
  3. Access appears on a second device with the same account. Expected: after restore or sign-in, unlocked. Why: users own several devices. How: sign in on another device.
  4. Backend and app agree. Expected: the server records the purchase. Why: mismatches cause "I paid but have nothing". How: compare the server record and the app state.

Cancel

  1. Cancel at the store sheet. Expected: back in the app with no change, no error. Why: users back out often. How: dismiss the payment dialog.
  2. Cancel and buy again immediately. Expected: second attempt works. Why: stuck states after cancel are common. How: cancel, tap buy, complete.

Failure

  1. Payment declined or method invalid. Expected: clear message, nothing unlocked. Why: unlocked features without payment lose money. How: use the store's test option for failure if available.
  2. Network lost during purchase. Expected: no double charge, no lost purchase; the app recovers on the next start. Why: payment confirmation can arrive late. How: go offline right after confirming, then reconnect and reopen.
  3. App killed during purchase. Expected: the purchase is detected on the next launch and unlocked. Why: calls and crashes happen. How: force-quit during the sheet, reopen.
  4. Double tap on buy. Expected: one purchase. Why: impatient users. How: tap rapidly.

Pending

  1. Purchase needing approval or confirmation (pending). Expected: a message that the purchase is pending, no unlock yet, unlock when approved. Why: some payments finish later. How: use a pending test scenario if the store offers one.
  2. Close the app while pending, return later. Expected: state updates when the result arrives. Why: nobody waits in the app. How: close, wait, reopen.

Restore and refunds

  1. Restore purchases after reinstall. Expected: access returns without paying again. Why: users reinstall and switch phones. How: reinstall, tap Restore.
  2. Restore with nothing to restore. Expected: a friendly message. Why: users tap it anyway. How: use an account without purchases.
  3. Refunded or revoked purchase. Expected: access ends in a defined way. Why: refunds happen. How: revoke in test environment if possible; see the subscription checklist for subscriptions.

After purchase

  1. Receipt or confirmation is available. Expected: user can see what they bought. Why: reduces support questions. How: look for it in the app and in the store.
  2. Price change or promo code (if you use them). Expected: correct amounts. Why: wrong promo handling loses money. How: test each code type.
  3. Analytics events fire once. Expected: one purchase event per purchase. Why: double counting misleads. How: check your analytics tool after a test.

This is not tax or legal advice; check local rules for receipts, VAT and refunds yourself.

AppReviewX gives you private, structured feedback from other developers on your purchase flow; one feedback you write earns one credit. See how AppReviewX works.