Custom build onlyLast verified 2026-09-11 · Reviewed by a person 2026-09-25
There is no maintained Authorize.net cartridge for Salesforce B2C Commerce: neither AppExchange nor Authorize.net's own partner directory lists one, so connecting the two means building a custom SFRA cartridge against the Authorize.net API using B2C Commerce's payment hooks. The Visa-owned sibling Cybersource does maintain a free SFCC cartridge, but it needs a Cybersource merchant account and does not route to an Authorize.net gateway account.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 Salesforce Commerce Cloud (B2C) integration itself has not been run.
Sources checked: 11 claims from 8 sites, listed at the foot of the page.
Connects through Custom cartridge: register a custom payment processor in Business Manager and implement the dw.order.payment.* hooks, calling createTransactionRequest with an Accept.js nonce or an Accept Hosted form token. Biggest gotcha: The Cybersource cartridge is not an Authorize.net bridge.
How it connects
Method
Custom cartridge: register a custom payment processor in Business Manager and implement the dw.order.payment.* hooks, calling createTransactionRequest with an Accept.js nonce or an Accept Hosted form token.2
Depends on the checkout mode you choose; see the gotchas below.3
What works on this platform
Pre-built integration capabilities
N/A — there is no maintained connector to verify; its capabilities depend on what a merchant builds.
Gateway capabilities potentially available to a custom implementation
These are not capabilities of a connector — there is no maintained connector here. They are what Authorize.net's own API supports, informational for anyone scoping a custom build.
Authorize.net supports this at the API level; whether a custom build exposes it depends on what gets implemented.
Testing it
Create a free Authorize.net sandbox account and store its API Login ID and Transaction Key (never production keys; mixing them returns reason code 13) as service credentials on an On-Demand Sandbox. Use the testing guide's card numbers, point Accept.js or Accept Hosted at the test endpoints, and register a webhook URL on a publicly reachable sandbox storefront; verify the X-ANET-Signature HMAC-SHA512 with the Signature Key. Assert the order's payment instrument carries the transaction ID and that the authorize hook returns an error status on a decline.5
UAT-Ops runs integration flows like this against the real sandbox and keeps the evidence. Get one email when it opens.
Gotchas
The Cybersource cartridge is not an Authorize.net bridge
Authorize.net and Cybersource share an owner (Cybersource bought Authorize.net in 2007; Visa bought Cybersource in 2010), so teams often assume Cybersource's free SFCC cartridge will take Authorize.net credentials. It will not: it is configured with Cybersource merchant keys and Cybersource endpoints, and none of its release notes mention Authorize.net. Switching to it means opening a new Cybersource merchant account, not changing a setting.
Two Cybersource listings, two compatibility claims
If you take the Cybersource route, check which cartridge you are installing. AppExchange carries both a REST and a SOAP Cybersource cartridge. The GitHub README for release 26.1.3 (2026-09-10) claims SFRA 7.0.0 compatibility, while Cybersource's developer page still says SFRA 6.3 and below. Confirm against the release history for the exact tag you deploy.
Without a vendor cartridge, your own cartridge has to implement the B2C Commerce payment hooks: authorize, validateAuthorization, reauthorize, capture, refund and releaseAuthorization, each returning a Status object. No vendor ships these hooks for Authorize.net, so every one is your code to write, test and keep working through SFRA upgrades.
A custom SFRA card form tokenised with Accept.js puts the merchant in SAQ A-EP. To stay at SAQ A, use Accept Hosted or the AcceptUI hosted form. Accept Hosted's iframe modes need an iframe communicator file served from the storefront domain, and both the nonce and the form token expire after 15 minutes, so a slow checkout has to fetch a fresh one.
Last verified 2026-09-11 · 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.