How to test a loyalty program app

01Direct answer

02What counts as a loyalty program app

A loyalty program app here is a member app on iOS, Android and web where points and tiers are earned from purchases across sales channels and partners, and redeemed for rewards, often with a linked stored value card. It covers earn rules per tier and promotion, receipt scans, redemption, paying with points, terms and expiry changes, balance migrations and program mergers. Card-issuer rewards inside a banking app and a store's checkout itself are out of scope.

Adjacent product types not covered here

• grocery delivery app: A grocery delivery app charges per basket with a refund guarantee for late or short deliveries, so fee disclosure and refunds replace point devaluation and balance migrations.
• subscription box service: A subscription box service charges a stored card each billing cycle, so renewals after cancellation replace point devaluation and stored value drained after account takeover.
• ecommerce store: An ecommerce store sells goods in one checkout without a points ledger, so balance migrations and redemption at old award prices do not arise.

03Risk map

04Mandatory tests (11)

1. 1

   Step 1: release smoke tests

   Why:store-rejection

   Done when: On every build, a test member signs in, scans a receipt or purchase, sees points arrive and redeems a reward without a crash.

   Tool class: mobile automation. Who usually runs it: QA engineer.

2. 2

   Step 2: end-to-end functional tests

   Why:money-lossregulatory-penalty

   Done when: A member who earned points before a terms change can still redeem them at the old price shown on their statement.

   Tool class: browser automation. Who usually runs it: QA engineer.

3. 3

   Step 3: penetration testing

   Why:fraud-abusedata-breach

   Done when: A tester replaying leaked password lists is throttled and blocked, and cannot read or redeem another member's balance by changing an account number.

   Tool class: proxy. Who usually runs it: security specialist.

4. 4

   Step 4: data integrity and migration testing

   Why:data-corruptionmoney-loss

   Done when: After a ledger migration or program merge, every member's points balance and tier on a full export matches the old system at the published conversion ratio.

   Tool class: data validation. Who usually runs it: QA engineer.

5. 5

   Step 5: unit tests

   Why:money-loss

   Done when: For a fixed set of sample members, redemption prices for points earned before a terms change stay at the old award price, and earn rules for each tier and promotion produce the points listed in the program terms.

   Tool class: unit framework. Who usually runs it: developer.

6. 6

   Step 6: exploratory testing

   Why:fraud-abuse

   Done when: A session log lists attempts at credential stuffing, detaching a linked stored value card, duplicate receipt scans, referral loops and refund-after-redeem, with the outcome of each and a ticket for every success.

   Tool class: test management. Who usually runs it: QA engineer.

7. 7

   Step 7: payment and money-flow testing

   Why:money-loss

   Done when: A stored value top-up and spend each show once on the member statement and in the sandbox, and the stored value card cannot be moved to another account without signing in again.

   Tool class: API client. Who usually runs it: QA engineer.

8. 8

   Step 8: compliance checks

   Why:regulatory-penaltystore-rejection

   Done when: Each change to earn rates, award prices or expiry is checked against the program terms and notice period before release, and paid point sales follow the store billing rules.

   Tool class: test management. Who usually runs it: product manager.

9. 9

   Step 9: integration tests

   Why:data-corruption

   Done when: After points move to a new ledger or a second program merges in, the balance and tier a member sees in the app, at the point of sale and in a partner channel equal the converted balance in the new ledger, and a new purchase in each channel credits points once.

   Tool class: API client. Who usually runs it: developer.

10. 10

    Step 10: security scanning

    Why:data-breach

    Done when: The scan report for the member API has no open high findings, and membership numbers never appear in page addresses, emails or support exports.

    Tool class: DAST scanner. Who usually runs it: security specialist.

11. 11

    Step 11: device and browser compatibility

    Why:store-rejection

    Done when: Sign-in, earn and redeem complete on the oldest supported iOS and Android versions and on the web member area.

    Tool class: device cloud. Who usually runs it: QA engineer.

05Recommended and optional tests

• accessibility testingrecommended

  Becomes mandatory when the program is offered by a business covered by an accessibility law in its market.

• performance and load testingrecommended

  Becomes mandatory when a promotion peak stops members from earning or redeeming.

• resilience and failure testingrecommended

  Becomes mandatory when a point of sale or partner outage leaves purchases without points.

• offline and poor-network testingrecommended

  Becomes mandatory when rewards redeemed at the till without signal are lost or applied twice.

• regression suiteoptional

  Optional: helps when promotions change weekly.

• analytics and event tracking testsoptional

  Optional: helps measure promotion uptake, no attached risk depends on it.

06Not needed and why

• usability testing

  Not needed: no attached risk comes from members misreading the app. Becomes recommended when support tickets show members missing earned rewards.

• localization testing

  Not needed: the program runs in one market and currency. Becomes recommended when points are earned in a second currency.

07Order of work

08Tools

Listed alphabetically inside each test type, filtered to the tests above and to the platforms of loyalty program app (ios, android, web). Not recommendations.

09What to send to the person who will test

Send the checklist and the brief below. The printable checklist for loyalty program app has the same 11 items with checkboxes.

Download the checklistMarkdownCSVBrief (Markdown)

Acceptance criteria wording

A release of the loyalty program app is accepted when, after points move to a new ledger, each member's balance and tier match across the app, the point of sale and partner channels, and a member who earned points before a terms change can still redeem at the old price. A stored value card cannot be moved to another account without signing in again. Sign-in throttles and blocks replayed leaked passwords.

Brief

# Test brief: loyalty program app

Product type: loyalty program app. Points, tiers and rewards tied to purchases.
Risk map and evidence: https://howtotestaproduct.com/how-to-test/loyalty-program/
Printable checklist: https://howtotestaproduct.com/checklists/loyalty-program/

Run these 11 mandatory tests in this order. A test is done only when its done condition is true on the build you will release.

1. release smoke tests (risks: store-rejection). Tool class: mobile automation. Usually run by: QA engineer.
   Done when: On every build, a test member signs in, scans a receipt or purchase, sees points arrive and redeems a reward without a crash.
2. end-to-end functional tests (risks: money-loss, regulatory-penalty). Tool class: browser automation. Usually run by: QA engineer.
   Done when: A member who earned points before a terms change can still redeem them at the old price shown on their statement.
3. penetration testing (risks: fraud-abuse, data-breach). Tool class: proxy. Usually run by: security specialist.
   Done when: A tester replaying leaked password lists is throttled and blocked, and cannot read or redeem another member's balance by changing an account number.
4. data integrity and migration testing (risks: data-corruption, money-loss). Tool class: data validation. Usually run by: QA engineer.
   Done when: After a ledger migration or program merge, every member's points balance and tier on a full export matches the old system at the published conversion ratio.
5. unit tests (risks: money-loss). Tool class: unit framework. Usually run by: developer.
   Done when: For a fixed set of sample members, redemption prices for points earned before a terms change stay at the old award price, and earn rules for each tier and promotion produce the points listed in the program terms.
6. exploratory testing (risks: fraud-abuse). Tool class: test management. Usually run by: QA engineer.
   Done when: A session log lists attempts at credential stuffing, detaching a linked stored value card, duplicate receipt scans, referral loops and refund-after-redeem, with the outcome of each and a ticket for every success.
7. payment and money-flow testing (risks: money-loss). Tool class: API client. Usually run by: QA engineer.
   Done when: A stored value top-up and spend each show once on the member statement and in the sandbox, and the stored value card cannot be moved to another account without signing in again.
8. compliance checks (risks: regulatory-penalty, store-rejection). Tool class: test management. Usually run by: product manager.
   Done when: Each change to earn rates, award prices or expiry is checked against the program terms and notice period before release, and paid point sales follow the store billing rules.
9. integration tests (risks: data-corruption). Tool class: API client. Usually run by: developer.
   Done when: After points move to a new ledger or a second program merges in, the balance and tier a member sees in the app, at the point of sale and in a partner channel equal the converted balance in the new ledger, and a new purchase in each channel credits points once.
10. security scanning (risks: data-breach). Tool class: DAST scanner. Usually run by: security specialist.
   Done when: The scan report for the member API has no open high findings, and membership numbers never appear in page addresses, emails or support exports.
11. device and browser compatibility (risks: store-rejection). Tool class: device cloud. Usually run by: QA engineer.
   Done when: Sign-in, earn and redeem complete on the oldest supported iOS and Android versions and on the web member area.

Acceptance criteria wording:
A release of the loyalty program app is accepted when, after points move to a new ledger, each member's balance and tier match across the app, the point of sale and partner channels, and a member who earned points before a terms change can still redeem at the old price. A stored value card cannot be moved to another account without signing in again. Sign-in throttles and blocks replayed leaked passwords.

Report back for each test: pass or fail against its done condition, the build or version tested, and the proof (screenshot, log line or report file).

Licence: CC BY 4.0.

For founders: what to forward and what to ask back. For product managers: turning this page into tickets.

10Questions about testing a loyalty program app

11Evidence

1. ev-0106court-or-fineprimary

   Attorney General James Gets Dunkin' to Fill Holes in Security, Reimburse Hacked Customers, Office of the New York State Attorney General

   An attacker that gained access to one of these accounts would have been able to use the DD card to make purchases, or remove the card from the account and sell it online.

   Settlement after credential stuffing took over rewards app accounts holding stored value cards, which attackers spent or resold. Supports fraud-abuse and money-loss for loyalty program apps that hold stored value or redeemable balances.

   published 2020-09-15 · verified 2026-10-07

2. ev-0103regulatorprimary

   Consumer Financial Protection Circular 2024-07: Design, marketing, and administration of credit card rewards programs, Consumer Financial Protection Bureau

   The circular treats reducing the value of rewards already earned, and point conversions after a merger that lose value, as possible unfair or deceptive practices. Written for card rewards; it transfers to any points program where earned balances carry value, so it supports money-loss, data-corruption and regulatory-penalty for loyalty program apps.

   published 2024-12-18 · verified 2026-10-07

3. ev-0105regulatorprimary

   FTC Finalizes Order with Marriott and Starwood Requiring them to Implement a [...] Data Security Program to Address Data Breaches, Federal Trade Commission

   FTC order after breaches that exposed loyalty numbers with other personal data, including payment card numbers and passport information; it requires deletion requests by loyalty account number and restoring stolen loyalty points on request. Supports data-breach for loyalty program apps.

   published 2024-12-20 · verified 2026-10-07

4. ev-0001store-guidelineprimary

   App Review Guidelines, Apple

   Apple reviews every iOS, iPadOS and macOS App Store submission against these guidelines, including crashes and bugs at review, privacy disclosures, in-app purchase rules and extra rules for medical, financial and kids apps, and apps with user-generated content must let users report offensive content and block abusive users (guideline 1.2), and apps offering loot boxes or similar mechanisms must disclose the odds of each item type before purchase (guideline 3.1.1).

   published undated · verified 2026-10-07

5. ev-0005store-guidelineprimary

   Payments policy, Google Play

   Google Play requires its billing system for digital goods and in-app purchases, with listed exceptions for physical goods and some services.

   published undated · verified 2026-10-07

12Disclaimer

This page lists tests and risks for a product category, not for your product. Risks are attached only with the evidence shown in the Evidence section. Tools are listed alphabetically and are not recommendations. Nothing here is legal, regulatory or security advice; where a regulator or a store sets a requirement, their page is linked and takes precedence.