Payment flow and cart restore

[BrocksiNet]

Async Payment Flow

Additional References

• Payments (Shopware Docu)
• Payments Async External Gateway (Frontends Docu)

Current problems

• Customer is leaving the "happy path"
  • Customer wants to change payments (Cart is empty when going back from payment provider to shop)
  • Payment was not successful for whatever reasons (Cart is empty)
• Instead of putting the payment to the last step, how could a process with pre-authorization look like
• We need a visualization of both the process and the related API calls and functions to make it clear

Unhappy path in the default Storefront (TWIG)

• Order is created (CartOrderRoute) & payment fails in HandlePaymentMethodRoute
• User selects another payment method via SetPaymentOrderRoute & pays via HandlePaymentMethodRoute
• Responsible Storefront Controller \Shopware\Storefront\Controller\AccountOrderController::updateOrder

Please feel free to participate and share ideas on how to solve the payment flow issues with the store API.

[dithom]

@BrocksiNet Thanks for opening the discussion! As discussed prior and proposed by you, maybe there is a way to create a copy of the cart before triggering the order, store the token of the cart as a backup and use it in these cases. However the question is if it is actually possible to create multiple carts per user/session using the API and if so how to handle the "abandoned" orders then?

[BrocksiNet]

Yes, that would be a possible workaround. I updated the first post to explain how the "unhappy" path is solved in the default Storefront (TWIG). With that discussion, I would aim for two things: a Workaround for current affected projects and a valid future-proof solution, maybe via an additional needed endpoint for store API.

[dithom]

So I managed to provide a solution for the "non happy path" in frontends with your help 💪

1. I call createOrder .
2. Then I call handlePayment.
3. Before setting window.location.href to the redirectUrl I set orderId as a URL param in the current route. This way, if the user is clicking the back button of the browser, the URL param with the orderId will still be there.
4. In the same checkout view I'm checking for exactly this parameter and if it exists I redirect to the checkout finish view. Also I'm adding the URL parameter redirectFromCheckout=1 to the finish view redirect.
5. In the order finish view I check wether the paymentSuccess from the payment providers redirect is 0 or redirectFromCheckout is 1 . In both cases I try to reset the orders transaction state to open using a custom store API endpoint (this step is needed, as the core does not allow handlePayment if the order transaction is in a non initial state, see here. This can also be done securely in the frontend using Nitro event handlers and the Admin API, as seen here. But in my experience its a bit buggy).
6. Additionally I show an alert on the finish view, to tell the customer the payment was not successful with a link to the account order view.
7. In the account order view I added a button to repeat the payment, which is only shown if specific order transactions states are met (e.g. open).
8. This button (also calls my custom ReopenOrderTransactionRoute if needed and then) calls handlePayment. I then again update my URL params before the actual redirect to the payment provider and then redirect to the redirectUrl again.
9. If the user returns from the payment provider in this scenario the same flow will be triggered by the URL param set before the redirect.

Its not pretty, but it works for now 😄

[mstegmeyer]

Why are you building a custom route and don't use the SetPaymentOrderRoute to initialize the payment again? Am I missing something?

[dithom]

@mstegmeyer Nice, didn't know that! Seems this is exactly what I need to 'reset' the payment. I just need to get the payment method id from the order and call this endpoint before calling handlePayment? Can't find any documentation.

[mstegmeyer]

Yes, exactly. This makes it also possible to change the payment method just like the Twig Storefront does, if you hand it a different payment method id. Of course only, if the previous transaction is in a supported state, e.g. open, failed or cancelled, not when the the status is already paid.

[mkucmus]

Nice, didn't know that! Seems this is exactly what I need to 'reset' the payment. I just need to get the payment method id from the order and call this endpoint before calling handlePayment? Can't find any documentation.

here you can find the "change payment method" feature for frontends: https://github.com/shopware/frontends/blob/4066556d6cb61d098c6e7f41d66f745e6b66a234/templates/vue-demo-store/components/account/AccountOrderDetails.vue

note that the request for orders must have checkPromotions flag set to true if you want to retrieve the order numbers that have an option to change the method.

---

as an appendix to the general solution @mstegmeyer : Could be doing a cleanup a solution in that case? let's say the customer doesn't finish the async payment flow, normally, the process for every external payment gateway has a very limited time period session for such action. according to that short session requirement we could reset the transactions (I know it may be very complex logic hard to abstract) to enable payment process once again.

1. In that case, maybe having a cron-job that will clean up the "in progress" transaction that hang to long to the open (or whatever) state again.
   or...
2. ability to call the handlePayment more than once - probably related to the previous one - but will solve the problem seamlessly. In that case, payment handler will initialize the payment process regardless the transaction state (or safer: as it's now, but including the cleanup process that will make it possible).

from UX having only a button "pay for order" which hides the complex logic behind is a good way to go. I think it's more human to just go to see your orders, find the latest order (or directly order from an email) and click "pay" straightforward.