Getting Started with Authorize.net Payment for Medusa

In this guide, you'll learn how to install and configure the Authorize.net payment provider for Medusa, prepare your Authorize.net account, set up the webhook and Google Pay, and switch from the payment-authorizenet-medusa plugin.

• Medusa v2.17.2 or later
• Node.js v22.23.4, v24.22.1, v26.12.1 or later
• An Authorize.net account. Test with a free sandbox account, and take real payments with a production merchant account
• Integration Module

yarn add @gorgo/medusa-integration @gorgo/medusa-payment-authorizenet

Add the configurations of the Integration Module provider and of the Medusa Payment Module in your medusa-config.ts file of the Medusa Admin application:

medusa-config.ts
1// ...
2const AUTHORIZENET_INTEGRATION_ID = "authorizenet-1"
3
4module.exports = defineConfig({
5  // ...
6  plugins: [
7    // ...
8    {
9      resolve: "@gorgo/medusa-integration",
10      options: {
11        encryptionKey: process.env.INTEGRATION_ENCRYPTION_KEY,
12        providers: [
13          {
14            resolve: "@gorgo/medusa-payment-authorizenet/providers/integration-authorizenet",
15            id: AUTHORIZENET_INTEGRATION_ID,
16            options: {},
17          },
18        ],
19      },
20    },
21    {
22      resolve: "@gorgo/medusa-payment-authorizenet",
23      options: {},
24    },
25  ],
26  modules: [
27    // ...
28    {
29      resolve: "@medusajs/medusa/payment",
30      options: {
31        providers: [
32          {
33            resolve: "@gorgo/medusa-payment-authorizenet/providers/payment-authorizenet",
34            id: "authorizenet",
35            options: {
36              id: AUTHORIZENET_INTEGRATION_ID
37            }
38          },
39        ],
40      },
41    },
42  ],
43})

The payment provider registered this way gets the id pp_authorizenet_authorizenet, and its webhook route is /hooks/payment/authorizenet_authorizenet.

Add environment variables with your secret Encryption Key:

.env
INTEGRATION_ENCRYPTION_KEY=supersecret

The API Login ID, the Transaction Key and the other Authorize.net settings are not provider options. You enter them in Medusa Admin, as described in Manage Authorize.net Settings in Medusa Admin.

The plugin needs three values from the Authorize.net Merchant Interface, and a fourth for webhooks. Take them from the sandbox account while you test, and from the production account for real payments:

• API Login ID and Transaction Key, from Account → Settings → API Credentials & Keys
• Public Client Key, from Account → Settings → Security Settings → General Security Settings → Manage Public Client Key. The storefront's card form sends the card to Authorize.net with it
• Signature Key, from Account → Settings → API Credentials & Keys. The plugin verifies the webhooks with it

Keep the sandbox account in Live Mode. In Test Mode, Authorize.net keeps no transactions and returns 0 for every transaction ID, so the plugin could not capture, refund or void them. Test connection in Medusa Admin fails while the account is in Test Mode.

An Authorize.net account takes payments in one currency, set when the account is created. Add the provider only to the regions that use it, as described in Add Payment Provider. Test connection shows the account's currencies.

To receive the payment notifications the plugin acts on, add a webhook for your store in Authorize.net:

1. Open the webhooks in the Authorize.net Merchant Interface of the account whose keys you use, or create the webhook with POST /rest/v1/webhooks of the Webhooks API.

2. Set the URL in the following format:

   Webhook URL
   https://{YOUR_MEDUSA_DOMAIN}/hooks/payment/authorizenet_authorizenet

   Replace {YOUR_MEDUSA_DOMAIN} with your Medusa store domain.

3. Subscribe it to net.authorize.payment.fraud.approved, net.authorize.payment.fraud.declined and net.authorize.payment.priorAuthCapture.created, and make it active.

4. Enter the account's Signature Key in the Signature Key field of the Authorize.net settings in Medusa Admin. Test connection then checks that an active webhook whose URL contains /hooks/payment/authorizenet_ exists and sends the three events.

fraud.approved completes a payment that the Fraud Detection Suite held for review, fraud.declined is only written to the log, and priorAuthCapture.created records a capture made in the Merchant Interface. Authorize.net retries a failed delivery up to 10 times over several days and then makes the webhook inactive. Test connection reports an inactive webhook as missing. During development, run the backend behind a tunnel with a public HTTPS address, as the example project does with yarn dev:tunnel.

Google Pay appears in the express checkout row of the storefront once you switch it on in the Express checkout section of the Authorize.net settings. The plugin reads the Payment Gateway ID of your account from Authorize.net and passes it to Google Pay, so you don't enter it.

In the sandbox, the button runs in Google Pay's test environment. In production, Google Pay needs your merchant ID from the Google Pay & Wallet Console, and the settings refuse to switch Google Pay on without it. The button works on a page served over HTTPS and on localhost.

The plugin registers under the same provider id as payment-authorizenet-medusa, so it replaces it without a data migration. The payments the old plugin created stay in the database, and this plugin captures, refunds and voids them by their transaction ID.

To switch:

1. Replace payment-authorizenet-medusa in the providers of the Payment Module with @gorgo/medusa-payment-authorizenet/providers/payment-authorizenet, keeping id: "authorizenet", and register the integration provider as shown in Configuration. Remove the old package, since only one provider can have id: "authorizenet".

2. Enter the keys and choose the Environment in Medusa Admin. The old plugin read api_login_id, transaction_key and enviornment from medusa-config.ts, and this plugin reads them from its settings.

3. Set Payment capture in the settings. The old plugin only ever authorized. With capture: true it recorded the payment as captured, but the transaction stayed authorized in Authorize.net and expired after 30 days. Check such transactions in the Merchant Interface and capture the ones still waiting.

4. Replace the storefront code. The old plugin took the card token, the addresses and the shipping from the session data the storefront sent. This plugin takes only the token from the storefront and reads the rest from the cart, as described in Integrate Authorize.net Payment into Storefront.