Add some kind of cart or order status indicating that a payment is being processed

[Laantje]

Hi,

First of all, thanks for your work!
Appreciate it :)

However, I do have a request.
I would like to be able to see cancelled/failed orders in the orders overview. This way we can provide better support to our customers if problems arise during payment.

There are order and payment statuses for cancelled and failed orders, but this package does not seem to make use of them.
Using the Mollie test API, any orders that are cancelled or failed do not appear in the orders overview.

I haven't tried it in production yet but I assume its the same case.

[mattbrailsford]

This should already be happening, you can see the logic here for mapping Mollie statuses to Umbraco Commerce payment statuses. https://github.com/umbraco/Umbraco.Commerce.PaymentProviders.Mollie/blob/main/src/Umbraco.Commerce.PaymentProviders.Mollie/MollieOneTimePaymentProvider.cs#L474-L524

The only reason I can think for this not to be happening is if you are testing locally and haven't setup a webhook forwarding solution such as ngrok https://docs.umbraco.com/umbraco-commerce-payment-providers/mollie/how-to-guides/testing-mollie-webhooks-locally

Alternatively, if there is an error in the mapping logic, I'd appreciate you identifying where it's going wrong for you and what changes would need to be made.

[Laantje]

This should already be happening, you can see the logic here for mapping Mollie statuses to Umbraco Commerce payment statuses. https://github.com/umbraco/Umbraco.Commerce.PaymentProviders.Mollie/blob/main/src/Umbraco.Commerce.PaymentProviders.Mollie/MollieOneTimePaymentProvider.cs#L474-L524

The only reason I can think for this not to be happening is if you are testing locally and haven't setup a webhook forwarding solution such as ngrok https://docs.umbraco.com/umbraco-commerce-payment-providers/mollie/how-to-guides/testing-mollie-webhooks-locally

Alternatively, if there is an error in the mapping logic, I'd appreciate you identifying where it's going wrong for you and what changes would need to be made.

Hmm very weird, I'm testing this on our demo server (not locally) so there shouldn't be any issues with the webhook.

I'll try to debug what is going on.

[Laantje]

So far I can't seem to find out what exactly is happening in the background.

Here are some notable things that I have found so far:

• Whenever the payment is successful by checking 'Paid' in Mollie during checkout, it's status changes to 'Captured' and it does appear in the order overview under the Commerce section like it should. Cart is also removed in backoffice and emptied at front-end.

• Whenever I check 'Cancelled', the order is not placed in the order overview BUT my cart stays like it was before payment. Not sure if this is normal behavior.

• Whenever I check 'Failed', the order disappears. The cart is empty in both front-end and the backoffice and no order is placed in the order overview.

• Whenever I check 'Open' or 'Expired', the cart can still be found in the backoffice, however it does not seem to be in my front-end anymore. It appears as the cart still exists but is removed from my session.

Conclusion; It does not seem to save any order in the overview (at commerce section) when the payment status is not 'Captured'.

I'm not sure why this is happening, but as long as there is some kind of traceback (in either cart or order overview) of the unsuccessful orders it would be fine. However for the 'Failed' Mollie status this does not seem to be the case.

Am I supposed to handle any order errors myself using the OrderFinalizedNotification?

[mattbrailsford]

I'm not quite sure how you are testing this as it sounds like you are creating orders, but then changing the status from within Mollie? Are you going through a full checkout flow?

I think possibly these aren't being updated in the back office because I don't think these are final states. According to the API docs here https://docs.mollie.com/payments/status-changes a "failed" state should return to the checkout to choose an alternative payment method. As such, this means the order isn't completed and can be retried so the Umbraco Commerce order doesn't receive a payment status because we only assign payment statueses to finalized orders.

Likewise, it depends what you mean by "Cancelled"? Is this that the payment process was canceled, in which case during checkout this should redirect you back to retry payment. If you previously Authorized a payment however, then yes, in this case this would denote a cancelled capture and should get picked up.

[Laantje]

I'm not quite sure how you are testing this as it sounds like you are creating orders, but then changing the status from within Mollie? Are you going through a full checkout flow?

I think possibly these aren't being updated in the back office because I don't think these are final states. According to the API docs here https://docs.mollie.com/payments/status-changes a "failed" state should return to the checkout to choose an alternative payment method. As such, this means the order isn't completed and can be retried so the Umbraco Commerce order doesn't receive a payment status because we only assign payment statueses to finalized orders.

Likewise, it depends what you mean by "Cancelled"? Is this that the payment process was canceled, in which case during checkout this should redirect you back to retry payment. If you previously Authorized a payment however, then yes, in this case this would denote a cancelled capture and should get picked up.

Thanks for the reply. Let me try to clarify.

I'm using the Mollie test API for testing the provider so I don't have to pay for real. We are using Mollie because it has the 'iDeal' payment method which is used a lot here in the Netherlands. Not sure if you're familiar with the payment method.

Using the Mollie test API, I get redirected to this screen on Mollie's domain where I can select any Dutch banks:

After I select a bank, I can test the payment statuses on this screen:

This last screenshot shows the statuses I was talking about in my previous post.
Selecting anything other than 'Paid' doesn't seem to be handled the right way.

It does succesfully redirect me to the right pages that I have configured in the payment method's settings in the backoffice, but I can't say for sure what exactly is (not) happening in the background.

[mattbrailsford]

Yea, the problem is this is a checkout. The only real outcome we can handle is "Paid". You should never be receiving an "Open" or "Expired" status for a order during this flow as far as I'm aware.

And for "Canceled" and "Failed" in this context I would assume it wouldn't finalized the order, but instead leave it open and send you back to the cart page to try again

[Laantje]

Yea, the problem is this is a checkout. The only real outcome we can handle is "Paid". You should never be receiving an "Open" or "Expired" status for a order during this flow as far as I'm aware.

And for "Canceled" and "Failed" in this context I would assume it wouldn't finalized the order, but instead leave it open and send you back to the cart page to try again

I think I understand what you're saying and you're right.
Sorry for the confusion.

In that case, let me drop the Mollie status handling subject but instead let's look at this situation from a different point of view.

Let's say a visitor is redirected to Mollie to complete his/her payment using Mollie iDeal. Payment is successful, but unfortunately at that exact moment our server crashed and thus the payment status is never redirected back to the server. In this situation, it would be nice to atleast have the order in the order overview, perhaps with a order status of 'New' and a payment status of 'Pending'.

I guess I can somehow save the order myself after the payment method is changed to Mollie, but I'm not sure if this package will create a new order in the overview or update mine after payment is successful.

Do you think this approach will work?

[mattbrailsford]

If your server crashes, your Mollie webhook would fail and so Mollie should retry at specific intervals until it succeeds. When your server is back up it should receive the webhook and finalize the order.

Until the website is notified it doesn't know that the order is complete and so it will be considered a cart and will appear in the cart section.

Finalizing your order at the point of redirecting to the Mollie gateway would be problematic as until you've actually received payment, it's not complete but by finalizing it you've closed it off and so if payment does fail or they do cancel out, they wouldn't be able to go back and retry or edit the order (if they canceled because they forgot an item)

[mattbrailsford]

The only real thing I could think we could do is add another status to the carts status dropdown of "Processing" which could list carts that have had their payment initialized and possibley a "Failed" statuses if they have been sat in that state for a specific period.

This would give you an indication of orders that are mid payment / stuck, but there isn't much a store owner can do to push it forward as we don't have a way to manually finalize carts ATM so all they could do is chase it with Mollie / maybe retrigger the webhook manually 🤷‍♂️

[Laantje]

Thanks a lot for sharing your thoughts!
You're right, I've checked the Mollie documentation it does indeed retry reaching the webhook up to 26 hours.

26 hours does seem like enough time to get the server running again, so we're just going to bet on that for now.
The suggestion in your last post might be a nice to have feature (atleast for us), but not necessarily a priority one.

It's up to you if you want to implement it in the future, therefore I'll just change the title of this issue and leave it on open.
Otherwise you can close this issue :)

Thanks for the help!