Test a payment app by lifecycle, not just by outcome. Approved and declined are the easy cases. Many production incidents come from lost responses, duplicate requests, retries, reversals, interrupted connectivity, and settlement mismatches. This checklist groups tests by lifecycle, failure behavior, device, backend, and operations, with prerequisites, expected outcomes, and the evidence to keep.

This is engineering QA. It is not certification and it is not a formal assessment.

Prerequisites

✓ A sandbox or test account with your processor or gateway.

✓ Test cards, simulators, or test cases supplied by the processor.

✓ Test devices that match your target hardware, SDK, and OS versions.

✓ Logging that masks sensitive data, so evidence never contains real card details.

Lifecycle tests

Test Setup Expected outcome Evidence to record
Approved sale Test card, sandbox Approved state, receipt data, backend record Request and response IDs, screenshot, log excerpt
Declined sale Decline test case Clear decline message, no activation, no capture Response code, screen, log
Partial approval, where supported Processor test case Partial amount handled by policy Response, receipt
Void before settlement Approved test transaction Void succeeds, state updated Void response, backend state
Refund after settlement Settled test transaction Refund recorded and linked to the original Refund ID, report row
Reversal on uncertain outcome Simulated timeout One reversal sent, state resolved Request IDs, log
Settlement Sandbox batch close Batch totals match backend totals Batch report, comparison sheet

Failure tests

Test Setup Expected outcome Evidence to record
Lost response Block the response after the request App queries or reverses, no double charge Logs, processor records
Duplicate request Double tap or forced retry One charge only Transaction IDs, processor records
Retry after timeout Delay the response past the timeout Retry is safe, outcome is consistent Idempotency key or ID, logs
Interrupted connectivity Drop the network mid-transaction State persisted, resolved after reconnect State history, logs
App or device restart Kill the app after approval App recovers to a known state State history, screen recording
Backend outage Take the backend offline Safe failure or queued processing Logs, alert record

Device, backend, and operations

Layer Test Expected outcome
Device Reader connect, disconnect, and reconnect App recovers without a stuck state
Device SDK and OS version matrix Each supported combination passes the core cases
Device Printer or peripheral errors, where used Clear error, transaction state still correct
Backend Duplicate and out-of-order webhooks State is correct and not double applied
Backend Reconciliation report Matches processor and backend records
Operations Alerts and runbook Failures reach a named owner with next steps
Operations Log retention and masking Evidence available, no sensitive data stored

Engineering QA is not certification

Activity What it is Who decides the result
Engineering QA Your own tests of app behavior Your team
Readiness testing Pre-checks against processor or EMV test plans Your team or a partner
Certification Formal testing and approval Processor, scheme, or lab
Formal assessment, such as PCI Review of controls A qualified assessor

Passing your own checklist makes certification smoother, but it does not replace it. For how certification and readiness fit together, see managed EMV certification and the Paying.co guides.

Use test data only

Run every example against sandboxes with test cards. Never use real card numbers or personal data in tests, screenshots, or logs. Keep evidence in a form you could share with a processor without exposing sensitive data.

FAQs

How many test cases are enough?

There is no universal number. Cover every lifecycle operation you support and every failure mode your design must survive.

Should QA run on real devices?

Yes, for anything involving readers, SDKs, or OS behavior. Emulators miss hardware and vendor behavior.

Can QA replace certification?

No. QA reduces risk, but approval comes from the processor, scheme, or lab.

What evidence should I keep?

Request and response IDs, state history, screenshots, and masked logs for each test, with the date and build version.

Next step

If you can share your app, devices, processor, and test environment, we can help review your test plan and find gaps. Start at the custom development page.

Sources

▸ PCI Security Standards Council

▸ EMVCo

▸ Paying.co guides