Authorize.net AIM sporadic issues after MYSQL/PHP upgrade

[earmsby]

URL: https://store.subitomusic.com
ZC version: v1.5.6a
MYSQL/PHP versions: MySQL 5.7.31 / 7.2.33
MySQL Mode: ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER, NO_ENGINE_SUBSTITUTION


Last week, I had to migrate a client's site to a new server with the specs shown above. Their ZenCart was previously running on a server with the following specs:

URL: https://store.subitomusic.com
ZC version: v1.5.6a
MYSQL/PHP versions: MySQL 5.6.47 / 5.6.40
MySQL Mode: NO_ENGINE_SUBSTITUTION


Since this migration, they have had a couple of occurrences where a customer placed an order and paid by credit card but the order was never added to ZenCart. There must have been some kind of error shown but the customer clicked confirm a few more times, causing the charge to be duplicated several times in authorize.net but still no order recorded in the zencart database.

I was able to get the customer's IP from authorize.net and search over the debug logs in the logs folder but nothing is coming up that is related to their transaction. The only logs that come up are a warning about a missing language define and this is not from the shopping cart page. It is only from the product info page that they viewed before they ordered the item.

Since this is not happening to every customer, I'm a bit baffled what's going on. I wondered if there was something about either the php version, MYSQL version or MYSQL mode that is interacting differently with authorize.net. Of course, I realize it's next to impossible to determine this without seeing the error that the customer got (or at least having them recount it). I just thought this might ring a bell if someone had something similar.

Thanks for any advice about the issue and/or additional steps I might take to get to the bottom of it.

[DrByte]

I've seen this on one other site in the last week. Still not sure what the cause is.

Things that can help, in the ZC AIM module settings:
- set the "Email to Customer" and "Email to Merchant" settings to True, so the transaction details (and what was ordered) are emailed out, even though the order isn't stored correctly.
- check the daily transactions in the authnet account a few times thru the day just to catch any payments that didn't get an order saved
- enable Database Storage and/or Debug Log To File. This will let you attempt to debug what's happening.

In the module's debug log I'm seeing that the transaction is "sent", and an HTTP 200 response received, but the returned payload is empty (thus Zen Cart assumes failure).

It's the empty response that's totally puzzling, and seems to be server-specific. (Putting same account credentials into another store works fine.)

In this case, ZC 1.5.4 on PHP 5.5, where the PHP version was upgraded (minor patch version, not a big upgrade) last week. Not sure if other server software was also changed, such as libcurl or openssl, etc. Sure, it's an old ZC version, but it's using the 1.5.6 AIM module, which again works fine on other servers.

[lat9]

I've been seeing these, too. My money's on the site's samesite-cookie settings.

Check out this Zen Cart posting (https://www.zen-cart.com/showthread....cess&p=1372258) and also this follow-on (https://www.zen-cart.com/showthread....cess&p=1372258) for changes to make to a pre-zc157a version of Zen Cart.

[DrByte]

The AIM module has nothing to do with cookies, because there's no page-redirection happening.

[idc1]

I'm experiencing the same thing. My issue started out intermittent, but is now 100% failure. No updates had been performed when this started. It was working one day, and started failing the next.

[DrByte]

What's your PHP version?

Any chance its "Build Date" is recent?

This is a GoDaddy VPS

[lat9]

What's your PHP version?

Any chance its "Build Date" is recent?

FWIW, I've got a client with a 100% failure rate over the weekend showing PHP 5.6.40 with a build date of Aug 25 2020 19:57:22.

[DrByte]

Ask GoDaddy to rollback their build. That solved it for this client anyway.

Edit: Specifically, GoDaddy rolled back the CURL version on the server.

Unfortunately I didn't have a note of what CURL version was linked before the rollback. But it now reports the following:

[idc1]

Ask GoDaddy to rollback their build. That solved it for this client anyway.

Edit: Specifically, GoDaddy rolled back the CURL version on the server.

Unfortunately I didn't have a note of what CURL version was linked before the rollback. But it now reports the following:

Finally got GoDaddy to update CURL and things appear to be working as they should. We had CURL 7.69.1 and updated to 7.72.0