Testing
Stage runs against every provider's test platform, so nothing you do there moves money. Test with the values published below for the provider your configuration routes to, rather than with your own card or bank account. Never send real card or bank details to stage.
Stage is not self-serve — see
Is there a test environment?
for how to get an account. Once you have one, point the client at
https://graph.stage.clientloop.com and set env="stage" on the embedded
components.
Which provider takes your test payment
Card payments go to CLP when your checkout configuration has CLP enabled, and to NMI otherwise; a configuration with both uses CLP. Ask your integration contact which one you are on if you are not sure.
It matters because the two test platforms disagree about the fields around
the card rather than about the card itself. The lists below overlap —
4111111111111111 is on both — but CLP checks the security code and expiry
against the card number, while NMI does not require the security code to match
it and takes the approve-or-decline outcome from the amount. So take the whole
row from the section that matches your configuration; a number copied from the
other section with its own expiry and security code is refused even when the
number itself is valid.
CLP test cards
Use each card with the security code and expiry published beside it. CLP's test platform checks both against the card number and refuses any other combination as a security code decline, so an arbitrary code on a valid test number does not work.
| Brand | Number | Security code | Expiry |
|---|---|---|---|
| Visa | 4111111111111111 | 737 | 03/30 |
| Visa | 4166676667666746 | 737 | 03/30 |
| Mastercard | 5555555555554444 | 737 | 03/30 |
| Mastercard | 2222400070000005 | 737 | 03/30 |
| Discover | 6011601160116611 | 737 | 03/30 |
| American Express | 370000000000002 | 7373 | 03/30 |
The postal code is checked for format rather than against the card, so any well-formed value works.
CLP test bank accounts
CLP takes US bank debit through ACH. It is a US network, so a test payment is made against a US address; Canadian bank debit is a separate method rather than ACH.
| Field | Value |
|---|---|
| Routing number | 011000138 or 121000358 |
| Account number | Any correctly formatted account number, for example 123456789 |
| Account holder | Any name |
| Billing address | Any correctly formatted US address |
To exercise your return-handling path, set the account holder name to
chargeback: followed by an ACH return reason code — chargeback:R01 for
insufficient funds — and leave the rest of the details as above. The payment
authorizes normally, and the return follows once it settles, reaching you as a
chargeback the way a real return would.
NMI test cards
Use the cards NMI publishes for its sandbox. Every one of them uses expiry
10/29.
| Brand | Number |
|---|---|
| Visa | 4111111111111111 |
| Mastercard | 5431111111111111 |
| Discover | 6011000991300009 |
| American Express | 341111111111111 |
| Diners Club | 30205252489926 |
| JCB | 3541963594572595 |
| Maestro | 6799990100000000019 |
The outcome comes from the amount rather than from the card: 1.00 and above
is approved, and anything below 1.00 is declined. That is the easiest way to
drive your failure path, since the same card produces either result.
The sandbox still reports a security-code and address result, it just does not
decide the payment on them: a security code of 999 comes back as a
security-code match, and address line 888 with postal code 77777 as an AVS
match. Use them to check your own handling of those fields. For bank payments,
the sandbox's test account number is 24413815 with routing number
490000018.
If your sandbox account has duplicate checking turned on, repeating an approved card and amount within its window is refused as a duplicate — a declined amount can be sent again straight away. Vary the amount between runs rather than chasing the refusal as a failure.
FlexPay
FlexPay decides on the customer's application, not on a card, so testing it means submitting one of the applicant profiles it publishes for the purpose — see FlexPay's test profile data. There are US and Canadian profiles, and within each the approved and the adverse profile differ only by date of birth, so copy the whole profile rather than part of it.
A FlexPay configuration in PRE mode simulates the rest from the payment amount, reading its final character:
| Amount ends in | Result |
|---|---|
9 |
The payment is declined. |
8 |
The request fails with an error. |
| anything else | The payment succeeds. |
So 2500.09 declines, 500.08 errors, and 999.00 goes through. These
triggers fire only in PRE mode; a production FlexPay configuration takes the
amount at face value.
In PRE mode you can also pay with FlexPay's own test card number. When the payment routes to NMI, whose sandbox does not recognize that number, ClientLoop substitutes one the sandbox accepts so the flow still clears end to end.