Test cards

Set it up in three steps

1. Pick your provider and scenarios

   Open Settings → Payments. Pick your provider and the scenarios to test. Success is always on. Add declines and 3D Secure to check that your app shows the right message.

   app.witnessqa.com/acme-app/settings/payments

   • acme-app
   • Overview
   • Runs
   • Environments
   • Integrations
   • Settings

   Payments

   Provider

   Stripe ▾

   Success

   Generic decline

   3D Secure

   Insufficient funds

2. The agent checks for test mode, then pays

   Before it types a card, the live payment guard looks at the page for test mode signals. With a test key it pays. With a live key it stops. See Live payment guard.

   app.witnessqa.com/acme-app/runs/1290

   • acme-app
   • Overview
   • Runs
   • Environments
   • Integrations
   • Settings

   Run #1290 · Checkout

   • 07Stripe key pk_test_51Hq… foundTest mode
   • 08Card 4242 4242 4242 4242 · Success✓
   • 09Card 4000 0000 0000 0002 · Generic decline✓ Error shown

3. Read the result per scenario

   Each scenario passes when your app does the right thing: a confirmation for success, a clear error for a decline, and a working challenge for 3D Secure.

   app.witnessqa.com/acme-app/runs/1290

   • acme-app
   • Overview
   • Runs
   • Environments
   • Integrations
   • Settings

   Payment scenarios

   1 bug

   • SuccessPassed
   • Generic declinePassed
   • 3D SecureChallenge never opens

Cards per provider

Checked against the official docs on 2026-10-06. If a provider changes its test data, its docs win. When a scenario is triggered by a cardholder name or an amount instead of a card number, the table says so.

Stripe · Paddle Billing · PayPal · Braintree · Adyen · Checkout.com

Stripe

Any future expiry date and any 3 digit CVC (4 digits for Amex).

Test or live: Publishable key starts with pk_live_ (live) or pk_test_ (test).

Source: Stripe testingStripe API keys

Paddle Billing

Any cardholder name and a valid future expiry date.

Paddle does not document test cards for insufficient funds or an expired card, so these scenarios are skipped for Paddle.

Test or live: Paddle.Environment.set("sandbox") on the page, and a client-side token that starts with test_ (sandbox) or live_ (production).

Source: Paddle card paymentsPaddle sandboxPaddle client-side tokensPaddle environment

PayPal

Future expiry date and any 3 digit CVV (4 digits for Amex). Decline triggers are case sensitive.

Test or live: The SDK usually loads from www.paypal.com in both sandbox and live, and the client ID does not show which one it is. The guard treats PayPal as live unless the SDK loads from sandbox.paypal.com, the page uses client-id=sb, or you mark the client ID as sandbox in payment settings.

Source: PayPal card testingPayPal 3D Secure testingPayPal JS SDK configuration

Braintree

Declines are triggered by the amount, not the card. 3D Secure cards use expiry month 01 and the current year + 3.

Test or live: Tokenization key starts with sandbox_ or production_.

Source: Braintree testingBraintree processor responsesBraintree 3D Secure testingBraintree tokenization keys

Adyen

Expiry 03/2030 and CVC 737. Declines are triggered by the cardholder name.

Test or live: Client key starts with test_ or live_. Test scripts and pages load from checkoutshopper-test hosts, such as checkoutshopper-test.cdn.adyen.com.

Source: Adyen test card numbersAdyen result codesAdyen 3D Secure testingAdyen client key

Checkout.com

Any future expiry date and any 3 digit CVV (4 digits for Amex).

Test or live: Sandbox public keys start with pk_sbox_. Sandbox API calls go to a {prefix}.api.sandbox.checkout.com host.

Source: Checkout.com test cardsCheckout.com API keys