Authorize.Net Accept.js Payments v1.0.3

Plugin ID is now 2459. That's the ID the Plugins Library assigned on
6 October 2026. The listing's earlier ID, 2261, belonged to another plugin,
so update notices in Plugin Manager now report this plugin.

Nothing else changes. No payment, code or settings changes. Upgrading is
optional and only matters for update notices.

Upgrading. Put the new zc_plugins/AuthorizeNetAccept/v1.0.3 folder
beside the old one and click Upgrade in Plugin Manager; Modules > Payment
keeps its settings and credentials. On Zen Cart 2.2.0 and later the next
Plugin Manager visit records the new ID. Zen Cart 1.5.8 through 2.1.x record
the ID only when the plugin is first registered, so an Upgrade there doesn't
change it, and upgrading isn't required: run this one line in Tools > Install
SQL Patches (it adds your table prefix), or in phpMyAdmin with your prefix
added:

UPDATE plugin_control SET zc_contrib_id = 2459 WHERE unique_key = 'AuthorizeNetAccept';

Don't remove the plugin folder to force the ID; on a live store that can take
the payment module off the checkout. The two bridge files for Zen Cart 1.5.8
through 2.0.x are unchanged.

Zen Cart 1.5.8 through 3.0.0, PHP 7.4 through 8.5, as before.

---

Re-cut 2026-10-17: the zip now carries the complete GNU GPL v2 text in LICENSE, as the Zen Cart team asks of every contribution. No code changes, so there is nothing to upgrade.

Authorize.Net Accept.js Payments v1.0.2

v1.0.2 (2026-09-16)

• The invoice number sent to the gateway now predicts the next order number
  the way core's AIM module does, the highest order id plus one, instead of
  reading the orders table's counter from SHOW TABLE STATUS. On MySQL 8.0 and
  later that value comes from the information_schema statistics cache, which
  refreshes once a day by default, so the same base number repeated across a
  day's orders (reported by chadlly2003 in the support thread). MariaDB reads
  it live, which is why our own test stores never showed it. The random suffix
  kept every invoice unique, so no transaction was affected; only the number
  was misleading.
• Nothing else changes: no settings change, no database change; card payments
  and the wallet hook are as in 1.0.1.

Authorize.Net Accept.js Payments v1.0.1

Wallet hook in the checkout script. An add-on (Apple Pay, Google Pay, anything the module's descriptor whitelist allows) hands its token to window.authorizenet_accept.setWalletToken(descriptor, value, {brand, last4, expires}). The script fills the hidden carriers, selects the module with a real radio click so One Page Checkout records the choice, keeps the token in session storage for fifteen minutes tied to the order total so an OPC re-render doesn't lose it, and lets Continue, Review or Confirm through without card validation or an Accept.js call. Editing the card fields, choosing another payment method, or submitting the form drops the token.

Why. The 1.0.0 script only let its own Accept.js nonce through. A wallet token placed in the carriers by an add-on was stopped on the standard checkout with the card-number message, and worked on OPC only by going around the script. There is now one sanctioned way in, on both checkouts.

Also

• Each render of the payment block fires an authorizenet_accept:ready event on the document carrying the same API, so a wallet button can be redrawn after OPC redraws the block.
• The script config carries the order total, currency, mode and the Accept descriptor; config() on the API returns them.
• The browser-side contract is documented in docs/CUSTOMIZING.md.

Nothing changes for card payments. No settings change, no database change. Upgrade by uploading the new zc_plugins/AuthorizeNetAccept/v1.0.1 folder beside the old one and choosing Upgrade in Plugin Manager; settings and credentials stay. The two bridge files for Zen Cart 1.5.8 through 2.0.x are unchanged.

Zen Cart 1.5.8 through 3.0.0, PHP 7.4 through 8.5.

Authorize.Net Accept.js Payments v1.0.0

First release.

• Card payments through Authorize.Net's JSON API (createTransactionRequest) with Accept.js tokenization. The card number and CVV are never posted to the store: the inputs carry no name, and a one-time nonce goes in their place.
• Authorize-only or authorize-and-capture; held-for-review handling with its own order status; gateway receipt emails; duplicate-transaction window; line items, tax and shipping detail; currency conversion to the gateway currency.
• Order page: a transaction history for the order, plus refund, capture and void that reuse Zen Cart's own order-page actions.
• Notifier seams for add-ons (docs/CUSTOMIZING.md).
• Works with the standard checkout, the PA-DSS AJAX confirmation and One Page Checkout.
• Zen Cart 1.5.8 through 3.0.0, PHP 7.4 through 8.5, from one codebase; 1.5.8 through 2.0.x add two bridge files in the core folders.