NMI (Network Merchants Inc.)

Two NMI options in the payment method list

The Foxy admin offers two NMI entries, and they are not interchangeable:

• NMI (Native integration) — Use it when: Always, for any new setup. This talks to NMI's own API.

• NMI (Authorize.net emulation, deprecated) — Use it when: Only if you are an existing merchant already connected this way.

If you are setting up NMI for the first time, choose NMI (Native integration) and skip the emulation section entirely.

Why an Authorize.net option exists at all

NMI has long published a "Gateway Emulator" that accepts transactions in Authorize.net's older AIM and SIM formats. Its purpose was migration: a merchant already integrated with Authorize.net could point the same integration at NMI's emulator URL and switch gateways without rewriting anything. Foxy's NMI (Authorize.net emulation) option is that path — Foxy sending Authorize.net-format requests to NMI.

It is a compatibility shim, not NMI's real API, and it inherits the emulator's limits. NMI states that the emulator does not support Authorize.net's XML AIM, CIM, ARB, DPM, Card Present or Transaction Details APIs. Foxy's native integration has no such ceiling, which is why the emulation entry is labelled deprecated.

What "deprecated" means here in practice

The word sits inside the option's own display name, but the emulation entry is still a live, supported gateway type in Foxy — it is not switched off, it is not hidden, and transactions on it still process. "Deprecated" is a recommendation, not an expiry date:

• Existing merchants on it: nothing breaks today. Your payment method keeps working and you do not have to act on any deadline that Foxy has announced.

• New merchants: do not choose it. There is no functional reason to, and it gives you strictly less than the native integration.

• Everyone: treat it as a path that will not receive new capability. Anything NMI adds, Foxy will add to the native integration.

Setting up NMI

NMI recommends creating a separate user in your NMI account for processing Foxy transactions, so the traffic is attributable and you can revoke it independently. These portal instructions were current as of December 2023 — tell us if your portal looks different.

1. 1

   Log in to your NMI Merchant Portal at https://secure.nmi.com/merchants/login.php.

2. 2

   In the left menu, go to Options > Settings > User Accounts and select Add a New User. Note the username and the password you set.

3. 3

   In the Foxy administration at https://admin.foxy.io, go to Settings > Payments.

4. 4

   Select the payment method set you want to use. If you only have one, it will be the Default Payment Method Set.

5. 5

   Click Add payment method + and choose NMI (Native integration).

6. 6

   Put the NMI user's username into Account Username.

7. 7

   Put that user's password into Transaction Key.

8. 8

   Click Create to save the payment method.

9. 9

   Test — including a live card before you assume things are working.

The panel is split into a Live setup block and a Test setup block carrying the same two fields. The credentials above go under Live setup. (The Live heading reads "Live setup (inactive)" while the payment method set has Use live credentials switched off — that reflects the state of the set, not a different set of fields.)

The Transaction Key field takes your password

This trips people up, so it is worth stating plainly: on this native integration, Foxy's NMI integration does not use an NMI API key. The field is called Transaction Key because that is Authorize.net's name for the second credential, and the label was carried over from Foxy's older Authorize.net-emulation NMI type without being renamed for the native API. The value Foxy wants in it here is the NMI user's password.

Do not paste the API key or key ID from Settings in the NMI portal. Doing so is the most common cause of the response code 122 error described below.

Note this mislabel is specific to the native integration. On the emulation path (below), "Transaction Key" is the genuinely correct name for that field, because the emulation path really does speak Authorize.net's wire protocol. Both NMI entries in the picker show the identical field label, which is exactly why it's confusing — the same words are accurate on one and wrong on the other.

Migrating from the emulation path to the native integration

If you are currently on NMI (Authorize.net emulation, deprecated), moving is straightforward, because both entries authenticate against the same thing: your NMI gateway username and password. On the emulation path NMI maps Authorize.net's API Login ID to your gateway username and its Transaction Key to your gateway password — which is exactly what Foxy's two fields already hold. There are no new credentials to obtain.

1. 1

   In Settings > Payments, open the payment method set carrying your current NMI configuration.

2. 2

   Add a new payment method, choosing NMI (Native integration).

3. 3

   Enter the same Account Username and Transaction Key values you are using now.

4. 4

   Run a test transaction, then a small live one.

5. 5

   Once it processes cleanly, remove the old emulation payment method.

What you gain by moving:

• Multi-currency processing. Supported on the native integration; not supported on the emulation path.

• Card verification. The native integration performs card verification automatically; the emulation path does not support it.

• Ongoing support. New NMI capability will land on the native integration only.

If you have live subscriptions running through the emulation path, raise a ticket with Foxy before you switch, so someone can sanity-check your specific configuration ahead of the next rebill. Nothing about the credential model suggests a problem, but a subscription book is not the place to find out.

Testing

Foxy provides shared test credentials for both NMI entries, so you can run test transactions without setting up your own account. Leave the Test setup fields as they are.

Those shared credentials exercise the integration only. Your production NMI account may have settings — ticket limits, duplicate checks, enabled card types, AVS and CVV rules — that the shared test account does not, so a clean test run is not a guarantee about your live account.

Obtaining a test account

If you need to test against your own account settings, contact your merchant service provider for a test account. NMI support will generally not issue one directly; it comes from whoever sold you the gateway.

Test card numbers

These work in test mode only.

• Visa — Number: 4111111111111111

• Mastercard — Number: 5431111111111111

• Discover — Number: 6011601160116611

• American Express — Number: 341111111111111

Use expiration 10/25 and CVV 999.

Advanced features

• Authorize only. Both NMI entries support authorization-only transactions, so you can authorize at checkout and capture later.

• Multiple currencies. Supported on the native integration, subject to the currencies enabled on your NMI account. Not supported on the emulation path.

• Card verification. The native integration runs card verification automatically, using a 1.00 verification amount for Visa, Mastercard, American Express and Discover.

• 3D Secure. Neither NMI entry supports 3D Secure through Foxy.

Important notes and caveats

• Use a dedicated NMI user. Per NMI's own recommendation, create a separate user account for Foxy rather than reusing your login.

• Username and password, never the API key. See above.

• Test with a live card before going live. Gateway-side account restrictions frequently only surface on real transactions.

Troubleshooting

"Overriding Duplicate Threshold is not allowed"

Your merchant account provider has that restriction switched on for your account. Contact them to have it removed — it cannot be resolved from the Foxy side.

Response Reason Code: 122

Three things cause this, in the order worth checking:

1. 1

   The credentials are wrong. Confirm you entered your NMI username and password, not an API key or key ID. This is the most common cause.

2. 2

   The transaction exceeds your maximum ticket amount. Your NMI account has a per-transaction ceiling. Only your merchant service provider's customer service team can approve raising it.

3. 3

   The gateway's duplicate transaction check is fighting you. NMI applies a duplicate-transaction window, 120 seconds by default. One merchant resolved this by asking their account rep to set the window to 3 seconds and enable the merchant override option. Discuss it with your own account rep rather than treating those numbers as a prescription — this is reported user experience, not an NMI-documented fix.

"The processor response format is invalid"

This comes from the processor behind NMI, not from Foxy. NMI support can tell you the reason, but the solution usually has to come from the processor directly.

One known case: the processor returns INV CVV2 MATCH, which NMI surfaces as a decline. That generally means the cardholder entered an incorrect card security code and the processor or issuing bank rejected the transaction.

Anything else

If a transaction is declined with a response code not covered here, contact NMI or your merchant service provider. They can see transaction detail that Foxy cannot.