The Shopping Cart service layer

Current version: 8.2

The Commerce Connect core framework contains a number of abstract service layers. The Shopping Cart service layer is one of the most important service layers.

This topic describes:

Operations in the Shopping Cart service layer API

The following table describes the operations contained in the Shopping Cart service layer.

Type of operation


Create, Read, Update, Delete (CRUD), and merge operations on a cart


DeleteCart* – not necessary to call if the cart turns into an order


SaveCart – typically not necessary to call explicitly as it is done indirectly by calling UpdateCart or updating cart lines


GetCarts – supports multiple carts per customer


CRUD operations on cart lines




CRUD operations on associated parties, for example, address and contact information




Add and remove operations on associated shipping information



Add and remove operations on associated payment information



Locking and unlocking cart




All operations marked with an asterisk (*) trigger a unique page event that allows the contact interaction to be carefully tracked, making it possible to report and act on these operations. Most of the events include information about the cart ID and the added products. The page events are installed when you install Commerce Connect.

User-case scenarios

The following illustrates basic shopping cart user-case scenarios:

Typical storefront usage of the shopping cart API is as follows:

  • When the contact first arrives at the webshop, the CreateOrResumeCart method is called to retrieve the cart and to show the cart content and total in a mini-cart.

  • If the contact has previously registered a profile and left a cart from previous visits, then the MergeCart method is called when the contact logs in.

  • As the contact starts to add products to the shopping cart, the AddCartLines method is called.

  • During the checkout process:

    • Shipping and billing addresses are added using the AddParties method.

    • Shipping information specifying method and referring to lines and parties is added using the AddShippingInfo method.

    • Payment information specifying method and referring to lines is added using the AddPaymentInfo method.

  • While processing the payment information and reserving money on credit cards, the cart is locked using the LockCart method.

For more detailed information, see the Commerce Connect Developer's Guide.

Cart-based rendering rule conditions

Commerce Connect includes three rendering rule conditions that can be used to personalize the contact experience based on the products in the cart, the cart total, and the quantity of products. The cart data is read live from the external commerce system, not from the marketing platform. The conditions can be combined in a rule in a number of different ways. For example:

  • Contains product: If [shopping cart contains product A] then …

  • Cart total: If [shopping cart total is > Y] then …

  • Item quantity: If [shopping cart total quantity of items > N] then …

  • A combination of the above: If [shopping cart contains more than N quantity of product A and cart total > Y] then …

The abandoned cart engagement plan

Commerce Connect contains a default Abandoned Cart engagement plan, which lets you track, act, and follow up on shopping carts to determine if they are abandoned.

When a new contact arrives or a new cart is created, the contact is added to the Abandoned Cart engagement plan.

By default, the plan works as follows:

  • After a default one-day period, the system checks whether there is a cart for the contact, whether this cart is empty, and whether an e-mail address is known for the contact.

  • If the cart is empty, the contact is moved to the end state Users With Empty Carts. If the cart is not empty but an e-mail address is not known, the contact is moved to the end state Anonymous Users With Abandoned Carts. In either of these cases, nothing further happens.

  • If the cart is not empty and the e-mail address is known, an e-mail message is sent to the contact reminding them that they have abandoned their cart. The intention is to get the contact to return and place an order.

  • After a default two-day period, the system checks whether there is still a cart for the contact and whether it is empty. If the cart is empty, the contact is moved to the end state Users With Empty Carts, otherwise it is moved to the end state Users With Abandoned Carts.

In Commerce Connect, you can use the Abandoned Cart engagement plan as a repository for shopping carts. You can also store custom data together with the state in the engagement plans. You can use this feature to serialize shopping carts and store the data in the plan. Storing carts in the plan has the following functions:

  • The carts are immediately available in Sitecore when the contact is recognized by Sitecore XP.

  • If the session is lost, the carts are resumed when the contact returns, assuming that the contact is recognized by Sitecore XP or that they log in with an account.

The cart data is directly available for the conditional rendering rules, without having to query the external commerce system, which improves performance.

The engagement automation state can be the only repository so that carts are handled solely in Commerce Connect if this is the preferred integration approach.

In case of shopping carts being purged in the external commerce system at regular intervals by cleanup routines, the engagement automation repository can act as backup storage. Some of the shopping cart information from the default Commerce Connect domain model might not be covered in the external commerce system and part of the information can be persisted, retrieved, and merged when working with the cart data. This is the case in the integration with nopCommerce, as illustrated in the StarterKit sample site.

Do you have some feedback for us?

If you have suggestions for improving this article,