Test cards
In the playground environment Trybe accepts a fixed set of test cards that simulate real-world outcomes — successful authorisation, soft decline, 3DS challenge, fraud reject, etc. — without ever moving real money.
Use these in the playground to exercise your integration's payment paths. Never use them in production; they're rejected outside the sandbox.
Defaults
For every test card below, unless noted otherwise:
| Field | Value |
|---|---|
| Expiry | Any future month + year (e.g. 03/30) |
| CVV / CVC | 737 for most cards; 7373 for Amex |
| Cardholder name | Anything non-empty |
| Postal code | Any value (US ZIP 90210 is fine) |
Mastercard
The recommended starting card for most playground tests.
| Number | Outcome |
|---|---|
5500 0000 0000 0004 |
Authorised (the happy-path test card) |
5555 4444 3333 1111 |
Authorised, alternative BIN |
5454 5454 5454 5454 |
Declined (issuer refusal) |
Visa
| Number | Outcome |
|---|---|
4111 1111 1111 1111 |
Authorised |
4977 9494 9494 9497 |
Authorised with non-EU issuer |
4400 0000 0000 0008 |
Soft decline (retry recommended) |
American Express
CVV is four digits on Amex.
| Number | Outcome |
|---|---|
3700 0000 0000 002 |
Authorised, CVV 7373 |
3714 4963 5398 431 |
Declined |
3D Secure (3DS2) challenge cards
For testing the customer-side authentication flow:
| Number | Behaviour |
|---|---|
4917 6100 0000 0000 |
3DS2 frictionless — authorised, no challenge prompt |
4212 3456 7891 0006 |
3DS2 challenge — the cardholder is prompted |
5454 5454 5454 5454 |
3DS2 challenge, then decline |
When the challenge prompt appears in playground, use password
as the answer to clear it. Any other value fails the challenge.
Other useful BINs
| Number | Use |
|---|---|
6011 6011 6011 6611 |
Discover, authorised |
3528 0000 0000 0000 |
JCB, authorised |
4111 1111 0000 0009 |
Insufficient funds error |
4111 1111 1010 1010 |
CVC declined |
4111 1111 0260 0009 |
Issuer suspected fraud — useful for testing review flows |
What "outcome" means in practice
- Authorised — the payment intent transitions to
paid; the Trybe webhookpayment.completefires (if you've subscribed). - Declined / soft decline — the payment intent goes to
failed; nopayment.completewebhook. Your integration should surface the decline to the user and offer a retry. - 3DS challenge — the payment response includes a redirect URL. Drive the cardholder there, then resume on the configured return URL.
- Insufficient funds / fraud-suspected — same as declined but
with a distinguishable
refusal_reasonin the response — useful if you want to differentiate the user-facing message.
If a scenario isn't covered here
The card numbers above are the most commonly-tested outcomes. If you need to exercise a scenario that isn't represented — a specific issuer-rejection code, a particular regional flow, an alternative payment-method behaviour — ask your Onboarding Manager and we'll share the right test artefact for your case.