Built-in connectorLast verified 2026-09-11 · Reviewed by a person 2026-09-24
Yes. Authorize.net is one of BigCommerce's built-in gateways, set up in the control panel with an API Login ID, Transaction Key and Payment Gateway ID, and documented by BigCommerce. It is an Open Payment Provider, not an embedded one, so self-serve stores pay BigCommerce a monthly fee of 0.6% to 2.0% of the GMV that goes through it, on top of Authorize.net's own charges.1
UAT-Ops testing: Authorize.net's sandbox was tested by UAT-Ops on 2026-09-11 with the directory's card flow (5 passed, 1 expected rejection) → evidence on the Authorize.net hub. The BigCommerce integration itself has not been run.
Sources checked: 14 claims from 5 sites, listed at the foot of the page.
Connects through Built-in gateway enabled in the BigCommerce control panel (Settings > Payments) with API Login ID, Transaction Key and Payment Gateway ID; also a compatible gateway for the server-side Payments API. Biggest gotcha: Authorize.net now carries a BigCommerce fee.
How it connects
Method
Built-in gateway enabled in the BigCommerce control panel (Settings > Payments) with API Login ID, Transaction Key and Payment Gateway ID; also a compatible gateway for the server-side Payments API.1
No app fee. On self-serve plans BigCommerce charges an Open Payment Provider Fee on Authorize.net GMV: 2.0% Core, 1.0% Growth, 0.6% Scale, 0% Performance. Authorize.net's own fees are extra.2
Checkout modes
optimized one page checkout, custom checkout, payments api1
What works on this platform
Yes: a source confirms it on this integration. Not verified here: the gateway supports it, but no source confirms this integration exposes it. No: not available. A capability with no source either way is left off.
Authorize.net supports this; no source confirms it on this integration.
Capability status reflects the integration and documentation available at the time of verification, not necessarily every capability of the underlying gateway or platform.
Testing it
Create a free Authorize.net sandbox account and paste its API Login ID, Transaction Key and Payment Gateway ID into the Authorize.net settings of a BigCommerce sandbox or trial store. Keep the Authorize.net sandbox itself in Live Mode, because Test Mode stores nothing and returns transaction ID 0. BigCommerce's own Test Mode toggle is only for trying the checkout flow. Mixing sandbox and production credentials returns reason code 13. Use test Visa 4111111111111111 with any future expiry, and billing ZIP 46282 to force a decline. Check that the order and the Authorize.net transaction ID match, that Authorize only leaves the order awaiting capture, and that a refund fails until the batch settles. The Payments API cannot use BigCommerce's Test Payment Gateway, so API tests need the Authorize.net sandbox.3
UAT-Ops runs integration flows like this against the real sandbox and keeps the evidence. Get one email when it opens.
Gotchas
Authorize.net now carries a BigCommerce fee
Authorize.net is built into BigCommerce, but it is not on the Embedded Payment Provider list. Since 1 June 2026, self-serve stores pay BigCommerce a monthly Open Payment Provider Fee on the GMV processed through it: 2.0% on Core, 1.0% on Growth, 0.6% on Scale. That comes on top of Authorize.net's own gateway and transaction fees. A Core store taking $50,000 a month through Authorize.net owes roughly $1,000 to BigCommerce alone, so compare the cost against an embedded gateway before migrating.
BigCommerce says plainly that its Authorize.net integration does not support 3D Secure. Stores selling into regions that require strong customer authentication, or relying on a 3DS liability shift to fight chargebacks, cannot get it here. Fraud screening is left to Authorize.net's own tools and whatever address and CVV checks you enforce. If 3DS is a hard requirement, pick a gateway whose BigCommerce entry lists it.
BigCommerce's Authorize.net settings have a Test Mode toggle for trying out the checkout. Authorize.net's sandbox account has its own Test Mode, and Authorize.net says to leave that off: sandbox Test Mode stores nothing and returns transaction ID 0, so the BigCommerce order ends up with no real transaction to capture or refund. Keep the sandbox in Live Mode and test with sandbox credentials. Mixing sandbox and production credentials always fails with reason code 13.
Authorize.net's ecommerce page lists BigCommerce among its integrations and says merchants can take eChecks through platform checkouts. BigCommerce's own Authorize.net article lists cards, Apple Pay, Google Pay and stored cards, but no eCheck. Its Transactions API also limits ACH to Adyen, Braintree and Stripe. Assume no eCheck at BigCommerce checkout unless you can confirm it in a test store.
Refunds wait for settlement; multicurrency needs extra accounts
BigCommerce can only refund an Authorize.net payment after it settles, and batches settle every 24 hours, so a same-day cancellation cannot be refunded straight away. Each additional transactional currency also needs its own Authorize.net merchant account. Stored cards will not work until Customer Information Manager is enabled on the Authorize.net account.
Last verified 2026-09-11 · Reviewed by a person 2026-09-24
Integration capabilities, requirements, pricing, availability, and vendor policies may change over time. UAT-Ops documents information based on the authoritative sources and testing available at the time of review.
Where newer information, testing, or vendor documentation materially changes a published claim, UAT-Ops may revise the page to reflect the most current verified information. Readers should confirm time-sensitive requirements with the relevant vendor before making production or purchasing decisions.