Approval Rates Across NMI and Authorize.Net in One Dashboard

Every tool that promises one dashboard for NMI and Authorize.Net approval rates skips the hard part. The two gateways do not mean the same thing by approval, decline, or attempt. Stacking their reports side by side produces arithmetic you cannot trust. This post maps the two vocabularies onto each other so the comparison stays honest. It also names what the comparison still cannot tell you.

This post is for subscription merchants running card volume through both gateways at once. It assumes read only access to each gateway. It also assumes no change to how you route payments. If you need the single gateway version of the metric first, start with approval rates by MID, the merchant ID the bank sees. If you are still deciding whether to run two gateways at all, read our guide to running multiple payment gateways.

Why do NMI and Authorize.Net report approval rates differently?

The two gateways report differently because each one sorts outcomes into a different set of top level buckets, and the disagreement starts before you compare a single decline code. NMI's payment API, its application programming interface, returns three top level outcomes: 1 approved, 2 declined, 3 error. Authorize.Net returns four, because it adds 4 held for review. Neither gateway publishes the formula behind its own approval percentage. The two figures are not the same measurement.

• Different outcome counts. NMI has three top level results and Authorize.Net has four. The held for review state has no NMI counterpart, so it belongs in neither an approval count nor a decline count.
• Different homes for a gateway block. NMI gives gateway rejections their own code, 300, outside the 200 series processor declines. Authorize.Net scatters its filter rejections across numbered codes that all read as declines.
• Different report keys. Authorize.Net transaction and statistics reports are keyed to the settlement batch date and capped at a three month range. The NMI query API filters on the last modification date, so a later refund pulls that transaction into a later window.
• Different clocks. NMI returns everything in Coordinated Universal Time (UTC). The Authorize.Net batch date range uses merchant local time unless you append a Z, and its default cut off is 3:00 PM PST.
• Different duplicate windows. Authorize.Net suppresses duplicates for 120 seconds by default and up to 8 hours. The NMI dup_seconds setting runs to 7,862,400 seconds, about 91 days, and can be switched off.

The collision is literal. On NMI, response codes 250 to 253 mean pick up card, lost card, stolen card and fraudulent card. On the Authorize.Net reason code list, 250 is a blocked internet protocol (IP) address. Code 251 is a fraud detection filter you switched on. Codes 252 and 253 are two held for review states. A stacked report keyed on the bare number turns a dead card into a review queue.

What counts as an attempt, and how do you fix one denominator across both gateways?

An attempt is one authorization request that a bank answered. Visa scopes both approval and decline to an authorization response. A gateway rejection, a validation error or an abandoned checkout therefore sits outside the rate entirely. Fix that definition once and apply it to both raw logs. The two rates then become comparable.

Three populations need a decision rather than a deletion. The Authorize.Net held for review codes 252 and 253 both show the customer a success message. Only 253 has an issuer authorization behind it. Code 254 arrives later, when a person declines the payment after review. That code double counts one attempt if you pull the data twice. NMI partial approvals are the third case, where the bank authorized less than you asked for. An abandoned NMI three step redirect row and a 3-D Secure (3DS) drop off are simpler. Both are checkout abandonment, not a bank decision.

Then pin the window. Authorize.Net caps settled batch reporting at a 31 day window. Its history stops at January 1 two years before the current year. You have to assemble a longer comparison from chunked pulls. NMI returns Coordinated Universal Time (UTC) and keys on the modification date, not the authorization date. Pick transaction date in UTC on both sides. Rebuild the daily buckets yourself.

How do you map each gateway's decline codes to one soft/hard/data-error taxonomy?

Normalize onto the Visa categories, not onto either gateway vocabulary. Table 7-2 of the Visa Core Rules sorts every decline response code into four buckets. Category 1 means the issuer will not approve. Category 2 means the issuer cannot approve at this time. Category 3 means data quality: revalidate the payment information. Category 4 holds the generic codes.

Each bucket carries a different retry right. Category 1 is an absolute stop. It holds 12 codes: 04, 07, 12, 14, 15, 41, 43, 46, 57, R0, R1 and R3. After any of them, a merchant must not resubmit that payment credential again. Categories 2, 3 and 4 currently permit up to 20 attempts in 30 days. That ceiling is up from the 15 that most older guidance still quotes. The Visa System Integrity Fee bills the 21st attempt at $0.10 domestically and $0.25 across borders. The cross border figure rose from $0.15 on 25 April 2026. After a Category 1 decline the charge applies from the 1st resubmission, because there is no retry budget to spend. Acquirers rebrand the same charge: TD Merchant Solutions lists $0.15 per domestic transaction and $0.38 on foreign cards.

Two dates make a mapping table go stale. Visa added response code 83, fraud or security, to Category 2 effective 25 July 2026. An 83 is now a retryable soft decline rather than a hard one. The reattempt ceiling moved from 15 to 20 on 25 May 2025. A table built before mid 2026 misses both changes. Vendor guidance published as recently as October 2026 still prints 15.

How do you compare approval rate per MID instead of per gateway?

Compare approval rate per MID, the merchant ID, because the MID is what the bank actually sees. One NMI gateway account can route to many MIDs through the processor_id field. An NMI gateway rate is therefore a blend you chose. An Authorize.Net login carries a single processor configuration. On that side the login is the MID.

• On NMI, group by processor_id. The query API returns processor_id on every transaction, so a per MID series needs no extra tooling. NMI reporting also groups by payment processor for the same reason.
• On NMI, check the router first. Transaction routing splits by monthly volume amount rather than transaction count, and ATRI, the advanced transaction routing interface, load balances across an unlimited number of MIDs. If either is on, a gateway level trend is measuring the router.
• On Authorize.Net, treat each login as one MID. Its transaction records carry no processor or merchant account identifier, and the merchant profile holds one processor configuration.
• Expect your MIDs to differ legitimately. Acquirers assign the merchant category code (MCC) that fits each outlet, and two or more when separate lines of business share one outlet. Two of your own MIDs can sit in different risk categories.
• Read each MID configuration. On NMI, address and card code prechecks and duplicate checking are per processor settings, so two MIDs behind one gateway account can report different approval rates on identical traffic.

Vendor benchmarks make the case for the MID grain. Gr4vy publishes an example of a 92% overall authorization rate that falls to 85% on one acquirer for cards issued in Europe. Gr4vy's 2026 benchmarks run 85% to 92% for general ecommerce and 90% to 95% for optimized merchants. A single number per gateway cannot show you that gap.

Harborline Coffee, a subscription roaster, runs two MIDs on NMI and one on Authorize.Net. Its blended figures look like the Gr4vy example: 92% across the NMI account and 85% on Authorize.Net. Split per MID, both NMI MIDs sit near 92%. The whole gap is the Authorize.Net MID, whose own address filter rejects transactions the bank approved. This example assumes both sides already share the denominator you fixed. That shared denominator is the only reason the comparison means anything.

Which tools read both NMI and Authorize.Net without a migration?

Both gateways already expose read only access. So build a spreadsheet or a small script before you buy a product. Authorize.Net has an Account Analyst user role limited to read only functions such as reports. NMI issues API security keys under Settings, Security Keys. Each key carries the permissions of the user it is attached to.

• Native reports, no build. NMI approval rate reporting lives in the transaction snapshot, where an approval percentage column sits inside the declines block and can be grouped by payment processor. The Authorize.Net transaction statistics report gives charge, refund, decline, void, chargeback, return and error counts by settlement batch or date range.
• Read only API pulls. The NMI query API needs a security key and a user with API access enabled. The Authorize.Net unsettled transaction list returns up to 1000 of the most recent transactions, so a near real time pull truncates on a busy MID.
• Reporting connectors are asymmetric. CData ships a dedicated Authorize.Net driver, and its Arc payment connector supports Authorize.Net, Stripe, CyberSource, Chase Paymentech Orbital and Payeezy. NMI is not on that list, so pointing one reporting tool at both has no off the shelf NMI leg.
• A published map to start from. The Spreedly normalized values tables map the NMI response_code and the Authorize.Net error codes into one value set, and the page is readable without signing up. Its own caveat is that the normalization covers only the gateways listed there.

Whatever reads the data, four join keys carry the comparison: the MID, the raw code, the card BIN and the transaction time in UTC. Any multi gateway reporting you build sits on those four keys. Our integrations list shows which gateways and processors we read directly today.

Do you need payment orchestration just to compare two gateways?

No. Orchestration changes where payments go, and comparing two gateways changes nothing about routing. Published orchestration pricing runs $0.01 to $0.10 or 0.5 to 5 basis points per transaction. Simpler multi provider setups add $2,000 to $15,000 a month. Enterprise scale setups run $15,000 to $60,000 a month.

Keep the two decisions apart for a sharper reason. Orchestration vendors note that the per transaction fee can apply per payment attempt rather than only to successful transactions. A vendor that bills per attempt charges you for each decline you measure once you put it in front of both gateways. Buy orchestration when you want failover and routing rules you can change. Segmenting a rate you already have costs nothing.

What can a merged cross-gateway approval view not tell you?

The comparison cannot tell you what the other gateway would have done with the same transaction. You have no issuer side comparison to run. The two gateways share no attempt identifier. You also get no view of retries an acquirer ran on your behalf. Cross-gateway payment analytics explain your own mix, not the behavior of the banks.

• Known. The code mix per MID, the share of declines that were your own filters, and the count of declines per card. All three fall out of the raw logs once the mapping is in place.
• Unknown. Whether a declined card would have been approved on the other MID. Visa forbids changing the acquiring identifier, country, MCC, point of sale fields or the ecommerce indicator between a decline and a reattempt, so you cannot test it by rerunning the decline elsewhere.
• Unknown. Whether Mastercard said the decline was retryable, because the merchant advice code is missing from the NMI payment API response and limited to TSYS backed accounts on Authorize.Net.
• Unknown. The raw issuer code on the Authorize.Net side. It returns a response code, a reason code and a description, and its rawResponseCode field is scoped to PayPal. NMI returns processor_response_code on every action.
• Assumed. That a card seen on both gateways is the same card. Both expose a BIN and a masked number only, so a count of declines per card is an estimate rather than a reconciliation.
• Assumed. That retries are collapsed. A gross rate counts a card approved on the fourth try as four attempts and one approval, so the gateway that retries harder looks worse on identical traffic.

The decline pattern matters beyond lost revenue. Acquirer side programs threshold on the decline count per card rather than on a rate. Published examples include 10 or more declines on one card in 24 hours, or 20 or more in 30 days. The Mastercard transaction processing excellence fee bites near 10 retries in 24 hours and 35 in 30 days. It runs $0.30 to $0.55 per excess attempt. The US rate rose to $0.50 in January 2025. A gateway approval rate dashboard that shows one number per gateway cannot see any of it.

What should you check first when one gateway's approval rate falls?

Check your own definitions before you suspect the banks. Most sudden gaps between two gateway reports come from taxonomy or denominator drift. A filter setting changed, a checkout field moved, a duplicate window changed, or a code changed category. Genuine issuer degradation is real, and it is the last thing to test, not the first.

1. Confirm the window. Check that both pulls cover the same hours in UTC and that neither is keyed to the settlement batch date.
2. Re-run the exclusions. Count the zero dollar checks, suppressed duplicates, abandoned rows and held for review rows separately, and confirm the denominator rule did not move.
3. Split your own rejections out. On Authorize.Net, codes 27, 45, 65, 250 and 251 are your settings, and the address verification rejection defaults include B, E, R, G, U, S and N, several of which mean the check could not be performed rather than a mismatch.
4. Compare the code mix, not the headline. Visa requires issuers to keep sending the same Category 1 code once sent, so a sudden shift in the mix points at a change on your side.
5. Drop to the MID. Group by processor_id on NMI and by login on Authorize.Net, then check whether routing moved volume between MIDs.
6. Read the MID configuration. Authorize.Net codes 28, 30, 31 and 35 are merchant setup and processor provisioning faults that read as approval rate loss.
7. Only then look at the banks. Group the remaining Category 2 and Category 3 declines by issuing bank and BIN before concluding that issuer behavior changed.

If the drop survives all seven checks, treat it as real. The next step is a structured investigation of the decline mix. Our walkthrough of an approval rate drop analysis covers that path.

1. Pull both gateways by transaction date in UTC rather than by settlement batch, so the day boundaries line up.
2. Filter to card sale and auth attempts only, and drop refunds, captures, voids and zero dollar card checks.
3. Move your own address, card code and fraud filter rejections into their own bucket on both sides.
4. Write down one rule for Authorize.Net held for review rows and keep it next to the number.
5. Map every NMI response code and every Authorize.Net reason code to a Visa category, keeping the raw code in the row.
6. Group by MID using processor_id on NMI, and treat each Authorize.Net login as its own MID.
7. Count declines per card over 24 hours and over 30 days, so the 20 in 30 ceiling stays visible.
8. Re-read the mapping each quarter, because Visa moved code 83 into Category 2 on 25 July 2026.

Frequently Asked Questions