BigCommerce still lists native connections for NMI and Authorize.Net under Online Payment Methods, which keeps third-party specialty acquiring in reach when a platform’s own payment rail will not underwrite a regulated catalog. Merchants who already hold MIDs on those gateways can wire credentials into Settings rather than rebuilding checkout from scratch, provided the storefront uses a supported checkout mode and the catalog stays inside Commerce’s Acceptable Use Policy.
That path matters for high-risk operators who leave Shopify Payments, Square, or similar hosted rails after a vertical cutoff. The cart still needs a gateway that will accept the MID. BigCommerce’s built-in NMI and Authorize.Net modules are the documented starting point. Custom hosted fields or a headless Payments API integration remain necessary when the native app cannot vault instruments, route multi-MID failover, or support a currency outside the store default.
What the native NMI connection exposes
BigCommerce’s Help Center article “Connecting with NMI” places the setup under Settings, Payments, Online Payment Methods, then NMI. The store needs Optimized One-Page Checkout or Custom Checkout. Staff accounts need Manage Payments and Manage Settings permissions. Merchants enter an NMI username and password, choose a transaction type of Authorize and capture or Authorize only, optionally require CVV, and enable the credit and debit checkbox.
NMI through that built-in connector supports only the store’s default currency. Authorize-only mode supports later manual capture. Incorrect credentials are a common failure mode during first connection. NMI’s integration portal guidance for BigCommerce built-in support tells merchants to ask their merchant service provider to enable “allow merchant override” when CVV or related processor settings block the native checkout behavior.
Stores that already run custom PHP against NMI’s classic transact.php endpoint, or that are migrating to NMI’s JSON Payments API, should treat the native BigCommerce module as a different integration surface. The NMI Classic API migration notes cover server-side reshapes that do not replace what the BigCommerce admin connector configures.
What the native Authorize.Net connection exposes
BigCommerce’s “Connecting with Authorize.net” Help Center article asks for an API Login ID, a transaction key, and a payment gateway ID (up to seven digits). The same connection can offer Apple Pay and Google Pay digital wallets when those wallet flows are configured. Supported store countries listed for the Authorize.Net connection include the United States, Canada, the United Kingdom, Australia, and additional European markets named on that page.
Authorize-only gateway configuration on BigCommerce follows the Payments API rule that authorization happens at processing time and capture happens later through the control panel or the Capture API. That split is useful when fulfillment or compliance review has to finish before settlement.
Payments API differences that still force custom work
BigCommerce’s public Payments API compatibility table draws a sharp line between the two gateways. Authorize.net supports stored instruments and raw card data. NMI supports raw card data only and does not support stored instruments on that API table. Merchants who need card-on-file rebills, vaulted instruments through the Payments API, or headless charge flows should confirm that matrix before promising a lift-and-shift onto native NMI alone.
Hosted fields, Collect.js-style tokenization outside the admin connector, or a custom checkout SDK still matter when the specialty MID needs instrument vaulting that the native NMI Payments API path cannot provide. Firearm accessory sellers who previously compared catalog control on WooCommerce and BigCommerce already hit the same fork between platform payment modules and specialty gateway plugins in that platform comparison.
Acceptable use puts compliance on the merchant
Commerce’s Acceptable Use Policy, last revised July 31, 2025, limits use of the Website and Services to lawful purposes. Its Highly Regulated Products section requires merchants to represent that products and services comply with applicable local, state, federal, and international law. Commerce disclaims responsibility for evaluating legality and puts indemnification on the merchant. The published AUP page does not print a product-by-product ban list.
That structure is different from a vertical ban published as a named SKU list. Merchants still have to confirm whether BigCommerce Payments (the PayPal-powered rail) is available for their vertical. Industry practice and processor underwriting often leave that rail unavailable for high-risk catalogs while third-party gateways such as NMI and Authorize.Net remain the practical card path. Treat that distinction as operational reality confirmed with the account team, not as a sentence copied from the AUP itself.
BigCommerce’s native NMI and Authorize.Net connectors give regulated catalogs a documented admin path onto specialty MIDs, with clear credential fields, auth-versus-capture choices, and known currency and vaulting limits. Merchants should verify AUP fitness for the catalog, match checkout mode and staff permissions, and escalate to hosted fields or the Payments API only where stored instruments, multi-currency, or multi-MID routing exceed what the built-in modules expose.