Hi Annelies,
No, unfortunately not. That is because of how Mollie returns the payment statuses.
Every time the transaction has a change (paid, canceled, refunded, etc), Mollie will call your server’s web hook. To increase/ensure security, they only send the transaction ID (tr_xxxxx) and nothing else.
The plugin then has to (re-)connect with Mollie to fetch the data and process it accordingly in EM (create a transactions table entry, send emails, change the booking status, etc).
To connect to Mollie (and get the info), the plugin needs to authenticatie itself by using the exact same API key as with which the transaction was originally done.
Your connection will even be refused if you try to access a live payment using your test key and vise versa.
Because of that security, the plugin has no way of knowing which API to use, if not a static one.
The transaction ID is created by Mollie and only returned to your server upon the first webhook call. So, before sending the customer off to Mollie, there is no transaction ID, yet.
Even if I created the transactions table entry before redirecting to Mollie, there would still be no way to link it back. Because Mollie only returns the transaction ID and WP/EM has no clue to which booking that belongs. That info is in Mollie’s answer when correctly responding to the web hook call.
Makes sense? 🙂
Hi Patrick,
You’re right, the way you describe it won’t work.
When I look at the documentation, when you create the payment, the webhook is also defined in the request.
So another solution could be to add a parameter to the webhook and change it per location (= API key). Then you only need one webhook and check there which parameter enters and you can call the Mollie API with the correct API key.
What do you think?
Again, no.
The web hook url itself is only there to wake the correct EM function up. Every Mollie transaction is done via a uniquely created link.
If you add the api key to the url, you will lose all security.
Also, think of it from the point of view of the customer.
A Mollie transaction has a description, also on the bank statement. If I order tickets on the website of Ticketmaster, I would distrust my payment going to any other company.
Especially with all the phishing emails going around.
Also you are still legally liable for every ticket sold through your website. So why give up control over that?
What happens with a refund or cancellation? Do your owners have those EM capabilities? What happens when there is a dispute?
I bought my tickets on your website, so I will turn to you.
Think of the Consumentenbond and EU’s vision on warranty with AliExpres. 😉
You don’t have to use the actual API key as the parameter I described, you can use a simple integer that (internally) maps to the API key / location.
Still, I will not be implementing any security risk. I am also wondering if Mollie’s policy would even allow it.
Hi Patrick,
I understand, no problem!
Thanks for your time and for the plugin.
Greets,
Annelies
