UAT·Ops About UAT-Ops

Authorize.net + commercetools integration

Custom build onlyLast verified 2026-09-11 · Reviewed by a person 2026-09-25

There is no Authorize.net connector for commercetools: the Connect marketplace, commercetools' partner listings, GitHub and Authorize.net's own partner directory show none. To connect them, build a private Organization connector from commercetools' open-source payment-integration template and point its processor at Authorize.net's API. You maintain it yourself.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 commercetools integration itself has not been run.

Sources checked: 14 claims from 6 sites, listed at the foot of the page.

Connects through Organization (private) Connect connector built from commercetools' payment-integration template, calling the Authorize.net API from the processor and Accept Hosted or Accept.js from the enabler. Biggest gotcha: You own the connector.

How it connects

Method
Organization (private) Connect connector built from commercetools' payment-integration template, calling the Authorize.net API from the processor and Accept Hosted or Accept.js from the enabler2
Maintained by
merchant3
Checkout modes
complete checkout, payment only4
PCI scope
Depends on the checkout mode you choose; see the gotchas below.5

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.

CapabilitySourceNotes
Cards6Authorize.net supports this at the API level; whether a custom build exposes it depends on what gets implemented.
Apple Pay6Authorize.net supports this at the API level; whether a custom build exposes it depends on what gets implemented.
Google Pay6Authorize.net supports this at the API level; whether a custom build exposes it depends on what gets implemented.
PayPal6Authorize.net supports this at the API level; whether a custom build exposes it depends on what gets implemented.
ACH bank payments6Authorize.net supports this at the API level; whether a custom build exposes it depends on what gets implemented.
Saved cards (vault)6Authorize.net supports this at the API level; whether a custom build exposes it depends on what gets implemented.
Subscriptions6Authorize.net supports this at the API level; whether a custom build exposes it depends on what gets implemented.
Partial refunds6Authorize.net supports this at the API level; whether a custom build exposes it depends on what gets implemented.
Level 2 / Level 3 data6Authorize.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 keep it in Live Mode, because Test Mode stores nothing and returns transaction ID 0. Put the sandbox API Login ID and Transaction Key into the connector's configuration values when you deploy it. Sandbox calls go to apitest.authorize.net, and production keys fail there with reason code 13. Pay with the sandbox test cards, for example Visa 4111111111111111 with any future expiry; ZIP 46282 forces a decline. Register a webhook at apitest.authorize.net/rest/v1/webhooks that points at the processor's deployed URL, and check the X-ANET-Signature HMAC-SHA512 using the Signature Key. What to check: authorize, capture, void and refund each write the matching transaction to the commercetools Payment, with the amount converted correctly from cents.3

UAT-Ops runs integration flows like this against the real sandbox and keeps the evidence. Get one email when it opens.

Gotchas

You own the connector

No public Authorize.net connector exists, so you build an Organization connector from the template. Organization connectors skip marketplace certification, so no commercetools reviewer checks your code. Security fixes, updates to the Connect payments SDK and the move from Preview to Production are all yours. The template's sample card, invoice and purchase-order methods are marked not for production. Delete them. Do not adapt them.

Source: github.com3

Cents in, decimals out

commercetools stores money as integer cent amounts plus a fraction-digit count. Authorize.net expects a decimal amount. The template README calls this conversion out explicitly. If you pass centAmount straight through, you charge 100 times too much. Test with a currency whose fraction digits are not two before going live.

Source: github.com3

Webhooks deactivate themselves

Authorize.net retries a failed notification up to 10 times over about nine days, then marks the webhook inactive and stops calling. Nothing alerts you. If the processor goes down, or answers anything other than HTTP 200, commercetools stops receiving captures, voids and refunds. Signatures use the Signature Key, which is separate from the Transaction Key. Store both in the connector's configuration.

Source: developer.authorize.net9

PCI scope depends on your enabler

Checkout advertises PCI compliance for its own components, but your enabler decides the card-entry surface. If the enabler renders Accept Hosted, you stay at SAQ A. If it builds its own fields on Accept.js, you are at SAQ A-EP. The form token and the nonce each expire after 15 minutes, so a slow checkout step can leave an unusable token.

Source: developer.authorize.net10

Sandbox Test Mode lies

A sandbox left in Test Mode returns transaction ID 0 and stores nothing. The processor then writes a meaningless interaction ID to the commercetools Payment, and refunds fail later. Keep the sandbox in Live Mode, and never mix sandbox and production keys, which fails with reason code 13.

Source: developer.authorize.net8

Alternatives

Other gateways on commercetools

Authorize.net on other platforms

Sources

  1. https://docs.commercetools.com/merchant-center/connectofficial documentation · describes this integration · checked 2026-09-11
  2. https://docs.commercetools.com/checkout/connectors-and-applicationsofficial documentation · describes this integration · checked 2026-09-11
  3. https://github.com/commercetools/connect-payment-integration-templatecode repository · describes the connector · checked 2026-09-11
  4. https://docs.commercetools.com/connect/templates/payment-integrationofficial documentation · describes the platform · checked 2026-09-11
  5. https://developer.authorize.net/api/reference/features/accept-hosted.htmlofficial documentation · describes the gateway · a claim here is implied by this source, not stated · checked 2026-09-11
  6. https://developer.authorize.net/api/reference/index.htmlofficial documentation · checked 2026-09-10
  7. https://developer.authorize.net/hello_world/sandbox.htmlofficial documentation · checked 2026-09-10
  8. https://developer.authorize.net/hello_world/testing_guide.htmlofficial documentation · checked 2026-09-10
  9. https://developer.authorize.net/api/reference/features/webhooks.html
  10. https://developer.authorize.net/api/reference/features/acceptjs.html

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.