|
humanear
|
February 22, 2022 at 6:56 am
I am switching from one server to another. Naively, I cloned the site and changed nameservers. Site appeared to work until I got to the authnet payment. I get this error with a red border over the payment info:
“The billing form could not be displayed. Your web browser may not be supported. Please restart your registration using different browser and notify the site owner.”
At this point you can enter your cc information and the payment will be accepted, but in EE4 the transaction will not be there and the registration says “abaondoned.” I quickly reverted back to the old server, cloned the site and put up a test site. Test site on the new server does the same exact thing. One note: Prior to the EE4 update, EE3 would give an error like this:
“The payment processor Authorize.net appears not to be responding. Their server may be having issues or <company name>.may have content being served over http and your browser is preventing the page from loading completely. Please contact the site owner and try again using a different browser.”
PHP 7.4x, WP 5.9, all identical setups. Any ideas how to fix this?
|
|
Tony
|
February 22, 2022 at 7:14 am
Hi there,
I am switching from one server to another. Naively, I cloned the site and changed nameservers.
Same domain? (I’m assuming so, but just checking)
At this point you can enter your cc information and the payment will be accepted, but in EE4 the transaction will not be there and the registration says “abaondoned.” I quickly reverted back to the old server, cloned the site and put up a test site. Test site on the new server does the same exact thing. One note: Prior to the EE4 update, EE3 would give an error like this:
Ok, so hang on.
Is this more than just a server change? The current site is EE3 and the new site is EE4 or is this just for reference?
Which Auth.net payment method are you using with EE4?
Can you link me to an event I can run a test registration on to view the error?
|
|
humanear
|
February 22, 2022 at 7:18 am
Thanks for the reply. The first time everything was EE3. I cloned and yes, used the same domain. Didn’t work so thought, well, I’ll upgrade to EE4. Upgraded on the original server. Everything worked fine after testing. So I cloned again and then set it up on a test domain. The test domain is https://scinu.com. some of the events are expired, so would suggest one towards the bottom of Feb.
Phil
|
|
humanear
|
February 22, 2022 at 7:19 am
PS, it’s authorize accept.
|
|
Tony
|
February 22, 2022 at 7:34 am
So, it’s hard to say if this is the cause because you had an issue with EE3 and EE4.
Just to confirm, you’ve checked th ‘Authorize.net API login ID’ and ‘Authorize.net Transaction Key’ keys used in the accept payment method are valid, yes?
https://eventespresso.com/wiki/eea-authorizenet-accept/#locate
Right now, the auth.net iframe communicator request is being blocked:
https://scinu.com/wp-content/plugins/eea-authorizenet-accept/iframe-communicator.php
That’s returning a 403 and it shouldn’t be, so something on your server is blocking that request.
The way the auth.net accept payment method works is to run the requests in the background with the above file to communicate to/from auth.net, its needs to be able to run and right now your server instantly returns the request with a 403…. the JavaScript is waiting on a response which is why the cog stays for a little until that times out and you see the above error.
I’d recommend checking with your host to see if they can tell you why the above requests are returning 403, they should load and return a status code of 200 for auth.net to work so that’s the first step.
|
|
humanear
|
February 22, 2022 at 7:40 am
Yes, the keys are identical. Let me do a bit of troubleshooting on the server end and see if I can get an answer there. Thanks!
|
|
humanear
|
February 22, 2022 at 8:22 am
Okay, well, it’s working now. the host I’m using, while having a great panel full of options, had one single option disabled by default that I had to enable. Although I feel sort of stupid now, I’m glad it’s resolved, and this is a great tip. The option under “Application Access” was labled “Direct PHP Files Access” and was set to Disabled. Enabled it and all is well. Thanks for the great response and support!
|
|
Tony
|
February 22, 2022 at 8:39 am
Ahh, ok. So yeah that’s a nice feature really but will cause problems with stuff like the above.
I’m glad you found the problem, any further issues just let us know.
|
