Orders

In Vendure, there is no distinction between a "cart" and an "order". The same entity is used for both. A "cart" is simply an order which is still "active" according to its current state.

The current state of an order is available via the state field on the Order type. The next possible states can be queried via the nextOrderStates query.

The available states and the permissible transitions between them are defined by the configured OrderProcess. By default, Vendure defines a DefaultOrderProcess which is suitable for typical B2C use-cases. Here's a simplified diagram of the default order process:

Let's take a look at each of these states, and the transitions between them:

• AddingItems: All orders begin in the AddingItems state. This means that the customer is adding items to his or her shopping cart. This is the state an order would be in as long as the customer is still browsing the store.
• ArrangingPayment: From there, the Order can transition to the ArrangingPayment, which will prevent any further modifications to the order, which ensures the price that is sent to the payment provider is the same as the price that the customer saw when they added the items to their cart. At this point, the storefront will execute the addPaymentToOrder mutation.
• PaymentAuthorized: Depending on the configured payment method, the order may then transition to the PaymentAuthorized state, which indicates that the payment has been successfully authorized by the payment provider. This is the state that the order will be in if the payment is not captured immediately. Once the payment is captured, the order will transition to the PaymentSettled state.
• PaymentSettled: If the payment captured immediately, the order will transition to the PaymentSettled state once the payment succeeds.
• At this point, one or more fulfillments can be created. A Fulfillment represents the process of shipping one or more items to the customer ("shipping" applies equally to physical or digital goods - it just means getting the product to the customer by any means). A fulfillment can be created via the addFulfillmentToOrder mutation, or via the Dashboard. If multiple fulfillments are created, then the order can end up partial states - PartiallyShipped or PartiallyDelivered. If there is only a single fulfillment which includes the entire order, then partial states are not possible.
• Shipped: When all fulfillments have been shipped, the order will transition to the Shipped state. This means the goods have left the warehouse and are en route to the customer.
• Delivered: When all fulfillments have been delivered, the order will transition to the Delivered state. This means the goods have arrived at the customer's address. This is the final state of the order.

Order Interceptors

Order Interceptors allow you to intercept operations that add, modify, or remove order lines. Example use-cases include:

• Preventing certain products from being added to the order based on custom criteria
• Enforcing a minimum or maximum quantity of a given product in the order
• Using a CAPTCHA to prevent automated order creation

For details on customizing the order process, see the Developer Guide.

Code Examples

Querying order state

You can see the current state of an order via state field on the Order type:

Querying next order states

The next possible states can be queried via the nextOrderStates query:

Configuring the default order process

It is possible to customize the defaultOrderProcess to better match your business needs. For example, you might want to disable some of the constraints that are imposed by the default process, such as the requirement that a customer must have a shipping address before the Order can be completed.

This can be done by creating a custom version of the default process using the configureDefaultOrderProcess function, and then passing it to the OrderOptions.process config property.

Custom order processes

Sometimes you might need to extend things beyond what is provided by the default Order process to better match your business needs. This is done by defining one or more OrderProcess objects and passing them to the OrderOptions.process config property.

Adding a new state

Let's say your company can only sell to customers with a valid EU tax ID. We'll assume that you've already used a custom field to store that code on the Customer entity.

Now you want to add a step before the customer handles payment, where we can collect and verify the tax ID.

So we want to change the default process of:

to instead be:

Here's how we would define the new state:

This object means:

• the AddingItems state may only transition to the ValidatingCustomer state (mergeStrategy: 'replace' tells Vendure to discard any existing transition targets and replace with this one).
• the ValidatingCustomer may transition to the ArrangingPayment state (assuming the tax ID is valid) or back to the AddingItems state.

And then add this configuration to our main VendureConfig:

Note that we also include the defaultOrderProcess in the array, otherwise we will lose all the default states and transitions.

To add multiple new States you need to extend the generic type like this:

This way multiple custom states get defined.

Intercepting a state transition

Now we have defined our new ValidatingCustomer state, but there is as yet nothing to enforce that the tax ID is valid. To add this constraint, we'll use the onTransitionStart state transition hook.

This allows us to perform our custom logic and potentially prevent the transition from occurring. We will also assume that we have a provider named TaxIdService available which contains the logic to validate a tax ID.

Responding to a state transition

Once an order has successfully transitioned to a new state, the onTransitionEnd state transition hook is called. This can be used to perform some action upon successful state transition.

In this example, we have a referral service which creates a new referral for a customer when they complete an order. We want to create the referral only if the customer has a referral code associated with their account.

TypeScript typings for custom states

To make your custom states compatible with standard services you should declare your new states in the following way:

This technique uses advanced TypeScript features - declaration merging and ambient modules.