Salesforce Commerce Cloud, engineered end to end.

Why Commerce Cloud matters — and when you need it

Storefronts get the attention, but commerce programmes are won or lost downstream. The visible site is perhaps a third of the work; the rest is checkout correctness under real payment flows, order handoff that never drops or duplicates an order, price and inventory sync that holds up at peak, and an operational model your team can actually run. That is why we treat Commerce Cloud as a systems-engineering problem, not a web project — the same discipline we apply across our Salesforce engineering services.

What the platform buys you depends on which side you are on. B2C Commerce gives merchandising teams a consumer-grade platform built for seasonal peaks, multi-site and multi-locale selling. B2B Commerce gives business buyers a self-service channel that sits directly beside your CRM data, so contract pricing, entitlements and service history live in one place. Neither is a light purchase: if you have a small catalogue, modest traffic and no merchandising team, a simpler commerce stack may cost less to buy and run. Commerce Cloud earns its licence when volume, catalogue complexity or CRM adjacency genuinely matter.

You are probably in Commerce Cloud territory when:

• You are replatforming a consumer storefront that cannot handle peak traffic, multi-brand or multi-locale expansion.
• You are digitising a B2B sales channel — contract pricing, buyer accounts, quick reorder — that reps currently key in by hand.
• You want commerce unified with service, so agents see orders, returns and payments in the console they already use.
• Order and payment data is scattered across the storefront, the payment provider, the ERP and spreadsheets, and reconciliation eats days.
• You face a storefront rebuild decision — composable front end versus templates — and need the trade-off assessed honestly before committing budget.

How Clouderia delivers Commerce Cloud

Clouderia is a boutique Salesforce engineering consultancy — senior engineers building on the platform since 2010, 46 certified Salesforce experts, offices in Provo and Prague. On a commerce build that matters more than usual: the architects who choose between B2C and B2B Commerce, or between SFRA and a composable storefront, are the same people who write and review the code. We work this way across telco, financial services, insurance, automotive, SaaS and nonprofit organisations, where commerce rarely stands alone — it plugs into order management, billing and core systems that already exist.

A typical engagement runs in five phases:

• Discovery and architecture. Product selection (B2C, B2B or D2C), storefront approach, an integration map, and a written decision on the system of record for orders, prices, inventory and customers.
• Storefront build. SFRA or PWA Kit on B2C Commerce; LWR templates or a headless front end on the core platform. Reviewed code, automated tests, no unreviewed cartridge sprawl — the standards from our code review guide apply here too.
• Checkout and payments. Payment provider integration, 3-D Secure and SCA flows, refunds and partial captures, and — where reconciliation matters — our TransactionHub product wired into checkout.
• Order flow and integration. OMS, ERP, billing, tax, shipping and search integrations built with idempotent handoffs, replay and monitoring, not fire-and-forget exports.
• Launch and run. Peak load testing, hypercare, runbooks, and optional managed services so the platform keeps improving after go-live.

Every phase ships with architecture decision records, test coverage and monitoring for the integrations — because the failure mode of commerce systems is silent: an order export that quietly stops is worse than one that visibly crashes.

B2C vs B2B Commerce: two different products

The single most common misunderstanding about Commerce Cloud is that it is one platform with two editions. It is not. The name covers two products with different codebases, different infrastructures and different skills.

D2C Commerce sits alongside B2B on the core platform, bringing consumer selling into the org for brands whose volumes fit there. Choosing between the platforms comes down to traffic profile, merchandising depth, catalogue complexity, how close the store must sit to CRM data — and, honestly, which skills your team already has. We have talked clients out of B2C Commerce when B2B or D2C on core did the job with half the operational surface.

Composable vs template storefronts

On B2C Commerce you choose between the Storefront Reference Architecture (SFRA) — a server-rendered cartridge stack — and the composable storefront: a React application built with the PWA Kit, deployed on Salesforce's Managed Runtime, talking to the platform through SCAPI. The equivalent choice exists in miniature on the core platform: LWR storefront templates versus a fully headless front end calling the Commerce APIs — a pattern we cover more broadly in our headless Salesforce article.

The trade-off is real and worth stating plainly:

• Templates (SFRA, LWR) are faster to launch and carry a mature ecosystem — on SFRA, LINK cartridges cover most payment providers, tax engines and search vendors. The cost is coupling: your front end moves at the platform's pace, and heavily customised cartridge stacks accumulate upgrade debt.
• Composable (PWA Kit, headless) gives you front-end freedom, modern developer experience, edge caching and independent deploys. The cost is ownership: integrations that were cartridges become API projects, some platform features need re-implementation, and you need a genuine front-end engineering practice for the life of the store, not just the build.

Our default advice: templates when time-to-market dominates and your requirements fit standard patterns; composable when front-end differentiation is a business requirement, when several touchpoints share one commerce backend, or when a strong React team already exists. Migrating from SFRA to composable later is feasible — SCAPI makes it a front-end rewrite, not a replatform — so starting pragmatic is rarely a trap.

Checkout and payment integration

Checkout is where commerce projects get hard. Payment methods multiply by market; 3-D Secure and SCA turn a synchronous authorisation into a redirect dance; webhooks arrive out of order; refunds, partial captures and gift cards each add states to the order lifecycle. On B2C Commerce, payment provider integration is usually cartridge-based in SFRA builds and API-level in composable ones. On the core platform, B2B and D2C checkouts integrate providers through payment gateway adapters in the platform's payments framework. In every variant, tokenisation keeps card data with the provider and most of the PCI scope out of Salesforce.

This is where our product work meets our consulting work. TransactionHub, our installable Salesforce accelerator, connects the payment gateways your customers actually use — Stripe, Adyen, ComGate and Unzer, including inside Salesforce Commerce Cloud checkout — and pulls bank transactions via PSD2 open-banking APIs. Gateway payments and bank feeds are then matched to orders and invoices in Salesforce automatically, so reconciliation that used to take days closes itself. If Stripe is your provider, our engineering walkthrough of Salesforce–Stripe payment integration covers the webhook, idempotency and dispute-handling patterns we build to.

Order flow into OMS and billing

Order capture is the beginning of the order's life, not the end. On B2C Commerce, orders must leave the storefront platform — via the Commerce APIs or export jobs — and land in an order management system. Salesforce Order Management, which runs on the core platform, is the natural destination: it ingests B2C Commerce orders, creates order summaries and fulfilment orders, orchestrates allocation, shipping, invoicing, returns and exchanges, and puts the whole lifecycle in front of service agents in the console. On B2B Commerce the first hop is free, because orders are born as native records in the org.

From the OMS, orders flow onward into billing and ERP — invoices, credit notes, payment application, revenue recognition — whether that is Salesforce billing within Revenue Cloud or an external financial system. The design decisions that matter here are unglamorous and decisive: which system is the system of record for the order at each stage; how storefront, OMS and ERP status models map onto each other; how the handoff stays idempotent when a retry fires twice; and how a stuck order surfaces to a human. We wrote up the full pattern in our order-to-cash on Salesforce guide, and the orchestration discipline in our telco order orchestration article applies to commerce almost unchanged.

Architecture and integration notes

Patterns we hold to on Commerce Cloud programmes, drawn from the same playbook as our Salesforce integration practice:

• Never call the ERP synchronously from checkout. Checkout latency is conversion; anything slow or fragile — tax fallbacks aside — belongs in asynchronous post-order processing with retries.
• Idempotent order export. Every order handoff carries an idempotency key; the receiving system deduplicates. Dropped orders and duplicated orders are both revenue incidents.
• Right-size the sync cadence. Inventory availability wants near-real-time; catalogue and price data usually tolerates scheduled sync. Pushing everything through one real-time pipe is expensive and brittle.
• Design customer identity early. B2C Commerce profiles, core-platform contacts or person accounts, and OMS records need a deliberate matching strategy — Data Cloud can carry unified profiles, but only over a mapping you have actually designed.
• Respect both limit models. B2C Commerce enforces API quotas and object-size limits on its side; checkout logic on the core platform runs inside governor limits. Both change over time — check current Salesforce documentation before committing volumes to a design.
• Events over polling for downstream sync. Platform Events and Change Data Capture keep OMS, billing and analytics current without hammering APIs; an iPaaS is a choice for many-system landscapes, not a prerequisite.
• Prove peak before peak proves you. Cache strategy (page and CDN caching on SFRA, edge caching on composable) and load tests against realistic baskets belong in the plan, not the post-mortem.

Frequently asked questions

What is the difference between Salesforce B2C Commerce and B2B Commerce?

They are separate products. B2C Commerce runs consumer storefronts on its own multi-tenant infrastructure, with merchandising, search, promotions and a cartridge-based or headless storefront. B2B Commerce runs on the core Salesforce platform, sharing the org with Sales and Service Cloud, and adds buyer accounts, contract pricing, large carts and reorder workflows. The right choice depends on traffic profile, merchandising depth and how close the store needs to sit to CRM data.

Does Commerce Cloud include order management and billing?

No. Commerce Cloud handles the sale up to order capture. Orchestration, fulfilment, invoicing and returns are handled by Salesforce Order Management, an external OMS, or an ERP. Billing — invoices, credit notes, revenue recognition — lives in Salesforce billing products or your ERP. Designing that handoff cleanly, with a clear system of record and an idempotent order export, is where most commerce programmes succeed or fail.

Should we build a composable storefront or start from templates?

Start from templates when time-to-market matters and your requirements fit standard storefront patterns — SFRA on B2C Commerce, LWR templates on the core platform. Go composable when front-end differentiation is a genuine business requirement, you serve multiple touchpoints from one commerce backend, or you already run a strong React practice. Composable shifts effort from platform configuration to code you own, so it needs a team that can carry that long term.

How do payments work in Commerce Cloud checkout?

The storefront collects payment through a payment service provider — on B2C Commerce usually via a PSP cartridge or an API integration in composable builds, on the core platform via a payment gateway adapter. Our TransactionHub product connects Stripe, Adyen, ComGate and Unzer inside Commerce Cloud checkout, then matches gateway payments and PSD2 bank feeds to records in Salesforce so reconciliation closes automatically. Tokenised payments keep most of the PCI scope with the PSP.

Can Commerce Cloud share data with Sales and Service Cloud?

B2B Commerce and D2C Commerce run on the core platform, so accounts, orders and cases already live in the same org. B2C Commerce runs on separate infrastructure, so customer profiles and orders reach CRM through integration — commonly via Salesforce Order Management, the Commerce APIs, or Data Cloud for unified profiles. Plan identity mapping early: matching storefront customers to CRM records is harder to retrofit than to design in.

Do we need MuleSoft to integrate Commerce Cloud?

Not necessarily. For a handful of endpoints, direct integrations using the Commerce APIs, webhooks and Platform Events are simpler to build and run. An iPaaS like MuleSoft earns its cost when you have many systems, shared canonical models, or an integration team that standardises on it. We recommend the lightest architecture that meets your reliability and monitoring requirements.

What drives the cost of a Commerce Cloud implementation?

The main drivers are which product you licence (B2C, B2B or D2C), storefront approach (template versus composable), catalogue and pricing complexity, the number of payment methods and markets, how many systems the store must integrate with — OMS, ERP, tax, shipping, search — and data migration from the platform you are leaving. We scope fixed phases with senior engineers rather than quoting a single headline figure, because these variables dominate the total.