# Testing checklist: peer-to-peer payment app

Source: https://howtotestaproduct.com/how-to-test/p2p-payment-app/
Generated: 2026-10-07. Licence: CC BY 4.0.

- [ ] 1. release smoke tests
  - Done when: On every store build, a tester installs the app fresh, links a test card, sends a payment to a second test user and sees it arrive once.
  - Risks: store-rejection
  - Tool class: mobile automation. Usually run by: QA engineer.
- [ ] 2. end-to-end functional tests
  - Done when: A payment held for review shows as pending to the recipient with the cash-out button disabled until the review clears, and a password, email or phone change or a login on a new device sends an alert to the previous contact details.
  - Risks: money-loss, fraud-abuse
  - Tool class: mobile automation. Usually run by: QA engineer.
- [ ] 3. security scanning
  - Done when: Each release build is scanned and no open high finding remains on login, password reset, device binding or the endpoints that return private payments.
  - Risks: fraud-abuse, data-breach
  - Tool class: DAST scanner. Usually run by: security specialist.
- [ ] 4. penetration testing
  - Done when: An external tester cannot take over a test account through password reset, SIM swap simulation or session reuse, and cannot read another user's private payments.
  - Risks: fraud-abuse, data-breach
  - Tool class: proxy. Usually run by: security specialist.
- [ ] 5. compliance checks
  - Done when: A test unauthorised-send claim opens an error investigation with a provisional credit decision and a written result, without routing the user to their card issuer.
  - Risks: regulatory-penalty, money-loss
  - Tool class: test management. Usually run by: product manager.
- [ ] 6. exploratory testing
  - Done when: A tester acting as a scammer tries fake support contacts, payment requests with misleading notes and refund tricks, and each working path is logged as a defect.
  - Risks: fraud-abuse
  - Tool class: test management. Usually run by: QA engineer.
- [ ] 7. data integrity and migration testing
  - Done when: After each statement from the app's bank, the sum of user balances, pending sends and cash-outs equals the funds held there; a run that finds a difference lists it by user.
  - Risks: money-loss
  - Tool class: data validation. Usually run by: QA engineer.
- [ ] 8. regression suite
  - Done when: After each release, a payment marked private by either party never appears on the public or friends feed of a third test user.
  - Risks: data-breach
  - Tool class: mobile automation. Usually run by: QA engineer.