|
Sinclair Lewis
|
December 7, 2015 at 5:52 am
Hi,
I’m getting this common error after making a payment on Authorize.net’s site:
An error occurred while trying to report this transaction to the merchant. An e-mail has been sent to the merchant informing them of the error. The following is the result of the attempt to charge your credit card.
This transaction has been approved.
It is advisable for you to contact the merchant to verify that you will receive the product or service.
I’ve used EE 3.1.36.6.P and EE 4.8.20.p.
Here’s what I’ve tried:
–Verified Authorize.net is not being blocked by host.
–Disabled other plugins.
–Tried WP Twenty-thirteen theme.
–Verified transactions page (https://www.jppcle.org/notify-url/) is publically accessible and has right shortcode. It also uses the template you recommended.
–Tried every variation of transactions-page URL on Auth’s site (?page_id=55 instead of pretty URL).
–I enabled EE logging. Here are the last steps:
[2015-12-07 07:33:42] EE_SPCO_Reg_Step_Payment_Options -> _post_payment_processing()
[$payment->redirect_url()] https://secure.authorize.net/gateway/transact.dll
—————————————————————————————-
[2015-12-07 07:33:42] EE_Cron_Tasks -> schedule_finalize_abandoned_transactions_check()
[$TXN_ID] 16
—————————————————————————————-
[2015-12-07 07:33:42] EE_Error.core.php -> get_notices()
—————————————————————————————-
[2015-12-07 07:34:09] EE_Checkin.class.php
—————————————————————————————-
[2015-12-07 07:34:09] EE_Cron_Tasks -> log_scheduled_ee_crons()
[scheduled EE cron] AHEE__EE_Cron_Tasks__clean_up_junk_transactions
—————————————————————————————-
[2015-12-07 07:34:09] EE_Cron_Tasks -> log_scheduled_ee_crons()
[scheduled EE cron] AHEE__EE_Cron_Tasks__finalize_abandoned_transactions
—————————————————————————————-
[2015-12-07 07:34:09] EE_Cron_Tasks -> log_scheduled_ee_crons()
[AHEE__EE_Cron_Tasks__finalize_abandoned_transactions args] Array
(
[0] => 16
)
—————————————————————————————-
[2015-12-07 07:34:09] EE_PUE -> __construct()
—————————————————————————————-
[2015-12-07 07:34:09] EE_Session -> __construct()
—————————————————————————————-
[2015-12-07 07:34:09] EE_Session.core.php -> _espresso_session()
—————————————————————————————-
[2015-12-07 07:34:09] EE_Cart.core.php
—————————————————————————————-
[2015-12-07 07:34:09] EE_Payment_Method.class.php
I could seriously use help with this. The host (Bluehost) and Authorize.net only gave very generic advice.
Thanks,
Sam
|
|
Josh
|
December 7, 2015 at 10:41 am
Hi Sam,
It turns out that the notify URL is not used by the Authnet SIM gateway. You’ll need to make sure that
1) The EE4 Thank You page is published
2) Your server meets these specs from Authnet:
If the merchant’s Web server is not available on the public Internet, has authentication enabled, or if the Relay URL uses a non-standard port for HTTP or HTTPS traffic, Relay Response timeouts will occur. Authorize.Net will not have any means to connect to your server or authenticate itself on your server, and can only use ports 80 and 443 for all Web traffic.
3) If you’re using EE4, then you do not set a Response/Receipt URL in the Authorize.net account setting. If you use EE3, then the Response/Receipt URL should be the same URL as the Thank You page.
|
|
Sinclair Lewis
|
December 7, 2015 at 9:29 pm
Hi,
I’ve tried many variations on your advice, but I’m still getting the same error. The receipt and relay-response URLs are both set to https://www.jppcle.org/?page_id=51 in Authorize.net now. (I’m using EE3.)
I paid for some premium support. How do I initiate that so I can send you passwords? I’m really stumped.
Thanks again,
Sam
|
|
Josh
|
December 8, 2015 at 9:01 am
Hi there,
You can redeem your support token by going to your account page, then you click on the link that says “To redeem your token(s) please complete this form”. Then you complete the form. Please note that the form needs to be filled out completely. Also in this case, we may need a temporary log in to your Authnet account, which you can also send via the secure form.
|
|
Josh
|
December 9, 2015 at 7:20 am
Hi Sinclair,
Is there any reason you didn’t send FTP credentials? We need those for troubleshooting. I can also recommend updating to the current version of Event Espresso 3. The version you have installed right now was released back in July of 2014 and there have been quite a number of fixes and compatibility updates since then.
Can you update the plugin and send FTP credentials via the support token form? Once we have the FTP credentials and a current version of Event Espresso 3 installed we can troubleshoot further.
|
|
Josh
|
December 10, 2015 at 9:46 am
Hi Sam,
Was the site moved onto a new server after November 12, 2015? If so, can you check with your host to see if the new server meets all of these requirements from Authorize.net?
Your certificate store includes certificates for Root 2 – GeoTrust Global CA
Your security transport—the part that negotiates TLS—supports SHA-256
Your solution does not connect directly to Authorize.Net using an IP address
There’s more information about the new requirements from Authorize.net here:
https://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/Production-Certificate-Upgrades-begin-May-27-2015/ba-p/50430
|
|
Josh
|
December 10, 2015 at 10:49 am
Further to the above, it looks like the Authnet gateway was working on your site up until mid-November. At this point it’s important that you verify with your host that the server is set up to allow communication with Authorize.net.
|
|
Sinclair Lewis
|
December 16, 2015 at 7:47 pm
Hi, I was finally able to get the host to resolve the security certificate issues. But I’m still getting the same error.
I noticed that Authorize.net doesn’t accept parameterized URLs, but that appears to be what’s sent by EE3. Right before going to Auth.net, the HTML source shows x_Relay_URL as “https://www.jppcle.org/confirmation/?id=1054&r_id=6-56721e378fe3c&type=authnet&attendee_action=post_payment&form_action=payment”.
Could that be the issue?
Thanks
|
|
Josh
|
December 17, 2015 at 9:23 am
Hi there,
As far as I know from experience, they will accept URL parameters. The same URL parameters are used on all of the other sites that run EE3 and use Authnet SIM. You can run a registration and test payment on my testing site and observe the results:
http://is.gd/WGqtac
Have they checked to make sure that Authnet isn’t being blocked by a firewall?
|
|
Sinclair Lewis
|
December 17, 2015 at 11:24 am
Hi, Josh,
It looks like I still have one support token remaining. I’d like to use that to have someone look at the set up with the credentials I previously sent. I’m all out of ideas.
I did confirm with the host that Authorize’s IP addresses were not being blocked. They also white listed them.
Thanks
|
|
Josh
|
December 17, 2015 at 11:41 am
Hi there,
We’ve gone through your site and checked through everything. The time that this took was more than 30 minutes. The one thing that looked like it could lead to something was it looked like everything was working up until November 12, 2015. Was the site moved to a new server after that date, or were there changes made to the site or server then?
|
|
Sinclair Lewis
|
December 17, 2015 at 12:14 pm
Hi, Josh,
The site was moved to the current host around March of this year, though you’re right that the transactions stopped working around mid-November.
Definitely, something happened on the server to misconfigure the security certificate — they wouldn’t give me a clear reason.
Can you think of more areas to investigate? Authorize.net said they couldn’t directly help. I’m truly stumped.
Thanks again.
|
|
Josh
|
December 17, 2015 at 12:33 pm
Another lead that you could look into is any of the plugins that were added or updated around November 12. For example, when I FTP in to the wp-content/plugins folder, I can see that the iThemes Security plugin was either added or updated on November 12. Further to this, itt appears that someone else is having a similar issue with Authorize.net notifications using the same version of iThemes Security.
|
|
Sinclair Lewis
|
December 17, 2015 at 1:02 pm
I’ll check further into iThemes Security (which affects a ton), but the last-modified dates are from me renaming the plugin folders to deactivate them.
|
|
Josh
|
December 17, 2015 at 1:18 pm
One thing that could be happening there is iThemes Security adds things to the .htaccess file. So even if you deactivate the plugin, its additions to the site’s .htaccess file will continue to function. So you could make a backup of your site’s .htaccess file, then set up a new .htaccess file with only the WordPress permalinks rules. Then you can see if those .htaccess rules have any affect on using Authnet SIM.
|
|
Sinclair Lewis
|
December 17, 2015 at 8:42 pm
Josh, I can’t thank you enough for suggesting I try to .htaccess file. That was it. iThemes Security must have blocked Authorize.net after so many failed connections. It somehow didn’t dawn on me to check that file.
I’m sure every developer knows the feeling of thinking there must be something supernatural behind all these mysterious errors … until suddenly the error is resolved and makes sense. Thanks again for helping make sense of a very stubborn mystery.
Sam
|
|
Josh
|
December 18, 2015 at 9:07 am
You’re welcome.
|
