Closed t-heuser closed 2 years ago
This is an interesting suggestion.
Are you aware though that as of v2.2.0 you can also override the Webhook URL in production, ensuring that in a headless setup you could still route them to the backend? Maybe that's a solution that would preserve a bit more of the "dynamic" that a webhook-based solution provides over a cron-based solution.
@fjbender No, was not aware of that. But that would atleast fix the issue in production mode in our public system. However in our internal stage, test and dev system(s) this will not work as they're not reachable from the internet.
That's true, and for those cases where using ngrok or an SSH tunnel is not feasible, your suggested feature would indeed work.
Thanks for the request @oneserv-heuser and for your input @fjbender.
I'm going to discuss this feature request internally but as @fjbender already pointed out, using ngrok on local is a good solution for this. But I'm not sure if adding a cron for testing things locally (when there is already a solution) is preferred as a solution as this could open up simultaneous updates on transactions on live.
Will come back on this next week!
@Frank-Magmodules Can you explain to me how exactly the custom webhook url is supposed to work? Just looked through the code and searched for the usages. I don't understand how it should work. The configured custom webhook url gets passed to mollie and then mollie calls the url. But the magento mollie controller obviously only triggers on https://domain.com/mollie/checkout/webhook. Do I have to redirect this myself internally? I don't find any logic on how magento is supposed to understand the custom webhook url. Maybe I'm missing something.
And we'd not only use the cron for our test, stage and dev systems but also for the production system as we then don't have to specifically route the webhook url to magento. Please keep that in mind when discussing internally.
And what exactly do you mean by
as this could open up simultaneous updates on transactions on live.
You mean that the webhook and the cron could be running at the same time? I think this could be avoided by providing a setting that either webhook or cron can be used and not both at the same time.
HI @oneserv-heuser ,
Again, thanks for opening this issue. We have discussed this with our team and decided not to go with it. It adds a lot of complexity while not adding any functionality that is already present. Next to that, we already have a solution in place for your specific situation, which is also not very common.
About the solution: You can set the option “Stores -> Configuration -> Mollie -> Advanced -> Triggers & Languages -> Use webhooks” to “Custom URL”. The description needs an update, but this should also work in production. This way, you can enter an URL in your frontend, which then gets proxies to your backend.
Based on your issue, we did create a good explanation about the webhook communication between Mollie and your local-Magento environment. Please see; https://github.com/mollie/magento2/wiki/Webhook-communication-between-your-Magento-webshop-and-Mollie
We are closing this issue now but please feel free to reopen the issue if you have other thoughts or ideas on this.
Describe the new feature
At the moment, the payment status for orders is updated via 2 methods:
Adminhtml, as seen in the image
Via webhook, executed by mollie itself when a change appears to the payment on mollies side. A webhook url gets called which then triggers a refresh in magento. Example:
https://domain.com/mollie/checkout/webhook/?isAjax=1
(can be obtained from mollie backend)Our problem now is that we use Magento as a headless system. So all urls which are called will be routed to our frontend, which is decoupled from magento. That means that the webhook runs into our frontend and doesn't get the result it expects.
The feature would be to build a cronjob which updates all payment statuses of all unfulfilled orders which are connected to mollie. It should be fairly easy as the logic is already implemented as it's the same as for the webhook and the adminhtml button. The only difference is the trigger point which would not be the webhook/button, but the cronjob.
This would also fix the issue that you have to manually fetch payment status updates via the adminhtml in your local development environment as mollie cannot reach it.
This would be an extremly important feature to us as otherwise we would have to update the payment status from all orders by hand as the webhook routes into our frontend.
Describe the solution to be implemented
Backend changes A cronjob is implemented that gets all orders from the database where the payment method is provided by mollie and the status is not fulfilled. For all those orders the function Mollie\Payment\Model\Mollie::processTransaction() would be executed.
Frontend changes None needed.