Common failures

Common failures

Treating the catalogue as an internal product map. Teams mirror their engineering structure into the commerce hub and end up with dozens of SKUs nobody can quote against. It happens because the people configuring it think in features, not purchases. Avoid it by modelling products around the buying decision and keeping internal structure in metadata.

Skipping tax until a threshold forces it. Tax feels like a finance problem for later, so it gets postponed, and then a registration threshold makes correct collection mandatory overnight. Reconstructing liability from historical invoices is slow and error-prone. Configure an automated tax engine and per-product tax categories from day one, before the first sale.

Leaving dunning on defaults, or off entirely. Involuntary churn is invisible until you measure it, so the failed-payment flow stays on whatever the platform defaulted to. The fix is to enable smart retries, write a real recovery email, and decide deliberately what happens when retries run out, rather than accepting a silent hard cancel.

Two-way syncing a field two systems can both edit. A bidirectional sync on subscription status or amount produces a value that flaps, with each system overwriting the other. It happens because "sync everything both ways" sounds thorough. Avoid it by giving every field exactly one owner and one direction of flow.

Matching records on email instead of a stable identifier. Email-based matching breaks the moment a customer buys under a different address, splitting one customer into two records. Set a shared identifier at first purchase, store it on both systems, and match on it.

Declaring done at the green checkout. A successful checkout screen says the payment cleared, not that the invoice, tax, webhook, and CRM update all fired. People stop testing too early because the customer-facing path looked fine. Drive every downstream effect and every unhappy path on the real surface before going live.