> For the complete documentation index, see [llms.txt](https://support.swisspay.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://support.swisspay.ai/api-reference/test-cards.md).

# Test cards

Use these card numbers in **test mode** (with an `sk_test_…` key) to exercise the authorisation paths your application needs to handle. They are rejected in live mode — live mode only accepts real cards.

All test cards use:

* **CVC:** `737`
* **Expiry:** any future date

## Common outcomes

| Brand      | Number                | Outcome            |
| ---------- | --------------------- | ------------------ |
| Visa       | `4111 1111 1111 1111` | Authorised         |
| Mastercard | `5555 4444 3333 1111` | Authorised         |
| Visa       | `4000 3000 1111 2220` | Refused            |
| Visa       | `4000 0200 0000 0000` | Expired card       |
| Visa       | `4988 4388 4388 4305` | Insufficient funds |

## 3-D Secure outcomes

When your account is configured for 3-D Secure (`authentication: "automatic"` in the payment body), these cards force specific authentication outcomes:

| Number                            | Outcome                                     |
| --------------------------------- | ------------------------------------------- |
| `4871 0499 9999 9910`             | Frictionless 3DS success                    |
| `3714 4963 5398 431` (CVC `7373`) | Challenge required, success after challenge |

For the full list of test cards (including AMEX, JCB, Diners, Discover, and country-specific issuer behaviour), see Adyen's [test card numbers reference](https://docs.adyen.com/development-resources/testing/test-card-numbers/).

## Smoke test before integrating

A reasonable smoke test:

1. ✅ **A successful payment** with the Visa 4111… card.
2. ✅ **A declined payment** — assert your code handles `status: "failed"` (not just HTTP 4xx).
3. ✅ **A 3DS challenge** — assert your code redirects to `next_action.redirect_url` and handles the return.
4. ✅ **A 3DS frictionless** — same setup, but the issuer doesn't challenge.
5. ✅ **An idempotent retry** — submit the same payment with the same `Idempotency-Key`; assert you get back the same `pay_...` ID.
6. ✅ **A retry with a changed body** — assert you get `409 key_reused`.
7. ✅ **A customer creation** — assert duplicate emails fail with `customer_email_taken`.
8. ✅ **A payment with a customer attached** — assert the customer is on the payment response.

If any of these eight scenarios behaves unexpectedly, fix it before integrating further.