Commerce 2.x Stories: Workflows
Now that we’ve covered products, it’s time to jump into orders. We are improving many aspects of orders based on previous feedback. One such aspect is the concept of order statuses and states.
In Commerce 1.x orders have a status. The status indicates the current checkout page, whether the order is a cart, whether it has been paid and fulfilled (shipped), or maybe cancelled/refunded.
Statuses are sequential, one goes after another. They are grouped by states, e.g. all checkout statuses belong to the “checkout state“.
The problem with this model is that one list of statuses indicates multiple concepts (checkout state, payment state, fulfillment state, etc). These concepts are parallel and trying to handle them sequentially creates bugs and confusion. For example, an order might be paid before or after checkout completes due to the async nature of certain payment gateways, or because the business is invoicing clients at the end of the month.
Furthermore, there is no requirement for the status to change sequentially, it can be set to any other status at any point. There is no way to express rules such as “only completed orders can be refunded“ or “completed orders can’t be sent back to checkout”.