For the complete documentation index, see llms.txt. This page is also available as Markdown.

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).

    • TypeE-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.

Last updated

Was this helpful?