Prerequisites
- An Authorize.net merchant account
- Commerce accessible over HTTPS (required for Accept.js)
- Accept.js requires the client to have JavaScript enabled
Configuration
Go to Admin → Settings → Payment Gateways → Authorize.net and fill in:
| Field | Where to find it |
|---|---|
| API Login ID | Authorize.net Merchant Interface → Account → Settings → API Credentials & Keys |
| Transaction Key | Authorize.net Merchant Interface → Account → Settings → API Credentials & Keys |
| Public Client Key | Authorize.net Merchant Interface → Account → Settings → Manage Public Client Key |
| Sandbox mode | Toggle on for testing |
Click Save and enable the Authorize.net toggle.
Getting Your Credentials
API Login ID and Transaction Key
- Log in to the Authorize.net Merchant Interface
- Go to Account → Settings → Security Settings → API Credentials & Keys
- Copy your API Login ID
- To get a Transaction Key, select "New Transaction Key" and confirm with your secret question answer
- Copy the new Transaction Key immediately — it is shown only once
[!WARNING] Generating a new Transaction Key invalidates the previous one after a short grace period. Update Commerce immediately after generating a new key.
Public Client Key
- In the Merchant Interface, go to Account → Settings → Security Settings → Manage Public Client Key
- If no key exists, click Generate New Public Client Key
- Copy the key
[!IMPORTANT] The Public Client Key is safe to expose in browser-side JavaScript. It is used by Accept.js to tokenise card data. The API Login ID and Transaction Key must remain server-side only.
How Accept.js Tokenisation Works
Authorize.net uses Accept.js — a JavaScript library that handles card data entirely in the browser:
- The client enters their card details into an Accept.js-powered form on the Commerce payment page
- Accept.js sends the card data directly to Authorize.net's servers — card numbers never pass through your server
- Authorize.net returns an opaque payment nonce (token)
- Commerce receives the nonce and submits it to the Authorize.net JSON API to complete the charge
- Commerce marks the invoice paid and sends the receipt email
This design means raw card numbers are never stored or transmitted by your server, significantly reducing PCI DSS scope.
[!TIP] Because card data goes directly to Authorize.net, your server only ever handles the payment token. This qualifies you for SAQ A-EP under PCI DSS rather than the more demanding SAQ D.
Refunds
Authorize.net refunds are processed via the Commerce refund interface (Admin → Invoice → Payments → Refund). The Authorize.net refund API requires the last four digits of the card used for the original payment. Commerce stores these in payments.card_last_four at charge time.
If card_last_four is missing for a payment (e.g. a very old record), the refund API call will fail. In this case, issue a credit note instead and process the refund manually through the Authorize.net Merchant Interface.
Sandbox Testing
- Enable the Sandbox toggle in Commerce gateway settings
- Use credentials from your Authorize.net sandbox account
- Use the following test card:
| Field | Value |
|---|---|
| Card number | 4111 1111 1111 1111 |
| Expiry | Any future date (e.g. 12/30) |
| CVV | 123 |
Sandbox transactions appear in your sandbox Merchant Interface but do not process real money.
[!TIP] The Authorize.net sandbox is separate from your live account. Create a sandbox account at developer.authorize.net if you do not already have one.
Transaction Settings
Commerce uses the AUTH_CAPTURE transaction type by default — this authorises and captures the payment in a single step, so funds settle without a separate capture action.
If you need to change this behaviour (e.g. AUTH_ONLY for pre-authorisation), modify the gateway class or open a feature request.