How to Test a Payment Form (QA Checklist)

Before You Start

• Use a test environment connected to your provider's sandbox.
• Prepare two kinds of data: synthetic Luhn-valid numbers for field tests, and the provider's published sandbox cards for payment tests. Test credit card numbers for developers explains the difference.
• Never use real cards in test environments.

1. Card Number Field

• Formatting: digits group as you type (4-4-4-4 for most cards, 4-6-5 for American Express).
• Pasting: a number pasted with spaces or dashes is accepted and cleaned.
• Card type detection: the logo or label updates after the first few digits for each supported network.
• Length: 15-digit Amex and 16-digit Visa both accepted; longer valid ranges (up to 19) aren't truncated if you support them.
• Luhn validation: a number with one digit changed is rejected with a clear message. The Luhn algorithm explained shows how the check works.
• Unsupported networks: if you don't accept a network, the message says so plainly rather than "invalid card".
• Mobile: the numeric keypad appears (inputmode="numeric"), and autofill works (autocomplete="cc-number").

2. Expiry Date

• Accepts MM/YY, with sensible handling of a typed "1" (doesn't jump to "01/" too early).
• Rejects past dates and invalid months (13, 00).
• Accepts the current month as valid.
• Doesn't reject dates far in the future that your provider accepts.

3. Security Code (CVC/CVV)

• 3 digits for most networks, 4 for American Express, switching when the card type changes.
• Field is masked or not, according to your design, and never stored after authorisation.
• Helpful hint about where to find the code, especially for Amex (on the front).

4. Name and Address Fields

• Accepts names with spaces, hyphens, apostrophes and non-Latin characters.
• Postcode or ZIP validation matches the selected country, if you collect it.

5. Error Handling

Use your provider's sandbox cards to trigger the declines and authentication flows; each provider documents which numbers produce which results.

6. Accessibility

• Every field has a visible label, not just a placeholder.
• Errors are announced to screen readers and linked to fields.
• The whole form works with a keyboard alone, including any card-type icons or tooltips.
• Colour isn't the only signal for errors.
• Time limits, if any, can be extended.

WCAG 2.2 is the reference for these requirements.

7. Data Safety

• Card numbers never appear in application logs, analytics events, error trackers or URLs.
• The form uses your provider's hosted fields or tokenisation where possible, so raw card data doesn't touch your servers.
• Test databases contain no real card data.
• Screenshots and recordings in bug reports don't show full numbers.

8. Across Devices and Browsers

• Desktop and mobile layouts, portrait and landscape.
• Browser autofill and password-manager card filling.
• Slow networks: the submit button shows progress and prevents duplicates.

Generating Field-Test Data Quickly

For the field-level checks above, you need numbers from each network that pass format validation. The test card generator creates synthetic, Luhn-valid numbers for Visa, Mastercard, American Express, Discover, JCB, Diners Club and UnionPay, with optional future expiry dates and correct-length security codes, and exports them as CSV or JSON for automated tests. It runs in your browser and is for testing only. Credit card number structure explains the prefixes and lengths behind the card type detection tests.

Summary

Test each field with synthetic numbers, the full flow with sandbox cards, every error path, accessibility and data handling. A good payment form is forgiving with typing, clear about errors and careful with data.