Order-created events

1. Documentation Type

Technical documentation.

2. Suggested Location in Sitemap

Suggested path: Documentation > Events > orderCreated__c.

3. Article(s)

Title

Order-created events and integrations

Content

This guide helps LWC developers, integration developers, implementation partners, and solution architects choose the correct OrderCentral event surface after checkout creates a web order. OrderCentral exposes two different order-created signals:

• OrderCreated__c for storefront UI reactions in the current Lightning page context
• Order_Created__e for durable downstream server-side integrations after the order transaction commits

Use the sections below to decide which surface matches your extension pattern, then implement only the subscriber model that fits your use case.

Choose the right order-created event surface

OrderCentral now publishes two distinct order-created events during checkout. They solve different integration problems.

Use the storefront message channel for UI behavior. Use the platform event for automation and integrations.

Use the OrderCreated__c UI message channel

OrderCreated__c is the storefront-facing event surface. Checkout publishes it from the current LWC checkout flow after order creation succeeds.

Important runtime behavior:

• The publisher is the checkoutFlow LWC, not the older Aura-based checkout implementation.
• Checkout publishes refreshShoppingCart__c first and then publishes OrderCreated__c.
• The message is intended for components running in the same Lightning page context.
• This is not a durable event bus. If your component is not active when the message fires, it will not receive it.

UI message payload contract

Current payload fields:

When to use the UI message channel

Use OrderCreated__c when you need a storefront component to:

• navigate the buyer to a custom confirmation experience
• show post-checkout UI state such as a toast, banner, or success panel
• refresh order-aware components on the current page
• coordinate page-level behavior with other storefront events such as refreshShoppingCart__c

Do not use this message channel for ERP integration, fulfillment orchestration, analytics ingestion, or any subscriber that must run outside the current buyer page.

Subscribe from a custom LWC

In source projects, the channel import is:

import ORDER_CREATED_CHANNEL from '@salesforce/messageChannel/OrderCreated__c';

In an installed managed package context, use the namespaced import:

import ORDER_CREATED_CHANNEL from '@salesforce/messageChannel/welisacommerce__OrderCreated__c';

Example subscriber:

import { LightningElement, wire } from 'lwc';
import { MessageContext, subscribe, unsubscribe } from 'lightning/messageService';
import ORDER_CREATED_CHANNEL from '@salesforce/messageChannel/welisacommerce__OrderCreated__c';

export default class OrderCreatedListener extends LightningElement {
    subscription;

    @wire(MessageContext)
    messageContext;

    connectedCallback() {
        if (!this.subscription) {
            this.subscription = subscribe(this.messageContext, ORDER_CREATED_CHANNEL, (payload) =>
                this.handleOrderCreated(payload)
            );
        }
    }

    disconnectedCallback() {
        if (this.subscription) {
            unsubscribe(this.subscription);
            this.subscription = null;
        }
    }

    handleOrderCreated(payload) {
        if (!payload?.orderId || !payload?.orderNumber) {
            return;
        }

        const paymentId = payload.paymentId || null;

        // Add navigation, toast, or page-level follow-up behavior here.
    }
}

UI implementation guidance

• Always validate the payload before acting on it.
• Treat paymentId as supplemental checkout context, not as the primary lookup key for order follow-up logic.
• Use orderId to load additional order data if your component needs more than the message payload exposes.
• Subscribe only from components that are intended to run in the current storefront page context.
• When your component also needs cart refresh behavior, pair this channel with refreshShoppingCart__c instead of adding cart data to the order-created payload.

Use the Order_Created__e platform event

Order_Created__e is the server-side integration surface for downstream processing after checkout creates a web order.

Important runtime behavior:

• The event is a high-volume platform event.
• Its publish behavior is PublishAfterCommit.
• Checkout registers the event during order creation and publishes it only after the transaction succeeds.
• The event payload is intentionally small. Subscribers should re-query the target web order instead of expecting denormalized order data in the event itself.

Platform event contract

When to use the platform event

Use Order_Created__e when you need to:

• trigger downstream fulfillment or ERP integration after the order transaction commits
• start Flow or Apex automation that should not depend on a buyer page staying open
• let middleware subscribe to order creation using the Salesforce event bus
• isolate integration processing from storefront rendering concerns

This is the correct pattern when the reaction is operational or integration-focused rather than UI-focused.

Permission and deployment considerations

Before an integration user or subscriber can consume Order_Created__e, confirm all of the following:

OrderCentral includes an OrderCentral Integration User permission set that grants read access to Order_Created__e. Use that permission set directly or mirror the same event access in your own integration permission model.

Subscriber design guidance

• Keep platform event subscribers idempotent. Retry behavior and duplicate handling should be designed into the downstream integration.
• Use Web_Order_Id__c to query the order and any related data your integration needs.
• Do not assume the storefront UI message channel and the platform event are interchangeable. They are published for different extension models.
• Prefer the platform event whenever the buyer might leave the page before your follow-up action finishes.

Validate and troubleshoot subscriptions

A storefront component does not react to OrderCreated__c

Check these first:

• The component is running on the same Experience Cloud page context as checkout.
• The component wires MessageContext correctly and subscribes during initialization.
• The implementation uses the namespaced channel import in an installed managed package org.
• The component expects paymentId to be optional instead of assuming it is always populated.

Cart-related UI stays stale after checkout

OrderCreated__c is the order-success signal. It is not the cart-refresh contract. If your custom component also needs cart refresh behavior, subscribe to refreshShoppingCart__c, which checkout publishes immediately before OrderCreated__c.

A downstream integration does not receive Order_Created__e

Check these first:

• The order transaction committed successfully.
• The event contract is deployed in the environment where you are testing.
• The integration user has read access to Order_Created__e.
• The subscriber itself is active and deployed in the same org.

A subscriber receives the event but cannot continue processing

Check these first:

• The subscriber re-queries the order by Web_Order_Id__c instead of expecting extra fields in the event.
• The integration user has access to the order data the subscriber needs after receiving the event.
• The downstream automation handles retry and duplicate-processing scenarios safely.

Summary

OrderCentral now exposes two supported order-created extension surfaces:

• OrderCreated__c for immediate storefront UI reactions on the active page
• Order_Created__e for durable downstream integrations after commit

Choose the surface based on where the subscriber runs and how reliable the follow-up action must be. UI reactions belong on the Lightning message channel. Server-side and external integrations belong on the platform event.