# QuickBooks Payments test cards

> Test card numbers, bank accounts and other details for QuickBooks Payments' sandbox, and the result each one gives.

Use these details to try payments in a QuickBooks Payments sandbox (test) account. They work only in the sandbox: never use them in live, and never put real card or bank details into a sandbox.

You need a QuickBooks Online sandbox company, which you create on the Intuit Developer portal. For ACH, the payment amount sets the result.

:::note[Where these details come from]
These are QuickBooks Payments' test details, not ours. They were copied from Intuit's [Practice processing payments with mock data](https://developer.intuit.com/app/developer/qbpayments/docs/workflows/test-your-app) page on 19 October 2026, and were correct on that date as far as that page shows. Intuit can change or withdraw them at any time, and we can't confirm that they work. Check Intuit's page for the current details, and ask Intuit if one doesn't behave as described.
:::

## How to choose a test result

- The card number must be one of Intuit's test numbers, with an expiry date in the future. The sandbox doesn't check the CVC or the billing address, so the **Require address (AVS)** setting on the QuickBooks Payments connection here makes no difference to the result ([Practice processing payments with mock data](https://developer.intuit.com/app/developer/qbpayments/docs/workflows/test-your-app)).
- Card errors are set by the cardholder name, for example `emulate=10401` for a decline ([Practice processing payments with mock data](https://developer.intuit.com/app/developer/qbpayments/docs/workflows/test-your-app)). The checkout has no separate cardholder name for QuickBooks Payments: we send the customer's first and last name, then a comma and the customer's account code (which we set), for example `emulate=10401, <account code>`. Enter the trigger as the customer's first name and leave the last name empty (or the other way round): if both are filled in, Intuit receives both and the trigger won't match. We always add the comma, and you can't leave out the account code, so the name Intuit receives is never exactly `emulate=10401`. Intuit's page doesn't say whether a longer name still matches, and our own tests don't cover these triggers.
- A card payment here is captured straight away, and sandbox charges settle at once, so voiding it gives error 10405: try a refund instead ([Practice processing payments with mock data](https://developer.intuit.com/app/developer/qbpayments/docs/workflows/test-your-app)).
- For ACH, switch on **Enable ACH** in the QuickBooks Payments connection settings here (it only appears when the account currency is USD), and enable ACH on the QuickBooks Payments account too. Then the amount sets the result: type it in dollars and cents, for example `3.33` for a decline or `5.55` for a success ([Practice processing payments with mock data](https://developer.intuit.com/app/developer/qbpayments/docs/workflows/test-your-app)). We show an ACH payment as pending first, and update it when QuickBooks Payments reports the outcome.

## Cards

The sandbox checks the card number against these test numbers and the expiry date against today's date, so use an expiry date in the future. It doesn't check the CVC or the billing address.

### Successful payments

| Card | Number | Notes |
| --- | --- | --- |
| Visa | `4112 3441 1234 4113` | |
| Visa | `4111 1111 1111 1111` | Used in our own tests, with expiry `01/30` |
| Mastercard | `5111 0051 1105 1128` | |
| American Express | `3782 822463 10005` | |
| Discover | `6011 0009 9550 0000` | |
| Discover | `6510 0000 0000 0000 069` | 19 digits |
| Diners Club | `3643 8999 9600 16` | |
| JCB | `3530 1113 3330 0000` | |

### Declines and errors

Use one of these as the cardholder name: in the checkout, enter it as the customer's first name and leave the last name empty (see [How to choose a test result](#how-to-choose-a-test-result)).

| Number or trigger | Result |
| --- | --- |
| Cardholder name `emulate=10401` | Declined (general payment decline) |
| Cardholder name `emulate=10301` | Error: card number is invalid |
| Cardholder name `emulate=10201` | Error: payment system error (a temporary issue) |

Sandbox card payments settle immediately, so you can try refunds but not voids. Intuit says voiding a card payment in a sandbox company returns error 10405. Our own tests with Intuit's sandbox void an authorisation that hasn't been captured, and that void succeeds.

### Address and CVC checks

The sandbox doesn't check the address (AVS) or the CVC, so these checks can't be tested in it.

## ACH (US bank accounts)

Use this bank account. The payment amount sets the result.

| Routing number | Account number | Result |
| --- | --- | --- |
| `322079353` | `11000000333456781` | Depends on the amount (below) |

| Amount | Result |
| --- | --- |
| `1.11` | Pending |
| `2.22` | Pending |
| `3.33` | Declined |
| `4.44` | Declined |
| `5.55` | Succeeded |
| Any other amount | Pending |

Intuit's page says `5.55` returns succeeded. In our own tests with Intuit's sandbox, a `5.55` ACH payment comes back pending when it is created.

Once the sandbox company has a successful `5.55` ACH payment, the refund amount sets the refund's result in the same way: `1.11` and `2.22` give pending, `3.33` and `4.44` give declined, and `5.55` gives succeeded.