B2C Commerce Cart and Checkout: The Lines You Don't Customize

Cart and checkout are the highest-revenue surfaces on a B2C Commerce site. They are also the riskiest to customize. The platform's base flows handle edge cases that custom code reliably gets wrong: race conditions on inventory, tax calculation timing, payment authorization retries, address validation across locales. Each year, teams override base flows to add a custom touch and discover 6 months later that they reintroduced a bug Salesforce fixed in 2017.

Sapota's Salesforce team has triaged checkout incidents on production sites. The pattern is consistent: customizations that survive are the ones built as additions to base flows, not replacements of them.

The base flow Salesforce ships

SFRA's reference checkout flow handles:

• Cart with line-level inventory checks.
• Shipping address entry with locale-aware validation.
• Shipping method selection with cost calculation.
• Billing address entry, often defaulting to shipping address.
• Payment method selection.
• Order review with final calculation.
• Payment authorization (with the configured payment service).
• Order placement with inventory commit.
• Confirmation page with order details.

Each step is a controller route. The controllers compose via the SFRA append/prepend pattern. The flow is opinionated but proven.

What to customize and what not to

Three principles separate safe customizations from risky ones.

1. Customize the UI freely. Templates, styling, layout, copy. These changes do not touch the underlying order or payment logic. Risk is low.

2. Add fields to the data flow but do not replace the calculation logic. A custom "delivery preference" field on Order is fine. A custom override of the order total calculation is not. The base calculation handles edge cases (split shipments, mixed currencies, tax-included pricing) that custom code rarely covers fully.

3. Append to controllers; do not replace them. SFRA's controllers expose extension points via server.append and server.prepend. Use these. A server.replace on CheckoutServices-PlaceOrder is a code review red flag requiring explicit justification.

The general rule: customize the surfaces (UI, custom fields, custom validations) but leave the engine (calculation, payment, inventory commit) to base.

Cart customizations that recur

Common custom additions to cart:

Estimated delivery date per line. Compute and display via a hook on cart calculation. Read shipping zone, lead time, fulfillment cutoff. Display on each line.

Cart-level promotions display. Show qualifying promotions for the current cart, even if not yet applied. Built as a model decorator that reads the active campaigns and matches against cart contents.

Save for later. Move items between cart and a saved-for-later list (often stored as a custom object on the customer). Add buttons to the cart template; add controllers for the move action.

Bundle awareness. When a bundle parent is in the cart, show child items as related. Use the product model's relationship data, not a separate query.

What to avoid in cart:

• Custom price calculation. The platform's pricing engine is more correct than handwritten alternatives. Trust it.
• Custom inventory math. Use ProductMgr.getProduct().availabilityModel for the source of truth.
• Custom promotion application. Use the promotion engine.

Checkout customizations that recur

Common custom additions to checkout:

Address autocomplete. Integration with Google Places or similar. Build as a client-side component plus a server-side service. The service validates the autocomplete result against the platform's address model.

Per-shipment shipping methods. A cart with multiple shipments where each can have a different shipping method. The platform supports this via shipment-level configuration. Custom UI exposes the choice to the customer.

Gift options. Gift wrap, gift message, gift receipt. Stored as custom attributes on Order or as line-item custom attributes. Charges added via a custom promotion or shipping cost.

Express checkout (Apple Pay, Google Pay). Use Salesforce LINK cartridges (plugin_apple_pay, plugin_google_pay) rather than custom integration. The plugins handle the platform interactions correctly.

What to avoid in checkout:

• Custom payment authorization logic. Use the platform's payment service framework with PSP integrations.
• Custom tax calculation. Integrate with Avalara, Vertex, or similar via the services framework.
• Custom inventory commit. The platform handles inventory commit on order placement with race condition protection. Custom code competing for the same inventory will lose.

Payment integration patterns

Payment is the highest-risk part of checkout. The pattern that works:

1. Use the platform's payment service framework. PSPs (Stripe, Adyen, Cybersource, PayPal) ship LINK cartridges that integrate via the framework. The cartridge handles authorization, capture, refund.

2. 3-step payment flow. Auth in checkout (immediate); capture at fulfillment (later); refund as needed (separately). Do not bundle them. Capture should trigger from OMS, not from the placeOrder controller, so partial fulfillment works.

3. PCI scope minimization. Card numbers never touch the SFCC servers. Use the PSP's hosted fields or tokenization SDK. The customer's card data goes directly to the PSP; SFCC stores only the token.

4. Idempotency on payment calls. Customer hits "Place Order" twice quickly; the platform should not authorize twice. Use the PSP's idempotency key, scoped to the order or attempt.

5. Refund flow tested. Most teams test the authorization path during implementation. Few test refunds until a real refund is needed. Test refund explicitly with a sandbox transaction.

Common cart/checkout mistakes

Five patterns Sapota has seen on engagements:

1. Replaced controller losing base improvements. A team replaced CheckoutServices-PlaceOrder to add custom analytics. 6 months later, Salesforce shipped a base improvement to handle a specific payment edge case. The replaced controller missed the improvement and produced a production incident. Use append.

2. Custom calculation drift. A team built custom order total calculation in Apex-like script in the cart controller. 2 years in, the total disagrees with the line-item sum by pennies on certain orders. Customer complaints. Revert to platform calculation.

3. Inventory race condition. A team built a custom "reserve inventory" call that fires when the customer reaches checkout. The reservation locks inventory. If the customer abandons, the lock leaks. Inventory shows as available in BM but is actually held. Use the platform's commit-at-place flow.

4. Tax calculation skipped on checkout. A team disables tax calculation on the basket recalculation to "speed up the cart." Final tax calculated only at place order. The customer sees one total in cart and a different total at place order. Complaint volume rises. Run tax calculation at every relevant cart step.

5. Express checkout misconfigured. Apple Pay button shows for guest customers but the integration assumes registered customers. Click produces an error. Configure the plugin correctly for guest checkout.

What good cart/checkout looks like

A B2C Commerce site with healthy cart and checkout:

• UI customizations layered on base templates.
• Custom fields added without replacing calculation logic.
• Payment integration via LINK cartridges through the services framework.
• Express checkout (Apple Pay, Google Pay) where supported.
• 3-step payment flow with capture from OMS.
• Refund flow tested end to end.
• Performance dashboard for checkout latency.

The temptation to customize cart and checkout is constant; the discipline is to limit the customization to surfaces that actually need it. Sapota's Salesforce team holds the line during code review on every B2C Commerce engagement, because cart and checkout customizations are where production incidents most often originate.

---

Building or refactoring cart and checkout on a B2C Commerce site? Sapota's Salesforce team, certified on B2C Commerce Developer (Comm-Dev-101), handles checkout architecture, payment integration, and post-launch optimization on production engagements. Get in touch ->

See our full platform services for the stack we cover.