Authorize.net stopped capturing bookings

[Tristan Tamplin]

Hi Stephen.

In the last 24 hours, all of our bookings seem to have stopped being submitted to authorize.net. In WordPress, they are all listed as “pending” while at Authorize.net there is no indication of them at all in the unsettled transactions report.

My client is in the middle of an important registration period and so is understandably quite worried.

Here are our installed plugin versions:

Authorize.net: Version 0.1.4
Pro: Version 1.11.8

This may well be unrelated, but just in case, we had previous problems with double registrations on a single submission. That issue appears to have been resolved by removing other plugins, but here’s the earlier thread:

https://wp-event-organiser.com/forums/topic/double-registrationpayment-on-single-submission/

Finally, we’ll be contacting Authorize.net as well and will pass along anything we learn from them.

Thanks,

Tristan

[Stephen Harris]

Hi Tristan,

Sorry to hear you’re having issues wit the Authorize.net plug-in.

My initial guess would be it’s related to PCI Security Standards Council’s regarding TLS 1.2 (see this post, the dates relate to PayPal, but otherwise it’s relevant: https://wp-event-organiser.com/blog/announcements/paypal-security-update/). This had been set for ‘early 2017’, but this post would suggest that is no longer the case: https://community.developer.authorize.net/t5/News-and-Announcements/Update-Regarding-TLS-Remediation-and-PCI-DSS/m-p/54459/highlight/true#M180

Are you aware of what the end users sees? An error message? Or a ‘booking confirmed’? If the payment is not appearing in Authorize.net then it shouldn’t be the latter. You may also want to inspect your error logs to see if there are any relevant error messages.

Have you tested it in sandbox mode? (Preferably on staging site so as not to disrupt the production site).

There have been no recent changes to the Authorize.net’s API listed here so that likely rules out an out-of-date API client.

[Tristan Tamplin]

Hi Stephen.

Thanks for the reply. The host (GoDaddy) indicates that they are using TLS 1.2, and I successfully tested the site using the plugin mention in the post you refer to above. When we contacted Authorize.net they indicated that there were get similar reports from merchants and their engineers indicated that it seemed to be the result of expired PHP SDK certificates. Here’s the link they sent for updated certs:

https://github.com/AuthorizeNet/sdk-php/blob/master/lib/ssl/cert.pem

I compared those certs with what is in the lib/ssl cert file in the plugin and they are definitely different. I’ve updated the file accordingly, and now I need to set up a sandbox at Authorize.net to do some testing, but I wanted to run this by you in the meantime. Does this seem a plausible solution path to you?

[Tristan Tamplin]

Just a quick update. Updating the cert file resolved the problem. I’m implementing this at our other sites that use the plugin, and unless I’ve somehow missed a release you’ll probably want to publish an update, and feel free to contact me directly if you want any more info.

[Stephen Harris]

Thanks for reporting back Tristan.

Authorize.net had previously announced an upgrade to SHA-2 but I wasn’t aware they had confirmed a date to update their production servers (nor have I been able to find a announcement).

I’ll release an update shortly, as the updated cert.pem file should be valid if they have not yet removed support for the old one which I suspect they have.

[Author]

Posts