Cart
A Cart in Salesforce B2B and D2C Commerce is the WebCart object, an online shopping cart that holds a buyer's selected products, applied coupons, calculated taxes and shipping, and running totals before an order is placed.
Definition
A Cart in Salesforce B2B and D2C Commerce is the WebCart object, an online shopping cart that holds a buyer's selected products, applied coupons, calculated taxes and shipping, and running totals before an order is placed. Each line a shopper adds becomes a child CartItem record, and the WebCart tracks the grand total across products, charges, and tax. The Cart is the working draft of a purchase. When the buyer finishes checkout, the platform places an order from the Cart, and the WebCart status moves to Closed.
A WebCart is tied to a buyer Account and a WebStore, and it carries a Status field with values Active, Processing, Checkout, Closed, and Deleted. Every storefront interaction (add to cart, change quantity, apply a coupon) writes to the Cart and triggers a recalculation. Pricing, promotions, inventory, shipping, and tax all run against the Cart through the Cart Calculate API. Understanding the Cart means understanding how those calculators read the WebCart, write their results back, and hand a finished total to checkout.
How the WebCart works inside Salesforce Commerce
The WebCart data model
The WebCart object is the parent record for a shopping session. It stores the buyer Account through AccountId, the storefront through WebStoreId, the record owner through OwnerId, and the currency through CurrencyIsoCode. Money fields hold the running figures: TotalProductAmount for products, TotalChargeAmount for charges like shipping, TotalTaxAmount for tax, and GrandTotalAmount for the combined total the buyer will pay. The Status field carries the lifecycle position, with picklist values Active, Processing, Checkout, Closed, and Deleted. Child CartItem records represent each product or charge line, with quantity, unit price, and line totals. CartItem has a type of Product or Charge, so shipping and similar fees sit alongside merchandise in the same child table. Other related objects round out the model, including CartDeliveryGroup for shipping destinations, CartTax for tax detail, WebCartAdjustmentGroup for cart-level discounts, and CartValidationOutput for messages the buyer needs to see. Knowing which field holds which number matters, because reports, custom Apex, and integrations all read these columns directly rather than recomputing totals from line items.
The Cart status lifecycle
A WebCart begins in Active when a buyer adds the first item. It stays Active through additions, removals, and quantity changes while the shopper browses. When the buyer starts checkout, the cart moves to Checkout, and shipping and tax calculators that only run at checkout come into play. Processing is a transient state used while the platform works through a calculation or order placement. Once an order is successfully placed, the WebCart status becomes Closed, and that cart is finished. Deleted marks a cart removed from active use. These five values (Active, Processing, Checkout, Closed, Deleted) are the documented Status picklist, so build any custom logic against them rather than inventing extra states. A common point of confusion is the idea of an abandoned cart. Salesforce does not ship a separate Abandoned status on WebCart. An abandoned cart is simply an Active cart that has gone quiet, identified by its LastModifiedDate, and re-engagement campaigns query for those records rather than reading a dedicated flag. Treating Active plus age as the signal keeps your reporting aligned with the real schema.
The Cart Calculate API and orchestrators
The Cart Calculate API (often shortened to CCA) is how Salesforce Commerce runs the math on a cart. It is organized in three layers. Orchestrators decide which calculators run and in what order. Calculators perform a single job, such as pricing or tax. Services hold the underlying logic that a calculator calls, and some services are extensible while others are not. The default orchestrator invokes calculators in a set sequence: pricing first, then promotions, then inventory for cart and checkout, followed by shipping, post-shipping, and taxes at checkout. The platform watches buyer actions through a BuyerActions object and runs only the calculators that the change requires, so adding a coupon does not need to rerun shipping. You extend behavior by writing a class that extends CartExtension.CartCalculate and registering it at the Commerce_Domain_Cart_Calculate extension point. A custom orchestrator can reorder calculators or skip ones you do not need. This design keeps cart math predictable, because every recalculation follows the same defined path instead of ad hoc triggers firing in an unknown order.
Pricing, promotions, and the calculator sequence
Order of operations is the part teams get wrong most often. Pricing runs first and sets each line price from the price book and any negotiated buyer pricing. Promotions run next and apply discounts on top of those prices, either to the whole cart through a WebCartAdjustmentGroup or to specific lines through a CartItemPriceAdjustment. Because promotions read the priced cart, running tax before promotions would tax a discount the buyer never actually pays, which inflates the total. The documented sequence avoids that by keeping tax at checkout, after promotions have settled. Pricing is extensible through the Commerce_Domain_Pricing_Service base class, so an org with complex contract pricing can plug in its own logic. Promotions in the standard flow are not service-extensible in the same way, so model your offers within the promotion setup rather than trying to rewrite the calculator. Test stacking deliberately. Two promotions that are each valid can combine in ways you did not intend, and the only reliable way to know the result is to add the qualifying items and read the adjusted total before launch.
Tax, shipping, and external services
Tax and shipping enter the picture at checkout, once the cart has a delivery destination. Shipping calculation works out delivery cost for each CartDeliveryGroup, and a post-shipping step can select the least expensive delivery method when that is the configured behavior. Tax calculation usually hands off to an external provider. The Taxes calculator is extensible through the Commerce_Domain_Tax_Service base class, which is the supported way to integrate a tax engine such as a third-party calculation service. Results flow back into CartTax detail records and into the WebCart TotalTaxAmount field, and the GrandTotalAmount updates to reflect products, charges, and tax together. Keeping these calculations at checkout rather than on every add-to-cart action serves two purposes. It avoids hammering an external tax service with a call on every quantity tweak, and it matches the moment when a real shipping address exists to calculate against. When you integrate a tax or shipping service, handle timeouts and failures gracefully, because a slow external call at checkout is felt directly by the buyer who is waiting to pay.
From Cart to Order at checkout
Checkout is where the working draft becomes a real commitment. After the buyer confirms shipping, reviews totals, and pays, the platform places an order from the cart. The WebCart contents map onto order records: the cart header informs the Order, each CartItem becomes an order line, and the CartDeliveryGroup information carries into the order delivery structure. The applied promotions and calculated totals carry over so the order reflects exactly what the buyer agreed to pay. Once the order is placed successfully, the WebCart status moves to Closed and that cart is done. From this point the Order, and in many setups the Order Summary used by Order Management, becomes the operational record for fulfillment, invoicing, returns, and service. A useful mental model is that the Cart is short-lived and editable while the Order is durable and authoritative. Anything that must survive for accounting or fulfillment belongs on the Order, not the Cart. If a placement fails partway, the cart does not silently close, which is why checkout error handling and idempotent order creation matter for a storefront that buyers trust.
Working with carts in Apex
Salesforce also exposes the cart to code. The Apex Cart object represents an in-memory WebCart record together with its related records, which is what a custom calculator or extension reads and updates during a calculation. Rather than running separate SOQL queries and DML for every related list, the Cart class gives a calculator a consistent in-memory view of the cart header, its CartItem records, delivery groups, and adjustments. When you build a custom calculator or orchestrator, you work against this object, set prices or discounts on the in-memory items, and the framework persists the results. This is important for governor limits and correctness. Doing pricing math by hand with loops of queries inside a trigger invites limit errors and race conditions, while the Cart Calculate framework batches the work and runs it at the right point in the sequence. For most storefront customization, the supported path is to extend the calculator framework, not to write triggers on WebCart or CartItem. Reserve direct DML on cart objects for data fixes and integrations, and let the calculation framework own the live shopping math.
How to configure cart calculation in B2B and D2C Commerce
The Cart itself is created automatically when a buyer shops, so there is no manual Cart record to add. What an admin or developer configures is the cart calculation behavior through the Cart Calculate API. These steps describe enabling and customizing that calculation for a B2B or D2C store.
- Confirm Cart Calculate API is active
For newer webstores the Cart Calculate API is enabled by default. In Commerce setup for your store, verify that cart calculation is using the CCA framework so that pricing, promotions, inventory, shipping, and tax run through orchestrators and calculators.
- Set up pricing and promotions
Associate the right price book with the store so the pricing calculator has list and negotiated prices to read. Build your discounts in the promotion setup so the promotions calculator can apply cart-level and line-level adjustments in the correct sequence.
- Integrate tax and shipping services
If you use an external tax engine, extend the Commerce_Domain_Tax_Service base class to call it from the Taxes calculator. Configure shipping so the shipping and post-shipping steps can calculate delivery cost per CartDeliveryGroup at checkout.
- Add a custom orchestrator only if needed
When the default calculator order does not fit, write a class that extends CartExtension.CartCalculate and register it at the Commerce_Domain_Cart_Calculate extension point. Use it to reorder or skip calculators, then test the resulting totals end to end before going live.
Runs first and sets line prices; extensible through Commerce_Domain_Pricing_Service for custom contract pricing.
Applies cart-level and line-level discounts after pricing; model offers in promotion setup.
Checks availability for cart and checkout; extensible through Commerce_Domain_Inventory_Service.
Runs at checkout and is extensible through Commerce_Domain_Tax_Service to integrate an external tax provider.
- Running tax before promotions taxes a discount the buyer never pays and inflates the grand total.
- There is no Abandoned status on WebCart; an abandoned cart is an Active cart identified by its last-modified age.
- Prefer extending the calculator framework over writing triggers on WebCart or CartItem, which fights the calculation sequence.
- A slow external tax or shipping call at checkout is felt directly by the waiting buyer, so handle timeouts gracefully.
Prefer this walkthrough as its own page? How to Cart in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Cart.
Hands-on resources to go deeper on Cart.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Discussion
Loading discussion…