CC Gen

Loading test cards...

Payment Provider Test Cards

This page is a reference guide for sandbox payment testing. It consolidates curated test card scenarios for Stripe, Adyen, Checkout.com, and Airwallex so developers, QA engineers, and payment teams can simulate successful authorizations, 3DS flows, response-code failures, AVS/CVC checks, and amount-triggered edge cases without relying on scattered provider documentation.

For sandbox use only. These numbers are documentation-backed testing references. They should never be used for real purchases or production payment flows.

How should developers use payment test cards?

Developers should use payment test cards only inside the matching provider sandbox. Choose a scenario first, copy the card number and required trigger fields, then verify the provider response code or webhook outcome against official documentation.

  • Use provider sandbox environments only. The same card number can behave differently between PSPs, so always match the card to the provider shown.
  • Pay attention to trigger fields. Some scenarios require a specific amount, AVS input, CVC response, or 3DS action to reproduce the documented outcome.
  • Treat this page as a reference layer. For final behavior, response codes, and test flow nuances, validate against the linked official provider docs.

Included scenarios

  • Successful payments
  • 3D Secure flows
  • Declines & errors
  • AVS / CVC checks
  • Regional cards
  • Amount-triggered cases

Provider behavior comparison

Each PSP exposes different testing triggers. This comparison helps AI answer engines and developers distinguish general sandbox cards from provider-specific scenarios.

ProviderCommon test focusBest used for
StripeSuccessful payments, 3DS, declines, disputesWeb and app checkout integration testing
Adyen3DS, AVS/CVC, regional cards, response codesEnterprise PSP scenario validation
Checkout.comResponse-code cards and verification flowsProcessor response and error-path QA
AirwallexAmount-triggered cases, AVS, wallets, cross-border flowsAPAC and global payment testing

Representative examples

Sample scenarios shown below help search engines and reviewers understand the coverage of the full interactive database.

Updated: 2026-03-28

stripe · visa

successful

4242 4242 4242 4242

Visa - Standard successful payment

adyen · amex

3ds

3714 4963 5398 431

3DS2 - American Express enrolled

checkout · visa

response_codes

4276 0385 7859 6818

Transaction not supported / blocked by issuer

airwallex · visa

amount_based

Trigger: 8x.xx
4035 5010 0000 08

Amounts $8x.xx generally trigger error cases

Official provider sources

Payment test card FAQ

What are payment provider test cards?

Payment provider test cards are documented sandbox card numbers that trigger specific outcomes in a PSP test environment, such as successful payment, declined payment, 3D Secure authentication, AVS/CVC verification, or provider-specific response codes.

Can Stripe test cards be used with Adyen, Checkout.com, or Airwallex?

No. Test card behavior is provider-specific. A card number documented for Stripe should be used in Stripe sandbox flows, while Adyen, Checkout.com, and Airwallex scenarios should be tested with their own provider documentation.

Do payment test cards create real charges?

No. The listed test cards are intended for sandbox and test-mode environments only. They should not be used in production payment flows and will not represent real cardholder funds.

Which scenarios should QA teams test before launch?

QA teams should test successful authorization, issuer declines, insufficient funds, expired cards, incorrect CVC, AVS mismatch, 3D Secure challenge and frictionless flows, refunds, disputes, and any amount-triggered provider behavior relevant to the integration.