Headless Commerce for decoupled commerce presentation.

Only when the storefront genuinely needs something the platform's theme layer cannot deliver — unusual interaction, multi-channel delivery, or a frontend shared with an existing application. Headless adds preview, deployment, caching and API complexity, and it makes checkout the hardest part rather than the part you get free. Most stores are better served by a well-built theme.

Never assume the customer's browser returns from the payment provider. Treat the provider's webhook as the source of truth, verify its signature, make processing idempotent, and reconcile against provider state on a schedule. Orders should have a pending state that resolves either way rather than existing only once someone lands on a success page.

In one system, with every channel reading from it. Overselling almost always traces to two systems both believing they own stock. Reservation behaviour at checkout, oversell handling and a reconciliation pass for missed updates need deciding explicitly rather than emerging from whichever integration was built last.

From the attributes customers actually choose by, not from how the warehouse organises SKUs. Each purchasable combination needs its own identifier, price, stock and availability, with a stable grouping identifier tying them together. Retrofitting variant structure onto a catalogue built around single products is one of the more expensive commerce migrations.

Usually, provided it offers a documented API and webhooks. The questions worth asking early are whether it supports the payment methods your customers expect, how it handles refunds and partial captures, and whether hosted fields are available so card data never touches your server. Provider migration mid-project is expensive and worth deciding before build.

Costs appearing late, forced account creation, too many form fields, unclear delivery timing, missing payment options, and slow or broken behaviour on mobile. Each is measurable per step, so instrument the funnel before redesigning it — the actual drop-off point is usually more specific than the general impression of where it happens.

Through customer-group or account-level pricing rules rather than duplicate catalogues, with tax display, minimum quantities and payment terms varying by group. Most platforms support some of this natively and none support all of it, so the gap between what is needed and what is built in is the actual scope of the project.

Rarely. A direct coupling means every ERP change becomes a storefront outage risk. An integration layer with defined contracts, idempotent writes, retries and a reconciliation job isolates each side from the other's failures and makes it possible to see which records did not sync and replay just those.