Authorize.Net Payments for OpenCart

Overview

Authorize.Net Payments adds card payment through Authorize.Net to the checkout of your OpenCart 4 shop with Accept Hosted. The customer confirms the order, pays on the secure Authorize.Net page (full-page redirect or a lightbox over your checkout) and returns to your shop. You connect with your own Authorize.Net merchant account.

What it does

• Hosted payment page (PCI). The card number, expiry and security code are typed on Authorize.Net's page and never reach your server, your database or your logs.
• Sale or authorize now, capture when you ship. Choose authorize-and-capture at once, or authorize only and capture from the order page or automatically when the order reaches a status you choose (default Complete). A capture may take a lower amount; Authorize.Net allows one capture per authorization.
• Void and refund from the order page. A payment that has not settled yet is voided as a whole; after the nightly settlement it is refunded in full or in part. The tab tells you which one applies and never sends a refund Authorize.Net would refuse.
• The result is read, not believed. The browser's return and the webhook body are only hints. The shop reads the transaction from Authorize.Net, matches it to the order by its invoice number, checks the amount against what was asked and against the order's current total, and only then marks the order paid. A mismatch is flagged and never marked paid.
• Webhooks and recovery. Webhooks are signature checked (X-ANET-Signature). A missed webhook is recovered by the customer's return and an hourly cron, which also follows unsettled payments until they settle.
• Never twice. Every capture, void and refund is written to the database before it is sent. A refund carries its own invoice number, so after a lost answer the shop looks it up instead of sending it again; a repeated webhook, the return and the cron confirm a payment once.
• Saved cards (optional). Signed-in customers can tick "Save my card"; after the first payment a customer profile is created at Authorize.Net and the hosted page offers the saved cards next time. Your shop keeps only the profile id.
• Order flow. By default the order stays a missing order until it is paid (no e-mail, nothing in the order list); the paid, authorized, void and refunded statuses are settings.
• Safe storage. Transaction Key and Signature Key are stored encrypted and masked in the log. Events and cron only: no OCMOD, no core edits. OpenCart 4, tested on 4.1.0.4.

Limits to know

• One-time card payments through the hosted page. Bank-account (eCheck) payments are switched off on the page, and the method is hidden for carts with a subscription.
• Authorize.Net refunds settled card payments only (the card's last four digits are read from Authorize.Net). An unsettled payment can only be voided as a whole.
• You need an Authorize.Net merchant account (a sandbox account for testing); Authorize.Net charges its own fees and decides availability and terms.
• Tested against a stand-in built from the Authorize.Net API reference, schema and sample code, not against a live Authorize.Net account: test the connection in sandbox mode and pay one test order before you go live. Points we could not confirm in the documentation are listed on the conformance page.

Authorize.Net is a trademark of its owner; this extension is independent software and is not affiliated with or endorsed by Authorize.Net or Visa. The Authorize.Net logo is not part of the extension.

Installation

Requirements: OpenCart 4.1.0.x, PHP 7.4 or newer with cURL and OpenSSL, an Authorize.Net merchant account (a sandbox account from developer.authorize.net for testing), HTTPS on the shop (webhooks and the lightbox need it).

1. In Authorize.Net open Account > Settings > Security Settings > General Security Settings > API Credentials & Keys and note the API Login ID; create a Transaction Key and a Signature Key. The sandbox and the production account are separate with separate keys.
2. In the OpenCart admin open Extensions > Installer, upload kv_authorize_net.ocmod.zip and click Install.
3. Open Extensions > Extensions, choose Payments, find Authorize.Net Payments, click the green Install button, then the blue pencil.
4. On the Connection tab choose the mode (start with Test and tick the test-mode confirmation), enter the API Login ID, Transaction Key and Signature Key and click Save and test connection, then Save and register webhook (the address is https://your-shop/extension/kv_authorize_net/notify.php; your web server must run PHP files under extension/).
5. On the Payment tab set the status to on and save. Place a test order and pay in the sandbox.
6. Make sure the OpenCart cron job runs (see Log and cron).

Updating

Your data and settings stay when you update. OpenCart 4 cannot replace an installed extension, so an update is a re-install:

1. Extensions > Extensions > Payments > Authorize.Net Payments: Uninstall. The tables and the licence stay; the settings are kept by the extension and come back in step 4.
2. Extensions > Installer: Uninstall kv_authorize_net, then Delete it.
3. Upload the new kv_authorize_net.ocmod.zip and click Install.
4. Extensions > Extensions > Payments > Authorize.Net Payments: Install, then open Edit and check the settings once.

Uninstalling and removing all data

Uninstall removes the events and the scheduled task; your data stays in the database so that a re-install or an update finds it. To remove everything for good, uninstall both ways above, then delete these tables with your database tool (your own prefix if it is not oc_): oc_kv_authorize_net_txn, oc_kv_authorize_net_op, oc_kv_authorize_net_profile, oc_kv_authorize_net_log, and the row kv_authorize_net of oc_kv_keep. Back up first: this cannot be undone.

Configuration

Extensions > Extensions > Payments > Authorize.Net Payments > Edit.

Payment

• Status: offered at checkout only while on, connected, and the cart currency is one the account settles (or can be converted to).
• Transaction type: sale (authorize and capture at once) or authorize only (capture later; an authorization that is not captured within 30 days expires).
• Payment page: redirect, or lightbox (needs HTTPS; the page opens over your checkout).
• Account currencies: the currency your Authorize.Net account settles (one processor currency; USD for most). Allowed: USD, CAD, AUD, NZD, GBP, EUR, CHF, DKK, NOK, PLN, SEK; other codes are refused on save. A cart in another currency is converted to the first one listed with the store's own rate. currencyCode is sent only when the currency is not USD.
• Saved cards: adds the "Save my card" box for signed-in customers (customer profiles).
• Geo zone and sort order as for any payment method.

Connection

API Login ID, Transaction Key and Signature Key for the Test (sandbox) and the Live account, and the mode. Secrets are stored encrypted and never shown again; leave a field empty to keep it, type a single minus sign to clear it. Save and test connection calls authenticateTestRequest. Save and register webhook creates the webhook endpoint for the payment events at Authorize.Net unless it exists.

Order statuses

Waiting for payment (default: keep as a missing order), Paid, Authorized, capture status (+ automatic capture), void status (+ automatic void of an unsettled payment), fully refunded, e-mail the customer.

Log and cron

Debug log (keys masked), recent calls, the cron command and the secret cron address. Run the OpenCart cron (php cron.php) at least every 10 minutes.

Test mode

Test (sandbox) mode takes no money, so card payment is hidden from customers while the mode is Test, unless you tick "I confirm: show card payment to real customers in test mode" on the Connection tab (for a test run in a shop that is not live yet). The settings page shows a red TEST MODE banner while the mode is Test. A fresh installation starts in Live mode.

Usage

Customer. Chooses card payment, confirms the order and pays on the Authorize.Net page. Returns to your success page. Signed-in customers may save the card.

Order page > Authorize.Net tab (shown for orders with a payment): state, invoice number, Authorize.Net transaction id and status, card ending, captured and refunded amounts and the list of requests.

• Read back from Authorize.Net: reads the payment and settles unconfirmed requests.
• Capture: for an authorized payment; an amount up to the authorized one; one capture per authorization.
• Void: cancels an unsettled payment as a whole (an authorization, a sale before the nightly settlement, a mismatch).
• Refund: for a settled payment; full or partial; the reason is stored. Before settlement the tab says so and offers the void instead.

Statuses. Moving the order to the capture status captures an authorization; moving it to the cancel status voids an unsettled payment (both optional). The extension's own history entries never trigger a second action.

Payment states. Waiting for payment, Held for review (Authorize.Net's fraud filters; released when approved), Authorized, Paid, Partly refunded, Refunded, Voided, Not paid, Amount mismatch.

Developer notes

Sources

Read on 2026-11-07. "Unverified" means no official page we could read stated it (flagged again in conformance). Sources: API reference developer.authorize.net/api/reference/ (AR), feature pages under developer.authorize.net/api/reference/features/ (accept-hosted, webhooks, payment-transactions), the published schema https://apitest.authorize.net/xml/v1/schema/AnetApiSchema.xsd (XSD), the official sample code github.com/AuthorizeNet/sample-code-php (SC).

Money rules

• Amounts travel as decimal strings with two places; internally integer minor units (amount_minor). The account currencies list is limited to Config::SUPPORTED_CURRENCIES (USD, CAD, AUD, NZD, GBP, EUR, CHF, DKK, NOK, PLN, SEK), all with two decimals.
• The order total in OpenCart's default currency is converted with the store's own rate when the order currency is not an account currency; the paid amount (authAmount) is compared with the amount asked for and with the order's CURRENT total (Orders::matchesNow), because OpenCart rewrites the total of a status 0 order when the cart changes. Authorize.Net's details carry no currency, so the currency is the one we asked for (unverified for multi-currency accounts).

Flow and safety

1. .confirm creates a payment row (status created), the invoice number OC<order>-<payment> and asks for the token; the browser POSTs it to the hosted form.
2. The customer pays. The result reaches the shop in three ways, all ending in the locked, forward-only Payments::reconcile: the signed webhook (transaction id -> details), the return (.back: finds the transaction by invoice number in the unsettled list, then details) and the cron.
3. A paid transaction whose amount differs, or whose order total changed, becomes mismatch (visible order status, never paid); a second paid payment of an order is flagged duplicate.
4. A return that finds nothing yet leaves the payment pending, clears the cart (a signed-in customer's saved cart too) and shows the success page; webhook or cron finish it. A declined or expired payment shows the failure page.
5. Capture, void and refund take a per-payment lock, write an op row (C|V|R<id>, also the refund's invoiceNumber) before the request, and on a lost answer read the transaction (capture, void) or look the refund up in the unsettled list by its invoice number; not found after one hour the reserved amount is released.
6. Status events call the same code under a re-entrancy guard.

Tests: php81 tests/unit.php and php83 tests/unit.php (need node tests/mock-server/server.js 11970 and MariaDB 3307), node tests/e2e.js on a dev store (STORE=oc41|oc41b|oc41c). The hidden setting payment_kv_authorize_net_base_url (loopback hosts only) points the extension to the mock. The mock enforces the documented element order, limits and refund / capture / void rules; it is not the real service and nothing here was run against an Authorize.Net sandbox account.

Conformance and open points

The extension was built from the official Authorize.Net API reference, the published XML schema and the official PHP sample code, and tested against a stand-in server (not against Authorize.Net). Before you go live run one sandbox order of each kind: sale, authorize + capture, void, refund after settlement (the sandbox settles in its own batch; wait for settledSuccessfully).

Points the documentation we could read did not state (the extension is written defensively for each; check them once in the sandbox):

1. Webhook signature format: hex letter case, a sha512= prefix, key used as text or as hex bytes. All variants are accepted.
2. Webhook registration body (url, eventTypes, status): the page printed the endpoints and event names, not the request body. The address is https://your-shop/extension/kv_authorize_net/notify.php: a plain path, because Authorize.Net accepts only letters, digits, dot, hyphen, underscore and slash in a webhook URL (no ? or =). If registration fails, create the webhook in the Authorize.Net portal (Account > Webhooks) with this address and the six payment events. The web server must execute PHP files under extension/; some nginx set-ups only pass index.php to PHP, then add a location for /extension/kv_authorize_net/notify.php (or allow PHP under extension/). Without the webhook the return page and the hourly cron still confirm payments.
3. Transaction lookup of a hosted-page payment: the return page and the cron find the transaction by our invoice number in the unsettled list (documented as a list of recent unsettled transactions). The webhook and the lightbox result carry the transaction id directly. A payment made while no webhook is registered and found only after it left the list would need the Authorize.Net portal (it expires from our list after 14 days). Payments held for review are listed by Authorize.Net under status pendingApproval; the extension asks for that list as well and does not mark such a payment expired.
4. order.invoiceNumber of the refund transaction is our handle to find a refund again after a lost answer.
5. currencyCode must match the one processor currency of the account. The settings accept only the currencies Authorize.Net documents (USD, CAD, AUD, NZD, GBP, EUR, CHF, DKK, NOK, PLN, SEK; Authorize.Net support, "currencies supported"); an account settles one of them, so the setting is that one currency, not several.
6. E00039 duplicate profile text format; if the id cannot be read the card is simply not linked (a log warning).
7. Lightbox communicator is our implementation of the documented behaviour; the official file was not readable.
8. Refund window (180 days by default) and duplicate window are Authorize.Net settings; refusals are shown as Authorize.Net words them.
9. eCheck (bank account) payments are not offered; refunds are for cards (last four digits) only.

FAQ

Does the customer need an Authorize.Net account?

No.

Does card data touch my server?

No. The card is typed on Authorize.Net's page (Accept Hosted).

Is the order paid when the customer returns?

Only when the shop has read an approved transaction from Authorize.Net whose amount matches the order. The return itself proves nothing; if the transaction is not visible yet the payment stays pending and the webhook or the cron finishes it.

Why can't I refund a payment from today?

Authorize.Net refunds settled payments only; settlement runs in the nightly batch. Until then void it.

Why does a second refund of the same amount fail right away?

Authorize.Net's duplicate transaction check can refuse an identical request within its window; wait a moment or change the amount.

A payment shows "Amount mismatch". The customer paid, but the amount differs from what was asked, or the order total changed while the payment was open (for example a coupon). The order is not marked paid; void it (unsettled) or refund it (settled).

Do I need the webhook?

It is recommended (faster confirmation), not required: the return and the cron read the state too.

Which currencies?

USD, CAD, AUD, NZD, GBP, EUR, CHF, DKK, NOK, PLN and SEK are the currencies Authorize.Net accepts; your account settles one of them (enter that one). Carts in other store currencies are converted with the store rate.

Why is the webhook address a .php file?

Authorize.Net refuses ? and = in webhook URLs, so the extension ships extension/kv_authorize_net/notify.php, which runs the normal webhook handler (POST and a valid signature required). If your server does not run PHP files under extension/ (some nginx set-ups), allow that one file; the cron and the customer's return still confirm payments meanwhile.

How often does the shop read payments back?

Every hour through the OpenCart cron, and at once when the customer returns.