NMI Test Cards: Numbers, Declines & Sandbox 3DS

Use the following public NMI test values in the documented sandbox or test environment. Keep payment processing tests separate from live customer traffic. The standard payment cards and the sandbox 3DS scenarios are different references, so choose the values for the integration you are testing.

NMI test card numbers.

Use expiration 10/29. NMI also publishes ACH account 24413815 and routing 490000018 for testing. These are the provider's documented test values, not credentials for real payments. NMI testing methods and values.

Trigger declines, errors and matching responses.

For standard payment testing, NMI documents response triggers based on the amount and submitted field values. A decline and an integration error should take different paths through your application. Test both, along with how you handle the AVS and CVV results.

These values are described in NMI Test and Deploy. Verify the response code your chosen API returns and map it to a useful customer message. A simulated decline does not establish which real production declines may be retried.

Choose the right test environment.

• Dedicated sandbox: use separate sandbox credentials and endpoints for development. Transactions are simulated.
• Per-transaction testing: NMI's testing reference describes a test flag. Verify support in the exact API/version you use; do not assume the field belongs in every endpoint.
• Account-wide Test Mode: the setting affects the merchant account's traffic. Valid cards can receive simulated approvals without funds moving. Do not enable this on an account serving live customers.

A successful-looking order is not proof that funds settled. NMI explains that Test Mode transactions do not go to the card or ACH processor. Keep test orders out of live fulfillment and customer notifications, and verify the environment explicitly before launch. NMI Test Mode documentation.

Sandbox 3DS test cards.

These values test authentication outcomes in NMI's sandbox. A successful 3DS result is separate from the payment authorization result. Run the full flow so your integration sends the required authentication data with the subsequent payment request.

For the sandbox challenge, code 12345 produces the documented successful response; another code produces failure, and Cancel produces an incomplete response. NMI sandbox authentication guide.

Check the complete order flow.

1. Approved sale: confirm that order and transaction records agree.
2. Decline and error: show an appropriate message and avoid creating a paid order.
3. Authorization/capture: if your workflow separates them, test both and authorization expiry handling.
4. Refund and void: verify the supported operations and resulting reports.
5. Recurring charge: verify saved credentials, billing schedule and applicable transaction flags.
6. Retries and callbacks: confirm repeated submissions or notifications cannot create duplicate orders.
7. Authentication: test success, failure and cancellation.
8. Environment separation: verify production configuration without exposing test or secret credentials.

NMI itself provides recurring billing and customer vault functionality. If Admoji coordinates your checkout and CRM workflows around a supported gateway, test both systems together. Confirm your exact gateway setup in the platform evaluation. See our subscription payment gateway checklist.

NMI testing questions.