Third-party pluginLast verified 2026-09-25 · Reviewed by a person 2026-09-25
Magento 2 no longer includes Authorize.net: Adobe deprecated the bundled module in 2.3.4 and removed it in 2.4.0. On current 2.4.x releases you install a Marketplace or Composer extension. Authorize.net publishes no Magento extension of its own, and Adobe's guidance names none, so every route is a third-party module; the one we could verify end to end, and by far the most downloaded, is ParadoxLabs' Authorize.net CIM module. It is free and Apache-2.0 licensed, supports 2.4.6 to 2.4.9, and offers Accept Hosted, Accept.js and inline card forms; ParadoxLabs sells optional support and installation separately.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 Adobe Commerce (Magento 2) integration itself has not been run.
Sources checked: 24 claims from 9 sites, listed at the foot of the page.
Connects through Composer-installed extension on the Commerce payment gateway framework (verified example: paradoxlabs/authnetcim). Biggest gotcha: The bundled module is gone, not just deprecated.
How it connects
Method
Composer-installed extension on the Commerce payment gateway framework (verified example: paradoxlabs/authnetcim)2
Maintained by
Third-party vendors (verified example: ParadoxLabs); Adobe no longer ships or maintains a module3
Depends on the checkout mode you choose; see the gotchas below.7
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.
The module's core function: ParadoxLabs' product page and GitHub README both document 'Pay by credit card or ACH (eCheck)', with Amex, Visa, MasterCard, Discover and JCB listed as supported card types.
ParadoxLabs' support portal states plainly: 'We will not be supporting Apple Pay or Google Pay with Authorize.Net at this time.' ParadoxLabs sells a separate Stripe extension that does add Google Pay, but that is a different module.
ParadoxLabs' support portal states plainly: 'We will not be supporting Apple Pay or Google Pay with Authorize.Net at this time.' Some other Marketplace vendors advertise wallets, but we have not verified them.
ParadoxLabs' support portal says Magento does not expose many Level 2 fields out of the box, so the extension does not enable them by default; adding the extra fields needs a custom 'before' plugin, not a setting.
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 (developer.authorize.net) and take its API Login ID, Transaction Key, Public Client Key (needed for Accept.js) and Signature Key. Enter them in Stores > Settings > Configuration > Sales > Payment Methods with the extension in sandbox mode, and keep the sandbox account in Live Mode. Pay with the sandbox test cards from the testing guide. Webhook notifications come from Authorize.net's servers, so a local site needs a public HTTPS tunnel or a staging host; verify the X-ANET-Signature header with the Signature Key.11
UAT-Ops runs integration flows like this against the real sandbox and keeps the evidence. Get one email when it opens.
Gotchas
The bundled module is gone, not just deprecated
Adobe deprecated the core Authorize.net integration in 2.3.4 and removed it in 2.4.0. A store upgrading from 2.3.x loses the payment method entirely unless an extension is installed first. Old configuration under the core method's settings does not carry over to a third-party module, so plan to re-enter credentials and to test refunds and captures on orders placed under the old method. Adobe's own payment reference no longer lists Authorize.net at all.
Authorize.net positions a merchant-built Accept.js form as SAQ A-EP, and its hosted form or Accept Hosted iframe as SAQ A. Magento extensions expose these as settings: ParadoxLabs offers Accept Hosted, Accept.js, and an inline form that it classes as SAQ D. Picking the inline option for styling convenience can multiply your compliance work, so decide the form type with whoever owns your PCI assessment.
Four different credentials, and they are not interchangeable
API calls authenticate with the API Login ID and Transaction Key. Accept.js also needs a Public Client Key, and Adobe documents 2.3.x checkouts freezing when that field was left empty. Webhooks are verified with a separate Signature Key: an HMAC-SHA512 of the body, sent in the X-ANET-Signature header. Mixing up the Transaction Key and the Signature Key is a common cause of webhook verification failures.
Sandbox and production are separate accounts with separate keys. Sending one environment's credentials to the other always returns response reason code 13, which looks like an authentication bug but is only an environment mix-up. Keep the sandbox account in Live Mode, because Test Mode stores nothing and returns transaction ID zero. After go-live, switch both the extension's environment setting and the keys together.
Strong customer authentication is not on offer here
ParadoxLabs' product page says Authorize.net does not support PSD2 strong customer authentication, and it points merchants who need SCA to its CyberSource module instead. Its documentation does not describe 3-D Secure for the Authorize.net module either way. If you sell to European cardholders, confirm how SCA will be handled before committing to Authorize.net on Magento.
Last verified 2026-09-25 · Reviewed by a person 2026-09-25
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.