[FEATURE REQUEST] mollieRestoreCart should restore the stock amount

[FloKnapp]

Describe the new feature

If i'm using the mollieRestoreCart-Mutation, the stock of the products remains unchanged. Currently, when a user cancels an order it'll still reduce the stock. This will lead to the situation where the product is eventually sold out, even though no one actually really has bought the product.

Describe the solution to be implemented

• The best way is to prevent the stock from decreasing.
• Another solution would be to restock the products again, after using the mollieRestoreCart-Mutation.

Backend changes Restock products from a cart which was reactivated through the corresponding mutation before.

Frontend changes No changes required

Additional context An approach from the community: https://stackoverflow.com/questions/12460568/programmatically-stop-decreasing-stock-qty-while-placing-an-order-in-magento

[Frank-Magmodules]

Hi @FloKnapp ,

The restocking of the product should happen through the Webhook, not through the GraphQL mutation. Please check if your Webhook is working as expected. Next, to that, we can recommend using the mollieProcessTransaction mutation as that will update the stock depending on the status of the transaction.

[Frank-Magmodules]

We are closing this issue now but please feel free to reopen the issue if this still occurs.

[FloKnapp]

Hi Frank,

thank you very much for your answer. Your tip regarding the mollieProcessTransaction mutation sounds very promising, i'll try that.

Thank you!

[FloKnapp]

Hi @Frank-Magmodules,

unfortunately i have to reopen that issue, as it still doesn't restock the products. As i read more about that topic, i saw that the documentation even recommends using mollieProcessTransaction, as this mutation is also able to restore the cart. It sounds right, but it won't work.

If i drop the mollieRestoreCart mutation and only use the mollieProcessTransaction mutation, i'll get a Cart isn't active error. Even if i restore the cart in the previous step, it doesn't restock the product with this mutation. The response from the mutation is correct though. I also provided the correct paymentToken.

Is it possible, that the mutation only works on aborted/abandoned carts? I checked the response from mollieProcessTransaction and the status was OPEN. Could this be the reason, that it just doesn't do anything?

[Frank-Magmodules]

Hello @FloKnapp,

The mollieProcessTransaction is meant to be called after the customer returns from Mollie. At that moment, usually, the status of the transaction is already determined and, the mutation handles accordingly to that. 

So when the status requires it, the product is being restocked. To manually test it, you can create a transaction like you would normally do, open the redirect link to Mollie and finish the transaction by either paying, canceling, etc. 

After this, you can call the mollieProcessTransaction and it should work as expected.

[FloKnapp]

Hi @Frank-Magmodules,

thank you again for answering so fast.

Our problem with the cart occurs when the user navigates back to our site with browser back. If he would abort the payment process as intended, we probably wouldn't have any problems.

Another issue could be, that we are using a PWA as the frontend. Before our adjustments, when the user navigated back from the payment provider (Mollie), he wouldn't have a cart anymore, as the previous cart gets submitted and inactivated after placing the order. Thus he'd get a new one. This is what i try to prevent here.

The stock issue is my last issue with this topic and i'm concerned that there isn't any reliable solution beside from programming the restocking mechanism for our case.

[Frank-Magmodules]

Hello @FloKnapp,

The mollieProcessTransaction is meant to be called after the customer returns from Mollie. At that moment, usually, the status of the transaction is already determined and, the mutation handles accordingly to that. So when the status requires it, the product is being restocked. 

To manually test it, you can create a transaction like you would normally do, open the redirect link to Mollie and finish the transaction by either paying, canceling, etc. After this, you can call the mollieProcessTransaction and it should work as expected.

[niklaswolf]

The restocking of the product should happen through the Webhook, not through the GraphQL mutation.

@Frank-Magmodules but how do you handle the "browser-back" case? In this case, Mollie can not send a Webhook immediately to trigger the restocking, am I right?

Example: Preconditions: Product has stock=1

1. User checks out with this product
2. On the Mollie payment page, the user navigates back to the shop with the browsers back-functionality
3. In Magento, there is a open order with status "Pending payment", the product has stock=0 now.
4. The cart gets re-enabled (through the mollieRestoreCart mutation, but the product is now out of stock and can not be bought again.

We have many products with stock=1, so this is a real problem for us...

btw. I can not reopen the issue, and @FloKnapp left the company, so could you please reopen it? :)

[azngeek]

Is there any feedback on this one? It is currently not possible for us to fix this without your support.

[Frank-Magmodules]

Hello @niklaswolf and @azngeek,

To maintain the correct status of the order, we depend on the status of the external payment method. The situation outlined would abort the order at an unexpected moment, which could lead to unexpected results at a later stage. This is therefore a scenario that we will not support.

That said, Magento is so flexible that you can always create a custom solution for your situation.

[niklaswolf]

Thanks for the answer :) In my/our view the browser-back functionality will be used by users more often than the back-button in the UI on the Mollie payment-page (especially on mobile devices, where you just have to swipe back). Would be interesting to have some data on this, Mollie should have that, right? ;) Maybe you can consider to work out a solution at a later point :)