Concepts

EmDash first

EmDash owns content modeling, auth boundaries for the admin, media storage, and how data lands in your database. DashCommerce adds a commerce domain on top: products, cart, checkout, orders, and the operations UI to manage them — exposed through the same EmDash admin surfaces you already use.

This layering matters. You are not installing a headless commerce backend plus a separate CMS. You are installing one CMS (EmDash) with one plugin (DashCommerce) that adds a commerce domain to the same data and admin surface. Content pages, blog posts, product descriptions, and order lookups all share one authentication model, one storage layer, one deploy.

Typed collections

Product definitions lean on EmDash's collection model — typed schemas validated at build and write time. The goal is to avoid "stringly typed" Woo-style meta fields for core commerce entities unless you truly need them for customization.

Plugins cannot register host content collections directly — you declare a products collection (and product taxonomies) in seed.json. Use the dashcommerce-merge-seed CLI or mergeDashCommerceSeed() from @dashcommerce/core so the JSON stays aligned with the plugin; then emdash seed applies it. See Getting started.

There are six product types in core: simple, variable (size × color etc.), grouped (bundles), external (affiliate links), subscription, and digital-download. They share a base schema and layer type-specific fields on top.

Edge-native storefront

Storefront routes and components are designed to run in edge-friendly deployments — Cloudflare Workers, Vercel Edge, Netlify Edge — consistent with EmDash's Astro-native story. The runtime entry avoids Node built-ins so it runs in Workers without polyfills. Heavy or privileged work stays on the server or in trusted worker contexts — not in the client bundle by default.

Practically, this means: product pages ship zero JavaScript by default, cart state hydrates only where needed, and checkout calls Stripe's Payment Element from a controlled island. Performance budgets are set by the framework, not renegotiated per feature.

Stripe primitives, directly

DashCommerce does not abstract Stripe behind a custom payment interface. Payment Intents are Payment Intents. Subscriptions are Stripe Subscriptions with all the lifecycle events Stripe supports. Connect means transfer_data and application_fee_amount on a PaymentIntent. This keeps the surface area small: if something works in Stripe, it works in DashCommerce; if Stripe changes a primitive, DashCommerce follows.

Every Stripe webhook is idempotent via unique-indexed Stripe event IDs. Replaying a webhook — which Stripe sometimes does at least-once — cannot double-process an order, double-charge a subscription, or double-issue a refund.

Money as integer minor units

All amounts are stored as integer cents (or equivalent minor units for other currencies). No floats, no currency-string mixing. Prices, taxes, shipping, discounts, and totals are all number values in minor units. Conversions for display happen at the render boundary with the product's currency.

"WooCommerce-shaped" — not Woo-compatible

Feature categories (shipping zones, coupons, subscriptions, marketplace payouts) are intentionally familiar if you've operated Woo stores, but there is no drop-in WordPress migration. Moving from Woo means rethinking content and catalog in EmDash terms — see Migrate from WooCommerce for the realistic scope.

Where DashCommerce isn't the right tool

DashCommerce does not offer a Merchant-of-Record service. If you sell digital goods to a global customer base and want VAT / sales tax handled for you, Lemon Squeezy or Paddle is the correct tool. DashCommerce also does not ship a point-of-sale, nor a polished merchant dashboard in the Shopify sense — if operational simplicity matters more than ownership and cost, see DashCommerce vs Shopify.