Authorize.Net

WooCommerce Payment Plugin Checklist for Authorize.Net and NMI Stores

Developer marking a WooCommerce payment plugin QA checklist beside a laptop showing payments settings
Illustration of a developer working through a WooCommerce payment plugin checklist at a standing desk.

By E-commerce 4 Internet Marketers Editorial

Misconfigured WooCommerce payment plugins are a common cause of failed renewals, unexplained declines, and refund friction for merchants who sell regulated or higher-risk products. Authorize.Net and Network Merchants, Inc. (NMI) both support tokenization, stored payment methods, and WooCommerce-facing refunds when the plugin and gateway account are set up correctly. This listicle is a practical ten-check QA plan for website owners and developers before a store goes live or after a credential change.

It is not underwriting advice. Confirm that your acquiring bank and merchant category code allow your catalog before you invest in plugin configuration.

1. Confirm CIM or Customer Vault before saved cards

Authorize.Net Customer Information Manager (CIM) stores customer and payment profiles on Authorize.Net servers so the store can charge returning customers and recurring orders without holding raw card numbers. Authorize.Net’s Customer Profiles documentation describes profiles as a PCI-oriented way to tokenize payment data for repeat and recurring use.

The official WooCommerce Authorize.Net Gateway documentation states that CIM must be enabled on the Authorize.Net account if you use WooCommerce Subscriptions, WooCommerce Pre-Orders, or saved payment details. Additional monthly costs may apply. Tokenization in the plugin settings is required for Subscriptions or Pre-Orders.

For NMI, stored cards live in the Customer Vault. NMI’s Payment Component docs describe saving a card to the Customer Vault, then charging the vault ID later or pairing it with recurring billing. WooCommerce plugins such as Gain Commerce NMI Payment Gateway for WooCommerce document Collect.js tokenization and remote Customer Vault storage so card numbers do not sit on the WordPress server. Premium features on that plugin include customer-selectable saved methods from the vault.

Check: create a test customer, save a payment method, confirm a profile or vault ID exists in the gateway console, then place a second order with the saved method.

2. Keep card data off the server with Accept.js or Collect.js

Direct gateways that post card fields to your server raise PCI scope. WooCommerce’s Payment Gateway API distinguishes form, iframe, and direct integrations, and notes that direct gateways need SSL and may require a higher PCI level.

WooCommerce Authorize.Net includes Accept.js so card data is handled by Authorize.Net and the store can aim for a lower SAQ path (SAQ A-EP for the inline form option in the official docs). Authorize.Net’s Accept.js docs require separate sandbox and production JavaScript hosts and matching API Login ID plus Public Client Key pairs.

NMI recommends the Payment Component for new work, with Collect.js still documented for tokenization. Both approaches return a payment token that your server sends to NMI. Gain Commerce’s WooCommerce plugin states it uses Collect.js so sensitive card data never touches the web server, and it requires a valid SSL certificate.

Check: view checkout network traffic or plugin debug logs and confirm only tokens or opaque payment data leave the browser, not full PANs.

3. Wire webhooks for profile and transaction sync

WooCommerce’s gateway API documents WC-API callbacks for asynchronous payment status updates. For Authorize.Net’s official WooCommerce extension, webhooks notify the site when customer profiles or payment profiles are deleted in Authorize.Net. That matters for Subscriptions troubleshooting when a token disappears at the gateway.

Setup requires an API Signature Key in plugin settings, then the “Click here to enable webhooks” flow that pushes the endpoint into the Authorize.Net account. If webhooks were removed, WooCommerce > Status > Tools includes Reset Authorize.Net Webhooks.

NMI’s Recurring Transactions docs say recurring billing can emit webhook notifications so platforms stay in sync, and that Recurring Module sales still fire transaction.sale webhook events. Even when WooCommerce Subscriptions owns the schedule, transaction webhooks help reconcile captures, refunds, and failed sales.

Check: delete a sandbox payment profile (or fire a test sale webhook) and confirm the WooCommerce order or payment-method log records the event.

4. Treat 3-D Secure as a hard requirement check, not an assumption

Strong Customer Authentication (SCA) and 3-D Secure (3DS) rules differ by region and acquirer. The WooCommerce Authorize.Net FAQ states the extension does not support 3D Secure at this time because Authorize.Net’s API path used by the plugin does not accept the customer data required for 3DS v2 / PSD2 SCA. WooCommerce points merchants who need SCA toward asking Authorize.Net about CyberSource migration.

NMI’s Payment Component documents built-in payer authentication (3DS), including frictionless and challenge flows. Gain Commerce’s NMI plugin lists 3D Secure 2 as a Premium feature described as PSD2 / SCA compliant. NMI’s Recurring Module is unavailable in PSD2-mandated regions; those merchants must use Credential on File patterns instead.

Check: if you sell into SCA markets, verify 3DS is enabled end to end in sandbox with issuer challenge cards, or choose a documented SCA-capable stack before launch.

5. Prove refunds and voids from WooCommerce admin

WooCommerce refund docs distinguish automatic refunds (funds returned through the gateway from the Edit Order screen) from manual refunds (WooCommerce marked refunded while you repay the customer in the gateway dashboard). Changing an order status to Refunded or Cancelled alone does not return money.

WooCommerce Authorize.Net (version 2.0+) supports automatic credit-card refunds and voids from WooCommerce. Voids apply to uncaptured authorizations or unsettled charges. Authorize.Net does not accept partial voids. Attempting a partial refund before settlement can force a void path and fail. eCheck automatic refunds are not supported.

Gain Commerce NMI documents authorize, capture, refund, and void from the WooCommerce dashboard.

Check: run a full refund, a partial refund after settlement, and a void on an uncaptured auth. Confirm gateway receipts and WooCommerce order notes both show success.

6. Align authorize-only versus charge with fulfillment

Authorize.Net’s WooCommerce settings expose Transaction Type Charge or Authorization. Authorization requires a later capture from WooCommerce or the Authorize.Net control panel. Optional settings can auto-capture virtual-only orders or orders that move to a paid status. Capturing more than the authorized amount is not supported for card-not-present ecommerce per the plugin FAQ.

Gain Commerce’s NMI plugin documents authorize-now and capture-later from the WooCommerce dashboard (sale, auth, capture, refund, and void API paths). Catalogs that ship physical goods often authorize at checkout and capture at fulfillment so unpaid inventory is not released when compliance or stock checks fail.

Check: place an auth-only order, capture the correct amount after a simulated fulfillment delay, and confirm a second capture cannot over-capture.

7. Validate subscription renewals against token rules

WooCommerce Authorize.Net supports WooCommerce Subscriptions features, but subscriptions are driven by WooCommerce using CIM tokens rather than Authorize.Net Automated Recurring Billing (ARB). Renewals therefore fail when the customer profile ID and payment profile ID on the user no longer match the subscription record, or when the gateway token is missing.

A frequent renewal failure is “Card Code is required” when the Authorize.Net account still requires CSC. Authorize.Net cannot store card security codes for renewals, so that account-level requirement breaks merchant-initiated charges. Official guidance is to remove that requirement for recurring use.

Do not share the same Authorize.Net API credentials across multiple sites. Profile edits on one site can desync another. Prefer updating payment methods through WooCommerce (and the subscription Change Payment flow) rather than editing profiles only inside Authorize.Net, because the plugin pushes site changes outbound and does not fully mirror inbound Merchant Interface edits without webhooks and manual repair.

On NMI, WooCommerce Subscriptions support depends on the plugin. Gain Commerce documents automatic recurring payments only with WooCommerce Subscriptions plus its Premium add-on, using Customer Vault stored methods. Separately, NMI’s gateway Recurring Module can own schedules, but sandbox recurring does not submit live transactions, and PSD2 regions must use Credential on File instead.

Check: create a short-interval sandbox subscription, force a renewal, expire a card, update payment via My Account, and confirm the next renewal uses the new profile IDs.

8. Separate sandbox credentials from production credentials

Authorize.Net sandbox and production are separate environments with separate logins and API credentials. WooCommerce Authorize.Net Environment Test versus Production switches credential fields. Live credentials cannot be used in Test mode. Do not place a production Authorize.Net account into the Merchant Interface “Test Mode.” That returns dummy data for live traffic and does not match the plugin’s sandbox mode.

API endpoints differ as well (apitest.authorize.net versus api.authorize.net). Accept.js sandbox and production script hosts must match the credential environment.

NMI documents sandbox hosts such as sandbox.nmi.com with public tokenization keys and private API keys. Go-live steps replace sandbox public and private keys with production keys, keep the private key server-side only, and enforce HTTPS. Gain Commerce’s plugin adds an explicit Live versus Test environment toggle with documented test card numbers.

Check: run a known sandbox approval and decline, switch to production keys in a maintenance window, then place a low-value live auth you immediately void.

9. Turn on the right fraud signals without breaking renewals

Require CSC at checkout when your underwriting expects it, but disable account-level CSC requirements that block token renewals. Use detailed decline messages in WooCommerce Authorize.Net when you need clearer shopper errors, and keep Debug Mode off in production except during active incidents (logs go to checkout and/or WooCommerce > Status > Logs).

For NMI, review AVS and CVV responses recorded in order notes (Gain Commerce documents this). Dynamic descriptors, when enabled in that plugin and the NMI account, help customers recognize the charge. Confirm the descriptor text matches what your acquirer approved.

Also confirm Partial Authorization is off in Authorize.Net Account settings so odd partial-approval response codes do not create confusing WooCommerce orders.

Check: decline a test card, confirm the shopper message and order note are actionable, and confirm a renewal still succeeds without prompting for CSC.

10. Run a cutover checklist before production traffic

Before you point real buyers at the gateway, verify:

  1. SSL is valid on checkout (required by WooCommerce Authorize.Net and NMI plugin guidance, including local test environments for Authorize.Net).
  2. WooCommerce version and PHP meet the plugin requirements (Authorize.Net docs list WooCommerce 3.5+, WordPress 5.6+, PHP 7.4+; Gain Commerce NMI lists WooCommerce 8.0+ with High-Performance Order Storage).
  3. Cart and Checkout Blocks compatibility matches your theme (WooCommerce Authorize.Net documents blocks support, with Apple Pay still limited on blocks at the time of that FAQ).
  4. Production API Login ID, Transaction Key, and Signature Key (Authorize.Net) or public and private security keys (NMI) are stored only in plugin settings or server secrets, not in tickets or public repos.
  5. Webhooks point at the production site URL, not staging.
  6. Refund, void, capture, saved-card, and renewal tests all passed in sandbox with the same plugin version you will ship.
  7. Debug logging is disabled after sign-off.
  8. Billing descriptor, support URL, and policies match what underwriting reviewed.

High-risk and regulated catalogs face more underwriting scrutiny and dispute pressure than low-risk retail. A clean plugin configuration will not replace underwriting, but it removes self-inflicted declines and renewal outages that look like processor problems.

Sources