Order Creation
Sometimes it's hard to support all kinds of options and possibilities that merchants need. And one of the major topic in Shopware 5 with Mollie might be the time when the order is created. This can either be before, or after the payment.
This document helps you to chose the best option for you and your Shopware shop.
The configuration can either be done within the plugin configuration, or separately for every Mollie payment method.
This option is what we recommend to use if you want to go the "safe" way.
When a customer orders something in your Shopware shop, then the order will be immediately created in Shopware as an "open" order, right before the redirect to Mollie happens.
The main purpose of the order button is, to have a "binding order contract". This tells us that this approach makes totally sense. An order is placed, but only the payment needs to be done to finish it.
As soon as the payment is made, the customer is redirected back to Shopware which finalizes a few things, such as the order confirmation mails. But the required update of the payment status or order status is also done in the background by using Webhooks. So this means, that the order is "completed" without any browser interaction of the customer.
Also, everything from the Shopware order is already available to be passed on to the Mollie Dashboard, directly when creating the payment.
The problem with this approach is, that payments can fail.
So when a user is coming back from Mollie with a failed payment, then the order will be automatically cancelled.
This is by design no bad thing, actually quite correct. But Shopware has only 1 number range for orders (order number). There is no separate order number and invoice number. And that means, that you might have missing and skipped order numbers if you only consider "successful" payments in your accountings.
Also, some plugins that export orders to ERP or goods management software, do unfortunately export those orders immediately. This means that orders will be exported, that might get cancelled a few moments later due to a failed payment. That approach of such export plugins is not correct, but reality.
A well designed export plugin would allow you to only export orders with a defined order status or payment status.
But still, a very very important benefit of this option is, that you always have the order in Shopware.
Sometimes it can happen, that a customer closes his browser immediately after the payment and will never return to Shopware. Or even some payment methods might not return the customer to the shop in some rare cases.
In such scenarios, there should not be a problem, because the order is already visible in the Shopware backend.
The only thing that might happen is, that you realize something has been forgotten to handle in a business process. But you can easily see and adjust the order in the Shopware backend, if even necessary.
- Safe option to always have an existing order in Shopware, which is a super important business requirement
- You might have gaps in order numbers due to the automatic cancellation of failed payments
- Other plugins might already use the "open" order which might not be correct at that time.
If the "cons" of the "Create Order Before Payment" approach are a problem for you, then this option might be a good choice.
If a customer places an order in your shop with this option, there won't be an order in Shopware created. The customer is redirected to the Mollie page, where he pays for his products.
Afterwards he will be redirected back from Mollie to Shopware.
Shopware (or the Mollie plugin) will now verify the payment status.
If the payment was successful, then a new Shopware order will be created along with other finalization steps that happen for both options (Before, After).
But if the payment fails, there will not be a Shopware order. Instead the customer is redirected back to the confirm page where he could adjust his payment method, or simply retry it.
While this is clearly a good thing to avoid gaps in order numbers, or automatic exports to other systems, it is major problem, because it's not always 100% safe that a user will return after the payment.
If the customer closes his browser after the payment, if the session of Shopware runs out, or if the customer is somehow not redirected because of a rare scenario in a payment, then there will not be an order created in Shopware!
The temporary Shopware order can still be found in the abandoned carts within the Shopware Backend (Marketing -> Analysis -> Cancellation Analysis).
So this might only be a good choice, if you need slim and accurate orders within Shopware.
If you are now wondering, why Shopware orders are not created from a webhook, which might always work, then please read the section later on this page.
- No gaps of order numbers in successful orders
- No accidental export of failed orders to other systems. Only successful orders exist in Shopware
- If the customer is not redirected back to Shopware, then you dont see an order and the customer waits for his products forever.
One of the major thoughts about creating a perfect flow would involve using webhooks. It would indeed be the best way, to always create orders and other things just from within a webhook.
But this is where it gets complicated with Shopware.
Mollie tries to stay as close as possible to the default behaviour of Shopware. This is a must have to avoid any side effects and other troubles in an eco system with lots of plugins and possible causes of errors.
The default function to create an order in Shopware can be used by all plugin developers.
But deep down in that function, Shopware has a very tight coupling to the browser session.
This means that it's only possible to create an order, if it's executed within the session of the customer and his browser. That, on the other hand means, that it's not possible to use this from within a webhook.
Webhooks work independent from the customer and his browser session, and does therefore not know anything about the customer session. So it's just as if an anonymous user without account or even basket would need to finish the order from another user who is currently signed in.
If you are now wondering, why don't we just fake the session, or build our own function to create an order. Then yes, you are right, that would be possible...at least in theory.
But rebuilding that (as duplicate code) or just faking the session, would mean that a Shopware update could easily change something in the original code, and suddenly it's not working anymore. Or maybe another plugin would change something in the session data, and suddenly you end up with wrong orders.
Another solution would be to completely backup and save the session data in a separate table in the database. That would be a perfect option, because it means we could always finish an order from...yeah...everywhere. But this would probably lead to a huge amount of data which might cause some shops to break. Though it might be the most likely one to consider.
Sometimes it happens that a user is returning from Mollie to Shopware and suddenly an error or login page is visible. The logs indicate that the "Shopware Session is gone".
This basically means, that the user is not signed in anymore, nor has he the products and cart available...so just like any anonymous user. In that case, the finish process after the payment cannot be done. If you use "Create Order After Payment", that even means that the Shopware order cannot be created, though the customer might have paid successfully.
There are different origins of this problem, and none of them is actually the fault of a plugin itself.
Sessions just run out after a while, and in fact this can be configured in Shopware. If a customer has to search his credit card, and is idle a few minutes, then a short session time would expire and the problem would occur.
But also if you have a garbage collector that always clears sessions, this might happen even though the time would still be fine.
After dealing with custom extensions of session expiration times, we figured out, that we just cannot fix problems that are completely out of our scope and a matter of hosting and Shopware configuration.
So we strongly recommend the correct configuration of Shopware and also consider using "Create Order Before Payment" to be safe. If you want to read more technical details about Shopware 5 Session handling, please see this page: https://developers.shopware.com/sysadmins-guide/sessions
Nevertheless, there is one thing the Mollie plugin brings with it.
In some circumstances a customer might switch browsers while paying for an order in a short amount of time (session still existing). Mobile payments with apps such as Paypal, iDEAL, might open your default browser after the payment, which might not be the one you have initially used for the checkout.
So there are indeed legit ways where a new browser is used to finalize the order.
And a new browser means, new session and that means you are a completely anonymous visitors.
How could Shopware then know that you can finish the order from "another users session"?
For this case we have implemented a feature, so that browser switching works, as long as the session is still available in Shopware.
With all this, please keep in mind, we are most of the time only talking about a handful out of lots of orders.
You should now know why some things are the way they are.
We would of course love to change things to be even better for you.
Because Mollie is an ever evolving company that aims to bring more and more features for you as a merchant, we cannot completely focus on changing Shopware in the way it has been designed.
If you have good ideas to improve the described workflow on this page, we are keen to hear it.
Thank you
