Commerce Engine is what runs quietly underneath everything else — your dashboard shows clear, simple tasks like Marketing, Payments, and Shipping, never a generic "Engine" screen. Behind those screens, every part of the system (products, orders, marketing, payments, shipping, sales channels) keeps its own data straight and reacts to the same shared record of what happened, so nothing gets out of sync.
You experience Commerce Engine as things simply matching up: the stock number on your storefront matches what a marketplace sale just used, the sale Meta reports matches the order Google Analytics reports, and your catalog sync doesn't quietly drift out of date.
Every integration — a marketing pixel, a catalog feed, a sales-channel connection — reads from the same shared, reliable record of what happened, instead of every integration having its own slightly different version of the truth.
The common failure mode elsewhere: a tracking pixel fires directly from checkout code, a second integration duplicates similar logic slightly differently, and nobody can say with confidence whether a reported sale actually happened. Prebit's answer is that a marketing connection only ever gets handed an event that's already confirmed — it can never decide on its own that a sale occurred.
The moment an order is marked paid, everything that needs to happen next is recorded in that same step — reliably, every time, with a safety-net check that catches the rare edge case where something would otherwise slip through.
A T-shirt that comes in three sizes is tracked as three separate sellable items internally, each with its own permanent ID that never changes even if the product is renamed. That's what keeps stock counts, feeds, and reports accurate down to the exact size or color a customer actually bought.
Every important event — a paid order, a refund, a catalog change — is written down once, in one consistent format, before anything downstream reacts to it. Every part of the system reads from that same record instead of guessing.
Merchant impact: A paid order reliably produces exactly the downstream effects it's supposed to — no silent drops, no accidental duplicates.
Developer impact: `DomainEventEnvelopeV1` (`eventId`, `eventName`, `schemaVersion`, `occurredAt`, `storeId`, `aggregate`, `source`, `payloadRef`) is the one provider-neutral description of "what happened." `eventId` for `commerce.order.paid.v1` is deterministic (the order's own `_id`), not a fresh random UUID, so the live path and the repair path can never disagree about identity.
Example: `commerce.order.paid.v1`, `commerce.refund.created.v1`, `catalog.product.updated.v1`, and `inventory.updated.v1` are all recorded in the vocabulary today, even though Marketing Hub v1 currently only subscribes to order-paid — recording the vocabulary now avoids a later rename/migration.
If Meta or Google is temporarily unreachable when a sale happens, that delivery isn't lost — it's queued and retried automatically until it succeeds.
Merchant impact: A temporary provider outage doesn't mean a lost conversion — delivery retries automatically until it succeeds, or is flagged for a closer look.
Developer impact: `OutboxDelivery` rows (`kind`, `subscriber`, `dedupeKey`, `status`, `attempts`, `nextAttemptAt`, `leaseUntil`, `lastError`) are dispatched by a worker that claims a lease before delivery, so two concurrently running dispatch cycles can never send the same due row twice. The unique delivery index (`{kind, subscriber, dedupeKey}`) guarantees Meta and GA4 each receive an event exactly once.
Example: The outbox processing cron runs every 5 minutes; a 48-hour bounded repair cron separately catches the rare case where an order is marked paid but its event enqueue failed at that exact moment.
A product with three sizes isn't tracked as one blurry item — each size gets its own permanent identity, so stock, pricing, and reporting are always accurate down to the exact variant a customer bought.
Merchant impact: Feed, pixel, and channel data stays accurate at the level a customer actually buys — no ambiguity about which size was actually out of stock.
Developer impact: Every sellable offer gets a stable, opaque `catalogItemId`, generated once at creation and never derived from title, SKU, or a transient database shape. Every catalog output (Meta, Google Merchant, TikTok, CAPI `contents.id`) uses the same identifier.
Example: A refund and a catalog feed update for the same variant both resolve to the same `catalogItemId` — there's no reconciliation step needed between the two.
Meta and GA4 don't get to independently decide a sale happened — they only ever receive and report an event that Prebit has already confirmed. That decision is made once, in one place, no matter how many marketing tools you connect.
Merchant impact: Connecting a second marketing tool doesn't risk double-counting or redefining what counts as a sale — that decision was already made once, upstream.
Developer impact: `MarketingProvider` (`key`, `capabilities`, `validatePublicConfig`, `buildPayload`, `deliver`) is a strict registry — Meta and GA4 today. Meta receives browser + server Purchase under the same canonical `eventId` for real dedupe; GA4 stays server-only through Measurement Protocol on purpose, since it can't safely dedupe a parallel browser gtag Purchase against a server one.
Example: A merchant connects GA4 mid-month; every order-paid event from that point forward reaches it through the same registry Meta already used, with no separate integration code.
Page views, product views, cart adds, and purchases are tracked once on the storefront using one standard set of event names. Connecting a new marketing tool later doesn't mean re-instrumenting the storefront from scratch.
Merchant impact: A single, standard event vocabulary means a new marketing provider doesn't require re-instrumenting the storefront.
Developer impact: `window.prebit.analytics` exposes `track(name, properties?)` and `subscribe(name | "*", callback)`. Standard events are auto-instrumented; provider adapters are subscribers on this bus, never an alternate direct-call path — a Meta adapter consumes the `purchase` event through the bus, it never calls `fbq` directly and bypasses it. Only JSON-safe properties are accepted, and direct identifiers (email, phone, tokens) are rejected.
Example: `purchase` is deliberately never auto-fired — only the authenticated order-summary page calls `prebit.analytics.track("purchase", {...})`, with a session guard preventing it from re-firing on refresh.
Publishing your catalog to Meta, Google, or TikTok, and bringing sales in from a marketplace, both build on the same underlying system — so adding a new sales channel is a smaller, more reliable step rather than a rebuild.
Merchant impact: Channel expansion doesn't require a new backend model per destination — only a new adapter on top of infrastructure that already exists.
Developer impact: Catalog outputs (push: Meta, Google, TikTok; pull: Pinterest) and inbound sales-channel order/refund import (`Order.channelOrigin` idempotency, `ChannelProductMapping`) reuse the same `catalogItemId` and outbox patterns as Marketing Hub. The `manual` sales channel is a real, credential-free reference implementation that exercises the entire inbound pipeline.
Example: Amazon's Selling Partner API adapter is on the roadmap as its own dedicated design — LWA OAuth, AWS SigV4 signing, and a multi-step Feeds API upload flow that deserves purpose-built handling rather than being squeezed into the generic adapter shape.
Every layer feeds the next: Commerce Engine sits inside this chain rather than bypassing Commerce Engine's data contracts.
Product & Catalog, Order & Customer, Marketing, Payments, Shipping, and Sales Channels each own their own collections and emit `DomainEventEnvelopeV1` rows for state transitions that matter to other domains.
State transition and outbox enqueue happen in the same code path (the next statement after the winning conditional write), backed by a bounded repair cron for complete, guaranteed delivery.
Marketing (Meta/GA4) and catalog (Meta/Google/TikTok push, Pinterest pull) providers each sit in their own typed registry, transforming and delivering — never deciding — against the canonical envelope.
Boron and the planned Krypton framework both read Commerce Engine through the same public Storefront API and the same analytics bus, so a change to the underlying event model doesn't require two different integration efforts.
Because Meta, GA4, and Prebit's own dashboard all key off the same `eventId`, a merchant doesn't have to reconcile three different purchase counts after a campaign.
The durable outbox plus repair cron means a temporary provider outage gets caught and retried automatically, never quietly dropped.
Multi-channel selling and catalog syncing reuse the same identity and delivery infrastructure instead of requiring a rebuild per destination.
Settings → Marketing's health block reads real delivery records — last success, last attempt, error category — instead of assuming a connection is working.
`schemaVersion` on the envelope and a stable naming convention (`commerce.order.paid.v1`) mean integrations can be built against a contract that's designed to evolve additively.
The architecture is explicit that no cross-collection Mongo transaction exists in this codebase's money-critical paths — every consumer of this platform can rely on the same conditional-write-plus-repair-cron pattern instead of guessing about consistency guarantees.
Adding a marketing or catalog provider is a new registry entry with a defined shape (`validatePublicConfig`, `buildPayload`, `deliver`), not a new `if (provider === ...)` branch scattered through the codebase.
The `manual` sales channel needs no real marketplace credentials and exercises the same inbound pipeline a real adapter would use — a genuine way to validate integration code before a partner's real API is available.
A developer needs to trust that a `commerce.order.paid.v1` event means the order is actually, durably paid before building a fulfillment automation on top of it.
Outcome: Confidence that comes from the outbox's atomic-enqueue + repair-cron design, not just documentation claiming reliability.
A brand wants Meta and GA4 purchase counts to agree with each other and with Prebit's own dashboard after a big campaign.
Outcome: They do, because all three read from the same canonical `eventId`, not three independently-implemented tracking snippets.
An agency needs the same catalog and order behavior to hold across several client stores without re-verifying event correctness per store.
Outcome: The event model and outbox are store-scoped but architecturally identical across every store on the platform.
A CTO wants to know whether Commerce Engine's reliability claims are backed by anything more than marketing copy.
Outcome: This page states specifically what's been type-checked and test-verified, and what hasn't been run against a live database yet — see Performance below.
Payload tests (Meta/GA4 shape, hashing/normalization, no plaintext PII), event-envelope tests (ID/version/source stability, per-subscriber dedupe), transaction/repair tests, and worker claim/lease/retry tests are all part of the required verification set — `tsc --noEmit` and the full test suite (333/333 at last count) pass, but live post-deploy Meta Test Events / GA4 DebugView verification against a real store has not been run in this environment.
The order-paid repair cron has an explicit 48-hour bound — a deliberate choice that keeps the repair job's own blast radius small and predictable rather than scanning unbounded history on every run.
A worker claim/lease on outbox rows is what actually prevents two overlapping cron ticks from double-delivering the same due event — not just a `status` field that both workers could race to update.
Push-based catalog providers run on a daily scheduled sweep rather than a continuous stream, keeping sync cost predictable as catalog size grows.
Search and content teams make better prioritization calls when the underlying purchase data they're optimizing against is not itself noisy or duplicated.
A `catalogItemId` that never changes on rename keeps product structured data and shopping feed entries from silently breaking during a routine catalog edit.
Deduped, canonical events make it easier to tell whether organic or paid content actually drove a purchase, rather than double- or under-counting it.
Because every domain reads the same canonical product/order truth, structured data on the storefront and feed data sent to search/shopping engines describe the same reality.
A direct, factual read on where each platform is strong, and where Prebit takes a different approach.
Directional and factual. Validate against your own catalog complexity, channel strategy, and budget before deciding.
Plain answers to what merchants, agencies, and developers actually ask.
Start free. No credit card required. Explore the rest of the Prebit platform once you're in.