[BUGFIX] Switch order of PaymentEvent & StockEvent

[rintisch]

The PaymentEvent has to be placed before the
StockEvent because the order can fail in the
PaymentEvent so the StockEvent has to be placed
after the PaymentEvent.
In case a PaymentProvider uses forwarding the
PaymentEvent and FinishEvent has to be triggered
within the EventListener of the PaymentEvent.
This is already described in the docs.

Fixes: #571

[extcode]

I think this change would already be a breaking change.

The original idea to choose this order was that a payment process can take a while until all the data has been entered. In the meantime, another user could buy the last available products and pay faster than the first user. A rather unlikely case, but still possible.
There are two possible solutions to this idea. Either the payment providers increase the stock again in the event of an error, or the extensions for the availability check include a storage system in which products and their number are saved during the payment process. In the event of incorrect payments, this storage is prepared accordingly and, if successful, the number is finally reduced in the product.

Since the current behavior of the payment providers is such that the order is saved even before the redirect to the payment provider and the order is marked as canceled in the event of an error, the stock should rather be updated again in the event of an error.
I'll have a think and see what needs to be adjusted in the product extensions.

I have to say that I have no idea how often the stock management in cart-products is really used.

[rintisch]

That sounds reasonable!

I guess you mean you look what needs adaption in the payment extensions (instead of "product extensions")?

When no realizing this ticket we need to adapt the documentation: https://docs.typo3.org/p/extcode/cart/main/en-us/Developer/Events/Index.html#confval-extcode-cart-event-order-stockevent
→ It's named as "fourth event" (after the PaymentEvent) and that it needs to be triggered by the payment extension.

[swisschocolate]

All reasonable arguments, @extcode . Problem of current behavior is: if the payment fails – or even if the customer simply does not process the payment process – the stock remains too low. Therefore it's not clever if the payment provider rolls back the stock in case of a failed payment, because it has no chance to do so if the customer simply closes the payment window.
Better solution would be a configuration in the payment settings, whether the stock handling shall be processed by cart (current and standard behavior) or not. In case of latter the stock handling (and cart-emptying) is in responsibility of the payment provider and will then only processed if payment was successful. And yes, there is a risk of overbuying. But to be honest: this would be rare, at least rarer than a failed or aborted payment.

[rintisch]

I close this ticket due to the discussion in #571. Another solution will follow.