NMI test cards.
The numbers, straight from the docs.

NMI test card numbers.

These are the card numbers NMI publishes in its testing documentation.¹ They simulate approvals in test mode or a sandbox account, and they're the same across brands' happy paths — the differences that matter (declines, AVS, CVV) are driven by amounts and field values, covered in section 02.

Triggering declines, errors, and AVS/CVV results.

The part most people miss: on NMI, the interesting responses are driven by the amount and field values you submit, not by special card numbers. Per NMI's testing docs¹:

Declines, fatal errors, and field mismatches are three different code paths in your integration. A subscription business lives or dies on the decline path — that's the one that runs unattended at 3 a.m. on rebill day — so test it deliberately, not incidentally.

Test mode vs. sandbox account.
Three ways to test, one big trap.

NMI's docs describe three testing methods¹, and they behave differently enough that picking the wrong one causes real problems:

• Sandbox account. A separate account purely for building and testing your integration — all transactions are simulated, nothing is ever charged. This is the right home for development and CI. Sandbox API keys come from your NMI sandbox account credentials.
• Per-transaction test flag. Send test_mode=enabled on a single API transaction with a test card. Useful for a one-off smoke test against an otherwise live setup without flipping the whole account.
• Account-wide test mode. Toggle a merchant account into test mode. While it's on, all valid credit cards are "approved" without actual charges or processing — including your real customers' cards.

Payer authentication (3DS) test cards.

If your integration uses 3-D Secure, NMI's sandbox docs publish a separate set of cards that simulate specific authentication outcomes² — frictionless flows, and challenge flows where the test challenge code is 12345:

Brand-to-number mapping as published on NMI's payer authentication testing page, observed September 3, 2026. Skip this table entirely if you're not running 3DS.

What to test before a subscription business goes live.

For a one-off ecommerce store, an approved sale is most of the story. For recurring billing, the sale is the easy transaction — the ones that break are unattended. Before launch, run each of these end to end (general good practice, not NMI-specific):

1. Straight sale. Test card, amount ≥ 1.00, confirm the approval lands everywhere it should — gateway, your database, the customer's email.
2. Auth + capture. If you authorize at signup and capture later (common for trials), test both halves separately, and test an auth you never capture.
3. Refund. Full and partial. Confirm your records and the customer notification both reflect it.
4. Void. Cancel a transaction before settlement and confirm your system doesn't count it as revenue.
5. Card-on-file rebill. Store the payment method, then trigger a recurring charge without the customer present. This is the transaction your subscription business actually runs on.
6. The decline path. Amount under 1.00 to force a decline, then watch what your system does: does it retry? Notify the customer? Mark the subscription past-due? This path runs unsupervised — it has to work.
7. Error handling. Send an invalid card number and confirm your checkout shows a human error message, not a stack trace.
8. AVS/CVV responses. Use the match values (address 888, zip 77777, CVV 999) and confirm your fraud rules read the responses the way you intend.
9. Test mode off. Last step, every time: flip test mode off and verify with one real card and a refund.

Common mistakes.

• Launching with test mode on. Covered above, worth repeating: fake approvals look exactly like real ones until you check your bank account.
• Testing only approvals. If every test you ran was a happy path, your decline handling ships untested — and for subscriptions, declines aren't an edge case, they're a scheduled event.
• Assuming test behavior predicts production behavior. Test mode approves everything; production involves real issuers, real AVS, real fraud rules. Treat the sandbox as an integration test, then do a small real-money verification.
• Hardcoding test credentials. Sandbox keys in a config file have a way of surviving into production deploys. Keep environments cleanly separated.
• Testing the gateway but not the stack. An approval at the gateway isn't the finish line — confirm the order, the subscription record, the receipt email, and your reporting all agree.

Where NMI fits in a subscription stack.

NMI is a payment gateway: it moves the transaction between your site and your merchant account. What it doesn't do is the layer above — the checkout pages, subscription schedules, retry logic, upsells, and customer records that decide whether a subscriber stays. That's a billing layer's job, and it's what Admoji does: a checkout and CRM that sits on top of your own merchant account, with NMI gateways supported alongside Stripe, Authorize.net, and high-risk specialists.³ If you're still choosing the gateway itself, start with our guide to picking a subscription payment gateway — and once real rebills are flowing, chargeback prevention is the next thing to get ahead of.

Common questions.