A storefront that can accept a real payment, decrement inventory, send order email, and hand fulfillment a clean order record.
Commerce on Build Me Web connects a product catalog, checkout, tax and shipping rules, and order operations to your marketing site or a dedicated storefront theme. This quickstart gets you from an empty store to a verified test order. Plan extra time for catalog imports, tax nuance, and payment provider verification beyond the core steps.
Prerequisites: a workspace with Commerce enabled, a payment provider sandbox account (card processor first), and clarity on currency, selling regions, and whether you ship physical goods, digital goods, or both.
1. Create the store
Open Commerce New store. Link the store to an existing website or create a storefront theme. Linking keeps brand tokens, analytics, and domain configuration shared; a dedicated theme is better when the shop should feel like its own property.
Set currency, tax region defaults, and shipping zones before importing catalog data. Changing currency after orders exist creates reconciliation pain. If you sell in multiple currencies, enable that explicitly and define how prices are sourced (manual vs converted).
- Name the store and attach it to the correct website project.
- Choose the base currency and unit system (metric/imperial for shipping dimensions).
- Define at least one shipping zone with a rate, even if you only offer local pickup initially.
- Confirm tax calculation mode (inclusive vs exclusive display) matches how you advertise prices.
Store setup
├── Storefront theme / linked website
├── Currency & tax display
├── Shipping zones & rates
└── Notification emails (order, shipping, refund)
Configure notification sender domains early so order receipts do not land in spam on launch day. Authenticate the sending domain with SPF and DKIM as prompted.
2. Add products
Create at least one product with a title, description, price, SKU, inventory count, and images. Variants (size, color, material) share a parent product and carry unique SKUs, prices, and stock levels.
Write descriptions for shoppers, not for your internal SKU sheet. Lead with benefits, then specifications. Put the primary image first — it drives LCP on product detail pages and feeds social cards when products are shared.
Product
├── Title, description, media
├── Price & compare-at price
├── Inventory (tracked / unlimited)
├── Variants (optional option sets)
└── SEO fields (title, description, handle)
Use collections to group products for navigation and campaigns. Manual collections work for curated drops; automated collections work for rules such as tag equals sale. Avoid overlapping automation rules that constantly add and remove the same SKU.
If you are migrating from another platform, dry-run a CSV or API import on a preview store first. Validate variant matrices, image URLs, and inventory quantities before touching production.
- At least one purchasable SKU with stock > 0
- Product images compressed and dimensioned
- Handles/slugs are stable and human-readable
- Compare-at prices only used when a real reference price exists
3. Configure payments
Connect a payment provider in sandbox mode from Commerce Payments. Enable card checkout first; add wallets and local payment methods after the happy path works. Never paste live keys into preview environments.
Walk through 3-D Secure / SCA settings for regions where they apply. Decide whether you capture immediately or authorize-then-capture for made-to-order goods. Document the choice for support.
- Create sandbox credentials at the provider and store them in the environment vault.
- Map webhook endpoints for payment success, failure, and dispute events.
- Enable only the methods you will support at launch to reduce checkout complexity.
- Test decline and authentication-challenge flows, not only successful charges.
Build Me Web never asks you to paste full card numbers into support tickets. Use provider test cards and keep live keys rotated and scoped.
4. Place a test order
Complete a full purchase with provider test cards on the preview or sandbox storefront. Confirm each side effect:
- Order appears in Orders with the correct line items and totals.
- Inventory decrements for tracked SKUs.
- Customer receives the order confirmation email.
- Staff notification fires to the operations inbox.
- If configured, the
order.completedwebhook delivers and verifies.
Refund the test order and confirm restock behavior matches your policy. Partial refunds should leave remaining items fulfilled correctly.
Switch providers to live mode, verify tax and shipping rates against a real address in each zone, run one low-value real order end to end, and only then announce the store.
Operations notes
Assign who monitors new orders on day one. Connect fulfillment early — even a spreadsheet export workflow is better than discovering orders overnight with no owner. For high-demand launches, enable oversell protection so inventory reserves at checkout start.
Troubleshooting
Checkout total looks wrong: inspect tax inclusive settings, shipping zone match, and discount stacking order.
Webhooks missing: confirm HTTPS endpoint, signature verification, and that sandbox vs live destinations are not crossed.
Inventory not moving: ensure the SKU is tracked and that the purchase used that variant, not a leftover unlimited stub.
Best practices
Keep catalog taxonomy boring and consistent. Prefer fewer payment methods with higher completion rates. Rehearse the first marketing campaign against staging with production-like product counts. Treat refund and return copy on the storefront as part of checkout trust, not an afterthought legal page.
Prerequisites & preparation
Before changing production settings for commerce store launches, align the people who own content, DNS, analytics, and approvals. A fifteen-minute kickoff that names owners prevents multi-day Slack archaeology later. Capture decisions in the workspace notes so the next teammate inherits context instead of guesswork.
Gather credentials and access: workspace admin or editor role, DNS control when hostnames are involved, payment or API sandbox accounts when money paths are involved, and a shared checklist link. Confirm which environment you will rehearse in — preview first, production only after a green run.
Decide product types, day-one countries, fulfillment ownership, and return policy copy. Open a payment sandbox and match settlement currency to the store.
Detailed walkthrough
Work the happy path slowly the first time. Narrate what you expect to see after each click: a status badge, a DNS record, a webhook delivery, a Lighthouse metric. When reality diverges, stop and resolve the mismatch instead of clicking ahead — most outages begin as ignored yellow states.
- Create the store, set currency and tax display, and authenticate the notification sending domain.
- Add a representative product with real variant axes and optimized primary imagery.
- Configure shipping zones you will actually honor on week one.
- Connect sandbox card payments; complete success, decline, and refund test orders.
- Switch to live keys; place one low-value real order before announcing.
Worked example:
Order side effects
paid → inventory, email, webhook
refund → restock policy, email, webhook
Edge cases & failure modes
Plan for partial failure. Networks drop, registrars delay, providers rate-limit, and humans approve the wrong revision. Your runbook should say what “abort” looks like: leave preview up, roll back the release, or freeze campaigns until metrics recover.
- Sandbox and live keys crossed between environments.
- Tax inclusive labels disagreeing with checkout math.
- Webhooks delivered twice without idempotent handlers.
QA checklist before you announce
- Happy path verified on mobile and desktop
- Failure path messaging reviewed
- Owners named for the first hour after launch
- Rollback or freeze path documented
Operating the change
After launch, watch the metrics that prove the change worked — not vanity charts. Pair quantitative signals with one qualitative check (support ticket themes, sales feedback). Schedule a follow-up within a week to remove temporary flags, raise DNS TTLs, or archive the experiment.
Staff order monitoring on launch day and review decline rates after the first hundred attempts.
Treat commerce store launches as a repeatable playbook. The second time your team runs it should be faster because the checklist and owners already exist.
Catalog vocabulary must be boring and consistent. Size/Color/Material discipline keeps filters, analytics, and imports sane when the catalog grows past a handful of SKUs.
Trust copy beside the pay button — shipping timelines, returns, support — converts better than fake scarcity that contradicts inventory.
Stage international expansion one country at a time with correct tax and shipping. Wrong totals in a new market create refunds and chargebacks faster than they create revenue.
Instrument add-to-cart, checkout start, and purchase separately so you can see whether problems are merchandising, sticker shock, or payment failure.
Keep a staging catalog for campaign rehearsal. Production inventory is not a playground for untested CSV imports on Friday afternoon.
For limited drops, enable checkout reservation and load-test PDPs. Marketing heat plus thin stock without reservation is an oversell machine.
Connect fulfillment early — even a manual morning export — so orders never sit unnoticed. Automate after the manual path is reliable.
Document who can issue refunds and how restock interacts with returns. Support macros should match the buttons they click in admin.