Test credentials¶
These numbers work in staging only. Use any CVV and any future expiry date.
Warning
These are the only sanctioned test numbers. Card numbers you have seen in other
payment providers' documentation — 4111 1111 1111 1111 above all — are designed to decline
in Aptean Pay. See below.
Test cards¶
| Card type | Number | Debit or credit |
|---|---|---|
| Visa | 4111110208009428 |
Debit |
| MasterCard | 5412750109056250 |
Credit |
| Discover | 6011000011020538 |
Credit |
| American Express | 375987004003245 |
Credit |
- CVV / CVV2 — any value of the right length (4 digits for Amex, 3 for the rest).
- Expiry date — any date in the future.
- Postal code and country — must be a real, valid combination. See capture a card.
Note
Only the Visa test card behaves as a debit card. The other three are credit. This matters if you are testing convenience fees, surcharging, or anything else that varies by funding type — a debit card may be exempt where a credit card is not. If you are testing a fee flow, use MasterCard, Discover or Amex.
Test bank account (ACH)¶
| Field | Value |
|---|---|
| Account number | 24413815 |
| Routing number | 490000018 |
Use these with the bank capture iFrame.
Note
ACH must be enabled for your staging merchant account. If the token is created but the payment is refused, ask Aptean support to check that bank payments are enabled for your tenant.
Why my test card declines¶
This is the single most common staging support ticket, and it is almost never a bug.
Saving a card runs a zero-dollar validation against the processor before the card is stored. The shared staging processor returns a fixed, simulated result per card number. Numbers on the list above are configured to approve. Everything else is configured to decline.
So a number that looks perfectly valid — passes the Luhn check, right length, right prefix — will
still come back as declined or Issuer Declined if it is not on the list. The usual culprits:
4111 1111 1111 1111— the all-ones Visa. Declines every time.3411 1111 1111 111— the all-ones Amex. Declines every time.- Any card number from another provider's test documentation.
Check your test data first. If you are using a number from the table above and still get a decline, then it is worth investigating.
Staging and production do not share test data¶
| Staging | Production | |
|---|---|---|
| Test numbers above | Work | Never work |
| Real card numbers | Never work | Work, and move real money |
If a test card "stopped working", check which host you are pointed at before anything else — see Environments and URLs.
Warning
Do not put a real card number into staging, even your own. It will not work, and staging is not the place for live cardholder data.
Testing failures on purpose¶
Happy-path testing is the easy half. Your integration also has to survive:
- A decline. Use any number not on the list — that is exactly what it gives you.
- A pending payment. Make an ACH payment; it will sit in
PENDING. Check your code does not treat that as paid. See Payment status. - A duplicate submission. Send the same
idempotency-keytwice and confirm you handle the rejection rather than surfacing it to the user as a failed payment. - An expired pre-authorisation. Harder to force, but worth reasoning about — you have 7 days and then the capture fails.