Support

September 26, 2017 at 1:32 pm

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.

September 26, 2017 at 2:59 pm

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)

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 1:27 pm

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.

September 28, 2017 at 1:52 am

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 $.ajax.post has its values wiped/altered. Or even something altering EE’s load process so that ajax called back isn’t being set on the request.

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.

September 29, 2017 at 5:02 am

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.

September 29, 2017 at 1:13 pm

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:

http://www.womensbusinessinitiative.net/transactions/?e_reg_url_link=1-ba10abc197d6b3ab334f1c9d3246658d&ee_payment_method=ideal_mollie

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:

https://help.mollie.com/hc/en-us/articles/213470829-Which-IP-addresses-does-Mollie-use-From-which-IP-range-can-I-expect-requests-

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.

October 2, 2017 at 4:21 am

I tested with our credentials and the same issue happens with those so it’s not the account.

October 5, 2017 at 10:54 am

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?

October 6, 2017 at 2:09 am

You’re most welcome, Lisa.

I’m glad its working and any further problems please do let me know.

Have a great weekend 🙂