|
Michael Budd
|
September 2, 2014 at 3:08 pm
I am using EE 3.1.36.5.P. WordPress is 3.9.2. I was getting a relay response error originally, but that turned out to be an issue with the registration page being https and the thank you page not being. I found that both pages must be one or the other. In my case they are not https. I have the relay response URL at Authorize set to the pretty permalinks http://www.frenchlickwinery.com/events/thank-you/. When someone goes to purchase it takes them through Authorize but says the following after taking the payment: “An error occured while trying to report this transaction to the merchant. An e-mail has been sent to the merchant informing the 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.” It never takes them back to the site, it never shows in the events that it happened, and when I go to void the transaction at Authorize it shows that the value was $0.00 instead of the $20 it should have been. Please help ASAP.
|
|
Lorenzo Orlando Caum
|
September 2, 2014 at 4:02 pm
Hi,
Do you have an SSL certificate available for this site? If so, could you enable https for the thank you page and the event registration page?
I attempted to check some pages and each time I was redirected back to the http version of the page.
—
Lorenzo
|
|
Michael Budd
|
September 3, 2014 at 8:05 am
I had turned off the SSL on those pages since it shouldn’t be needed. Processing is handled by Authorize.net. I have re-enabled it for the four pages used by EE. The Main Registration and Cancel Return URL must be either set to either SSL or not, but they must both be the same or it won’t send the user to the payment gateway. I have tried it both on and off and the result is the same.
|
|
Lorenzo Orlando Caum
|
September 3, 2014 at 8:57 am
We generally see issues with Authorizenet declining due to bad credentials (live credentials in testing mode) or a required field that Event Espresso does not use.
Could you regenerate your API credentials and enter them into your payment methods page (ensure there is no extra spacing before and after the credentials) for Event Espresso again?
https://eventespresso.com/wiki/payment-settings-ee3/#SIM
Also, please change that relay URL to use https:
http://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/5-Most-Common-Errors/ba-p/35655
—
Lorenzo
|
|
Michael Budd
|
September 3, 2014 at 12:24 pm
I regenerated the API and entered the new info. I already had the relay response url set to https. I don’t have either side in test mode. I do not have MD5 in use. The SSL is valid. I can see the thank you page just fine by going to it directly.
I did notice that there was supposed to be a ‘Force SSL’ button in the payment settings, but it’s not there.
I have used Authorize.net in other carts/plugins (oscommerce/woocommerce) on the same server without issue.
|
|
Michael Budd
|
September 3, 2014 at 12:25 pm
Oh, and I forgot in the last post, it’s still not working. Sends the user over to Authorize, but can’t get back and does charge their card.
|
|
Josh
|
September 3, 2014 at 3:45 pm
Hi Michael,
Can you check your server’s PHP error log to see if an error was thrown at the time the relay response was fired?
|
|
Michael Budd
|
September 4, 2014 at 8:35 am
I don’t see any errors pertaining to this issue. I had installed the requirement check add-on and it is throwing a bunch of errors in the log, but nothing else. It is also filling up the log pretty fast, so I am disabling the add-on and resetting the log.
|
|
Michael Budd
|
September 4, 2014 at 8:36 am
I wouldn’t expect the log to have any info anyway since it’s not getting back to the site from Authorize to trigger anything.
|
|
Josh
|
September 4, 2014 at 9:02 am
Is WooCommerce activated on this same site?
|
|
Michael Budd
|
September 4, 2014 at 9:35 am
WooCommerce is not installed on this site.
|
|
Josh
|
September 4, 2014 at 10:32 am
Can you go into Event Espresso > General Settings and set the Use full logging? option to Yes? Then, if you run a test, it will log each step of the registration process to a file in /wp-content/uploads/espresso/logs.
Since you mentioned that it’s not getting back to your site from Authorize.net you could also try disabling any security plugins if you have any installed. I know from a few times where there have been security plugins that were blocking the payment response from the payment processor site. It may even help to try temporarily disabling the google events calendar plugin since its resources are being blocked (they’re not coded to allow for loading as https). This might be contributing to your server not sending Authorize.net an OK server response.
There’s more info in this guide from Authorize.net:
https://support.authorize.net/authkb/index?page=content&id=A663&impressions=false
|
|
Michael Budd
|
September 4, 2014 at 11:19 am
I have enable the full logging and ran one test.
I can test disabling the security plugin (iThemes Security), but I will have to change everything from https to http to do so since it’s that plugin that turns on the SSL. Although it will have to be turned back on after as we won’t be turning it off permanently no matter what the result. It is by far the best security plugin out there.
The Google Cal is not running on an https page, but I assume you are referring to the list in the sidebar. I will disable the entire plugin just for a test. If that works, I will reenable it and just disable that widget on the Espresso pages to see if that helps but lets the calendar page run independently.
|
|
Lorenzo Orlando Caum
|
September 4, 2014 at 12:12 pm
Hi Michael, that sounds like a good plan. If possible, please also try testing with a default WP theme and only Event Espresso running.
It should work on defaults since there should be no conflicts at this point.
Then begin to restore your site a couple steps at a time (e.g. activate a couple plugins) and then re-test again and continue the process until your site is restored.
—
Lorenzo
|
|
Michael Budd
|
September 4, 2014 at 12:39 pm
This is a live site, so changing themes is not possible. I’m not sure what turning off all the plugins will mean for this site, I’ll have to look into it. Unfortunately, the client decided to add live events before we had a chance to test and we are stuck working with the live site and in a rush to fix the problem.
|
|
Josh
|
September 4, 2014 at 1:08 pm
You can test a default theme without changing theme on the live site by installing the theme test drive plugin
Rather than deactivating Better WP Security (aka iThemes Security) you could check with them to see if there’s a configuration setting that should be verified to make sure nothing from authorize.net gets blocked.
|
|
Michael Budd
|
September 5, 2014 at 11:08 am
I found the issue. In iThemes Security there is a checkbox to add HackRepair.com’s blacklist feature, with this disabled it goes through. Funny, that means Authorize.net’s IP is on the blacklist??? Thank you for your help.
|
|
Josh
|
September 5, 2014 at 11:15 am
Hi Michael,
You’re welcome. It might be good to check with iThemes on this. They likely have other users that will run into this and they’ll be able to tweak the config so authorize.net isn’t blacklisted.
|
|
Michael Budd
|
September 5, 2014 at 11:46 am
I agree, I will let them know. I use it on every site I do. I do have a could WooCommerce sites running and they don’t have the issue. Not sure what the difference could be. I have worked with their API sending manually made forms before and there’s not much there that could be different between EE & WC. We always run our sites on the same host so that takes that out of the equation. odd.
|
|
Michael Budd
|
September 5, 2014 at 1:23 pm
Everything is working except the ticket app. I have the backend using something other than wp-admin. Is that why it won’t let me login to the app? If so, how do I get around that. I would hate to have to start over with another plugin, but we won’t be disabling that feature of iThemes Security. This is the last piece to the puzzle.
I also figured out that if SSL is enabled for the Event Listings page that the ticket link comes as HTTPS which breaks the CSS for the ticket template. So, I have SSL enabled for the Thank You page only and that keeps everything working smoothly.
|
|
Josh
|
September 5, 2014 at 1:44 pm
Hi Michael,
Since you’re using SIM for the payments, only enabling SSL for the Thank You page only will be fine.
I’m afraid I’m not understanding the issue here. First, I’ll ask for a bit of clarification. When you mention:
I have the backend using something other than wp-admin. Is that why it won’t let me login to the app?
Please explain what you mean by the backend using something other than wp-admin.
I would hate to have to start over with another plugin, but we won’t be disabling that feature of iThemes Security.
What feature, what does this have to do with iThemes Security? I thought that got worked out?
Can you verify that the Espresso JSON API plugin is installed? Along with that, here are some links to our documentation that will help you get up and running with the ticketing app:
https://eventespresso.com/wiki/json-api-add-on/
https://eventespresso.com/wiki/mobile-apps/
Besides installing the JSON api add-on, can you let me know specifically what’s not working with the ticketing app? Please let me know which version of the app you have installed, any error messages you see, and what you are trying to do when you see them.
|
|
Michael Budd
|
September 5, 2014 at 1:53 pm
I am so sorry. I was missing the JSON API plugin. Looks great. Tested it without issue after installing the API plugin. I should read closer.
What I meant by using something other than wp-admin was that the security plugin allows me to change that to whatever I want to help prevent hacking. for instance: http://www.mydomain.com/loginarea/ or http://www.mydomain.com/backend/
|
|
Josh
|
September 5, 2014 at 3:00 pm
Okay.
|
