Posted: September 26, 2017 at 12:09 pm
|
September 26, 2017 at 12:09 pm Hi there, |
|
September 26, 2017 at 12:11 pm Sorry, I’ve left it on PHP 7. |
Hi Lisa, You can go to Event Espresso > Payment Methods > Logs and check the log entries there. Usually there are three log entries per transaction and one of them will include a response from iDEAL. There may be an error message in the response. |
|
|
Hi Josh, There aren’t any logs there..?? (Since 03/26/2017) Cheers, |
Hi Lisa, That may mean there isn’t any communication happening between the site and iDEAL when it sends the payment notification. Can you check to see if the server has cURL enabled and also check for the potential of a security plugin blocking the response? Also does the site have the current version of the iDEAL plugin? (v1.0.1.p) |
|
|
Hi Josh, I have EE4 iDeal Mollie Payment Gateway v1.1.4.p installed. cURL is enabled, and using Wordfence plugin, but I’ve disabled it now. It still doesn’t complete the payment and there are still no logs. Interestingly, I now can’t approve payments manually that have been made, so getting a bit stuck with registrations (attempted both before and after disabling WordFence) Help! |
|
(I can send you a screen shot – it just sits there on the approve payment page saying processing at the bottom of the screen but doesn’t complete) |
A screenshot won’t help, there will be an error being thrown on the request which is breaking the ajax (the processing). Do you have access to the server’s error logs? If so check if any fatal errors are being thrown by EE. |
|
|
September 27, 2017 at 11:30 am Nothing in the logs on the server… |
|
September 27, 2017 at 11:37 am I have also used developer tools to monitor the network traffic and other errors whilst making a payment but nothing shows up. I guess ajax problems would show up here? |
September 27, 2017 at 11:41 am Can I take a look in the admin? If so you can send temporary login details using this form: https://eventespresso.com/send-login-details/ Note the FTP credentials are important as I’ll likely need to enable WP_DEBUG on the site to view the error and please also provide details oh how I can reproduce within the form. |
|
September 27, 2017 at 11:42 am You’ll see the ajax request there yes (within the admin-ajax.php request), but if your server isn’t displaying errors you’re not going to see anything on the request. |
|
|
September 27, 2017 at 11:59 am I’ve sent the temporary login details. |
ok, there is no error because the method isn’t even running so it’s not getting to the point where it would throw an error. Have you restricted admin-ajax.php with WordFence at all? (Note that disabling WordFence doesn’t remove a lot fo the modifications it makes, for example custom .htaccess rules) |
|
I’d like to install plugin to confirm the capabilities are correct on Admin role, just confirming that’s ok? If you prefer to install them yourself: Members by Justin Tadlock s fine. Or User Role Editor, anything that allows me to view caps. |
|
|
Hiya, no .htaccess rule to block access to file and haven’t made any other modifications. # END WordPress Yes, its OK to install confirmation plugin to check if capabilities are correct. Thanks Tony |
Hmm, so the capabilities are fine. The above .htaccess is fine. It’s possible something is de-registering the ajax action EE registered for the above actions or something is hijacking ajax requests and If you test the above with only Event Espresso running what happens then? Each request made throws errors from Thesis, it’s on a totally unrelated file but it may be a clue that Thesis is doing one of the above on the ajax requests. Try temporarily switching to a default theme and see if it works then. https://eventespresso.com/wiki/troubleshooting-checklist/#themeconflicts If you’d rather not test this on the live site I’d recommend cloning the site on a subdomain and troubleshooting this there, once the cause is found a fix can then be applied to the live site. |
|
|
Thanks for your reply. I’ve now tested EE on just Twenty Seventeen with no other plugins running with the same result. The transaction sits at Pending Payment and no confirmation is sent. Reverting the site back to PHP 5.6 has resolved the manual completion transaction problem, so at least I can manually complete registrations. Thanks, |
Is the server running opcache with PHP7? You’ll need to disable that to use it with EE4. I’m running multiple test sites on PHP7 and PHP7.1 without any problems updating the registrations so if you’ve tested that with no other plugins and a default theme there’s something different about the setup there. I’ve added some additional logging to the Mollie iDeal payment method, can you switch out the version in use on the site currently to the version I have just emailed to you please. I’d like to confirm that the mollie payment object is created correctly and the values it is using are correct. |
|
|
Hi Tony, I deleted the old Mollie plugin and installed the one you emailed. Then I ran a test transaction, and it still doesn’t complete. I reverted back to PHP 5.6 as PHP 7 wasn’t allowing me to manually complete the transactions. Could this have been caused by opcache running then?. Many thanks! |
|
September 29, 2017 at 10:55 am (By the way the site is hosted on siteground) |
September 29, 2017 at 11:10 am Opcache will tend to cause fatal errors like this:
|
|
The changes I made to the Mollie add-on won’t fix the problem, it just added a log entry with the mollie payment object contents. That object is created when you select mollie, EE builds out a mollie payment object and then passes you over to mollie. As part of that object, EE tells Mollie the ‘webhookUrl’ and ‘redirectUrl’ webhookUrl is the URL that Mollie will send the IPN too, redirectURL is the URL you are directed to after payment. For EE the webhookUrl looks like: All that request does is trigger EE to pull the Mollie payment from your transaction and then send a request to Mollie to confirm the payment went through. The problem on your site is that URL isn’t being hit by Mollie (that’s why there is no other payment logs) so either something is blocking that request or the transactions page is being cached and not telling EE to load the payment etc. Can you check with siteground that the requests aren’t being blocked by them? You can find Mollie’s IP Addresses here: If I manually load the above URL in my browser I can see from the EE logs that it attempts to check with Mollie and confirm the payment, which means on a ‘normal’ payment, that isn’t happening at all. If you’d like I can temporarily switch out your Mollie details on your payment method with our test account and run a payment using my account just confirm its not an issue with the Mollie account. The test account will be live for roughly 5 mins but during that time another user may register and attempt to pay. |
|
|
September 30, 2017 at 10:38 am Hi Tony, Yes do go ahead and run a test with your Mollie details and let me know how that goes. If you rule out the account itself, I will get in touch with Siteground. Cheers, |
I tested with our credentials and the same issue happens with those so it’s not the account. |
|
|
Hi, Tony, |
|
Shall I reinstall EE from scratch? Will I loose all of the previous events and registrations? |
I thought you were contacting SiteGround to have them confirm they are not blocking the connection from Mollie?
De-activating and deleting Event Espresso through the plugins menu will not remove any data from your site. WordPress may show a notice advising you will lose data, but that’s incorrect, plugins choose to remove data when uninstalled and EE does not. So to answer your question, no you will not lose any events and/or registrations. However, EE appears to be working correctly, if I hit the /transactions/ page using the URL above I can see the Mollie payment method logs trying to connect to Mollie to confirm the payment. That doesn’t happen with live payments on your site (it should) so it seems something is blocking the request from Mollie. |
|
|
OK thanks Tony – I will check with Siteground 😀 |
|
Dear Tony, Siteground given a clear answer: no, the Mollie IP’s are definitely not being blocked. ?? |
Hmm ok. How have you set up the site to load over https? One thing I can see is the webhookUrl value I mentioned above is using HTTP, Mollie uses that value to POST back a value and the redirect that is happening might (although it shouldn’t) be breaking that. Your WP and Site URL settings are set to load over HTTP so I’m assuming you’ve set up some form of redirect? |
|
|
Hi Tony, Thank you very much – that was exactly the problem. I over looked setting the URL’s to https and the redirection was being done somehow by Siteground. Thank you! |
You’re most welcome, Lisa. I’m glad its working and any further problems please do let me know. Have a great weekend 🙂 |
|
The support post ‘iDEAL Mollie not changing Transaction Status to Complete after payment’ is closed to new replies.
Have a question about this support post? Create a new support post in our support forums and include a link to this existing support post so we can help you.