Implement draft order support in Medusa ourselves
Medusa offers the option of creating draft orders. Unfortunately, these are only properly integrated in the cloud solution. For our self-hosted Medusa instance, there was only one option: do it ourselves!
We have already implemented a web shop with Medusa for our customer.
Now our customer wanted to offer a new payment method: prepayment. But then a new problem arose in connection with Medusa:
The problem:
The normal Medusa process stipulates that an order is only generated once the customer has paid for their shopping cart.
This does not work with prepayment, as the payment process can take several days. During this waiting period, however, the order should still be “parked,” listed in the admin view, and no longer displayed in the shopping cart.
The prepayment workflow should therefore work as follows: The customer wants to complete their purchase process and is directed to the payment service provider, where their bank details are displayed. Only after the customer has transferred the amount and the payment has been confirmed by the payment service provider is the order finally placed so that it can be processed internally
Draft orders as the solution:
Medusa has the option of marking an order as a draft in the data. However, this status is not integrated into the regular e-commerce processes and is only used when the draft orders plugin of the cloud version is used.
Although it is possible to create this draft order and convert it into a normal order, this only changes the status from “draft” to “pending.”
This meant that we had to ensure that the products were reserved correctly when the draft order was converted and that the draft orders were displayed in the backend.
The implementation:
For every order with prepayment, we create a draft order that is assigned to the payment session. The order remains in draft status until we receive notification from the payment service provider that the payment has been received. The draft order is then converted into a normal order. To do this, we had to use Medusa functions to reserve the products and update the inventory correctly. Once the inventory has been updated, the order is marked as “completed” and can now be processed further and shipped.
When converting the draft order into a normal order, we followed the “complete cart” workflow. It was important to test thoroughly and replicate the workflow exactly, otherwise orders would not be completed correctly or products would not be reserved properly.
Conclusion:
This example clearly shows how working with standard software can be done. Although a feature is available, it does not exactly match the current use case. Thanks to Medusa's modular structure and the ability to view the Medusa source code, we were able to extend the standard to such an extent that it now meets the required specifications.
)
)
)
)
)
)
)
)