Checkout

Current version: 9.3

In the Experience Commerce (XC) data flow and processes for checkout, the customer enters shipping details on the checkout page and proceeds to enter payment details on the billing and payment details page. Then the customer completes the check out by confirming the order on the order confirmation page, and if a merchandiser does not place the order on hold, it is automatically processed.

These steps involve the Content Delivery (CD) role, the Web database, the Shops role, the Shared Environments (SE) database, a third-party payment provider, the Orders Scope (OS) index, and the Minions role.

The customer enters the shipping details

The customer goes to the shipping page with one or more items in the cart, and the CD role uses the Web index to retrieve the SXA Storefront shipping layout and content from the Web database. The CD role also requests the Shops role to retrieve all relevant shipping methods from the SE database.

The customer chooses a shipping method and enters the required shipping details, which the CD role requests the Shops role to store in the customer cart in the SE database.

The customer enters the shipping details using the CD role, the Web database, the Shops role, and the SE database.

The customer enters billing and payment details

SXA Storefront logic leads the customer to the billing and payment details page, and the CD role retrieves the SXA Storefront billing and payment details layout and content from the Web database.

The customer enters a billing address, which the CD role requests the Shops role to store in the customer cart in the SE database.

The customer enters an email address and the required payment details, which the CD role validates against a third-party payment provider such as Braintree, who returns a payment token. The CD role then requests the Shops role to store the payment token in the customer cart in the SE database.

The customer enters billing and payment details using the CD role, the Web database, the Shops role, the SE database, and a third-party payment provider.

The customer confirms the order and completes the check out

SXA Storefront logic leads the customer to the order confirmation page, and the CD role retrieves the SXA Storefront confirmation layout and content from the Web database. The CD role also requests the Shops role to retrieve the order details from the customer cart in the SE database.

The customer confirms the order and completes the check out, which triggers the CD role to confirm the payment with the third-party payment provider. The CD role then requests the Shops role to start processing the order.

The Shops role converts the cart into an order with a pending status, reduces the sellable item inventory by the purchased quantity, and stores the cart, the order, and the inventory update in the SE database together with an indexing entity for updating the Orders Scope index. Then the Shops role adds the order to the pending orders list in the SE database.

The customer confirms the order and completes the checkout using the CD role, the Web database, a third-party payment provider, the Shops role, and the SE database.

The Minions role updates the OS index

When the check out is completed, the Minions role reads the indexing entity from the SE database and updates the OS index with the new order data to make it searchable and retrievable.

The Minions role updates the OS index using the SE database.

The Minions role processes the order

After a configurable waiting period that lets a merchandiser evaluate and possibly place the order on hold, the Minions role picks up the pending order from the SE database, finalizes the payment with the third-party payment provider, and changes the order state to released. After another configurable waiting period, the Minions role picks up the released order from the SE database and changes its state to complete.

This is a natural extension point for specific business logic, for example, pushing the order out to an ERP system, or updating stock levels in an external system.

The Minions role processes the order using a third-party payment provider and the SE database.

Scaling the checkout scenario

Sites with a large amount of orders place a heavy load on the following roles and database, which we recommend that you scale as necessary:

Privacy and security

Refer to the Architecture and Roles documentation for privacy and security considerations for each role on the processing and aggregation data flow.

Do you have some feedback for us?

If you have suggestions for improving this article,