> For the complete documentation index, see [llms.txt](https://docs.peakcommerce.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.peakcommerce.com/guides/feature-guides/build-and-launch/guide-building-a-checkout-journey.md). # Building a Checkout Journey ### Overview A **journey** is a guided, multi-step flow that PeakCommerce hosts as a public page and runs a customer through to a commerce outcome — here, buying a plan. You compose the journey from pages, wire the steps in order, attach the **commerce actions** that create the order in your billing system, decide who can enter it, then preview and publish. No custom front-end code is required. This guide walks through building a public, self-service **E-Commerce** checkout end to end: plan selection → signup → billing → confirmation. For the conceptual reference, see the **Journeys** section of the product docs. ### Before you begin * You have at least one **plan / product** in your catalog (**Commerce → Product Catalog**) that the journey can sell. * You have the **pages** the steps will render, or you'll create them as you go (**Content → Pages**). A typical checkout uses a plan-selection page, a signup page, a billing/payment page, and a confirmation page. * A billing integration (for example Zuora or Stripe) is connected if you want the journey to create a real subscription downstream. ### 1. Create the journey 1. Go to **Content → Journeys** and click **+ New Journey**. 2. Set the **Journey Details**: * **Name** — an internal name (for example *Pro Plan Checkout*). * **Type** — **E-Commerce** for a public, unauthenticated checkout. * **Status** — leave it **draft** until you're ready to publish. * **Order Structure** — how products are grouped when the journey creates orders. 3. Click **Create Journey**. You land in the journey builder. ### 2. Add and order the steps On the **Steps** tab, click **Add step** for each page the customer passes through, and put them in order. A standard checkout runs: **Plan selection → Signup → Billing → Confirmation** For each step, set: * **Page** — the page that renders for this step. * **Label** — the name shown in the journey's progress bar. * **Role** — the step's purpose, which also mandates the right internal writes (next section). Give the signup step the **Signup** role and the billing/payment step the **Payment** role. Data collected on an early step (for example `email`, `firstName`, the selected `productId`) is written to the journey's shared **context** and is available to every later step, so the billing step already knows who and what it's charging. ### 3. Attach the commerce actions **Commerce actions** are the work a step performs the moment the customer advances — creating the account, placing the order, recording it in PeakCommerce. Expand a step and look under **Commerce actions**. * Giving a step a **role** brings its **required (locked 🔒)** internal actions with it, already configured — for example the **Payment** role guarantees PeakCommerce records the order and keeps the contact and organization current, *regardless of what the billing system returns*. You can reorder locked actions but not remove them. * Add an **integration** action to push to a connected system — for example a `create_order` action targeting your billing integration to create the subscription. * **Run order matters.** Actions run top to bottom; **blocking** actions must finish before the next starts. A checkout step typically runs *create account → create order → record order*, because you can't create the order before the account exists. * Map each action's fields from **context** (a value from an earlier step), a **literal**, or an expression. The builder validates that every required destination field is supplied before you can save. ### 4. Set the journey Settings On the **Settings** tab: * **Subscription term** — the contract length the journey creates: **Evergreen** (no end date) or **Termed** (a fixed length with a renewal policy). PeakCommerce shows a live preview of the terms it will send to your billing system. * **Profile assignments** — who may enter the journey. For a public checkout you generally leave this open; for signed-in flows, add an assignment per **Role** (and optionally a **Profile**) that's allowed in. * **SEO & Metadata** — the browser-tab title, meta description, and social preview for the journey's public page. ### 5. Preview, then publish 1. Click **Preview** and walk the whole flow as a customer would — confirm each step renders, data carries forward, and the final step places the order. 2. When it's right, click **Publish**. Publishing makes the journey live and gives you a **public URL** you can share or embed. 3. After launch, use the row menu (**⋯ → View Sessions**) on the **Content → Journeys** list to review completed, active, and abandoned sessions. ### Tips * **Build pages first, or alongside.** Each step binds to a page from **Content → Pages**; a step can't render without one. * **Let roles do the heavy lifting.** Rather than hand-adding internal writes, set the step's role and the mandated actions appear locked and pre-configured. * **Re-preview after every change**, and only **Publish** once the preview is clean — publishing is what changes the live experience. ### FAQ **Can the same journey serve signed-in customers or CSRs?** A journey's **Type** sets its audience — **Customer Self-Service**, **CSR Self-Service**, and **Partner Self-Service** run the same builder for signed-in customers, reps, and partners. Build a separate journey per audience and use **Profile assignments** to control who can enter each. **Why are there both internal and integration actions for the order?** PeakCommerce models commerce natively *and* syncs to your systems of record. The **integration** action creates the subscription in your billing system; the **internal** (locked) action authoritatively records the order in PeakCommerce, so your records stay correct and complete even while an integration is still being deepened. **How do I add branching (for example a different path by plan)?** Use the **Flow** tab to connect steps and add conditional branches, so a customer's choices send them down different paths. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.peakcommerce.com/guides/feature-guides/build-and-launch/guide-building-a-checkout-journey.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.