NMI

Adapter 0.1.0, documentation reviewed 2026-10-25. Overall status: limited.

Capabilities

Supported input

Notification delivery

• Repeated deliveries are recognized by event_id together with event_type.
• Delivery order: not documented by the provider.
• Make the webhook handler idempotent: record processed event_id values and also check the transaction_id and the transaction condition before acting. NMI re-attempts a delivery up to 20 times over about 3 days until it receives HTTP 200, but does not document whether re-attempts keep the same event_id.

Known limitations

• White label: NMI lets partners re-brand the gateway (logos, colors, URLs), so the same Classic and webhook formats come from many reseller brands and hostnames. Detection says NMI format; it cannot tell NMI from a reseller, and Classic responses carry no provider marker, so their detection confidence is capped below certainty. NMI's Authorize.Net and Sparrow emulators produce foreign formats that are not attributed to NMI.
• Classic responses are recognized from the documented field combination (response, responsetext, avsresponse, cvvresponse and a 3-digit response_code) when they arrive as form data or a raw HTTP response. The documentation renders examples as JSON objects; such JSON copies are not recognized. A raw HTTP response with Content-Type text/plain (as in NMI's code examples) is not parsed as form data by PandaPayLens today.
• The response field is read first. NMI's own example "Failed to Create Plan" pairs response=3 with response_code=100, so response_code is never trusted alone: when response and response_code disagree the record keeps the outcome given by response (unknown for response=3 without a documented error code) and the conflict is shown with insufficient confidence.
• response_code is NMI's gateway mapping. Raw processor codes (processor_response_code in webhooks) have no documented table and are shown, not decoded. merchant_advice_code values are not documented and are shown, not interpreted. HTTP 429 (system-wide rate limit) without a body carries no NMI marker and is not attributed.
• AVS and CVV results are informational. AVS B is listed twice by NMI (address only matches, and AVS not available) and is shown as ambiguous. A no-match result is mentioned on a decline only as a possible factor; NMI does not state that it caused the decline.
• Classic responses carry no amount (amount_authorized has no currency) and do not say which earlier transaction a capture, void or refund belongs to. Capture and void keep the authorization's transactionid in NMI's examples, so they group with it; a refund gets a new transactionid and no parent field, so it cannot be linked to the original payment.
• orderid / order_id is an optional merchant reference that can be reused across attempts and is never used for correlation. customer_vault_id is a stored-credential reference and is only flagged as present.
• Webhooks: content type, delivery order and whether re-attempts keep the event_id are not documented. Repeated deliveries are recognized by event_id together with event_type, because NMI's own samples reuse one event_id for different events. Webhook-Signature (t=nonce,s=HMAC) cannot be verified without the merchant's signing key; a pasted webhook is never treated as authentic and the header value is never copied.
• Webhook action.date is used as event time only when it has the 14-digit YYYYMMDDhhmmss form, read as UTC as documented for the Query API; the webhook pages do not restate its format or time zone. Otherwise the timeline falls back to input order.
• Transaction webhooks set isRecurring only when action.source is recurring. A subscription_id on transaction events is not documented, so recurring charges are not linked to their subscription. Recurring events read only subscription_id from event_body; plan event bodies are not described in the research.
• Settlement batch events are expanded into one settlement event per documented transaction_ids entry (at most 500 per batch). Chargeback batch events are summaries with chargebacks[] (id, date, amount, reason); whether a chargeback id is a transaction id is not documented, so chargebacks are not linked to payments, and their amount format and currency are not documented, so no amount is normalized. NMI sends chargeback events only if the processor supports chargeback reporting.
• transaction.*.unknown events and condition unknown mean an unknown processing error; their outcome stays unknown and no retry is suggested before the transaction is looked up.
• REST API v5 JSON (transactions and E_* errors) and Merchant Sign-Up partner webhooks are recognized but not analyzed. Query API and Three-Step Redirect XML are not parsed. Collect.js, Gateway.js 3-D Secure callbacks and CardEase XML are out of scope.
• NMI documents no high-risk sector and sells only through partners (ISOs, ISVs). Sector eligibility depends on the partner, the acquiring bank and the connected processor; approval for one sector does not imply another. The relationship between NMI Payments and Anovia Payments is not explained in the documentation read, so merchant_account_intermediary is not claimed.

Examples

• NMI: declined, insufficient funds: A Classic Payment API response decoded from response and response_code.
• NMI: webhooks for auth, capture and refund: Transaction webhooks for one payment in one timeline.

Provider documentation

• Payment API (transact.php)
• Response codes
• Rate limiting
• Query API
• Webhooks overview
• Webhook retry logic
• Transaction events
• Integration Portal
• Customizable white-label payment gateway

PandaPayLens is not affiliated with NMI. Pasted notifications are never treated as verified: PandaPayLens does not check webhook signatures.