Authorize.Net Accept.js Payments - support thread

Opening post for the Zen Cart forum support thread (Addon Payment Modules).
Markdown; the forum also accepts it as plain text. Not part of the release package. Once posted, the opening-post permalink (/threads/N?page=1#post-M) goes into the manifest, the readme, and the Library listing.

Authorize.Net Accept.js Payments v1.0.0 - card payments through Authorize.Net's current JSON API with Accept.js tokenization, as a drop-in successor to the AIM module

Plugins Library: To Be Determined
GitHub: https://github.com/dbltoe/AuthorizeNet_Accept_Payments
Zen Cart: 1.5.8, 2.0, 2.1, 2.2, 2.3 and 3.0.0-dev, from one codebase
PHP: 7.4 through 8.5
License: GPL-2.0

Why it exists

Authorize.Net has retired the AIM and SIM methods used by Zen Cart's built-in modules. They still answer today, with no shutdown date announced, but they get no new features, and the current API is the only place Authorize.Net accepts a tokenized card. This module moves a store onto that API without changing what the customer sees.

What it does

The customer sees the same card fields on the same payment page. Underneath, the card number and security code inputs have no name attribute, so a form post can never carry them. When the customer clicks Continue, Authorize.Net's own Accept.js script turns the card into a one-time nonce in the browser, and that nonce is what your server sends to the gateway. If the script can't run at all, the order is refused rather than accepting a bare card number.

For the store owner:

• Authorize-only or authorize-and-capture, with separate order statuses for paid, authorized-but-uncaptured, refunded and held-for-review orders.
• On the order page: the transaction history for the order, plus refund, capture and void through Zen Cart's own order-page actions.
• Line items, tax and shipping sent with each transaction; gateway receipt emails if you want them; a duplicate-transaction window.
• Sandbox, test-request, and Production modes. It starts in Sandbox.
• Works with the standard checkout, the PA-DSS AJAX confirmation, and One Page Checkout.
• Modules > Payment > Remove keeps a copy of the settings; the next Install puts them back.

Encapsulated. One folder under zc_plugins/, installed from Plugin Manager, then enabled under Modules > Payment like any core payment module. It's its own transaction table, kept on uninstall because it holds your payment history.

Installing

1. Upload zc_plugins/AuthorizeNetAccept/ so it lands at <store root>/zc_plugins/AuthorizeNetAccept/v1.0.0/.
2. Zen Cart 1.5.8 through 2.0.x only: also upload the includes folder from the package's for_zen_cart_1.5.8_to_2.0.x folder. Those releases look for a payment module only in the core folders; the two small files there hand off to the plugin. From 2.1.0 on, skip this.
3. Admin -> Modules -> Plugin Manager -> Authorize.Net Accept.js Payments -> Install.
4. Admin -> Modules -> Payment -> Authorize.net (Accept.js) -> Install, then Edit: enter the API Login ID, Transaction Key, and Public Client Key, and choose the Transaction Mode.

The full documentation (readme.html) is inside the plugin and linked from the Plugin Manager panel. It covers the three credentials, sandbox testing with the test card numbers, going live, the order-page actions, statuses, currencies, and troubleshooting.

You need

An Authorize.Net account (a paid service with a merchant account behind it; their sandbox is free for testing and is the right place to start), a store served over https (in Production mode, the module hides itself on a page that isn't), and PHP with curl and json.

Moving from AIM

Install this module alongside the AIM module, test it, then remove AIM under Modules > Payment. Orders paid through AIM keep their history. Capture or refund any open AIM transactions before you remove it, or do so in the Merchant Interface.

Not included

Apple Pay, Google Pay, and card on file. Those need customer profiles and wallet registration and are a separate Pro edition built on this module's notifier seams.

Reporting a problem

Please include: your Zen Cart and PHP versions, your template, whether you use One Page Checkout, the Transaction Mode, and the exact message shown. Turn Debug Mode to Log File (Sandbox mode always logs) and attach the log for the call in question; it shows the masked request and the full gateway response, with the transaction key and the card nonce masked. For E00007, the credentials don't match the mode (sandbox credentials only work in Sandbox mode). For "Your card details did not arrive securely", JavaScript didn't run on the payment page; check the browser console.

Authorize.Net Accept.js Payments v1.0.1 is up.

One change for anyone adding a wallet button: the checkout script now has a hook for wallet tokens. An add-on calls window.authorizenet_accept.setWalletToken(descriptor, value, {brand, last4, expires}) and the script does the rest: it fills the hidden fields, selects the module with a real radio click so One Page Checkout records the choice, keeps the token through OPC's re-render of the payment block, and lets the order through without asking for a card. Editing the card fields, choosing another payment method, or submitting the form causes the token to drop.

Each render of the payment block fires an authorizenet_accept:ready event on the document with the same API, so a button can be redrawn after OPC redraws the block, and config() on that object returns the order total and currency, so a wallet sheet asks for the amount the module will charge.

Why. In 1.0.0, the script only allowed its own Accept.js nonce through, so a wallet token placed in the hidden fields by an add-on was blocked on the standard checkout with the card-number message, and worked on One Page Checkout only by bypassing the script. Now there's one sanctioned way in on both checkouts.

Nothing changes for card payments. No settings change, no database change. To upgrade, upload the new zc_plugins/AuthorizeNetAccept/v1.0.1 folder beside the old one, then Plugin Manager > Upgrade; your settings and credentials stay. On Zen Cart 1.5.8 through 2.0.x, the two bridge files are unchanged.

Zen Cart 1.5.8 through 3.0.0, PHP 7.4 through 8.5, same as before. Source at <https://github.com/dbltoe/AuthorizeNet_Accept_Payments>; the browser-side contract is in docs/CUSTOMIZING.md. Happy to answer questions here.

---

## Variant — a reply in the Google Pay thread (207334)

Short version for chadlly2003's thread, after the post above is up:

Accept.js Payments 1.0.1 is out with the wallet hook mentioned above. If your add-on calls window.authorizenet_accept.setWalletToken('COMMON.GOOGLE.INAPP.PAYMENT', encodedToken, {brand: 'Google Pay'}) instead of writing the hidden fields itself, the script handles the field filling, the module selection, and the OPC re-render, and it works on the standard checkout as well as OPC. The contract is in docs/CUSTOMIZING.md in the package.

Authorize.Net invoice number kept reusing the same base order number.

I fix it

path: zc_plugins\AuthorizeNetAccept\v1.0.0\catalog\includes\modules\payment\authorizenet_accept.php

Replace the entire current nextInvoiceNumber() function with:

protected function nextInvoiceNumber(): string
{
    global $db;

    // Get the most recent actual Zen Cart order number.
    $last = $db->Execute(
        "SELECT MAX(orders_id) AS last_order_id FROM " . TABLE_ORDERS
    );

    $next = (int)($last->fields['last_order_id'] ?? 0) + 1;

    $prefix = '';
    if ($this->cfg('TESTMODE') === 'Test') {
        $prefix = 'TEST-';
    } elseif ($this->isSandbox()) {
        $prefix = 'SANDBOX-';
    }

    // Keep the random suffix for Authorize.Net duplicate protection.
    return $prefix . $next . '-' . strtoupper(substr(bin2hex(random_bytes(2)), 0, 4));
}

AuthorizeNet Accept Payments if you want to add google and apple pay. Use the attach files.

Thanks for both of these.

The invoice number: you're right, and it's our bug, not something on your side. The module reads the orders table's Auto_increment through SHOW TABLE STATUS, and on MySQL 8 that value comes from a statistics cache that refreshes once a day by default, so the base number repeats. Our test stores run MariaDB, which reads it live, so we never saw it. The random suffix keeps every invoice unique, so no transaction was affected; only the number was misleading. Your replacement is what the core AIM module does, and 1.0.2 will ship the same query, so nobody needs to patch a file. Please install 1.0.2 rather than editing v1.0.0 once it's up, since the edit will be lost on the next upgrade.

The Apple Pay and Google Pay add-ons: we went through both the way we check our own packages before a release. The gateway side is correct. Three things to fix before anyone runs them on a live store. The Apple session page accepts a POST from anyone with no session token or AJAX header, so any visitor can make the store open sessions to Apple with your merchant certificate; check $_SESSION['securityToken'] and the X-Requested-With header first. Its host rule also refuses cn-apple-pay-gateway.apple.com and the pod hosts (apple-pay-gateway-nc-pod1.apple.com and so on) that Apple lists on its server setup page and does hand out, and initiativeContext should be the request host rather than a typed-in domain. And both scripts write the module's hidden fields directly and keep their own copy of the token; 1.0.1 added window.authorizenet_accept.setWalletToken() and an authorizenet_accept:ready event so the module handles persistence across OPC redraws, drops the token when the customer edits the card fields, and lets the submit through. As they stand, approve Google Pay, change your mind, type a card within 15 minutes, and the wallet token still gets charged. The full contract with an example observer is in docs/CUSTOMIZING.md in the package.

If you'd rather keep the add-ons in your own thread, that keeps this one about the module itself, but either way, thank you for the report.

I made the changes you addressed. If you could take a look at the files on this thread and verify it looks good. It would be greatly appreciated

https://www.zen-cart.com/threads/207334?page=1#post-1347150

Authorize.Net Accept.js Payments v1.0.3 is out

v1.0.3 changes one thing: the Plugin ID in manifest.php is now 2459. On 6 October the Plugins Library team let us know the ID the listing had been given, 2261, already belonged to an older plugin, so Plugin Manager's update check was being answered with that plugin's details instead of ours. They gave us 2459, and v1.0.3 carries it.

There are no payment, code or settings changes. You only need this release if you want Plugin Manager to tell you about future updates.

To upgrade, put the v1.0.3 folder beside your current one in zc_plugins/AuthorizeNetAccept/ and click Upgrade in Admin > Modules > Plugin Manager. Modules > Payment keeps its settings and credentials. On Zen Cart 2.2.0 and later, that's all. On 1.5.8 through 2.1.x, Plugin Manager keeps the ID it recorded when it first saw the plugin, so also run this line in Admin > Tools > Install SQL Patches (it adds your table prefix itself):

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

Please don't remove the plugin folder to force the new ID on a live store; that can take the payment module off your checkout.

Download: https://github.com/dbltoe/AuthorizeNet_Accept_Payments/releases/tag/v1.0.3

Sorry this took a while. We went through both revised packages from your post in the Google Pay thread, against the versions we looked at in September.

The three Apple endpoint fixes are in and look right. The session page now refuses a request without the AJAX header and the store's session token, compares the token safely, and only then looks at the certificate files, so an outside POST learns nothing. initiativeContext comes from the request host, checked as a hostname, so www and non-www both work.

One correction on our side about the host rule: Apple's server setup page has changed since we wrote. It now lists four validation hosts and no pod hosts: apple-pay-gateway.apple.com and cn-apple-pay-gateway.apple.com for production, apple-pay-gateway-cert.apple.com and cn-apple-pay-gateway-cert.apple.com for the sandbox. It also asks for a strict allow list. Your rule allows the first three, so production is fine. The only one it refuses is cn-apple-pay-gateway-cert.apple.com, which matters only if you test against the China sandbox. The pod pattern is no longer needed, though it does no harm.

The stale token is fixed in both. Typing in any of the card fields now clears the stored wallet token and the hidden fields, and the field IDs you used match the module's, so approving Google Pay or Apple Pay and then switching to a typed card charges the card.

One new problem: the Google Pay zip has no manifest.php. Copied over your September install it works, because the old manifest stays, but on a fresh install Zen Cart skips the folder and the add-on never shows up in Plugin Manager. Putting the manifest back fixes it.

The Google README says a future module release may add a wallet-token API. It's already there: since 1.0.1 the module has window.authorizenet_accept.setWalletToken() and an authorizenet_accept:ready event, described in docs/CUSTOMIZING.md in the package. You don't need it for what you've fixed, but it would let both add-ons drop their own storage and refill code.

Two small things if you keep sharing them: neither package carries a license line (the module is GPL-2.0, and the same would fit), and the module is now at v1.0.3. v1.0.2 shipped your invoice-number fix, so you can drop your edited v1.0.0 file. We checked all of this by reading the code and running our usual checks on every PHP version from 7.4 to 8.5, not on a device.

Authorize.Net Accept.js Payments Pro v1.0.1

Pro is the paid add-on to this module. It adds Apple Pay, Google Pay and saved cards to the same payment block, using the module's own extension points, so the free module itself is never changed. v1.0.1 makes one change, to Apple Pay.

When Safari opens the Apple Pay sheet, the store has to ask Apple to validate the merchant, and Pro sends that request only to Apple's own hosts. v1.0.0 accepted any host named apple-pay-gateway-something.apple.com. Apple's server setup page now lists exactly four hosts and asks for a strict allow list, so v1.0.1 contacts only those four: apple-pay-gateway.apple.com and cn-apple-pay-gateway.apple.com, and their sandbox twins apple-pay-gateway-cert.apple.com and cn-apple-pay-gateway-cert.apple.com. Every host v1.0.0 accepted was Apple's own, so this tightens the rule rather than closing a hole.

There are no settings, database or checkout changes, and Google Pay and saved cards work exactly as before. To upgrade, put the v1.0.1 folder beside v1.0.0 in zc_plugins/AuthorizeNetAcceptPro/ and click Upgrade in Admin > Modules > Plugin Manager. If you own Pro and need the new package, send us a note through the Contact Us page on myzencartzone.com.

Pro needs this module at v1.0.1 or later; v1.0.3 is current.

Product page: https://myzencartzone.com/index.php?main_page=product_info&products_id=17