Grow online without outgrowing your storefront.

PCI DSS applies to any business that stores, processes, or transmits cardholder data, and scope covers every system that touches that data or could affect its security. Which self-assessment questionnaire you complete depends on how the payment page is built: a fully hosted or iframe payment form carries far fewer requirements than a page your own code controls, and PCI DSS v4.0 added requirements for managing and monitoring the scripts that run on payment pages. A well-built checkout tokenizes card data at the payment provider so it never reaches your servers, and keeps an inventory of every script allowed on the payment page.

Headless separates the storefront from the commerce engine: the front end is a custom application that talks to the catalog, cart, checkout, and order APIs of a platform such as Shopify or a custom backend. It makes sense when the template limits the experience, when the same catalog feeds several front ends or kiosks, or when page speed is a problem the theme cannot solve. The trade-off is that you now own features the platform gave you for free, such as SEO plumbing and checkout, so a well-built headless store budgets for them and keeps the platform checkout where it can.

Products, prices, and stock usually flow from the ERP to the store, orders and customers flow from the store to the ERP, and fulfillment status flows back. It breaks on identifier mapping between systems, units of measure and variants, partial shipments, refunds and exchanges, tax rounding, and timing gaps where a sale posts before stock does. A well-built integration keeps a mapping table per entity, processes events idempotently, and runs reconciliation jobs that list every order or SKU the two systems disagree on.

Each marketplace has its own listing feed with category-specific attributes, its own inventory and price sync, order import, fulfillment options, returns policy, and fee structure, and each enforces API rate limits and suppresses listings that fail its rules. Stock sold on a marketplace has to come off the web store within minutes or you oversell. A well-built platform abstracts channels behind one inventory position with per-channel buffers and treats a suppressed listing as an alert, not a surprise at month-end.

Buy online, pick up in store and ship-from-store both depend on store-level inventory being accurate, which means the POS, receiving, transfers, and shrink all post in near real time, with safety stock per location so a single unit is not promised online while it sits in a fitting room. Routing rules then choose the fulfilling store by proximity, stock, and labour, and store staff need a tool to pick, stage, and hand off the order. A well-built system reconciles POS and web inventory continuously and shows customers availability per location rather than a single aggregate number.

Privacy law applies to every account and order: PIPEDA federally and Quebec Law 25 in Canada, which includes rules on consent for tracking technologies that identify or profile a visitor, and state laws such as the California Consumer Privacy Act in the United States. Email and SMS marketing fall under CASL in Canada and CAN-SPAM and TCPA in the United States, and storefront accessibility is governed by rules such as the AODA in Ontario and ADA litigation in the United States, with WCAG as the usual benchmark. Confirm the exact obligations with counsel; a well-built store runs consent-aware tags, server-side events, and an accessible front end so marketing and legal are not at odds.

Flooring sold by square foot but shipped by box, cable sold by the metre, and products assembled from compatible components all break a catalog built around simple variants. The model has to hold a base unit for inventory, conversion rules for how the product is priced and packed, compatibility constraints for configurators, and shipping weight derived from the actual packaged quantity. A well-built catalog gets this right before the storefront is designed, because pricing, stock, the ERP sync, and the carrier quote all depend on the same conversions.

A product information management system is the single source for product attributes, media, translations, and channel-specific content, feeding the web store, marketplaces, print, and the POS. It earns its place when there are many SKUs, several languages, or several channels with different attribute requirements, and it is overhead when a single store on one platform could hold the same data. A well-built stack decides which system owns each attribute so the ERP, the PIM, and the storefront never fight over the description.

In Canada, GST or HST applies federally and PST or QST applies in several provinces, generally based on where the goods are delivered, with registration obligations by province. In the United States, most states require remote sellers above an economic nexus threshold to collect state and local tax, product taxability varies, and marketplaces often collect on your behalf under marketplace facilitator laws. A well-built checkout calculates tax through a tax engine with address validation and keeps the records your accountant needs for filing; confirm registration obligations with a tax professional.

Core Web Vitals measure loading, interactivity, and visual stability as real users experience them, and Google uses them as a ranking signal while shoppers simply abandon slow pages. The usual culprits on commerce sites are third-party scripts from marketing and review apps, unoptimized product images, and render-blocking theme code. A well-built storefront measures field data per template, loads third-party scripts after the product is interactive, and treats a performance regression as a bug.

Beyond products, customers, and order history, a migration has to map every old URL to a redirect, preserve category and product content that ranks, carry over gift cards and store credit, and move subscriptions and saved payment methods, which requires the old and new payment providers to cooperate on token migration. Tracking, email flows, and integrations all need re-verification, and the cutover should avoid your peak season. A well-planned launch rehearses the migration on a copy, compares order counts and revenue before and after, and keeps rollback possible for the first days.

A returns flow issues an authorization tied to the original order, decides refund to the original tender, exchange, or store credit, and handles restocking so inventory is correct again. Fraud screening combines address and card verification, 3-D Secure where it is required or useful, and risk scoring from the payment provider, balanced against the false declines that turn good customers away. A well-built system keeps the evidence for chargeback disputes and lets operations tune the rules without a developer.