> This is part 1 of 4 of the full documentation (pages 1–100 of 345). > The content is paginated: fetch every part to see all of it. > Next part: https://docs.peakcommerce.com/llms-full.txt/1 > Page index: https://docs.peakcommerce.com/llms.txt # 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 This site has an agentic ask interface you may use to query the documentation dynamically by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.peakcommerce.com/index.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. --- # Home Welcome to your team’s developer platform

Find the right documentation for your needs

Build commerce experiences with PeakCommerce's powerful platform

Meet Mango

Cover image
Product DocsLearn how to configure PeakCommerce and self-service experienceshttps://docs.peakcommerce.com/productCard_GettingStarted.svg
Guides & How-ToFollow hands-on guides to implement key featureshttps://docs.peakcommerce.com/guidesCard_PlatformDocs.svg
Developer DocsBrowse, test, and implement in-app code, templates, and APIs.https://docs.peakcommerce.com/developersCard_DeveloperDocs.svg
IntegrationsConnect PeakCommerce with Salesforce, Zuora and other systemshttps://docs.peakcommerce.com/integrationsCard_Workflows.svg
Support & AdministrationFind troubleshooting steps and admin best practiceshttps://docs.peakcommerce.com/supportCard_Support.svg

Integration Highlights

Join our Discord community or create your first PR in just a few steps.

Zuora IntegrationConnect PeakCommerce to Zuora for subscription billing, payment processing, and product catalog managementLearn More
Salesforce IntegrationIntegrate PeakCommerce with Salesforce for subscription commerce and revenue operationsLearn More

Need Assistance?

Get support from the PeakCommerce team and access trouble shooting resources

Email SupportContact our support team for assistance, questions, and issuessupport@peakcommerce.com
TroubleshootingFind solutions to common problems and learn about known issuesTroubleshooting
Platform StatusCheck live platform availability and active incident updatesPlatform Status
# What's New The latest features, improvements, and fixes in PeakCommerce. Admins also see new entries in the notification bell at the top of the app. ### Stripe subscriptions stay in step with Stripe **New** · September 29, 2026 When Stripe renews, changes or ends a subscription, PeakCommerce now updates its own copy — status, current period, billing interval and cancel-at-period-end — and sends your webhooks the matching subscription and payment events. Connect it once per Stripe integration with a webhook endpoint and its signing secret. [Learn more →](https://docs.peakcommerce.com/integrations/stripe/stripe-subscription-sync) *** ### Stripe API cancellations now honor the paid period **Improved** · September 29, 2026 Cancelling a Stripe-billed subscription through the API now asks Stripe to end it at the close of the current paid period, the same as a cancel from the customer portal. The subscription stays active until then, and subscription.cancelled is sent when it ends. [Learn more →](https://docs.peakcommerce.com/developers/api-reference/subscriptions) *** ### Webhook connections now require HTTPS **Improved** · September 29, 2026 Webhook endpoint URLs must use https\:// when you add or edit a subscription, and loopback or private network addresses are refused with the reason shown. A new Security and data protection page summarizes how PeakCommerce protects your data and the systems you connect. [Learn more →](https://docs.peakcommerce.com/product/using-peakcommerce/authentication-and-security/security-and-data-protection) *** ### Update an API key's scopes without replacing it **Improved** · September 29, 2026 The admin API can now update an existing key's scopes in place, so an integration keeps its key while its access is widened or narrowed. [Learn more →](https://docs.peakcommerce.com/developers/api-reference/admin-api-keys) *** ### Unknown amounts show as a dash, not $0 **Fixed** · September 29, 2026 Where an order's subtotal, recurring total or amount due today, or an account's net MRR, isn't known yet, PeakCommerce now shows — instead of a misleading $0.00. *** ### Jump through Audit Logs with numbered pages **Improved** · September 29, 2026 Audit Logs now pages through long histories with numbered pages, so you can jump straight to the part of the record you need. [Learn more →](https://docs.peakcommerce.com/product/using-peakcommerce/authentication-and-security/viewing-audit-logs) *** ### Book a product set line as its own order action **New** · September 15, 2026 Mark any product set line as "Its own order line" and turn on Honor order grouping in a journey's create-order step: checkout still places one order and one subscription, but each marked line is booked as its own order action — easier to read line by line, and recorded on the day that line actually starts. Invoicing is unchanged. [Learn more →](https://docs.peakcommerce.com/guides/feature-guides/billing-setup/guide-booking-a-line-as-its-own-order-action) *** ### Contacts, now in the API **New** · September 6, 2026 The people behind an account are readable from your own systems: list a tenant's contacts, filter to an exact email address, or fetch one by id. It uses the same scoped keys as the rest of the v1 surface, so a key with read scope is all an integration needs. [Learn more →](https://docs.peakcommerce.com/developers/api-reference/contacts) *** ### Consent, set once for the whole journey **New** · September 4, 2026 Which acknowledgement a buyer must give — and where it appears — is now a property of the journey rather than something wired step by step. Every route through the journey is checked when you publish, so one can't go live with a path that skips consent, and each acceptance is recorded against the session that produced it. [Learn more →](https://docs.peakcommerce.com/product/settings/company-settings/acknowledgements-overview) *** ### Collapse the Settings sidebar too **Improved** · September 3, 2026 Settings now collapses its sidebar the same way the main navigation does, and both stay the way you left them between visits — more room for the page you came to work on. *** ### Find a session by the customer, not the session id **New** · September 1, 2026 A support call starts with a name or an email address. Journey sessions can now be searched by customer email, customer name, or date and time, so you can open the exact session someone is asking about instead of scrolling a list. [Learn more →](https://docs.peakcommerce.com/product/reporting-and-analytics/analytics-workspace/session-explorer) *** ### New guides: the rules engines, and working with Mango **Improved** · September 1, 2026 Seven walkthroughs — policies, plan dependencies, audiences, retention routing, segment and partner pricing, change-lifecycle timing, and promotions — each with a short video of the thing being built. Alongside them, a full guide to Mango: what she can see, how the propose-and-approve build flow works, and when to hand off to a human. [Learn more →](https://docs.peakcommerce.com/product/rules-and-customizations/rules-overview) *** ### The recurring total says what the invoice will say **Improved** · August 30, 2026 When a subscription carries more than one discount, the figure on the card rarely matches the percentages added up in your head — and it isn't meant to. The recurring total reads the amounts your billing system says it will charge rather than presenting them as an estimate, and a new article walks through the cases that surprise people. [Learn more →](https://docs.peakcommerce.com/product/customer-success-portal/discounts-and-the-recurring-total) *** ### Market Studio — one place to run every currency you sell in **New** · August 26, 2026 A market is a currency: the market a visitor resolves to decides the payment page they see, the language they read, and the profile they get. Market Studio is where you set that up — which journeys and portals belong to a market, which hosted payment page serves each of them, and what else that market's buyers receive — with a trace view that replays how a given customer was routed. [Learn more →](https://docs.peakcommerce.com/product/using-peakcommerce/market-studio) *** ### Session event exports carry the payload **Improved** · August 26, 2026 Exporting a journey session's events to CSV now includes the detail each event carried, not just its name and timestamp — enough to reconstruct what happened without opening the session. *** ### One Support menu, every route to help **Improved** · August 24, 2026 Support is now a single entry that opens one dialog — ask Mango, search the help center, or reach a person — instead of separate launchers competing for the corner of the screen. [Learn more →](https://docs.peakcommerce.com/support/getting-help-from-mango) *** ### Say what each plan actually grants **New** · August 23, 2026 Define your capabilities once as a feature vocabulary, then grant them per plan — as a plain include, as a value your application reads (a seat limit, a tier string), or as unlimited. Your code gates on the feature key rather than the plan name, so changing which plan includes something takes effect without a release, and entitlements reach your app through the API and webhooks. [Learn more →](https://docs.peakcommerce.com/product/settings/billing-catalog/plan-entitlements) *** ### Slack workspaces, under an administrator's control **New** · August 19, 2026 Connect Slack workspaces, map Slack users to PeakCommerce accounts, and choose which slash commands your reps can run — from one settings page, gated by the Integrations permission. Bot credentials and per-user mappings live in the product rather than scattered across environment files. [Learn more →](https://docs.peakcommerce.com/product/settings/developer-tools/slack) *** ### Journey version history, side by side **Improved** · August 17, 2026 Published versions now sit in a master/detail view: pick a snapshot on the left, read what changed on the right — instead of the detail landing at the bottom of the page. [Learn more →](https://docs.peakcommerce.com/product/journeys-and-pages/journey-basics/journey-history) *** ### Compare every profile at a glance **New** · August 13, 2026 The Permissions Grid puts profiles across the top and permissions down the side, so "how do these two differ?" is one screen instead of opening each profile in turn — sidebar sections, resource access levels, and named capabilities, with the differences flagged. [Learn more →](https://docs.peakcommerce.com/product/using-peakcommerce/profiles-and-permissions/comparing-profiles) *** ### Mango is honest about being away **Improved** · August 12, 2026 On the rare occasion the assistant can't hold a conversation, the Mango bubble now shows a clear offline state — with direct routes to the help center and support — instead of a launcher that looks alive. It restores itself automatically the moment service returns, no reload needed. [Learn more →](https://docs.peakcommerce.com/product/getting-started/meet-mango) *** ### Mango builds native, on-brand components **New** · August 11, 2026 Describe a component and Mango now assembles it from the same blocks the page editor uses — styled by your brand tokens automatically, every element individually selectable and editable afterwards, no code involved. Live data renders through the familiar placeholder syntax with proper currency, number, and date formatting, and a layout that couldn't render is refused at save with the exact problem named — a component can't be published quietly broken. [Learn more →](https://docs.peakcommerce.com/developers/native-components) *** ### Save any part of a page as a component **New** · August 11, 2026 Arranged something on a page you'd like to reuse? Select its top block and choose Save as component: pick which text values become editable fields, and it lands in your Component Library ready to drop anywhere. It's also the fastest way to work with Mango — ask for something close, adjust it by hand on the page, keep the result. [Learn more →](https://docs.peakcommerce.com/developers/native-components) *** ### A portal built for sales teams **New** · August 10, 2026 Sales is now a full role with its own portal, separate from customer support: its own accounts list and account workspace with the same depth support staff have, team-only notes that stay inside the sales team, and its own set of pages you can tailor in the page editor — the editor now treats Sales as a portal type with its own component library. Grant it like any other role, from a user's role and profile. [Learn more →](https://docs.peakcommerce.com/product/sales-portal/sales-portal-overview) *** ### Journeys and Pages, now in the API **New** · August 10, 2026 Journeys are a first-class part of the v1 API for the first time: list, create, update, and delete journeys, manage steps and commerce actions, read and restore versions, and publish. Pages gained publish, version history, and restore. Publishing anywhere is an explicit, separately-permissioned action that runs the same validation gates as the app's own publish button — nothing goes live over the API by accident. [Learn more →](https://docs.peakcommerce.com/developers/api-reference/admin-content) *** ### API keys with exactly the authority you intend **Improved** · August 9, 2026 API keys can now carry narrow, per-resource scopes — a key can hold exactly journeys:write or pages:read instead of whole-tenant access. Publishing is its own permission, so a key that authors drafts can never push them live. Existing read, commerce, and admin keys keep working unchanged; narrow keys are minted through the v1 admin API. [Learn more →](https://docs.peakcommerce.com/developers/api-reference/authentication) *** ### Sell one-time products — and price recurring ones properly **New** · August 4, 2026 The catalog now handles more than subscriptions: create a One-Time Purchase product with its own price, imagery, and storefront details, alongside Recurring plans and Bundles. Recurring products get a real pricing-model picker — Flat Fee, Per Unit, Volume, or Tiered — with a band editor and a live calculator showing what any quantity costs. And every product now has a fuller page: a live preview of the exact card customers see, full tier bands in the pricing table, and which Product Sets carry it. [Learn more →](https://docs.peakcommerce.com/product/using-peakcommerce/products-and-bundles/products-overview) *** ### Quotes: build, send, and close a deal in one place **New** · August 3, 2026 Build a priced proposal from your catalog, send the customer a secure link they can approve without creating an account, and turn the accepted quote into a real order. One click reprices linked lines from the catalog while keeping your discount, and a discount past your authority ceiling holds the quote for a second person's sign-off — a genuine two-person rule. Every quote carries a status from draft to completed, so you always know where the deal stands. [Learn more →](https://docs.peakcommerce.com/product/sales-portal/quotes-overview) *** ### Learn PeakCommerce by watching **New** · August 1, 2026 The help center now has a full video library: short product guides filmed in the real app — journeys, commerce actions, pricing and retention rules, offers, fraud signals, usage-based billing, and more — plus the Quote-to-Cash Playbook and Market Trends series. Videos are embedded right on the doc pages they explain, and the library page collects them all in one place. [Learn more →](https://docs.peakcommerce.com/guides/video-library) *** ### Know which plan is running — and which one's next **Improved** · July 31, 2026 A plan queued to start later — a paid plan waiting behind a free trial, say — now reads “Starts {date}” instead of being badged as current, in the customer portal and the agent console alike. The order summary shows the active plan and the scheduled one separately, and editing a queued plan swaps what's scheduled while keeping its start date, with nothing due today. Admins can also flag genuine trial plans in the catalog so trial-only offers reach exactly the right customers. [Learn more →](https://docs.peakcommerce.com/product/customer-self-service/subscription-management/customer-subscription-management) *** ### Finer control over who can un-cancel **Improved** · July 31, 2026 Revoking a scheduled cancellation now has its own permission on customer, agent, and sales profiles — no longer tied to the Cancel Plan grant — with three levels: no access, view (see the scheduled-cancellation banner and why revoking is blocked), or manage (the one-click Revoke button). It starts at no access, so grant it deliberately alongside the retention-journey setting. [Learn more →](https://docs.peakcommerce.com/product/using-peakcommerce/profiles-and-permissions/portal-action-permissions) *** ### Changed their mind? Un-cancel a scheduled cancellation **New** · July 24, 2026 Subscriptions cancelled for a future date now show exactly when access ends — “Scheduled for {date}” right under the status badge — and, when you enable it on your retention journey, the customer (or your agent) can revoke the cancellation in one click before that date arrives. A built-in safeguard requires all invoices to be paid first. [Learn more →](https://docs.peakcommerce.com/product/customer-self-service/subscription-management/customer-subscription-management) *** ### See — and create — sub-accounts from the account workspace **New** · July 24, 2026 A new Subaccounts tab on the agent's account view lists an account's children straight from your billing system's own hierarchy, and a configurable journey lets agents create a new sub-account with the parent linked automatically. Built for the parent-child account structures B2B billing runs on. [Learn more →](https://docs.peakcommerce.com/product/customer-success-portal/working-with-an-account) *** ### Concessions, governed **New** · July 23, 2026 Give reps real discount authority without giving away the store: admins define concession bands — value ranges tied to a reason vocabulary and the right GL bucket — with a hard ceiling per journey. Reps compose the concession right inside the change-plan flow, the server enforces the ceiling no matter what, and every grant is recorded and forwarded to your CRM and ERP through journey context. [Learn more →](https://docs.peakcommerce.com/guides/feature-guides/retain-and-manage/guide-csr-assisted-change-plan) *** ### Agents can add a customer's payment method — safely **Improved** · July 23, 2026 The account workspace's payment-methods panel now adds a card through your billing system's secure hosted payment page, in a modal, so reps can help a customer over the phone without card data ever touching PeakCommerce. Admins choose which hosted page each surface uses. [Learn more →](https://docs.peakcommerce.com/product/customer-success-portal/working-with-an-account) *** ### Your brand, down to the browser tab **Improved** · July 23, 2026 Upload your favicon directly in Company Profile — no hosting required — and your signed-in customer and partner portals pick it up automatically. Uploads are validated for safety, and a hosted URL still works for your public pages. [Learn more →](https://docs.peakcommerce.com/product/settings/company-settings) *** ### A full account Timeline for your support team **New** · July 21, 2026 Every account now has a single chronological history: lifecycle stages, plan and product changes, billing events synced nightly from your billing system, retention outcomes, and staff notes — searchable and filterable in one feed. Notes log straight to your CRM as activity history, and escalations stand out without triggering CRM case workflows. [Learn more →](https://docs.peakcommerce.com/product/customer-success-portal/account-timeline) *** ### On-brand pages by default **Improved** · July 21, 2026 Text and heading blocks gain a brand-palette color control, section backgrounds are picked from the same curated palette, and the built-in marketing blocks — pricing tables, feature grids, testimonials — now follow your brand colors automatically and reflow cleanly on tablets and phones. [Learn more →](https://docs.peakcommerce.com/product/journeys-and-pages/pages) *** ### Manage your users' sign-in lifecycle without leaving PeakCommerce **Improved** · July 20, 2026 The user detail page now handles the full authentication toolkit: reset a password, send a verification email, change a user's email or phone, block or unblock sign-in, and reset MFA enrollment — each action audited, no identity-provider console required. [Learn more →](https://docs.peakcommerce.com/product/using-peakcommerce/users-and-user-roles/editing-a-user) *** ### A cleaner, tabbed editor for journey steps **Improved** · July 16, 2026 Editing a journey step now opens a focused full-page editor — a left rail groups everything into Overview, Variables, Custom fields, Advanced, and Tracking scripts, so there's no more long scroll. The role picker is searchable, unsaved-edit dots show what changed, and one Save saves the whole step, tracking scripts included. [Learn more →](https://docs.peakcommerce.com/product/journeys-and-pages/journey-steps/managing-journey-steps) *** ### Usage-based billing with Metronome, now native **New** · July 15, 2026 Metronome joins Zuora and Stripe as a native billing provider. Connect it under Settings → Integrations and sell metered, consumption-priced products through the same catalog, journeys, and customer portal you already use — Metronome rates the usage and finalizes invoices, and a linked Stripe integration collects payment automatically. The full lifecycle runs natively: catalog sync flattens Metronome products and rate cards into your PeakCommerce catalog (monthly and annual rates become distinct plans), signup journeys provision the customer and contract with included allowances and overage rates, card capture happens right in the payment step, and plan changes, retention discounts, and cancellations all write back to the contract. Optional usage ingest streams executed commerce value to Metronome as it happens. [Learn more →](https://docs.peakcommerce.com/integrations/metronome/metronome-usage-based-billing) *** ### Customers see live usage against their plan allowance **New** · July 15, 2026 On usage-based plans, the customer portal now shows a live usage drawdown — real consumption against the included allowance, a clear flag when usage crosses into overage, and how many days remain in the billing period. No more surprise invoices. *** ### Install your analytics and tag-manager scripts, no engineering required **New** · July 15, 2026 Add Google Tag Manager, GA4, VWO, Heap, or any analytics snippet to your public storefront, signup, and payment pages straight from Settings — and layer page-, journey-, or even step-level snippets on top, so every step of a multi-step funnel can fire its own goal. Behind-login tracking in the customer portal stays off until you deliberately opt in. [Learn more →](https://docs.peakcommerce.com/product/settings/developer-tools/tracking-scripts) *** ### Offers get a dedicated page and a full-page editor **New** · July 14, 2026 Every offer now has its own page — plain-English terms, redemption stats, guardrails, and the exact catalog discount it resolves to — plus a full-page editor with a live customer preview and billing-impact estimate that update as you type. [Learn more →](https://docs.peakcommerce.com/product/using-peakcommerce/products-and-bundles/offers-and-discounts) *** ### Retention discounts with built-in guardrails **Improved** · July 13, 2026 Save offers in cancellation flows now apply through governed offer records with per-customer usage caps and a live conflict check against your billing system — a discount can never stack twice, and an offer only reappears once an existing discount is about to end. Each offer controls its own guardrails: a per-customer redemption cap counted over the customer's lifetime or a rolling window, a **conflict scope** that decides which existing discounts suppress the offer, and a **re-offer window** that lets the offer resurface just before a blocking discount expires. Checks run against live billing state at the moment of acceptance. And a discount accepted during a free trial now automatically waits and activates when the paid subscription begins — the customer is told exactly when it starts. [Learn more →](https://docs.peakcommerce.com/product/using-peakcommerce/products-and-bundles/offers-and-discounts) *** ### Design your signup form, field by field **New** · July 12, 2026 The signup step now has a visual field editor: drag fields onto a live preview, reorder them, and set each field's format, requirement, width, label, and error message. Add address or job-title presets — or fully custom fields — and the preview validates exactly like the real form. [Learn more →](https://docs.peakcommerce.com/product/journeys-and-pages/journey-steps/signup-form-fields) *** ### See exactly what changed — and restore any journey version **Improved** · July 11, 2026 Journey version history now summarizes what changed in every version and shows a color-coded diff against the previous one. Restore any past version into a new draft with one click — what's live stays untouched until you publish. [Learn more →](https://docs.peakcommerce.com/product/journeys-and-pages/journey-basics/journey-history) *** ### Test commerce actions before you publish **New** · July 10, 2026 Every commerce action now has a Test panel: supply sample data and instantly see the resolved payload, with invalid values caught against your CRM's restricted picklists — no live order required. And when a blocking action does fail, steps can route visitors to a fallback page instead of stopping them. [Learn more →](https://docs.peakcommerce.com/product/journeys-and-pages/journey-steps/commerce-actions) *** ### Saved payment methods, managed in a click **Improved** · July 10, 2026 Customers can set a new default or remove a saved payment method straight from the payment-methods list in the customer portal, with a confirmation before anything is removed. *** ### Reliable invoice PDF downloads **Fixed** · July 10, 2026 Downloading an invoice from the customer portal now returns a proper PDF every time — with a clear message in the rare case a document is still being generated by the billing system. *** ### Ask Mango, right inside the app **New** · July 9, 2026 Mango is now one click away anywhere in the admin app. Ask about your catalog, plans, journeys, live journey activity, or your retention numbers — by chat or voice — and Mango answers from your own workspace. It reads, it never changes anything. [Learn more →](https://docs.peakcommerce.com/product/getting-started/meet-mango) *** ### Find any account from the header search **New** · July 7, 2026 The global search now finds customer accounts by name, account number, or CRM id and jumps straight to the account workspace. Results respect each user's role and account scope — people only ever see what they're allowed to. *** ### A sharper accounts workspace for support teams **Improved** · July 6, 2026 The accounts list gets a cleaner search-and-filter toolbar, sortable Net MRR and CRM-id columns, and at-a-glance tiles that mix live counts — active accounts, customers in a retention flow — with nightly usage and trial-ending signals. *** ### A clearer plan-change summary — for customers and CSRs **Improved** · July 6, 2026 Changing a plan now shows a live order summary: what you have today, what you'll have after the change, per-line price differences, and the exact prorated amount due today. Customers see it in the portal; CSRs see the same summary plus a redesigned billing preview before they confirm. *** ### Faster, more reliable billing operations **Improved** · July 5, 2026 Subscription changes — plan switches, add-ons, quantity updates, pauses, and cancellations — now flow through your billing system's modern orders API, giving more consistent results and more accurate cost previews for every change. *** ### Show trial-only plans to the right customers **New** · July 4, 2026 Product-set items can now be marked “Only during an active trial,” so trial-specific plans appear for trialing customers and stay hidden from paying ones — while a customer's current plan always remains visible. *** ### Meet Mango, your AI assistant **New** · June 28, 2026 Our AI assistant now has a name and a face. Look for “Create with Mango” in the page and component editors and on the rule engines — describe what you want and Mango drafts it for you to review. Mango is the clever mongoose who lives inside PeakCommerce and helps you build. Build components and pages from a description, draft rules on the automation engines, and ask Mango questions from the help docs. Every change Mango proposes is yours to **accept, reject, or refine** — a human is always in the loop. [Learn more →](https://docs.peakcommerce.com/product/getting-started/meet-mango) *** ### A redesigned admin Dashboard **New** · June 27, 2026 The admin home is now a command center — the metrics, recent activity, and quick actions you reach for most, surfaced the moment you sign in. Panels you have no data for stay hidden, so the view stays relevant. [Learn more →](https://docs.peakcommerce.com/product/reporting-and-analytics/dashboard) *** ### Outbound integration usage at a glance **New** · June 24, 2026 API Usage now shows aggregated outbound rate gauges for your integrations, so you can see how close each one is to its limits before it becomes a problem. *** ### Separate Change-Plan and Cancel-Plan permissions **Improved** · June 20, 2026 Subscription management splits into two distinct permissions — Change Plan and Cancel Plan — so you can let a CSR adjust a subscription without granting the ability to cancel it. *** ### Reliable journey version history **Fixed** · June 18, 2026 Editing a journey now records a draft snapshot every time, so version history is complete and you can compare or roll back with confidence. An “unpublished changes” indicator shows when a draft differs from what’s live. *** ### Serve portals and pages on your own domain **New** · June 14, 2026 Map your own custom domains and subdomains to your customer portal, partner portal, and hosted pages, so customers see your brand end to end. Add a hostname, point your DNS at the records we give you, and PeakCommerce provisions the certificate for you. *** ### A clearer Settings area **Improved** · June 9, 2026 Settings now opens to a home hub with quick actions and grouped sections, and you reach it from your user menu in the bottom-left corner. Users, Profiles, API Keys, integrations, and the rest are organized so you can find what you need faster. *** ### See what a profile grants — and who has it **Improved** · June 3, 2026 Permission profiles now show their full permission set at a glance and list every user assigned to them, so you can audit access without guesswork. View a profile read-only, or edit it in place. *** ### Sell plans programmatically with the Agent API **New** · May 27, 2026 The PeakCommerce Agent API (v1) lets your own systems — and AI agents — discover plans, build carts, preview pricing, and place orders, with your pricing and discount policies enforced on the server. Explore it in the developer docs. # Welcome to PeakCommerce ### Welcome to PeakCommerce PeakCommerce helps Go-To-Market teams launch, optimize, and scale subscription and usage-based commerce across every channel. We’re excited to have you using PeakCommerce to build modern, flexible commerce experiences that convert, expand, and retain customers—without the complexity of traditional custom builds. ### Platform Overview PeakCommerce is a composable commerce platform purpose-built for subscription businesses running on Salesforce and Zuora. It enables teams to unify product-led growth (PLG) and sales-assisted motions into a single, cohesive customer journey—spanning acquisition, conversion, expansion, and renewal. Designed for speed and flexibility, PeakCommerce delivers fast, responsive, mobile-ready commerce experiences that support everything from self-service trials to complex, sales-driven quote-to-cash workflows. ### One Platform. Every Channel. PeakCommerce brings together the critical building blocks of subscription commerce into a single, low-code platform: * Product & Offer Configuration * Pricing & Packaging * Checkout & Order Capture * Subscription Lifecycle Management * Self-Service & Account Management * Salesforce-Native Sales Workflows \ This unified approach allows teams to design and operate end-to-end customer journeys—from first interaction to renewal and upsell—without stitching together disconnected tools. ### Unified Product-Led & Sales-Led Growth #### Product-Led Growth (PLG) PeakCommerce enables frictionless self-service experiences that accelerate acquisition and expansion: * Self-service signup and checkout * Free trials and freemium offers * Usage-based and hybrid pricing models * In-app upgrades and plan changes * Seamless free-to-paid conversions #### Sales-Assisted Growth For sales-driven and enterprise motions, PeakCommerce supports robust quote-to-cash workflows: * Salesforce-native order creation * Agent-assisted and customer-initiated orders * Complex pricing, promotions, and amendments * Smooth handoffs between sales and self-service #### Partner & Indirect Channels Extend commerce beyond direct sales with partner-ready experiences: * Self-service ordering for partners * Customer and subscription management * Consistent pricing and offer governance across channels ### Native Integration Advantage PeakCommerce is built to work *natively* with the systems subscription businesses already rely on. With out-of-the-box integration to Zuora for billing and Salesforce for CRM, PeakCommerce allows teams to launch complete, production-ready commerce experiences without custom middleware, fragile integrations, or long implementation cycles. * No duplicated business logic * No sync jobs to manage * No custom checkout rebuilds \ Just clean, reliable commerce—connected directly to your source systems. ### Core Platform Components #### PeakCommerce Catalog A flexible product and offer configuration layer designed for rapid experimentation and iteration. Teams can define products, pricing models, trials, promotions, and conversion paths—all without code. This enables fast go-to-market changes while maintaining alignment with Zuora and Salesforce data models. #### PeakCommerce Checkout A modern subscription checkout experience optimized for conversion and scalability. * Hosted or embedded checkout options * Support for subscriptions, add-ons, and usage-based pricing * Trial flows and free-to-paid transitions * Secure, mobile-friendly, and extensible Checkout experiences are configurable and reusable across acquisition, upgrade, and sales-assisted flows. #### PeakCommerce Self-Service A comprehensive customer portal that drives adoption, reduces churn, and unlocks expansion revenue. * Secure authentication * Account and subscription management * Upgrade, downgrade, and add-on flows * Cancellation prevention and retention paths Customers can manage their full lifecycle independently—while staying fully in sync with Salesforce and Zuora. #### PeakCommerce Subscriptions A unified view of the subscription lifecycle across all channels. Track customers, orders, subscriptions, and changes from initial signup through renewal. This provides the foundation for analytics, lifecycle automation, and operational visibility across PLG and sales-led motions. ### Omnichannel Commerce, Built for Subscriptions PeakCommerce works hand-in-hand with Salesforce and Zuora to power scalable, subscription-first commerce across every channel. Whether your growth strategy is PLG, sales-led, or hybrid, PeakCommerce provides the flexibility and control to support it—today and as you scale. # What is PeakCommerce? #### Overview PeakCommerce is a unified commerce platform — a revenue execution layer that turns buying intent into a completed transaction, instantly. It brings every buying touchpoint into one seamless experience, from storefronts and self-service portals to partner and CSR portals, so customers, your teams, and even AI agents can complete orders, upgrades, and account changes across any business model. Rather than building and maintaining custom checkout, self-service, and account-management experiences, companies use PeakCommerce to deliver production-ready commerce flows that connect to the systems they already use — connect your payment gateway directly, run on Zuora, Stripe, or Maxio, or use PeakCommerce's built-in ordering. No billing engine required. PeakCommerce is built for the full range of modern revenue models — subscription, usage-based, and one-time — and for every motion, from product-led growth (PLG) to sales-led and CS-driven expansion, without duplicating logic or introducing fragile integrations. ### Why PeakCommerce Exists Many organizations underestimate the cost, complexity, and risk of building custom commerce on top of enterprise billing, CRM, tax, and payment systems. PeakCommerce removes that burden by providing a proven, low-code platform that handles: * Checkout and order capture * Subscription lifecycle management * Self-service account experiences * CRM-connected sales workflows * Direct integration with your billing system This allows teams to move faster while maintaining operational integrity. ### How PeakCommerce Fits Together Watch the overview — the big picture, from catalog to a live storefront: {% embed url="" %} PeakCommerce is easiest to understand as a few connected building blocks. Setting up your tenant means putting these in place, in order: * **Catalog** — your **products**, and the **plans** and **charges** that price them. This is what you sell. Plans and charges typically sync from your billing system, so your catalog mirrors your source of truth. * **Product sets** — the purchasable grouping a customer chooses from. A product set assembles catalog items — a base plan, add-ons, options — into the offer you actually present. * **Journeys** — the experience that sells a product set: checkout, signup, self-service, or sales-assisted. A journey is how customers transact, and it references the product set it sells. * **Pages** — the screens a journey is built from, composed in a low-code editor. * **Domains** — your branded hostname, so the storefront and account portal run under your own domain rather than a generic URL. * **Rules & Automation** — the guardrails: pricing rules, plan dependencies, territory routing, and policy limits that keep every sale consistent, no matter who — or what — is transacting. These connect in a single line: > **Catalog → product set → journey → storefront** (under your **domain**), with **Rules & Automation** as the guardrails — all connected to the billing and CRM systems you already use. Everything else in setup — connecting billing, adding your team, going live — is about putting this chain in place. The rest of this getting-started guide walks each step in order. ### Key Benefits of PeakCommerce #### Cost-Effective Compared to Custom Builds Building commerce in-house often requires significant engineering investment, ongoing maintenance, and deep expertise across billing, tax, payments, and CRM systems. PeakCommerce provides these capabilities out of the box, reducing total cost of ownership and eliminating the need to reinvent complex commerce workflows. #### Faster Time to Market PeakCommerce enables teams to launch commerce experiences quickly without lengthy development cycles. * Pre-built patterns for subscription checkout and self-service * Configurable pricing, plans, and trials * Low-code customization instead of hard-coded logic This allows businesses to respond quickly to market changes and go-to-market initiatives. #### Proven Reliability and Quality PeakCommerce is a production-grade platform that has undergone extensive testing and real-world usage across businesses of every model. Teams benefit from a stable, well-supported solution rather than maintaining bespoke code that can be difficult to test, scale, and support over time. #### Built to Scale With Your Business PeakCommerce is designed to support growth without re-architecture. As your business evolves, the platform can accommodate: * Increased transaction volume * New pricing and packaging models * Additional sales channels * More complex customer journeys This ensures commerce does not become a bottleneck as demand increases. #### Expert Platform and Integration Support PeakCommerce provides support across both the platform and the billing and CRM systems you connect to it. This includes: * Troubleshooting and issue resolution * Guidance on best practices * Documentation and implementation support Teams are not left managing complex integrations on their own. #### Access to Advanced Commerce Capabilities PeakCommerce delivers capabilities that are costly and time-consuming to build internally, including: * One-time, subscription, and usage-based checkout * Free trials and free-to-paid conversions * Plan changes, add-ons, upgrades, and amendments * Self-service and CSR-driven account management * Conversational and agentic commerce These features are designed for businesses operating at scale. #### Focus on Core Business Priorities By using PeakCommerce, organizations can focus engineering and operational resources on what differentiates their business—such as product innovation, customer experience, and go-to-market execution—instead of maintaining commerce infrastructure. #### Security, Compliance, and Data Integrity PeakCommerce is built with enterprise security and compliance in mind. * Secure handling of customer and payment data * Alignment with the security models of your connected billing and CRM systems * Reduced risk compared to custom-built solutions This helps protect sensitive data while meeting regulatory and operational requirements. # Meet Mango Say hello to **Mango** — the clever mongoose who lives inside PeakCommerce and helps you build. Mango hails from the shores of Hawaii, has a bottomless appetite for problem-solving (and for ripe mangoes from the island hills), and a real talent for turning *"I wish I could just describe what I want"* into something working on your screen. She's mischievous enough to be fun, but **veracious** where it counts: Mango always shows you exactly what she's about to do and waits for your okay. She proposes — you decide. Here's Mango in a playful mood: {% embed url="" %} ## What Mango can do Wherever you see a **Create with Mango** button or a **Chat** panel, Mango is ready to help: * **Build components from a description.** In the [component editor](/product/using-peakcommerce/templates/creating-a-component), tell Mango *"a three-tier pricing table with a highlighted middle plan"* and she generates a working component — built from the page editor's native blocks, no code, every element editable — for you to refine. * **Design pages.** In the page designer, describe the page (or the change) you want and Mango assembles it from your components. * **Draft rules.** On the Rules & Automation engines — Business Rules, Pricing Rules, and the rest — describe the behavior (*"15% off annual upgrades"*) and Mango drafts the rule for you to review. * **Answer your questions.** Stuck on something? Ask her from the launcher in the app and she'll explain it and point you to the right screen. ## How to work with Mango * **Create with Mango** — the button on the editors and the rule engines. Describe what you want; Mango builds a first draft you can keep refining. * **Chat** — the Chat tab in the component and page editors. Ask for a change in plain language; Mango proposes an edit you can **accept, reject, or refine** — and every decision is recorded, so your team can always see who changed what and when. ## Ask Mango anywhere in the app Administrators reach Mango from the **user menu** (your name, bottom-left) — click **Support** on any page and ask the way that suits you: pick a suggested question for the page you're on, type your own, or **just talk** — Mango converses by voice too, so you can think out loud while you work. The conversation opens in the corner and leaves the moment you close it, so nothing floats over your work between conversations. If Mango can't hold a conversation right now, the Support dialog says so plainly, keeps the routes to the help center and support, and restores itself automatically when service returns. What makes this Mango special is that she answers from **your own tenant's data**, not generic documentation: * **Catalog and pricing** — your product catalog, plans, charges, and plan pricing, so *"what does the annual tier of our advanced plan cost?"* gets a real answer. * **Journeys** — your configured [journeys](/product/journeys-and-pages/journey-basics/journeys-overview), their steps, routing, and the commerce actions on each step — handy for *"why does our cancellation flow skip the offer step?"*-style questions. * **Live journey activity** — recent journey-session activity in aggregate (statuses, outcomes, where sessions are in the flow). Customer identity and captured form data are **deliberately excluded** from what Mango can see; for individual-customer investigations she'll point you to the journey's session view in the app instead. * **Retention analytics** — cancellation and save-rate figures computed from the very same source as the app's **Retention** analytics tab, so Mango's numbers can never disagree with what's on your screen. Two things to know about how this is built: * **Strictly read-only.** Mango's in-app knowledge tools can look things up but can never change anything — she can explain and diagnose your configuration, but plans, journeys, and rules stay exactly as you left them. At worst a confused question gets a wrong answer, never a wrong action. * **Tied to you.** Each conversation is bound to your tenant and your user, so if you later contact support about the same issue, the team can see the context and pick up where Mango left off. ## Learn how to work with her This page is the introduction. For the working detail — every way to open Mango, the tenant data she can read, how the propose-and-approve build flow works on components, pages, and rules, and where her boundaries are — see [Working with Mango](https://docs.peakcommerce.com/guides/guide-working-with-mango). ## Mango always asks first Mango is quick and a little cheeky, but she never goes rogue. Every change she suggests is a **proposal you approve** before it takes effect — so you get the speed of an eager problem-solver with a human always in the loop. Clever, hungry, and honest to the core. 🥭 # Project Prep Project Prep is the short, ordered sequence that gets you and your team ready to start your PeakCommerce implementation — before the real configuration work begins. The goal is simple: arrive at your kickoff call with your data, your project team, and your platform access already in place, so the first working sessions go straight to building instead of setup. Work through these four steps in order: 1. [What Should I Expect During Onboarding?](/product/getting-started/project-prep/1.-what-should-i-expect-during-onboarding) — the shape of onboarding, from the Success email cadence through your requirements review. 2. [Getting Ready for Your PeakCommerce Project](/product/getting-started/project-prep/2.-getting-ready-for-your-peakcommerce-project) — prepare your data, materials, and project team ahead of kickoff. 3. [Org Provisioning & Adding Users](/product/getting-started/project-prep/3.-org-provisioning-and-adding-users) — claim your tenant and invite your team in **Settings → Users**. 4. [Intro to Support](/product/getting-started/project-prep/4.-intro-to-support) — how help works during implementation and after you go live. New to the platform? Start with [What is PeakCommerce?](/product/getting-started/what-is-peakcommerce) for the bigger picture first. # 1. What Should I Expect During Onboarding? **Overview** Whether you're a new PeakCommerce customer or thinking about partnering with us, let's review what you can expect during your onboarding and setup process. New customers are automatically enrolled in our Success Onboarding email cadence, which will introduce you to pre-project planning plus support and training resources. **Getting Ready for Your PeakCommerce Project** Before you do anything else, we encourage you to review our "Getting Ready Guide". This guide has sections covering everything from prepping your data, to ensuring your materials and models are prepped for your project, and identifying your project team. **Org Provisioning & Adding Users** Your org will be automatically provisioned on the start date of your contract, and an invite will be sent to your designated admin. For security reasons, we ask that your admin add any additional users to your organization. Instructions on how to do so can be found here. **Support** Your admin will be sent an invite to our Support community around the time your project kicks off. Make sure to register for the Support portal ASAP, as the link does expire! **Requirements Checklist** During your onboarding call, we will review your SOW and the dates associated with each one of your deliverables. Please review your SOW and come prepared to discuss your ability to deliver the requirements on the timeline outlined. **Configuration** If configuration rules are a part of your project, you can review our Configuration Workbook We will answer any of your questions during your onboarding call. # 2. Getting Ready for Your PeakCommerce Project The single biggest factor in a smooth implementation is how prepared you are when the project starts. PeakCommerce builds on your existing Salesforce and Zuora systems, so the configuration we do together is only as good as the data, pricing, and decisions you bring into it. Time spent preparing now is time you won't lose to rework later. To help, our Implementation Team has captured its best practices in the **Getting Ready Guide** — a structured walkthrough of everything to line up before kickoff. We strongly recommend reviewing it as a team while there's still room to gather what's missing. **What the guide helps you prepare** * **Your data** — clean, current customer, account, and subscription records, and a clear picture of what lives in Salesforce versus Zuora. * **Your catalog and pricing** — the plans, products, add-ons, and pricing models you intend to sell, so they can be reflected in your catalog. * **Your project team** — the people who'll own decisions during the project: an executive sponsor, a project lead, and the business and technical contacts who know your billing and CRM setup. * **Your commerce experiences** — a rough sense of the checkout, self-service, and sales-assisted flows ("journeys") you want to launch first. **Who and when:** review this before your onboarding call, ideally with your full project team in the room. Bring open questions to your Customer Success Manager or Implementation Team — that's exactly what kickoff is for. **Gotcha:** don't wait for the platform to be provisioned to start this. Data cleanup and team alignment are the long poles; they can and should begin immediately. **Next step →** Once your team and data are lined up, move on to [Org Provisioning & Adding Users](/product/getting-started/project-prep/3.-org-provisioning-and-adding-users). # 3. Org Provisioning & Adding Users Before anyone can explore PeakCommerce or start configuration, your organization needs its own tenant and your team needs sign-in access. This step gets both in place. **Provisioning your org** Your PeakCommerce org (tenant) is provisioned automatically around the start date of your contract. Your designated administrator receives an email invitation to claim it — click the link and follow the prompts to set up the account. Sign-in is handled by **Auth0**, so you'll be prompted to set your own password; PeakCommerce never sees or stores it directly. **Who and when:** for security, only your designated admin should claim the org and set up the initial account. Everyone else joins by invitation afterward. **Adding your team** Once you're signed in, the admin invites everyone who needs access — including your PeakCommerce project team members — so the org is ready for collaboration: 1. Open the **user menu** (your name, bottom-left) → **Settings → Users**. 2. Click **Add User** (top right). 3. Enter the person's details and assign them a **Role** and a **Profile**. Each user gets two settings that work together. The **Role** — **Admin**, **CSR**, **Partner**, or **Customer** — sets which portal they land in and their broad experience. The **Profile** fine-tunes exactly what they can see and do within that role. New users receive an Auth0 email to set their own password, so you never handle credentials for them. You can add or remove users from **Settings → Users** at any time. **Gotcha:** the role alone doesn't grant detailed permissions — the profile does. A teammate with the right role but a thin profile may still be missing access they expect, so pick the profile deliberately. For the full picture, see [Users & User Roles](/product/using-peakcommerce/users-and-user-roles). **Next step →** With your team in place, learn how help works in [Intro to Support](/product/getting-started/project-prep/4.-intro-to-support). # 4. Intro to Support Knowing where to turn for help — and how that changes as you move from implementation to going live — keeps your team unblocked at every stage. **During implementation** While you're building, your **Implementation Team** is your primary point of contact. They run your project, answer configuration questions, and guide you through your requirements and timeline. Lean on them for anything project-specific as you stand up your catalog, journeys, and integrations. **After you go live** Once your implementation is complete and you're live on the platform, we formally transition you from the Implementation Team to our **Support Team**. You'll be introduced to the people who become your primary contact for day-to-day questions and ongoing help with product features and functionality as new needs arise. **Getting help in the app** Day to day, the fastest way to reach us is **in-app Support**, available right inside PeakCommerce. Use it to ask a question or report an issue without leaving your work — your message reaches our support team, and you can pick the conversation back up from the same place. **Who and when:** your admin is invited to our Support community around the time your project kicks off. Register promptly — the invitation link expires, and registering early means your team has the channel ready the moment a question comes up. **Gotcha:** don't wait until you're stuck to set up access. Confirm your admin has accepted the Support invite during kickoff so nothing is blocked later. That completes Project Prep. From here, move into [Setting Up Your Platform](/product/getting-started/setup) to begin configuring — connecting your billing system, building your catalog, and launching your first storefront. # Setting Up Your Platform With your team and data ready — see [Project Prep](/product/getting-started/project-prep) — you're set to configure PeakCommerce. Setup follows the platform's dependency chain, so each step builds on the one before it: > **Catalog → product set → journey → storefront** (under your **domain**), with **Rules & Automation** as the guardrails. Work through these steps in order: 1. [Connect Your Billing System](/product/getting-started/setup/1.-connect-your-billing-system) — link Zuora, Stripe, Maxio, or any billing system so your plans and charges flow in. 2. [Build Your Catalog](/product/getting-started/setup/2.-build-your-catalog) — organize what you sell and assemble a product set. 3. [Your First Storefront](/product/getting-started/setup/3.-your-first-storefront) — create a journey that sells your product set. 4. [Going Live](/product/getting-started/setup/4.-going-live) — point your branded domain and launch. New to the platform? Start with [What is PeakCommerce?](/product/getting-started/what-is-peakcommerce) for the big picture first. # 1. Connect Your Billing System PeakCommerce is built to run on top of your existing billing system — most often **Zuora** — as the source of truth for your plans, charges, and subscriptions. Connecting it is the foundation of setup: once linked, your **catalog syncs directly from billing**, so what you sell in PeakCommerce mirrors what you actually bill, without re-entering pricing by hand. **What connecting gives you** * **A synced catalog** — your plans and their charges flow into PeakCommerce, ready to sell. * **Write-back** — commerce actions like checkout and subscription changes post to your billing system. * **Alignment over time** — as your billing catalog changes, PeakCommerce stays in step. **How to connect** 1. Open **Settings → Integrations**. 2. Choose your provider. PeakCommerce connects **Zuora**, **Stripe**, **Maxio**, and others — or any billing system. 3. Add a connection and enter its credentials. 4. Run an initial **catalog sync** so your plans appear under **Commerce → Product Catalog**. **Who and when:** connecting a provider needs credentials from that system, so have them on hand — or bring the question to kickoff. Your Implementation Team can help with Zuora-specific configuration. **Gotcha:** until a billing system is connected and synced, your catalog will show no plans. That's expected — the catalog is populated *from* billing, not entered by hand. **Learn more:** see the **Integrations** documentation for provider-specific setup (including Zuora Billing), and [Billing & Catalog settings](/product/settings/billing-catalog) for sync and cache controls. **Next step →** With billing connected, [Build Your Catalog](/product/getting-started/setup/2.-build-your-catalog). # 2. Build Your Catalog Your **catalog** is what you sell. In PeakCommerce it has three layers: **products**, the **plans** that package them, and the **charges** that price those plans. With your billing system connected, these sync in automatically — so building your catalog is mostly about **organizing what synced into something customers can buy**. {% embed url="" %} **Products, plans, and charges** * **Products** are the things you offer. * **Plans** package a product into a sellable tier — for example Free, Premium, and Ultimate. * **Charges** define how a plan is priced — recurring, usage-based, or one-time. Review these under **Commerce → Product Catalog**. **Assemble a product set** A **product set** is the purchasable grouping a customer actually chooses from — a base plan, its add-ons, and options, presented together. A journey sells a product set, so this is the bridge between your catalog and your storefront. 1. Go to **Commerce → Product Sets** and create a set. 2. Add your base plans and any add-ons or options. 3. Save. Your set is now ready for a journey to sell. **Learn more:** [Products & Bundles](/product/using-peakcommerce/products-and-bundles) · [Product Sets](/product/using-peakcommerce/products-and-bundles/product-sets). **Next step →** [Your First Storefront](/product/getting-started/setup/3.-your-first-storefront). # 3. Your First Storefront A **journey** is the experience that sells a product set — a checkout, a signup flow, or a self-service portal. This is where your catalog becomes something a customer can actually buy. {% embed url="" %} **Create a journey** 1. Go to **Content → Journeys** and create a new journey. 2. Choose the type — for a storefront, an **e-commerce** journey. 3. Point it at the **product set** you built. This coupling is what the journey sells. **Give it a page** A journey is built from **pages**, composed in the low-code editor. Add the pages your flow needs — a plan picker, a checkout, a confirmation — and arrange the steps. > **Note:** the page editor is available to system administrators. If you don't see it, ask your admin to grant access or to build the pages with you. **Publish** When the journey and its pages look right, **publish** so the storefront is live and ready to serve customers. **Learn more:** [Journey Basics](/product/journeys-and-pages/journey-basics) · [Ecommerce & Payment Pages](/product/using-peakcommerce/ecommerce-and-payment-pages). **Next step →** [Going Live](/product/getting-started/setup/4.-going-live). # 4. Going Live With a published journey selling your product set, the last step is making it reachable under your own brand and turning it on. {% embed url="" %} **Point your branded domain** By default your storefront runs on a PeakCommerce URL. To serve it under your own domain: 1. Go to **Settings → Domains** and add your hostname. 2. Map it to the surface it should serve — your storefront journey, or your account portal. 3. Follow the prompts to verify the domain. **Activate** Set your journey's status to **active** so it's live to customers, and confirm its pages are published. Pointing a domain and activating a journey are the load-bearing "go-live" steps — they change what real customers see, so do them deliberately. **A quick launch checklist** * Billing connected and catalog synced. * Product set assembled with the right plans and add-ons. * Journey points at the product set; pages published. * Branded domain mapped and verified. * Journey set to active. **Learn more:** [Domains](/product/settings/organization/domains). **You're live.** For ongoing help, see [Intro to Support](/product/getting-started/project-prep/4.-intro-to-support) — and explore the rest of the documentation to go deeper on pricing, self-service, rules, and more. # Overview The **customer portal** is the signed-in space where your customers manage their own account, subscriptions, billing, and support. It's assembled from configurable [customer portal pages](/product/journeys-and-pages/pages) and powered by [Customer Self-Service journeys](/product/journeys-and-pages/journey-basics/journeys-overview), so the experience matches your brand and the actions you choose to expose. This section covers what the portal is, how customers reach it, and how it fits together: * [Customer portal overview](/product/customer-self-service/overview/customer-portal-overview) — how the portal works end to end. * [What is the customer portal?](/product/customer-self-service/overview/what-is-the-customer-portal) — the capabilities at a glance. * [Access the customer portal](/product/customer-self-service/overview/access-the-customer-portal) — sign-in, sign-up, and SSO. # Customer Portal Overview The **customer portal** is your customer's signed-in, self-service home in PeakCommerce. It gives each account holder one place to manage their subscriptions, billing, account details, and support — without opening a ticket or waiting on a CSR. Because every screen is configurable, the portal you ship reflects your brand, your catalog, and the exact actions you want customers to be able to take on their own. This matters because self-service deflects support load while giving customers the control they expect. ## How it works Customers reach the portal at your portal domain and sign in through **Auth0** (or your own IdP / SSO if connected). After login they land on **My Subscription**, the default view of their active plans. From there they can move between the portal pages you've published. The portal is assembled from **Portal-type pages** built in [Content → Pages](/product/journeys-and-pages/pages). Each page is composed of configurable blocks — for example an account header, subscription cards, a billing summary, invoice history, payment methods, and usage meters — so you control what each customer sees and in what order. Self-service **actions** (change plan, add or remove add-ons, renew, cancel) don't run as hard-coded buttons; they execute as [Customer Self-Service journeys](/product/journeys-and-pages/journey-basics/journeys-overview). That keeps pricing, eligibility, and retention logic configurable rather than fixed — see [customer subscription management](/product/customer-self-service/subscription-management/customer-subscription-management) and the [retention journey](/product/customer-self-service/subscription-management/customer-retention-journey). ## Who it's for & admin view The portal is for your end customers. Admins can preview what a customer sees by opening the customer from the **user menu** (your name, bottom-left) → **Settings → Users** and using the impersonation / login-as option — useful for troubleshooting and CSR assistance. **Gotcha:** which actions a customer can take is gated by [portal action permissions](/product/using-peakcommerce/profiles-and-permissions/portal-action-permissions), so a published page may still hide or disable a control if the account's profile lacks it. ## Next steps * [What is the customer portal?](/product/customer-self-service/overview/what-is-the-customer-portal) * [Access the customer portal](/product/customer-self-service/overview/access-the-customer-portal) # What is the customer portal? The **customer portal** is where customers manage their accounts and subscriptions with PeakCommerce. It gives customers a single place to: * **Manage their account** — contact details, billing info, and payment methods. * **Manage subscriptions** — view plans, upgrade or downgrade, add or remove add-ons, renew, or cancel. * **See billing** — invoices and payment history, and pay invoices. * **Get support** — view and open support cases (when a support integration is connected). It is built from customer **portal pages** (Content → Pages) and powered by **Customer Self-Service journeys** for actions like plan changes and cancellations — so the whole experience is configurable, not fixed. # Access the Customer Portal Customers sign in at your portal domain. Authentication is handled by **Auth0** (or your own IdP / SSO if connected). * **New customers** sign up on the portal's hosted login / sign-up page. Depending on your setup, sign-up may ask for an email and password (and sometimes a billing account number to link an existing account). * **Returning customers** sign in with their credentials, or via SSO / social login where enabled. * **Forgot password** is handled by Auth0's reset flow. This is separate from signing up through an e-commerce checkout journey, which creates the account as part of the purchase. # Account Management In the customer portal, the **My Account** area lets signed-in customers view and update their own account — contact details, billing information, and payment methods — with every change writing through to your billing system. What each customer can see and do is governed by their [profile](/product/using-peakcommerce/profiles-and-permissions/portal-action-permissions). See [Customer Account Management](/product/customer-self-service/account-management/customer-account-management) for the full walkthrough. # Customer Account Management The **My Account** area of the customer portal is where signed-in customers keep their own account details current — without raising a support case or waiting on a CSR. Letting customers self-serve their contact, billing, and payment details reduces failed payments and stale records, and keeps your billing system as the single source of truth. ## What customers can view and do * **Contact information** — the name, email, phone, and address on the account (billing and sold-to contacts), shown from the customer's live billing record. * **Billing details** — billing address, account/billing name, and a summary of the current plan, next billing date, and cost breakdown. * **Invoices** — the account's invoice history, with each invoice **downloadable as a PDF** straight from the list. * **Payment methods** — view saved methods (card type, last four, expiry, default badge), **add** a new method, **remove** one, and **set a default**. Adding a card is completed on a secure hosted payment page, so raw card data never touches PeakCommerce. ## Managing payment methods Each saved payment method that is **not** the current default carries an actions menu with two options: * **Make default** — promotes that method to the account's default; future charges use it. * **Remove** — deletes the saved method. Removal always asks for confirmation first, since it can't be undone. The **default** method deliberately has no actions: it can't be removed or demoted directly. To retire it, make another saved method the default first — the old default then gets its own actions menu, including Remove. This guarantees the account always has a usable default on file. Both actions honor the customer's [portal-action permissions](/product/using-peakcommerce/profiles-and-permissions/portal-action-permissions): a profile without the update permission won't see **Make default**, and one without the delete permission won't see **Remove** — so you can offer a fully read-only payment view where that's appropriate. ## How it works These views are built from Portal-type pages and their blocks (for example the payment-method manager and billing summary). Changes write through to your billing system rather than being stored only in the portal, so what the customer sees and what billing charges stay in sync. ## Who it's for / permissions Every signed-in customer reaches **My Account**, but what they can see and change is governed by their [profile](/product/using-peakcommerce/profiles-and-permissions/portal-action-permissions) — portal-action permissions can show a section read-only or hide an action entirely. Admins can review a customer's account by impersonating them from the **user menu** (your name, bottom-left) → **Settings → Users** (see the [portal overview](/product/customer-self-service/overview/customer-portal-overview)). ## Gotchas * Payment-method changes depend on a configured hosted payment page; without one, adding a card won't complete. * Invoice PDFs are generated by the billing system **after** an invoice posts, so the document for a just-issued invoice may not exist yet. If a customer downloads too early they see a clear "Invoice PDF not available" message rather than a broken file — trying again a little later succeeds once the billing system has finished generating it. * Contact and billing edits reflect the billing record, so they may differ from CRM or marketing contacts elsewhere. ## Related * [Customer Portal Overview](/product/customer-self-service/overview/customer-portal-overview) * [Customer Subscription Management](/product/customer-self-service/subscription-management/customer-subscription-management) * [Portal Action Permissions](/product/using-peakcommerce/profiles-and-permissions/portal-action-permissions) * [Payments & Payment Methods](/product/using-peakcommerce/payments-and-payment-methods) # Subscription Management The **My Subscriptions** area of the customer portal lets customers manage their own subscriptions — view plans, change them, renew, and cancel — through configurable Customer Self-Service journeys, and see their consumption on usage-based plans. Use these pages to understand what customers can do for themselves and how to shape those flows. * [What Is Subscription Management?](/product/customer-self-service/subscription-management/what-is-subscription-management) * [Customer Subscription Management](/product/customer-self-service/subscription-management/customer-subscription-management) * [Customer Retention Journey](/product/customer-self-service/subscription-management/customer-retention-journey) * [Usage Information in the Customer Portal](/product/customer-self-service/subscription-management/customer-portal-usage-information) * [Mastering the Subscription Management Process](/product/customer-self-service/subscription-management/mastering-the-subscription-management-process) # Customer Subscription Management **My Subscriptions** is the heart of the customer portal — it's where your customers manage what they've bought without contacting support. Giving customers a clean, self-service way to upgrade, add on, renew, or cancel reduces support load, speeds up expansion revenue, and gives customers the control they expect from a modern subscription product. ## What customers can do The page lists each active subscription with its plan, add-ons, price, billing period, and renewal date. From there, depending on what you've enabled, a customer can: * **Change plan** — upgrade or downgrade to a different plan. Timing (immediate vs. end-of-term), proration, and which plans are offered are governed by your [business rules](/product/rules-and-customizations/rules-overview/creating-and-managing-rule-sets). * **Add or remove add-ons** — adjust optional products on the subscription. * **Renew** — extend a termed subscription. * **Cancel** — start a cancellation, optionally routed through a [retention experience](/product/customer-self-service/subscription-management/customer-retention-journey) that captures the reason and offers a save (discount, pause, or downgrade) before the cancellation completes. ## What the order summary shows When a customer changes plans, an **order summary** sits alongside the plan picker and updates **live** with every edit — select a different base plan, adjust a quantity tier, toggle an add-on, and the summary recalculates immediately. It's organized as a clear before → after story in three zones:
The customer portal change-plan page with plan cards on the left and a live order summary on the right showing current products, the resulting products with per-line price changes, and the prorated amount due today

Changing a plan in the customer portal — the order summary shows what the customer has now, what they'll have, per-line changes, and the real prorated Due today.

* **Products you have now** — a read-only snapshot of the current base plan and add-ons at today's prices, totalled as **Current monthly**. This zone never changes while the customer edits, so there's always a stable "before" to compare against. * **Products you'll have** — the resulting lineup after the change: the new (or kept) base plan, retained add-ons, and anything newly added. Each line shows its resulting monthly price with a per-line change indicator — a **New** badge for additions, or a **+/−** amount showing exactly how much that line moves versus today's bill (add-ons priced as a percentage of the plan re-price automatically when the base changes). Every changed line has its own **remove** control, and a removed current add-on stays visible struck-through with an **Undo** link, so any edit can be reversed before confirming. The zone totals to a **New monthly** subtotal, and a timing banner states whether the change is an upgrade (**effective today, prorated for this cycle**) or a downgrade (**starts next billing period, nothing due today**) — or, when the customer is editing a plan that's already scheduled to start later, a neutral notice instead (see below). * **Due today** — the real, prorated amount that will be charged now, calculated live by your billing system's order preview for the days remaining in the current cycle (tax included). It reads **$0** when nothing has changed — and also for downgrades, during a free trial, and **whenever the customer is editing an already-scheduled plan**, since nothing is charged today in any of those cases. While the preview is being calculated the summary says so rather than showing a misleading full-month figure, and if live pricing is briefly unreachable, the exact amount is confirmed before the customer pays. ### When a plan is already scheduled Sometimes a subscription has a plan **queued to start later** — most commonly a paid plan waiting behind a free trial, or a change already committed for the next term. The portal renders that queued state explicitly rather than pretending it's the current plan: * In the plan picker, the queued plan's card shows a **clock badge — "Starts {date}"** — instead of a Current badge, and its card action reads **Scheduled** rather than a select button. * In the order summary, the "after" zone's heading changes: it reads **"Already scheduled"** when the customer hasn't edited anything, and **"Your schedule will be"** once edits are pending — in both cases captioned **"Starts {date}"**. * When the customer does make an edit, a **neutral banner** appears: *"Your scheduled plan is changing · still starts {date} · nothing due today."* It's deliberately not styled as an upgrade or a downgrade — it's neither, because the edit changes what happens on the scheduled date, not today's bill. * **Due today is $0 whenever the customer is editing a scheduled plan** — unconditionally. No proration applies, because nothing changes before the start date. * Edits target the **scheduled** plan, not the one still running: confirming swaps what starts on the scheduled date while the current plan runs untouched until then, and the swap **keeps the original start date**. After the customer confirms, a completion screen confirms the change — **"Your plan is updated"**, naming the new plan (and quantity tier, when relevant) and letting them know a **receipt is on its way by email** — with a button back to My Subscription. ## Cancelling — and changing your mind Most cancellations are **scheduled, not instant**: the subscription ends at a future effective date (typically the end of the current term), and the customer keeps full access until then. The portal is built to make that state — and the way back out of it — unambiguous. ### "Scheduled for {date}" — what the customer sees When a cancellation is scheduled for a future date, the subscription card shows **"Scheduled for {date}"** directly under its status badge. This caption is doing real work: the billing system reports a future-dated cancellation as **Cancelled immediately**, even though service continues for weeks or months. Without the date, a customer who cancelled effective end-of-term would see "Cancelled" today and reasonably conclude they've already lost access. The caption is what tells them access continues until that date. (Once the effective date has passed, the cancellation is historical and the date no longer shows — the subscription is simply cancelled.) ### Revoking a scheduled cancellation Customers change their minds — and while the cancellation hasn't taken effect yet, there's a genuine window to keep them. If you've enabled it on your [retention journey](/product/customer-self-service/subscription-management/customer-retention-journey), an eligible customer sees a **revoke strip** on the subscription card during that window: *"Cancellation scheduled for {date} — service continues until then. You can still revoke this cancellation"*, with a one-click **Revoke Cancellation** button. What happens next depends on the account's state: * **Eligible** — clicking the button opens a confirm dialog that lays out exactly what revoking means: the subscription (by number), the scheduled cancellation date and how many days remain, and the resulting state (**Active**, auto-renewing on that date, on the current plan and price). An **eligibility checklist** confirms the two preconditions are met — all invoices paid, and the cancellation not yet effective — and notes the action is recorded on the account timeline. No new order or charge is created; confirming simply removes the scheduled cancellation. * **Blocked — unpaid invoice** — if any invoice on the account is unpaid, the button is disabled and the strip shows the **outstanding amount** with a link to **Billing & Invoices** (see [account management](/product/customer-self-service/account-management/customer-account-management)) so the customer can settle up and come back. Once the balance is paid, the revoke unblocks. * **Blocked — billing can't be read** — if the portal can't verify invoices right now, revoking is **withheld rather than guessed** (fail-closed). The strip says billing can't be verified; the customer can retry once it's reachable. An unreadable gate never reads as "eligible." * **Success** — after confirming, the strip flips to a confirmation: the cancellation is revoked, the subscription **stays active and auto-renews** on its normal date, and the action was recorded on the account timeline. After a revoke, the subscription simply **continues on its current plan and terms** — same price, same renewal date, nothing re-provisioned and nothing charged. **Good to know about revoking:** * The window is real: a cancellation is revocable **only while its effective date is in the future**. The billing system enforces the same window when the revoke is committed, so there's no race at the boundary. * Revoking has its **own permission** — **Revoke Scheduled Cancellation** — independent of Cancel Plan, so being able to cancel doesn't automatically mean being able to un-cancel (or vice versa). Unlike the on/off Change and Cancel grants it has **three levels**: **no access** (the default) hides the revoke experience entirely, **view** shows the cancellation-scheduled banner — including why a revoke is currently blocked — but no button, and **manage** shows the **Revoke Cancellation** button. See [portal action permissions](/product/using-peakcommerce/profiles-and-permissions/portal-action-permissions). * If the strip doesn't appear at all: the feature isn't enabled on the retention journey (it's off by default), the billing integration doesn't support it, or the customer's profile grants **no access** (or only **view**) on Revoke Scheduled Cancellation — in those cases the card shows the standard pending-cancellation banner instead. ## How it's powered Each action runs as a configurable [Customer Self-Service journey](/product/journeys-and-pages/journey-basics/journeys-overview), so you control the steps, pages, and the [commerce actions](/product/journeys-and-pages/journey-steps/commerce-actions) that execute the change in your billing system (and write it back to PeakCommerce). The portal binds each button to the right journey by its [purpose](/product/journeys-and-pages/journey-settings/journey-purpose) (`change_plan`, `cancellation`), so you can redesign or rename a journey without breaking the link. > **Builder note — wire the commit actions, or Confirm commits nothing.** The confirm button on the summary step only *advances the journey*. The plan change itself is committed by the **commerce actions configured on that confirm/summary step** — `record_order` + `update_order`. If those actions aren't configured there, confirming sails through to the completion screen **without changing the subscription**. Also remember that journeys run their **published snapshot**: after changing a journey's configuration, republish it for the change to take effect for customers. ## Who can do what Which actions appear is controlled by the customer's profile. **Change Plan** and **Cancel Plan** are [separate permissions](/product/using-peakcommerce/profiles-and-permissions/portal-action-permissions), so you can, for example, let a customer cancel but route upgrades through a CSR, or offer a read-only "managed customer" who can view and pay but not change anything. ## Good to know * Self-service actions write through to your billing system in real time; a failed external call surfaces to the customer rather than silently dropping. * A subscription only shows the actions its journeys and the customer's permissions allow — if a button is missing, check the journey's purpose binding and the profile's portal-action permissions. ## Related * [Customer Retention Journey](/product/customer-self-service/subscription-management/customer-retention-journey) * [Customer Portal Overview](/product/customer-self-service/overview/customer-portal-overview) * [Journeys overview](/product/journeys-and-pages/journey-basics/journeys-overview) # What Is Subscription Management? Subscriptions come with great promise: the promise to build customers for life, and drive predictable growth. But promises are not reality, and building a subscription business is no guarantee that you’ll realize its benefits. Enter subscription management. It puts your subscription business on a launchpad. Then it lights a flame. Below we’ll look at how subscription management helps CFOs and CROs create world-class buying and paying experiences — driving loyalty, renewals, and growth. #### Why is subscription management important? Point yourself in the direction of your dream: a subscription business that hums with predictable growth. That only happens when customers continue to renew. Subscription management makes this possible. It helps you create easier and faster experiences — from buying the product to using it and paying for it — that keep your customers active. In one-time sales, you hit your targets by acquiring new customers. But in a recurring revenue business — like those that run on subscriptions — revenue depends on retaining existing customers who pay on time and renew. That’s the goal of subscription management — keeping your customers engaged so you achieve top-line subscription growth. #### Customer retention is the key to subscription growth. Imagine this: A customer has to call up a sales rep every time they want to buy a subscription. Then, when they want to make a change request, they have to call up a sales rep again — who calls up finance. Clunky. In the background, the system is clunky, too. Teams wrestle with spreadsheets to manually update invoices and apply credits. With subscription management, the scenario looks different. The same customer would buy and update their subscription instantly and online. They could also choose to engage with a sales rep to seek extra help. Updates like pricing changes are applied to the bill automatically. It’s a string of positive interactions that leads to happy customers and renewals. There’s a lot that subscription management handles in the background to make this possible — bringing customer data into one place, replacing disconnected tools with one platform for every team, and running automation and AI-powered analytics throughout. But what it all comes down to in the end is experience. #### Subscription management improves customer experiences across the business. Customer experience is everyone’s job now. As you interact with your customers constantly, not just here and there, subscription management helps you deliver delight from every corner of the business, so customers are happy to buy and pay. # Mastering the Subscription Management Process Subscription management solutions provide a seamless experience for customers, from the initial purchase to adoption and renewal. These solutions utilize behind-the-scenes processes and technology to automate the flow of data across various aspects such as product catalog management, order management, fulfillment, and billing. The billing process is particularly crucial as it represents a close interaction with customers. It is the moment when the value promised is evaluated, and whether customers are satisfied with the service. The success and growth of a business depend on customers answering "yes" to these questions. Implementing a subscription management solution can help achieve this positive outcome. Let's explore how it functions from start to finish, specifically within Salesforce's framework. 1. **Empowering B2B Shopping Across Platforms**: Customers now have the freedom to purchase B2B products through any medium, even self-service. By leveraging easy setup tools, administrators can introduce subscription-based products alongside one-time offerings, allowing for diverse pricing structures. All these are conveniently made available on self-service platforms like your company's website, where customers can either make selections or connect with sales reps for guidance before finalizing their purchase. 2. **Sales Reps: The Backbone of Streamlined Transactions**: Whenever customers desire modifications to their orders prior to completion, sales representatives can access the subscription management tool to swiftly adjust the transaction details. Whether it's tweaking product quantities or introducing special discounts, reps can ensure customers receive the most optimized deals. This quick turnaround ensures that no opportunity is lost, guaranteeing maximum revenue. 3. **Sales and Customer Success: The Duo Behind Subscription Longevity**: Subscriptions aren’t static; customers can adjust them as needed via self-service channels. Sales reps, supported by insightful data, can subtly guide customers toward renewing or upgrading their subscriptions. Backend teams benefit from a panoramic view of customer transaction histories and behaviors, while AI-driven tools suggest the most relevant offerings to pitch next. 4. **Efficient Invoicing and Timely Payments with Finance**: The evolving nature of customer subscriptions is seamlessly managed in the background. Be it order generation, invoicing, or payment application, everything is executed automatically. This flawless operation is attributed to the holistic integration of customer data throughout the subscription lifecycle, eliminating any chances of manual discrepancies that were once a chink in the sales-finance armor. With this system, finance teams can be rest assured that quotes align perfectly with invoices. # Customer Retention Journey When a customer starts a cancellation in the portal, you can present a **retention experience** instead of a plain cancel: ask why they're leaving (capturing the reason — for example to Salesforce) and offer save options such as a discount, pause, or downgrade before the cancellation completes. The customer can still choose to cancel. This is built as a **Customer Self-Service** cancellation [journey](/product/journeys-and-pages/journey-basics/journeys-overview): the cancel path routes through a reason step, retention/save-offer steps, and finally the cancellation. See [What you can build with journeys](/product/journeys-and-pages/journey-basics/journey-use-cases). ## Reasons & routing The reason step is configured with a dedicated **Reasons & routing** editor. In the journey builder, expand the cancellation-reason step and click **Edit reasons & routing**. There you can: * **Manage the reasons** customers can choose — add, edit, enable, or disable each one. * **Set each reason's value** — for custom (author-added) reasons you control the stored **value** separately from the label shown to the customer. The value is what gets stamped to your CRM and order custom fields (for example `CancellationReason__c`), so keep it stable and reporting-friendly. * **Route by reason** — choose whether **all reasons go to one step** (a single retention path) or each reason routes to its **own downstream step**, so "too expensive" can lead to a discount offer while "missing a feature" leads somewhere else. ## Save offers and discounts A retention journey can present a **discount save-offer step** — an offer card that shows the customer what they'd save by staying, with **Accept** applying the discount to their subscription on the spot. The offer itself is not hard-coded in the journey. It comes from the central **Offers catalog** (**Commerce → Offers**): the journey step references a subscription-discount offer, and the offer defines the discount's value, duration, guardrails, and the billing instrument it executes through. That separation means the team that owns pricing can tune the offer — change the percentage, tighten the caps, retarget the audience — without touching the journey, and the same offer can back several journeys. See [Offers & Discounts](/product/using-peakcommerce/products-and-bundles/offers-and-discounts) for how offers are defined. The offer's guardrails are enforced **at accept time, against live billing state** — not just when the card is shown: * **Per-customer usage caps** (with a lifetime or rolling-window cap basis) and **cooldowns** are checked server-side from the redemption ledger; a customer who has hit their cap sees the flow route past the offer. * **Conflict scope** re-reads the subscription's current discounts from the billing system in the last moment before the discount is written. Billing has many writers — finance, CPQ, other self-service surfaces — so this live check is what stops a second discount stacking on one that arrived between showing the offer and the customer accepting it. If the subscription can't be read, the apply fails closed rather than risking a stack. * The **re-offer window** lets the offer surface again shortly before a blocking discount is scheduled to end, so a customer nearing the end of a previous save discount can be saved again. **Trials are handled honestly.** If the customer accepts a discount while still in a free trial, the discount doesn't apply to the $0 trial period — it is parked and **activates automatically when the paid subscription begins**, and the flow shows the customer the price and the date the discount will start. The parked discount counts as active for conflict checks, so re-running the cancel flow during the trial can't stack another one. ## Allowing customers to revoke a scheduled cancellation Retention doesn't end when the customer clicks cancel. Because most cancellations take effect at a **future date**, there's a window — often the rest of the term — in which a customer who has second thoughts can simply un-cancel. Retention and cancellation journeys carry a setting for exactly this: **Allow revoking a scheduled cancellation** (**off by default**). Enabling it lights up a **Revoke Cancellation** strip on the subscription card wherever a future-dated cancellation is pending — on the **customer portal** *and* on the **agent console** subscription card, so a CSR taking a "please don't cancel me after all" call has the same one-click action the customer does. The customer-facing side of the flow (confirm dialog, eligibility checklist, blocked states) is described in [Customer Subscription Management](/product/customer-self-service/subscription-management/customer-subscription-management). What the setting buys you, and its built-in guardrails: * **The setting is only the first gate — a permission is the second.** Enabling the journey setting doesn't by itself put the button in front of anyone: the viewer's profile must also grant **Revoke Scheduled Cancellation** (on customer profiles) or **Revoke Customer's Scheduled Cancellation** (on CSR and sales profiles) — a three-level grant that **defaults to no access** on customer, CSR, and sales profiles alike. **View** level shows the cancellation-scheduled banner (including why a revoke is currently blocked); only **manage** level shows the Revoke button. See [portal action permissions](/product/using-peakcommerce/profiles-and-permissions/portal-action-permissions). * **Built-in precondition: every invoice paid.** Revoking is only offered when the account has no unpaid invoices; an outstanding balance blocks the action and shows the customer the amount due. If invoices can't be read, the action is withheld rather than guessed (fail-closed) — an unreadable billing state never counts as eligible. * **Executed in the billing system, recorded on the account.** The un-cancel is a real billing-system operation — it removes the scheduled cancellation so the subscription continues on its current terms, with **no new order and no charge** — and it is written to the account's **audit trail and timeline**, so there's always a record of who revoked what, and when. * **The window is enforced twice.** The strip only appears while the cancellation's effective date is in the future, and the billing system rejects a revoke of an already-effective cancellation at commit — so there's no race at the boundary. * **Only where supported.** The action is offered only when the billing integration supports un-cancelling; otherwise the card keeps its standard pending-cancellation banner, with or without the setting. The setting lives on the journey **bound to the cancellation purpose** — the same journey that produced the scheduled cancel — so the surface that scheduled the cancellation is the one that decides whether it can be revoked. ## Recording the cancellation When the customer does cancel, the journey's [commerce actions](/product/journeys-and-pages/journey-steps/commerce-actions) run a `cancel_order` action that cancels the subscription via the Orders API and **maps the captured reason into the cancellation record** (and your CRM), so every cancellation carries its reason for reporting and win-back. # Customer Portal Usage Information For usage-based and metered plans, the customer portal shows customers their **current consumption** alongside their subscriptions — so they can see exactly what they're drawing down and what they're being billed for, with no need to call in. That transparency reduces "bill shock," cuts support contacts, and helps customers self-manage before they hit a limit. ## What the customer sees Each metered charge appears in a **Current period usage** card with a line per charge — the charge name and a `used / included` reading in its unit of measure (for example `1,200 / 5,000 API calls`), plus a progress bar showing how much of the allowance is consumed. The card header shows the billing period and **days remaining** in it. Charges without an included allowance are labelled **Pay-as-you-go** (the consumed total shows with no bar), and a charge consumed past its limit is flagged as overage. ## How it works Usage is metered and rated by your billing system and read back through the platform's usage API, then surfaced on the customer's subscription view — customers never see raw meter events, only the rolled-up drawdown. If a subscription has no metered charges, the card shows a quiet empty state ("No metered usage on this subscription"); if the usage read fails it shows "Usage data unavailable" rather than a wrong number. Whether the usage card appears on a given portal page is a page-configuration choice, so you decide where — and for which audiences — consumption is shown. ## Related * [Customer Subscription Management](/product/customer-self-service/subscription-management/customer-subscription-management) * [Customer Portal Overview](/product/customer-self-service/overview/customer-portal-overview) # Support Management In the customer portal, the **My Cases** area lets customers view and open support cases — available when a support ticketing integration is connected for the tenant. These pages cover what customers can do there and how it's gated. * [Customer Support Management](/product/customer-self-service/support-management/customer-support-management) # Customer Support Management Giving customers a place to raise and track issues inside the portal keeps support self-service — they don't have to leave the product or dig up an email address, and every request lands in the same system your support team already works in. ## What the customer sees and does When a support ticketing system is connected, customers manage their requests from **My Cases** in the customer portal: * **View cases** — see their open and past cases with current status. * **Open a case** — click **Add Case** to submit a request; a support rep follows up. If a customer has no cases yet, the page shows a friendly empty state inviting them to open their first one. ## How it works My Cases is backed by your connected **support & service integration**, so cases created in the portal flow into — and stay in sync with — that external system (the customer never leaves the portal to file one). If no support integration is connected for the tenant, the support area has nothing to show and is effectively unavailable, so connect your support tool first. ## Who can see it What a customer can do in this area is governed by their [profile](/product/using-peakcommerce/profiles-and-permissions) — profiles control which portal areas and actions are available, so My Cases can be shown or withheld per audience. ## Related * [Customer Portal Overview](/product/customer-self-service/overview/customer-portal-overview) * [Profiles & permissions](/product/using-peakcommerce/profiles-and-permissions) # Partner Portal Overview The Partner Portal gives your channel partners — resellers, agencies, and referral partners — a dedicated, co-branded workspace to manage the customers assigned to them and their own account. Partners are a **role type** in PeakCommerce: they sign in to a focused portal rather than the full admin app, and everything they see is scoped to their book of business. This lets you run an indirect sales channel without giving partners visibility into other partners' customers or your internal operations. ## Key concepts * **Partner role** — a user whose portal type is *Partner*. The role determines which portal they land in and which permissions apply. * **Assigned accounts** — the cohort of customer accounts a partner can see and act on. Assignment is driven by **Territory Rules** and/or manual assignment (see [Partner Administration](/product/partner-portal/administration)). * **Partner Channel** — the admin-side area (sidebar group) where staff configure and monitor the channel: **Commission Structures** and **Channel Analytics**. ## What a partner does * **Manage assigned customers** — view each assigned account's contacts, subscriptions, and invoices, and make subscription changes on the customer's behalf. * **Change and cancel subscriptions** — within the limits of their permissions (see *Who can do what* below). * **Manage their own subscription** — partners with their own billing account can view and manage it under *My Subscription*. * **See performance and earnings** — partners can review their accounts and commissions; staff see channel-wide totals and a partner leaderboard under **Channel Analytics**. ### Accounts and Account Detail The partner **Accounts** list and **Account Detail** pages now match the same depth support staff have on the internal CSR account-detail page — contacts, subscriptions, billing & invoices (with payment methods, payment history, refunds, and credit memos), timeline, subaccounts, and audit trail — scoped to a partner's own assigned accounts. These are the partner's own pages (own components, own Puck blocks, own endpoints under `/api/partner-account/*`), so they can be tailored per-tenant over time independently of the CSR experience they were originally cloned from. Access still follows the same Territory Rule / manual-assignment scoping and portal-action permissions described below — cloning the CSR view didn't change *who* a partner can see, only *what they can do* once an account is in view. Expect to walk permissions back for most tenants: a fresh partner profile currently has CSR-equivalent capability (including actions like issuing refunds or deleting payment methods) until an admin tightens the **Partner Default** profile's grants to what that partner channel actually needs. ## Who can do what A partner's access is scoped by their **partner profile** (record access limited to accounts assigned to them) and by **portal-action permissions** — change-plan and cancel-plan are *separate* grants, so you can let a partner upgrade/downgrade plans without allowing cancellations, or vice versa. See [Portal Action Permissions](/product/using-peakcommerce/profiles-and-permissions/portal-action-permissions) and [Partner Users](/product/using-peakcommerce/users-and-user-roles/partner-users). ## Gotchas * A partner sees an account **only** once it's assigned to them — a customer with no matching Territory Rule and no manual assignment is invisible to every partner. * Change vs. cancel are independent. If a partner can't cancel, confirm the cancel-plan permission, not just change-plan. ## Setting up partners 1. Create partner users with the **Partner** role and a partner profile ([User Roles](/product/using-peakcommerce/users-and-user-roles/user-roles)). 2. Assign each partner their customers — see [Assigning Accounts to Partners](/product/partner-portal/administration/partner-realms). 3. Configure earnings under **Partner Channel → Commission Structures**. ## Related * [Partner Administration](/product/partner-portal/administration) * [Customer Management](/product/partner-portal/customer-management) * [Partner Users](/product/using-peakcommerce/users-and-user-roles/partner-users) # Administration Standing up the partner channel has three parts, all configured by staff in the admin app: * **Partner users** — create users with the **Partner** role and a partner profile, so they sign in to the Partner Portal with the right record scope (see [Partner Users](/product/using-peakcommerce/users-and-user-roles/partner-users) and [User Roles](/product/using-peakcommerce/users-and-user-roles/user-roles)). * **Account assignment** — give each partner their cohort of customers via **Territory Rules** and manual assignment (see [Assigning Accounts to Partners](/product/partner-portal/administration/partner-realms)). * **Commissions** — define how partners earn under **Partner Channel → Commission Structures** (percentage or flat, channel-wide or per partner/product). Monitor the channel under **Partner Channel → Channel Analytics** — partner totals, revenue, commissions, and a leaderboard. ## Related * [Partner Portal Overview](/product/partner-portal/partner-portal-overview) * [Customer Management](/product/partner-portal/customer-management) # Assigning Accounts to Partners Each partner acts only on the **accounts assigned to them** — their book of business. This boundary is what keeps an indirect channel safe: partners never see each other's customers, and they never see accounts outside their cohort. Getting assignment right is the foundation of the whole Partner Portal, so it's worth understanding both ways accounts reach a partner. ## How assignment works PeakCommerce determines a partner's accounts two ways, which combine: * **Territory Rules** (under **Rules & Automation → Territory Rules**) — rules that match customer accounts by attributes such as region, locale, or segment and route them to a partner. As accounts match a rule, they join that partner's book of business automatically. This is the scalable path: define a Northwest territory for one partner and a Southwest territory for another, and new matching customers fall into place without manual work. * **Manual assignment** — you can assign a specific account to a partner directly, for one-off or exception cases that no rule covers. Both feed the same scope: a partner's view is the union of rule-matched and manually assigned accounts. You can preview a Territory Rule before saving it to see which accounts it would match. ## Who manages this Staff with permission to manage **Territory Rules** create and edit the rules; account assignment also respects each partner's **profile record scope** ("created by or assigned to them"), which is what enforces the boundary at view time. Together, the rule decides *who gets the account* and the profile scope ensures *only that partner sees it*. ## Gotchas * **An unmatched account is invisible.** If a customer matches no Territory Rule and has no manual assignment, no partner can act on it — check rule conditions first when a partner reports a "missing" customer. * **Rules are evaluated against current account attributes.** If you change how territories are defined, a partner's cohort can shift; preview before saving. * Territory Rules govern *visibility and assignment* — what a partner can *do* with an assigned account (change vs. cancel) is controlled separately by [Portal Action Permissions](/product/using-peakcommerce/profiles-and-permissions/portal-action-permissions). ## Related * [Partner Administration](/product/partner-portal/administration) * [Customer Management](/product/partner-portal/customer-management) * [Partner Users](/product/using-peakcommerce/users-and-user-roles/partner-users) * [Profiles & Permissions](/product/using-peakcommerce/profiles-and-permissions) # Customer Management Partners use the portal to work their book of business: finding a customer fast, reviewing where each account and subscription stands, and — with the right permissions — acting on a customer's subscription. Everything here is scoped to your assigned accounts. You only ever see and act on the accounts assigned to you through Territory Rules and manual grants, enforced on the server. What you can do (view, change, cancel) is set by your **Partner** profile. In this section: * [Account and Subscription Summary Reports](/product/partner-portal/customer-management/account-and-subscription-summary-reports) — live account and subscription summaries pulled from billing. * [Customer Search](/product/partner-portal/customer-management/advanced-customer-search) — find an assigned account by name or number within a large cohort. Related: * [Partner Portal Overview](/product/partner-portal/partner-portal-overview) * [Assigning Accounts to Partners](/product/partner-portal/administration/partner-realms) * [Portal Action Permissions](/product/using-peakcommerce/profiles-and-permissions/portal-action-permissions) # Account and Subscription Summary Reports To advise a customer well — or to act on a subscription for them — you first need a clear, current picture of where that account stands. The partner portal gives you live account and subscription summaries pulled from billing, so what you see matches what the customer is actually billed. ## Account summary **My Accounts** lists every customer assigned to you, each row backed by a real-time read from the billing system: * **Account name** and **account number** * **Billing status** (for example, Active) * **Current balance** (with currency) * **Active subscription count** * **Assignment** — whether the account reached you by a territory rule or a manual grant Open an account to drill into its detail: **Bill To** and **Sold To** contacts (name, email, phone, address), the account's subscriptions, and an **Invoices** tab listing open invoices. Contact fields are editable inline when your permissions allow. ## Subscription summary From an account's detail you can review each subscription and its rate plans, then open one to manage it. With the **Change Customer Subscriptions** or **Cancel Customer Subscriptions** permission, you can drive an upgrade, downgrade, or cancellation on the customer's behalf through a partner journey. For roll-up performance and earnings across your whole book of business — rather than a single account — use **Partner Channel → Channel Analytics**. ## Who can see this These summaries are scoped to your assigned accounts: you only see accounts assigned to you through Territory Rules and manual grants, enforced server-side. Visibility and edit rights come from your **Partner** profile. ## Gotchas * Figures are read live from billing. If a value is blank or shows a dash, the billing integration may be momentarily degraded — your assignment list still loads. * Acting on a subscription requires the specific portal-action permission; viewing a summary does not grant the right to change or cancel it. ## Related * [Customer Search](/product/partner-portal/customer-management/advanced-customer-search) * [Partner Portal Overview](/product/partner-portal/partner-portal-overview) * [Portal Action Permissions](/product/using-peakcommerce/profiles-and-permissions/portal-action-permissions) # Customer Search When you work a large book of business, the slowest part of helping a customer is finding them. The partner portal's customer search lets you jump to the right account in seconds, without paging through your whole list. ## What you can search From **My Accounts** in the partner portal, type into the search box to filter your assigned accounts by: * **Account name** (the billing or display name) * **Account number** (the customer's external billing account ID) Matching happens as you type, and results stay paged so a large cohort stays manageable. Each row shows the account name, account number, billing status, current balance, the number of active subscriptions, and how the account was assigned to you (by **rule** or granted manually). Select a row to open the account, where you can review contacts, subscriptions, and open invoices — and, with the right permission, change or cancel a subscription on the customer's behalf. ## How scope works Search never reaches outside your assigned accounts. The portal only ever searches the accounts assigned to you — the cohort defined by your **Territory Rules** plus any manual grants — and that scope is enforced on the server, not just hidden in the UI. You cannot find or open an account that isn't yours, so it's safe to search freely. ## Who can use it Customer search is available to any user with the **Partner** role whose profile grants read access to partner account assignments. The accounts that appear are governed by your profile's record scope and your territory assignments. ## Gotchas * Search matches **account name and account number** only. To narrow by status, balance, or subscription count, scan or sort the columns in the results. * If billing details (status, balance, subscription count) show as blank or a dash, the billing integration may be temporarily degraded — the account list still loads from your assignments. * No results usually means the account isn't assigned to you yet. Confirm its territory assignment with an admin. ## Related * [Account and Subscription Summary Reports](/product/partner-portal/customer-management/account-and-subscription-summary-reports) * [Partner Portal Overview](/product/partner-portal/partner-portal-overview) * [Assigning Accounts to Partners](/product/partner-portal/administration/partner-realms) * [Portal Action Permissions](/product/using-peakcommerce/profiles-and-permissions/portal-action-permissions) # Customer Success Portal Overview The customer success portal is the workspace for **CSRs** (and customer-success / account-executive roles) to manage customer accounts on a customer's behalf — looking up accounts, reviewing subscriptions, running changes, and handling support cases. ## What CSRs can do * **Find and view accounts** — search the accounts they're responsible for and open a customer's details and subscriptions. Accounts are reachable from the **global header search** anywhere in the app or from the filterable **Your Accounts** list — see [Finding Accounts](/product/customer-success-portal/finding-accounts). * **Work a single account** — the account detail page collects the customer's identity (including a link to their record in your CRM), key metrics, subscriptions, billing history, payment methods, and any journey work in flight — see [Working with an Account](/product/customer-success-portal/working-with-an-account). * **See the whole history** — the account's **Timeline** merges lifecycle events, plan changes, billing activity, retention flows, and staff notes into one staff-only feed, with notes that can also be logged to your CRM — see [The Account Timeline](/product/customer-success-portal/account-timeline). * **Navigate account hierarchies** — a **Subaccounts** subtab lists the account's children straight from the billing system's own hierarchy, with one-click navigation into each — see [Working with an Account](/product/customer-success-portal/working-with-an-account). * **Act on a customer's behalf** — run plan changes, cancellations, and other tasks via **CSR Self-Service** [journeys](/product/journeys-and-pages/journey-basics/journeys-overview). * **Handle cases** — view and manage support cases pulled from your connected support system. A CSR's reach is scoped by their [role and profile](/product/using-peakcommerce/users-and-user-roles/user-roles) — record access can be limited to, say, only the accounts assigned to them. Admins can view a CSR's workspace by impersonating them from the **user menu** (your name, bottom-left) → **Settings → Users**. # Finding Accounts PeakCommerce gives customer-success teams two complementary ways to reach a customer account: a **global search** in the header that works from anywhere in the app, and the **Your Accounts** list — a filterable, sortable workspace view of every account you're responsible for, topped by summary tiles that surface the accounts worth looking at today. Both are **permission-gated and territory-scoped**: you only ever see the accounts (and other records) your [role and profile](/product/using-peakcommerce/users-and-user-roles/user-roles) allow. ## Global search — from anywhere The search box in the header is available on every page. Press **⌘K** (Mac) or **Ctrl+K** (Windows/Linux) to jump into it, or just click it and start typing — results appear after the second character. **Finding an account.** Accounts match on **billing name**, **account number**, **external account id**, or **CRM id**, and each account result shows the CRM id and account number under the name so you can confirm you have the right one. Selecting an account result takes you **straight into that account's workspace** — no detour through the list. **Other record types.** The same search also reaches **organizations, contacts, orders, subscriptions, conversations, products, and users**, with results grouped by type. Each type is gated by the *same* permission that guards its own page — if your profile can't read contacts, contact results simply don't appear. There's no separate "search permission" to manage, and no way for search to show you more than the corresponding page would. **Territory scoping.** For CSRs (and partners) whose record access is limited to assigned accounts, account and order results are filtered to that accessible set. Record types that can't be tied to a specific account are withheld from territory-scoped users entirely — search fails closed rather than leaking anything cross-territory. **Recent searches.** When you focus the empty search box, your recent searches appear for one-click reuse. History is **private per user** — your searches are never visible to teammates, and theirs are never visible to you. **Keyboard driving.** Arrow keys move through results, **Enter** opens the selected one, **Esc** closes the dropdown. ### Global search gotchas * Some result rows are **informational for your role** — shown so you know the record exists, but not clickable because no detail page exists on your surface (hovering explains this). For example, an admin who isn't a CSR can see account matches but has no account workspace to open them in. * Results need at least **two characters** — a single letter won't search. ## The "Your Accounts" list The accounts list is the workspace home: every account you can access, ranked, searchable, and filterable, with the page you're viewing hydrated live from the billing system so figures are current.
The Your Accounts workspace with four summary tiles (live and nightly), a search box, filter chips, and a sortable accounts table with CRM ID, MRR, and churn-risk columns

The Your Accounts list — live tiles (Active accounts, In a retention flow) beside nightly-scan tiles, with search, filter chips, and sortable Net MRR / CRM-id columns.

### Search, filters, and sorting * **Search** matches across **name, account number, or CRM ID** (it also matches status, billing system, and other visible column values), narrowing the list as you type. * The **Filters** button opens a condition builder for precise, multi-condition queries (AND/OR groups over account fields). Applied conditions show as **chips** above the table — remove one with its **×**, add more with **+ Add filter**, or **Clear all**. Applied filters are carried in the page URL, so you can bookmark or share a filtered view as a deep link. * **Columns are sortable** — click a header to sort ascending, again for descending, and a third time to clear. Blank values always sort last so empty cells never crowd the top. Sortable columns include **Net MRR** and the **CRM id**, alongside name, status, balance, renewal date, subscription count, and churn risk. Admins can tailor which columns appear (including extra billing-system fields) when configuring the page. ### The summary tiles Four tiles above the list give you a working read on your book of business. They come in two kinds, and the distinction matters: | Tile | Kind | What it counts | | ----------------------- | ------------------------------ | ------------------------------------------------------------------------------------------------- | | **Active accounts** | Live | Accounts currently active in the billing system. | | **In a retention flow** | Live (badged **Live**) | Accounts with an active cancellation / save journey session right now — a real-time churn signal. | | **No usage reported** | Nightly (badged **◷ Nightly**) | Active accounts the most recent scan found no usage for — "active but idle." | | **Trials ending soon** | Nightly (badged **◷ Nightly**) | Trials whose end date falls in the next 14 days. | The two **live** tiles are computed in real time on every visit. The two **nightly** tiles read signals from an **opt-in nightly scan**; when the scan is enabled, the tile shows when it last ran (for example "scan 3h ago") so you know how fresh the number is. If the scan isn't enabled for your organization, the tile shows an em dash and **"Not currently tracked"** — that's a configuration state, not a zero. Enabling the scans is an admin action, so if you want those signals, ask your administrator. ### Accounts-list gotchas * A **"Not currently tracked"** tile doesn't mean no idle accounts or no ending trials — it means the nightly scan is switched off, so the signal isn't being collected. * Nightly numbers are **as of the last scan**, not this second. Check the scan timestamp on the tile before acting on a borderline count. * The list only contains accounts within your territory scope. If an account you expect is missing, it's usually a [record-access](/product/using-peakcommerce/profiles-and-permissions/access-levels-for-permissions) question, not a data problem. ## Related * [Customer Success Portal Overview](/product/customer-success-portal/customer-success-portal-overview) * [Working with an Account](/product/customer-success-portal/working-with-an-account) * [User Roles](/product/using-peakcommerce/users-and-user-roles/user-roles) # Working with an Account The account detail page is the CSR's single-account workspace: everything about one customer — identity, key financial metrics, subscriptions, invoices, payments, and any journey work in flight — on one screen, so a rep on a call never has to tab between systems. Open it by selecting an account from the [accounts list or global search](/product/customer-success-portal/finding-accounts). ## The account header The header shows the account name, its account number, the billing system it lives in, and its status, with a breadcrumb back to **Accounts**. Below it, a five-tile metric strip gives the financial picture at a glance: **Net MRR**, **Next Billing**, **Balance**, **Customer Since**, and **DSO**. Hover a tile's info icon for a plain-English explanation of the figure and where it comes from — DSO's tooltip, for example, reads *"The average days customers take to pay this account's invoices, based on matched invoice and payment pairs"*, and when no matching pairs exist it says the figure can't be calculated (the tile shows **N/A**) rather than showing a number it can't back up. If any of the account's subscriptions is scheduled for cancellation, a banner at the top of the page says so — including the effective date — so no one runs a change on an account that's already on its way out without knowing it. The subscription card itself carries the same fact in miniature: a **"Scheduled for {date}"** caption directly under the status badge. And when the retention journey's revoke setting is enabled **and the rep's profile grants Revoke Customer's Scheduled Cancellation** (default none; **view** level shows the banner, **manage** level shows the button), an eligible scheduled cancellation shows a revoke strip right on the card, so a rep can undo the cancellation before the date arrives — the counterpart of the cancellation flows described in [Customer Subscription Management](/product/customer-self-service/subscription-management/customer-subscription-management). Scheduled **plan changes** get the same explicit treatment. When a subscription has a plan queued to start later — a paid plan waiting behind a trial, or a change already committed for a future date — the subscription card and the change-plan rail show **"Starts {date}"** on the queued plan, and the rail's before/after zones read **"Already scheduled"** (nothing edited yet) or **"The schedule will be"** (edits pending). Editing swaps the queued plan while **keeping its original start date**, and nothing is due today — the rep is changing what happens on the scheduled date, not the current bill. ## The Customer card The **Customer** card in the sidebar collects the account's identifying details: primary email, billing system, external account number, the **CRM id**, and how long they've been a customer (plus a fraud/risk score when one is available). When your organization has a CRM integration connected (for example Salesforce), the CRM id renders as a **link that deep-links straight to the account's record in your own CRM instance** — one click from the PeakCommerce workspace to the CRM record, opened in a new tab. The link targets *your* CRM domain, not a generic login page, so it lands directly on the record. If the account carries no CRM id, the row shows an em dash — the field is always present so the card reads consistently across accounts. ## In-flight changes When a [journey](/product/journeys-and-pages/journey-basics/journeys-overview) — a plan change, a cancellation/save flow — is started on this account and not finished, it surfaces on the relevant subscription card. Without that, a half-completed wizard would be invisible: the session stays alive server-side, but nobody would know to go back to it. How sessions render depends on whose they are and how many there are: * **Your own resumable sessions stay pinned as full banners**, tagged **YOURS**, showing the journey, the step you're on, and when you last touched it — with a prominent **Resume** button. Your sessions never get compressed away. * **One or two other sessions** (started by other CSRs, or by the customer) render as dense rows beneath. * **Three or more other sessions collapse into a single collapsible strip** per subscription: a one-line summary ("2 plan changes · 1 cancellation in progress"), a count badge, a facepile of who started them, the oldest start date, and a call-out when any have gone stale. Expand the strip to see every row. Each row shows the actor, **who is driving it** (a CSR or the customer), when it started, its last activity, and a **type chip** — **Plan change**, **Cancellation**, **Add-on change**, or **Other change**. When an expanded strip contains mixed types, **type filter chips** appear so you can look at, say, just the cancellations. ### Resume, Dismiss, Abandon — and View A row's **actions menu** (⋮) offers up to three actions, plus a read-only view: * **Resume** — appears only when the session is resumable *by you*: it's your own session, for a journey your profile lets you run. Resuming reopens the flow at the exact step you left off, with everything already collected still in place. * **Dismiss** — hides the entry **just for you**. Dismissals follow your user account (they persist across browsers and devices), and other CSRs still see it. If the session later sees new activity, it **resurfaces** for you — a dismissed session that wakes up is news you want. * **Abandon** — **ends the session server-side, for everyone.** The session's status becomes abandoned, it disappears from every CSR's in-progress list, and it **cannot be resumed afterwards**. Use it when a session was started in error or is permanently stale. Abandonment is recorded in the session's history, so analytics and the audit trail reflect who ended it and why. * **View** — opens the session **read-only** (observe mode). Any same-tenant CSR or admin can watch exactly where a flow stands — which step, what's been chosen — without being able to advance it or touch the owner's progress. Useful when a customer calls mid-flow and asks "where was I?", and safe by construction: peeking cannot corrupt a live session. ### Stale sessions and bulk cleanup A session with no activity for **more than 14 days** is marked **stale**. The expanded strip's **Bulk** menu offers **Dismiss all** (cosmetic, just for you) and **Abandon stale (n)…** — which always confirms first, listing exactly which sessions it will end, because abandoning is terminal and global. Customer-driven sessions are an opt-in view per CSR (**Show customer activity**, visible only to roles with the observe capability), rendered in blue with a View-only button, so the page stays uncluttered for reps who don't co-pilot live customer flows. ### In-flight gotchas * **Dismiss and Abandon are very different.** Dismiss is cosmetic and personal; Abandon is terminal and global. If you only want the entry out of *your* way, Dismiss. * **Abandon can't be undone.** An abandoned session is gone for good — the customer or CSR would start the journey fresh. When in doubt, Dismiss instead. * **No Resume on a row?** Either the session belongs to someone else, or your profile isn't assigned to that journey. Use **View** to see where it stands. ## Payment methods The **Payment Methods** area lists the account's stored methods — card type, last four digits, expiry, status, and a **Default** badge — read straight from the billing system. What you can do with them is permission-gated: viewing requires the payment-methods read permission, and the write actions require update. * Each row's actions menu offers **Make default** and **Remove…** (with a confirmation). * **Add payment method** opens a modal that runs the **billing system's own hosted payment page** — the card details are entered on the billing provider's secure form and never pass through PeakCommerce. * Admins choose *which* hosted page the Add flow uses via the block's **integration-aware hosted-page picker** in the page editor — the picker lists the pages that belong to the account's billing integration. Leaving it blank uses that integration's default hosted page. ## Sub-accounts The **Subaccounts** subtab lists the account's children exactly as the billing system's own account hierarchy defines them — accounts that bill under this one. It's a read-only list of name, account number, status, and balance; each row's actions menu (⋮) offers **View Account**, which opens the child's own account detail page. Two honest limits: * The hierarchy read is available on **Zuora-backed accounts**. On other billing systems the tab plainly says sub-accounts aren't available for that billing system, rather than guessing at a hierarchy it can't see. A failed load likewise shows as an error with a Retry — never as "no subaccounts". * Creating a sub-account happens through a journey, not an inline form: a subscription card's **Manage → Create Subaccount** entry appears when an admin has authored a journey with the **create\_subaccount** purpose. The journey launches with the current account injected as the parent, and its confirmation step can show the newly created account's number. ## Timeline The **Timeline** subtab merges the account's entire history — lifecycle milestones, plan changes, billing events, cancellation/retention flows, and staff notes — into one staff-only feed, with a lifecycle stepper and a notes composer that can mirror into your CRM. It has its own page: see [The Account Timeline](/product/customer-success-portal/account-timeline). ## Acting on the account From the subscription cards you launch the CSR journeys themselves — change plan, cancel/save, and whatever else your organization has built for the CSR surface. The changes those flows commit are driven by the journey's [commerce actions](/product/journeys-and-pages/journey-steps/commerce-actions), and everything a rep does is attributed to the rep in the [audit log](/product/reporting-and-analytics/audit-trail-and-logs/audit-logs-overview). ## Related * [Customer Success Portal Overview](/product/customer-success-portal/customer-success-portal-overview) * [Finding Accounts](/product/customer-success-portal/finding-accounts) * [The Account Timeline](/product/customer-success-portal/account-timeline) * [Journeys Overview](/product/journeys-and-pages/journey-basics/journeys-overview) # The Account Timeline The **Timeline** subtab on the account detail page is the account's whole story in one staff-only feed: when the customer started, every plan change and its outcome, every invoice and payment, every cancellation flow they entered (and whether you saved them), and every note a teammate left — merged into a single stream, newest first. Instead of reconstructing "what happened with this customer" from four different tabs, a rep on a call scrolls one feed and knows. The timeline is the *curated* lifecycle view. The **Audit Trail** subtab remains the exhaustive record — every read, download, and low-level action. The timeline deliberately keeps only the events that tell the customer's story, and just as deliberately **includes failures**: a failed payment, a failed plan change, or a failed cancellation shows up with a red **Failed** badge, because a history that hides failures misreports the customer. Open it from any account — see [Finding Accounts](/product/customer-success-portal/finding-accounts) and [Working with an Account](/product/customer-success-portal/working-with-an-account). Everything on it is staff-only (the feed carries a "Staff only" badge); nothing here is ever shown to the customer. ## One feed, five families Every event belongs to one of five families, each with its own color and icon: | Family | What lands here | | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Lifecycle milestones** | Subscription started, subscription suspended, cancellation committed / revoked, billing contact updates | | **Plan & products** | Plan changes, quantity and frequency changes, add-ons added/removed, orders — including the failed variants | | **Billing & payments** | Invoice generated, payment received, payment failed (with the gateway's response), payment methods added/removed/set default, credit memos, invoice emails | | **Journeys & retention** | Cancellation flows started and completed — a completed flow whose outcome was a save (discount accepted, pause, expert booked) reads **"Cancellation saved"** with an "Offer accepted" badge; one that ended in a cancel reads "Cancellation completed" with the reason the customer gave | | **Staff notes** | Notes your team writes in the composer (below) | Each event shows who did it — a named staff member, **Customer**, or **System** — plus the timestamp, a reference number (subscription, invoice, or payment number) where one exists, and the amount when money moved. Changes with a before and after (quantity, frequency, plan) render a **from → to** delta pill so the change is legible at a glance. ## Filtering, search, and history depth * **Family chips** across the top filter to one family; each chip carries a live count, and the counts stay stable while a filter is active so you always see the full picture. The **Event types** legend in the right rail does the same thing. * **Search** matches event titles, actors, reference numbers, and event details. * **Date ranges** — All time, last 30 days, last 90 days, or this year. * The feed is grouped by **month**, newest first, and loads 50 events at a time — **Show earlier events** pages further back. ## The lifecycle stage and key milestones The right rail derives a stepper and a milestone card from the same data the feed already loaded — no extra billing-system calls: * **Lifecycle stage** — one of **Trial**, **Active**, **Active — recovering**, **Churn risk**, **Cancelled**, or **Suspended**, rendered as a stepper (trial end, conversion date, current state, next renewal). The states are deliberately honest: * **Recovering** means a cancellation flow ended in a save within the last 90 days. * **Churn risk** means the account entered a cancel flow that reached a terminal record without a save — genuine risk, not a completed loss. * **Cancelled is terminal.** It outranks everything (a cancelled trial reads Cancelled, not Trial), and the stepper stops projecting a next renewal — a renewal date on a churned account would tell you to expect money that isn't coming. A cancellation done *directly in the billing system* — which leaves no journey record at all — is still recognized, from the subscriptions themselves. * **Suspended** is not terminal: billing is paused but the relationship can resume. The step reads **"since {date}"** when the suspension date is known. * **Key milestones** — first activity, first subscription (by its human-facing number), last plan change, and **lifetime billed** (the sum of swept invoices). When a value isn't known it shows an em dash, never a fake zero or an invented date. ## Billing events come from an opt-in nightly sweep Invoice and payment events originate in your billing system, so the timeline reads them from a **local cache** that a nightly sweep keeps fresh — which means opening a timeline costs **zero billing-system API calls**, no matter how often reps look at it. * The sweep is **off by default** and enabled per workspace on **Settings → Billing Integration Cache**, on the **Account timeline billing-events sweep** card. You pick the hour it runs; a per-run call budget keeps a large account base from hammering the billing system (a very large tenant simply spreads across days). * **Run now** on the same card triggers an immediate sweep — it runs **asynchronously in the background**, so you don't sit on a spinner; the card's last-run time updates when it finishes. * Every sweep call is attributed to your workspace in **API Call Stats**, and a fetch failure for one account is logged and surfaced — never swallowed — before the sweep moves on. The timeline is honest about freshness. If billing events aren't being synced, a hint tells you where to enable the sweep — but that hint appears **only when the server has affirmatively said the sweep is off**. While the page is loading, or when the status read itself failed, the timeline stays silent rather than guessing: a failed read is not the same fact as "disabled", and telling a rep to enable a sweep that is already running would point them away from the real problem. ## Staff notes The composer at the top of the feed writes notes straight into the timeline. Notes are never shown to the customer. * **Categories** — General, 📞 Call, ✉️ Email, 🗓 Meeting, ⚠️ Escalation. The category renders as a chip on the note so a scan of the feed distinguishes "we talked" from "this is escalated". * **Pin to top** — one pinned note per account (the newest pin wins) renders as a persistent strip above the feed: the right place for "customer is migrating in May — don't upsell". Anyone with notes access can pin or unpin; pinning is curation, not authorship. * **Visibility** — **All staff**, or **your own team only**: the team tier matches the portal you're writing from (**CSR team**, **Sales team**, or **Partner team**). Team-only notes stay within that team's portal — a CSR-team note is not visible to Sales staff, and a Sales-team note is not visible to CSRs — with two deliberate exceptions: the note's author always sees their own note, and system administrators see everything. * **Edit and delete are author-only** — only the person who wrote a note can change or remove it, with no time limit either way. Edited notes carry an "edited" timestamp. * Every note action (create, edit, delete, pin) is also recorded in the [audit log](/product/reporting-and-analytics/audit-trail-and-logs/audit-logs-overview), so the exhaustive record stays exhaustive. ## Logging notes to your CRM When your organization has a CRM integration connected (Salesforce today), the composer's **Add note** button grows a split-button option: **Add note & log in Salesforce**. Your choice is remembered per account, so a rep who always mirrors doesn't re-pick every time. The option is offered only when it can actually work — the server checks that a CRM integration is **active** and that this account carries a **valid CRM record id**. A placeholder id (seeded and test accounts sometimes carry marker values in that field) is detected and named in the explanation, rather than offering a sync that could never succeed. What gets logged: * Every category logs a **completed Activity Task** against the account's CRM record — Calls as Call tasks, Emails as Email tasks, Meetings as Meeting tasks. It lands in the record's activity history as something that already happened, not as an open to-do in someone's queue. * **Escalation logs a High-priority Task — deliberately never a Case.** A Case is a workflow object that assigns owners, sends notifications, and counts against SLAs; a staff note must not fire any of that. High priority is what makes it stand out. And when the sync fails, you see it: the note itself is always saved first (a CRM outage never loses your note), and the failure renders on the timeline entry **in full** — the upstream error message, with a **Retry** button — never quietly dropped. A note that was saved without mirroring can be sent later from its **⋮** menu (**Log in Salesforce**). Retry is only offered while the target is still valid; if the account isn't actually linked, the timeline says that instead of offering a button that can only fail again. ## Every staff workspace sees the same timeline The identical Timeline component renders in the CSR, Sales, and Partner account workspaces as well as on the admin organization view, against the same account. A rep and an admin looking at the same customer see the same history, the same notes (subject to the team-visibility rules above), and the same composer — the surfaces cannot drift. ## Related * [Working with an Account](/product/customer-success-portal/working-with-an-account) * [Finding Accounts](/product/customer-success-portal/finding-accounts) * [Customer Success Portal Overview](/product/customer-success-portal/customer-success-portal-overview) * [Audit Logs Overview](/product/reporting-and-analytics/audit-trail-and-logs/audit-logs-overview) # Discounts and the Recurring Total Every subscription card shows a **Recurring total** at the bottom — the amount the customer pays each period once every discount is applied. Most of the time it needs no explanation. The moment it does is almost always the same moment: a subscription carries **two or more discounts**, someone adds the percentages together in their head, and the number on screen doesn't match. It isn't meant to. This article explains what the total represents, where its numbers come from, and walks through the cases that surprise people. ## Where these numbers come from PeakCommerce does not calculate discounts. It **reads the amounts the billing system says it will charge** and displays them. That distinction matters more than it sounds. Billing systems apply discounts according to their own rules — the order discounts were added, whether they stack, whether one discount applies on top of another's result, whether a charge is prorated this period. Those rules live in the billing system's configuration, and they can be changed there without anyone touching PeakCommerce. If we reproduced that logic here, our figure and the invoice would drift apart the first time a setting changed, and the customer would be told one number and billed another. So the rule is simple: **the invoice is the source of truth, and the card shows what the invoice will say.** One consequence is worth knowing up front: if you change a discount in the billing system, the card reflects it as soon as the change is committed — not on some refresh cycle of ours. ## It's a rate, not the next invoice The Recurring total is a **steady-state figure** — what this subscription costs in a full billing period. It is deliberately *not* the amount of the next invoice. Those two differ whenever a period is partial. A customer who signs up on the 26th of a month, on an account that bills on calendar months, gets a short first invoice covering 26th–31st only. The card still shows the full monthly rate, because that is what the subscription costs — a rate of "$1.67" would be true of six days and misleading about everything after them. To see what the customer will actually be invoiced next, use **Billing & Invoices**. *** ## Worked examples Every example below uses the same starting point: an **Essentials** plan at **$14.00 / month**. ### One discount A single **30%** discount. ``` Essentials $14.00 30% discount -$4.20 Recurring total $9.80 ``` Nothing surprising. 30% of $14.00 is $4.20. ### Two discounts — the one that catches people out Now add a second discount of **15%** alongside the 30%. The instinct is 30 + 15 = 45%, so $14.00 − 45% = **$7.70**. The card shows **$8.33**. ``` Essentials $14.00 30% discount -$4.20 ← 30% of 14.00 15% discount -$1.47 ← 15% of 9.80, not of 14.00 Recurring total $8.33 ``` The second discount is applied to what remains **after** the first, not to the original price. The effective combined discount is 40.5%, not 45%. This is a normal, deliberate billing-system behaviour, not an error — and it is the single most common reason a Recurring total doesn't match a mental calculation. Whether discounts combine this way or apply independently depends on how each discount is configured in the billing system, which is exactly why PeakCommerce reads the result rather than guessing at it. > **If a customer questions the figure**, the honest and correct answer is that the discounts apply in sequence. The invoice will show the same three lines. ### A discount that expires Discounts often run for a fixed number of periods. If the 30% discount above is set to last three billing periods, the total changes on its own when it lapses: ``` While both are active $8.33 / month After the 30% discount ends $11.90 / month ← 15% of 14.00 ``` Nothing needs to be done for this to happen, and no one gets a notification. If a customer calls about a total that "went up without warning," an expiring discount is the first thing to check — the subscription card shows each discount as its own line, so an expired one simply won't be there any more. ### A 100% discount used as a free trial Some teams grant a free period by applying a **100% discount** rather than setting prices to zero. Both approaches are valid, and they read differently on the card: ``` Essentials $14.00 100% discount -$14.00 Recurring total $0.00 ``` The plan and its price stay visible, which is usually what you want — the customer can see what they're getting and what it will cost when the discount ends. A subscription priced at zero instead would show $0.00 with no indication of the eventual price. ### A "negative discount" is a surcharge Some billing systems have no direct way to express a percentage-based *add-on*, so the convention is a discount with a **negative** percentage. A −20% "discount" is really a 20% markup. PeakCommerce renders these as what they are — a cost, not a saving: ``` Essentials $14.00 Premium support (20% of plan) +$2.80 Recurring total $16.80 ``` If you see a positive amount on a line that looks like a discount, this is why. It is adding to the bill, not reducing it. ### Metered and usage charges Usage charges are excluded from the Recurring total and called out separately beneath it ("Plus metered usage charges, billed in arrears"). They belong to what was consumed, not to what the subscription costs, and including them would make the headline figure move every time usage did. Usage charges still appear as their own rows on the card, with their rate and any included allowance, so nothing is hidden — it just isn't folded into a number that is meant to be stable. ### More than one billing cadence A subscription with both monthly and annual charges shows **two** Recurring totals, one per cadence. They are not blended into a single figure, because there is no honest way to express "$14 a month and $500 a year" as one number without inventing a conversion. *** ## When a total looks wrong Work through these in order: 1. **Count the discounts.** Two or more, and they almost certainly apply in sequence — see the worked example above. This resolves most questions. 2. **Check whether a discount has an end date.** An expiring discount changes the total with no other signal. 3. **Check whether the period is partial.** A mid-cycle signup, plan change, or cancellation produces a short invoice that will not match the monthly rate. Compare against **Billing & Invoices**, not the card. 4. **Look for a negative percentage.** A line that adds instead of subtracting is a markup, not a discount. 5. **Compare against the billing system directly.** The card shows what the billing system reports. If the two genuinely disagree, that is worth escalating — include the subscription number and what each side shows. ## Related * [Working with an Account](/product/customer-success-portal/working-with-an-account) — the account detail page these cards live on * [The Account Timeline](/product/customer-success-portal/account-timeline) — the history of changes to a subscription # Sales Portal Overview The Sales portal is the workspace for **sales reps** — a portal of its own, signed into with the **Sales** role, where a rep works their assigned **book of business**: the accounts an administrator has put in front of them. It is deliberately separate from the customer success portal. Sales and support start from similar capabilities, but they are different jobs, so each role gets its own portal, its own pages an admin can tailor, and its own permission profiles — access and screens can evolve for one team without touching the other. ## What sales reps can do * **Work an accounts list scoped to their book** — signing in lands on **Accounts**, a list containing exactly the accounts assigned to the rep. When the billing system behind the list is having trouble, the portal says so honestly — a banner names the system and suggests whether to retry or contact an administrator — rather than showing an empty list that reads as "you have no accounts." * **Open a full account workspace** — the account detail page mirrors the customer success workspace in depth: the account header and key financial metrics, a churn risk panel, and tabbed sections for **subscriptions**, **billing & invoices**, the **Timeline**, **Subaccounts**, and the **Audit Trail**. Rather than duplicate that documentation here: the workspace mirrors [Working with an Account](/product/customer-success-portal/working-with-an-account), and the Timeline is covered in [The Account Timeline](/product/customer-success-portal/account-timeline). * **Act on a customer's behalf** — launch self-service [journeys](/product/journeys-and-pages/journey-basics/journeys-overview) (plan changes, cancellations and saves) from within the account workspace. * **Leave notes the sales team can keep to itself** — see [Team-only notes](#team-only-notes-stay-with-the-sales-team) below. * **Build and send quotes** — once an administrator grants quote access on the Sales profile; see [Quotes](/product/sales-portal/quotes-overview) and [the access note](#quotes-in-the-sales-portal) below. ## Granting access Three things put an account list in front of a rep: 1. **The Sales role.** On the user record (**Settings → Users**), set **Role** to **Sales**. Sales users sign in to the Sales portal — not the customer success portal, and not the admin console. 2. **A Sales-role profile.** Every workspace ships with a seeded **Sales Default** profile that gives a new sales team similar coverage to support staff out of the box. It is managed independently — an admin can create additional Sales profiles (a senior/junior split, for example) exactly as for other roles. See [Profiles & Permissions](/product/using-peakcommerce/profiles-and-permissions) and [User Roles](/product/using-peakcommerce/users-and-user-roles/user-roles). 3. **A book of business.** Admins define which accounts each rep sees two ways, which combine: **territory rules** — condition-based rules evaluated against the billing system (for example, accounts above a balance or MRR threshold) — and **direct assignment** of individual accounts. An account outside the rep's book is not reachable: opening one shows *"This account isn't part of your assigned book of business. Ask an admin to assign it to you, or return to your accounts list."* If an admin removes an assignment while a rep has the account open, the workspace says so and returns them to the list — access changes take effect live, not at next sign-in. System administrators can also open the Sales portal directly, which is useful for verifying what a rep will see. ## Team-only notes stay with the sales team Notes written on the account Timeline carry a visibility choice: **All staff** or **your own team only**. In the Sales portal, "team only" means the **Sales team** — a sales-team note is not visible to CSR staff or partner users, and a CSR-team note is likewise not visible to sales reps. Two deliberate exceptions apply everywhere: the note's author always sees their own note, and system administrators see everything. So a rep can record deal context ("pushing for the annual plan, revisit in March") without it surfacing in a support interaction — and support can do the same in reverse. The full note feature set — categories, pinning, CRM logging — is documented in [The Account Timeline](/product/customer-success-portal/account-timeline). ## Tailoring the Sales portal's pages Sales is a first-class **portal type** in the page editor, so what reps see is buildable, not fixed: * The **Pages** list in the admin console has a **Sales Portal** filter alongside Customer, CSR, and Partner. * Three Sales pages are seeded for every workspace — **Sales Dashboard** (metrics, the assigned-accounts list, and a journey launcher), **Sales Search**, and **Sales Account Detail** — and an admin can edit them or add new ones. * The editor offers a dedicated **Sales component set** (account list, account header, churn-risk panel, subscription list, tabbed sections, and more), so a tailored Sales page composes from the same building blocks as the stock ones. ## Quotes in the Sales portal The quote screens — the list, the editor, and the send-for-approval flow — are wired into the Sales portal, but the stock **Sales Default** profile does not grant the **Quotes** resource, so a new rep won't see them until an administrator grants it (open the Sales profile's **Resource Permissions** and enable **Quotes**). That's a setup step, not a defect — it lets each organization decide whether reps quote directly. See [Quotes](/product/sales-portal/quotes-overview) for where quotes live and how the permission behaves. ## Current limits, honestly * **The navigation bar shows one tab today: Accounts.** The other Sales pages — search, analytics, the escalation queue, quotes — exist and work, but are reached from within flows and links (or from a link an admin adds to a tailored Sales page) rather than from the portal's navigation. * **The in-portal chat assistant is the billing assistant** — the same billing-focused agent the support portal uses. A Sales-specific assistant, once one is configured for the workspace, is picked up automatically. # Quotes A **quote** is a saved, priced proposal you build for a customer — the products and services they want, the term, the discount, and the amounts — that you can edit over time, send for the customer's approval, and later turn into an order of record. Because a quote is a durable document rather than an in-flight wizard, it can sit with a customer for days, come back for changes, and pick up internal approvals along the way without losing its history. ## Where quotes live * **The admin console** carries the primary surface: **Commerce → Quotes** in the sidebar. Administrators see every quote in the workspace. * **The Sales portal** has the same quote screens wired in, with two honest caveats. First, the stock **Sales Default** profile does not grant the **Quotes** resource — a sales rep can use quotes only after an administrator enables **Quotes** on their profile's **Resource Permissions** (see [Profiles & Permissions](/product/using-peakcommerce/profiles-and-permissions)). This is a setup step, not a bug: it lets each organization decide whether reps quote directly. Second, the Sales portal's navigation doesn't yet include a Quotes tab — reps reach the quote screens from links (for example, a link an admin adds to a tailored Sales page, or the portal's quotes address, `/sales/quotes`). Record access follows the usual scope rules: unless your profile grants full record access (as an administrator's does), the list shows **the quotes you own**. A quote belonging to another rep isn't just hidden from the list — opening it directly behaves as if it doesn't exist, so reps can't probe each other's pipelines. ## The Quotes list The list shows each quote in a single table: * **Quote** — the quote number (for example `Q-00042`) and the name you gave it. * **Status** — where the quote is in its life (see below). * **Total** — the quote's total value, in its currency. * **Term** — the contract term. One honest rough edge: the column currently renders the stored value as-is (for example `12_months`) rather than a formatted label. The list follows the console convention: rows don't click through. Use the **actions menu** (the `⋯` at the end of each row) to **Open**, **Edit**, or **Delete** a quote (delete asks for confirmation). To start a new quote, use the **New quote** button at the top of the list. ## Statuses A quote's status tells you, at a glance, where it stands: * **Draft** — being built; not yet sent to anyone. * **Pending approval** — held for internal sign-off because its discount exceeds the rep's authority ceiling (see [Creating & editing a quote](/product/sales-portal/creating-and-editing-quotes)). * **Sent** — shared with the customer for their approval. * **Accepted** — the customer has approved it. * **Declined** — the customer declined it. The decline is recorded on the quote; no one is notified automatically today, so watch the list. * **Processing** — the quote is mid-commit into an order. * **Completed** — the quote has been processed; it carries a reference to the order it produced. * **Failed** — the commit into an order errored. This is a real, visible status: the quote keeps the upstream error message, and the commit can be retried once the underlying issue is resolved — a failure is never silently swallowed. * **Expired / Cancelled** — no longer live. ## Related * [Creating & Editing a Quote](/product/sales-portal/creating-and-editing-quotes) * [Sending a Quote for Customer Approval](/product/sales-portal/sending-quotes-for-customer-approval) * [Sales Portal Overview](/product/sales-portal/sales-portal-overview) # Creating & Editing a Quote Building a quote takes two things: the **quote details** (who it's for and on what terms) and the **line items** (what they're buying, at what price and discount). This page walks through both, plus catalog pricing and the internal approval flow that guards large discounts. For the list view and statuses, see [Quotes](/product/sales-portal/quotes-overview). ## Start a new quote From the **Quotes** list, click **New quote**. That opens the full-page quote editor. (You need the **Quotes** permission on your profile — see [Quotes](/product/sales-portal/quotes-overview) for how access is granted.) The editor keeps a **sticky header** at the top as you scroll: the quote's name, a live **status badge** (green once processed, red if a commit failed), and the **Cancel** and **Save quote** buttons — so where the quote stands and how to save it are always in view. ## Quote details The top of the editor captures the terms of the deal: * **Quote name** — a short label so you can recognise it in the list (for example "Q3 expansion"). * **Billing account** — the customer's billing account identifier. * **Currency** — the currency the quote is priced in. * **Term** — the contract length (12, 24, or 36 months). * **Billing period** — how often the customer is billed (annual, monthly, quarterly). * **Order type** — what kind of order this quote will produce when processed: a **New order**, a **Change order** (a change to an existing order), or a **Renewal**. * **Expires** — the date after which the quote is no longer valid to the customer. ## Line items Below the details, add a row for each product or service: * **Product** — type a free-text name, or use the **catalog picker** (the book icon beside the name) to link the line to a **catalog plan**. A linked line shows the picker highlighted; choosing **Custom line** unlinks it and keeps whatever price you type. * **Qty** — how many. * **Unit price** — the price per unit. For a custom line this is always your number; for a plan-linked line it can be replaced by the catalog's price (below). Each row shows its **line total**, and the editor keeps a running **subtotal**. Use **Add line item** to add a row and the trash icon to remove one. ### Reprice from catalog When at least one line is linked to a catalog plan, a **Reprice from catalog** button appears. It's on-demand — repricing never happens behind your back. Clicking it saves your lines, then replaces the typed price on each plan-linked line with the catalog's authoritative price, and recomputes the totals **preserving your discount percentage** — a reprice never silently drops or changes the concession you set. Custom (unlinked) lines are left exactly as you entered them. Repricing is deliberately honest about what it can't price. It refuses — and names the affected lines in a warning panel — rather than fabricate a number, when: * **the plan can't be resolved** to a billable plan in the catalog; * **the plan has no priceable recurring charge** in the catalog; * **the line needs a live billing quote** — tiered/volume-banded charges, and display-only or passthrough charges, have no trustworthy single local price. Lines with warnings keep the price you typed; the warning tells you which ones to verify against a live billing quote. ## Discount and totals Below the line items, enter a **Discount %**. The editor shows the derived discount **amount** against the subtotal and the resulting **Total** live as you type. ## Internal approval — discounts over your authority When the workspace has a **discount authority ceiling** configured, a quote whose discount exceeds it is **held**: an **Approval** panel appears explaining the discount and the ceiling, and the quote cannot be sent to a customer or processed into an order until a teammate approves it. * **Request approval** raises a request; the quote moves to **Pending approval**. * **Two-person rule** — the request must be decided by a **different user** than the one who raised it. Self-approval is refused outright. * **The approval covers the granted discount only.** If you later raise the discount above what was approved, the quote **re-locks** and needs a fresh approval. Lowering the discount back within the approved amount (or within your own authority) clears the hold. * **A rejection** returns the quote to draft, but the gate stays closed — the rep either lowers the discount or gets a new request approved. * **No ceiling configured?** Then no discount is ever "over authority" and the panel never appears. * **Fail-closed.** If the authority policy can't be read, the quote stays held. A policy read failure never silently widens what a rep may give away. ## Save Click **Create quote** (or **Save quote** when editing) to store the quote, its line items, and its totals. Nothing is billed at this stage — saving a quote just captures the proposal, and the editor says so. ## Edit an existing quote Open any quote from the list's **actions menu** (**Open** or **Edit**) to come back into the same editor. Change the details or line items and save again; the totals update in the list. > **Gotcha — edits after sending.** There is no quote versioning live today: if you edit a quote **after** sending it, a customer who opens their still-un-actioned approval link sees the **current** state of the quote, not the state at send time. If the terms changed materially, tell the customer — don't rely on the link to carry history. See [Sending a Quote for Customer Approval](/product/sales-portal/sending-quotes-for-customer-approval). A quote that has been processed into an order shows that in the editor (with the order reference) and is kept as the record of what was agreed. # Sending a Quote for Customer Approval Once a quote is ready, you can put it in front of the customer as a secure link they open to review and **approve or decline without signing in** — no account, no password. This page covers sending the link, what the customer sees, and what happens on approval. For building the quote, see [Creating & Editing a Quote](/product/sales-portal/creating-and-editing-quotes). ## Send the link Open the quote and click **Send to customer**. The quote moves to **Sent** and a secure approval link appears in the editor with a **Copy** button. Two things to know, honestly: * **No email is sent.** "Send" mints the link and marks the quote sent — *you* share the link with your customer however you work (email, chat, your CRM). * **The link is valid for 14 days.** That's the link's own lifetime — long enough for a real sales cycle. The quote's **Expires** date is the business-level expiry the customer sees on the page; the two are separate. Clicking **Resend link** on a sent quote mints a fresh 14-day link any time. The link is signed and tied to that one quote. It never lets the customer see anything else in your workspace. You can also re-send a quote that was declined or expired — useful after revising the terms. > **Approvals first.** A quote whose discount is over your authority ceiling must be approved internally before it can be sent — the **Approval** panel on the quote explains the hold. A held quote can't go to a customer. > **Gotcha — edits after sending.** There is no quote versioning live today. If you edit the quote after sending, an un-actioned link shows the quote's **current** state, not what it looked like when you sent it. Re-copy the link and tell the customer when terms change. ## What the customer sees The link opens a clean page carrying your organization's name and the quote summary: each line item with its quantity (one-time items marked as such), the subtotal, the discount if there is one, and the total per billing period. There is no app navigation, and the page says plainly that nothing is charged until they approve. The customer can: * **Approve quote** — optionally typing their name to sign, then confirming; or * **Decline** — which records the decline on the quote. **A link is single-use by state, not by trickery:** only a quote in the **Sent** status can be acted on. Once it's been approved or declined — by this link or any earlier one — a second attempt gets a clear "already decided" response rather than a silent failure. The quote records who approved and when. > **Declines are recorded, not broadcast.** Declining marks the quote **Declined** — nothing more. No notification is sent to you or anyone else today, so keep an eye on your **Quotes** list for quotes you're waiting on. ## What happens on approval By default, an approved quote **routes back to you**: it's marked **Accepted** and waits for you to process it into an order when you're ready (**Process quote** in the editor). Automatic processing on approval — where acceptance immediately commits the order — is available on request via the API; there's no in-app setting for it today. Processing — whether you trigger it or it runs automatically — goes through **one guarded commit path** with the same safeguards either way: * **It produces an order of record** in PeakCommerce — a durable record of what was agreed. It does **not** create a subscription, an invoice, or a charge in your billing system; nothing is billed by processing a quote. * **It can't run twice.** A quote already processed refuses a second commit and points at the existing order — a double-click, or you and the customer's auto-process racing, can't create two orders. * **The over-authority gate still applies.** A discount that exceeds the authority ceiling can't slip through at commit time, even on the automatic path. * **Failures are visible.** If the commit errors, the quote moves to **Failed** with the upstream error message stored on it — never a silent drop. On the automatic path the customer's approval is still recorded (their intent is never lost); the commit can be retried once the issue is resolved. Either way, the outcome is always visible on the quote's status in the **Quotes** list. # Ecommerce & Payment Pages Your customer-facing pages — storefronts, checkout, payment, and confirmation — are built and managed in **Content → Pages** and composed from reusable [components](/product/using-peakcommerce/templates). Pages come in four types — **Checkout**, **Storefront**, **Payment**, and **Portal** — and most render as steps inside a [journey](/product/journeys-and-pages/journey-basics/journeys-overview). A page can also stand alone, like a hosted payment page a customer reaches from a billing email. Card capture always runs on the billing provider's hosted page, so sensitive details never touch PeakCommerce, and any page can be localized by language and currency through [Market Studio](/product/using-peakcommerce/market-studio). * [Create a Page](/product/using-peakcommerce/ecommerce-and-payment-pages/adding-an-e-commerce-page) * [External & Hosted Payment Pages](/product/using-peakcommerce/ecommerce-and-payment-pages/external-payment-pages) * [Updating Subscriptions Through Ecommerce](/product/using-peakcommerce/ecommerce-and-payment-pages/updating-subscriptions-through-e-commerce) * [Localizing Pages](/product/using-peakcommerce/ecommerce-and-payment-pages/translating-e-commerce-pages) # Create a Page Pages are the visual surfaces your customers actually interact with — the storefront where they pick a plan, the checkout where they enter details, the payment page where they pay, and the portal where they self-serve. Building them in **Content → Pages** keeps design, copy, and metadata in one place and lets you reuse the same page across multiple journeys instead of rebuilding it each time.
The visual page designer: a component palette on the left, a live canvas in the center with a page being built from blocks, and a properties inspector on the right

The page designer — drag components from the palette onto the canvas and configure each block's properties on the right.

## Page types The Pages list groups every page by type and shows its slug, tags, and status: * **Storefront** — plan and product discovery; the entry point a buyer browses. * **Checkout** — collects the details needed to place an order. * **Payment** — captures a payment method or pays an invoice (see [External & Hosted Payment Pages](/product/using-peakcommerce/ecommerce-and-payment-pages/external-payment-pages)). * **Portal** — authenticated self-service surfaces for existing customers. ## Add a page 1. Go to **Content → Pages**. 2. Click **New Page** to start from scratch, or **From Template** to start from a prebuilt layout. 3. Give the page a **name** and choose its **type**. 4. Build the page in the editor by dragging [components](/product/using-peakcommerce/templates) onto the canvas and configuring each block. 5. Set the page's **SEO metadata** (title tag and meta description) so it surfaces well in search. 6. **Publish** the page. Each published page gets a public **slug** (for example `/s/signup`); the slug is unique within your tenant. Bind a published page to a [journey step](/product/journeys-and-pages/journey-steps/managing-journey-steps) to use it inside a guided flow. ## Styling with brand colors * **Heading** and **Text** blocks carry a **Color** control offering the brand palette — surface, brand, ink, and muted variants — so copy stays on-brand without hand-picking hex values. * **Container** and **Section** background colors come from the same curated palette. Pages authored earlier with custom hex values keep rendering exactly as saved. * The built-in **Marketing** blocks (Pricing Table, Feature Grid, Testimonial Carousel, FAQ Accordion, Plan Comparison) pick up brand colors automatically and reflow responsively on tablet and phone. ## Key concepts * **Draft vs. published.** A page only serves publicly once published; the slug is what a journey step (or a direct link) resolves to. Edits are versioned, so you can revert a page to an earlier saved state. * **Reuse over duplication.** Because pages are bound to steps rather than owned by one journey, the same checkout or payment page can back several journeys. ## Gotchas * A page that isn't **Active/published** won't resolve — a journey step pointed at a draft or unpublished slug renders nothing or 404s. Publish before you wire it up. * Slugs must be unique per tenant; reusing a slug from another page will conflict. * To translate a page's copy per market, see [Localizing Pages](/product/using-peakcommerce/ecommerce-and-payment-pages/translating-e-commerce-pages). # External & Hosted Payment Pages A **payment page** lets a customer securely add a payment method or pay an invoice without walking through a full checkout journey. This matters for moments outside the initial sale — collecting a card after a trial, updating an expired card, or settling a one-off invoice — where a lightweight, linkable page is faster than a full flow. Payment capture always runs on the billing provider's **hosted payment page** (for example Zuora's), so card and bank details go straight to the provider and never touch PeakCommerce servers, keeping your PCI scope minimal. ## What you can do * **Add a payment method** — capture and store a default payment method on the customer's account, optionally enabling auto-pay. * **Pay an invoice** — present a specific invoice (with an optional partial-payment amount) and collect payment, storing the method for future use. ## How it works 1. Build a **Payment**-type page in **Content → Pages** and drop in the payment component, which embeds the provider's hosted page (curated in [Settings → Hosted Pages](/product/settings/developer-tools/hosted-pages)). 2. **Publish** the page to get its public slug/URL. 3. Link customers to it — for example from a billing email (see [Add payment page links to Zuora email templates](/product/journeys-and-pages/pages/add-payment-page-links-to-zuora-email-templates)). 4. Pass **prefill parameters** on the URL (such as the account and invoice id) so the page opens already scoped to the right customer and balance. ## Key concepts * **Hosted pages are configured once.** Each hosted payment page is registered against a billing **integration** in [Settings → Hosted Pages](/product/settings/developer-tools/hosted-pages) (provider page id, name, and version); your Payment-type pages reference that registration rather than re-entering provider config. * **The provider owns the card form.** PeakCommerce orchestrates and records the result, but the sensitive capture happens inside the provider's iframe. ## Gotchas * The hosted page must be registered in **Settings → Hosted Pages** before a Payment-type page can embed it; an unregistered or stale provider page version will fail to load. * Prefill params scope the page — omit the account/invoice and "pay an invoice" has nothing to settle. Double-check the URL parameters when building billing-email links. * A payment page is for capture and invoice payment, not for changing what a customer is subscribed to — for that, see [Updating Subscriptions Through Ecommerce](/product/using-peakcommerce/ecommerce-and-payment-pages/updating-subscriptions-through-e-commerce). # Updating Subscriptions Through Ecommerce Customers can change an existing subscription — upgrade, downgrade, or add and remove add-ons — through a guided flow with no admin involved. Self-service change beats a support ticket for routine moves: it's instant for the customer, frees your team, and lets you insert save offers exactly where churn happens. In the current platform this is a **journey**, not a special page mode — the same building blocks as a new-sale flow, pointed at an existing subscription. ## How it works 1. Build a journey of type **Customer Self-Service** (see [Create a journey](/product/journeys-and-pages/journey-basics/adding-a-journey)) that loads the customer's current subscription. 2. Add [steps](/product/journeys-and-pages/journey-steps/managing-journey-steps) that let the customer pick a new plan or adjust add-ons. 3. The journey applies the change to the **existing** subscription in your billing system rather than creating a new one. 4. Add **branching** to respond to intent — for example a retention offer on a downgrade or cancellation. ## Key concepts * **Journey type sets the audience.** **Customer Self-Service** is the end-customer-facing variant; for rep-assisted changes, build a **CSR Self-Service** journey instead so an agent can drive the same change on the customer's behalf. * **Change, not re-buy.** These flows amend the live subscription (plan swap, add-on add/remove), so billing reflects a true upgrade/downgrade rather than a duplicate order. * **Branching is where retention lives.** The same conditional routing that powers a checkout funnel lets you intercept a downgrade or cancel with an offer before it commits. ## Gotchas * Use the right journey type: a **Customer Self-Service** journey is for the account holder; a **CSR Self-Service** journey is for a rep acting on their behalf. Picking the wrong one exposes the flow to the wrong audience. * These journeys operate on an **existing** subscription — they must load the current subscription first, so the customer (or rep) needs to be in the right account context. * This is distinct from a [payment page](/product/using-peakcommerce/ecommerce-and-payment-pages/external-payment-pages), which captures a payment method or pays an invoice but does not change what the customer is subscribed to. # Localizing Pages Selling across markets means serving the right language *and* the right currency to each visitor. PeakCommerce localizes the buying experience by **language and currency** so you don't script translations by hand or maintain a separate storefront per region — one set of pages adapts to whoever lands on it. ## How it works Localization is driven by [Market Studio](/product/using-peakcommerce/market-studio). A visitor's **currency selects their market** (each market sells in exactly one currency), and the market's [Who gets what](/product/using-peakcommerce/market-studio/who-gets-what) sentences decide the rest: 1. The visitor's currency — from their entry link (for example `?currency=CAD`) or detected from their locale — places them in a market. 2. The market's ordered sentences assign **language** and, optionally, a **profile** (theming and configuration), matching on locale patterns (`fr-*`) or [audiences](https://gitlab.com/peakcommerce/peak-help-docs/-/tree/main/product/rules-and-customizations/README.md). 3. The **Otherwise** line fills anything the sentences left blank, so every visitor resolves a complete experience. The page then renders in that language and currency. ## Key concepts * **Sentences, not per-page translation files.** You localize centrally in Market Studio; the page surfaces the matched language and currency at render time. * **Page copy is component-driven.** Because pages are built from [components](/product/using-peakcommerce/templates), localized copy and per-market variants are managed in those components and shown according to the resolved market. * **Otherwise is your safety net.** It catches visitors no sentence matches, so there's never a blank or untranslated experience. ## Gotchas * Sentences read **top to bottom** — the first line with an opinion about a facet decides it, so order them most-specific-first. * A currency a visitor explicitly arrived with is **authoritative**: sentences fill in the open facets but never switch the visitor's currency. * A currency no market serves is a **reported gap** — the visitor is offered the currencies you do sell in, never silently charged in another one. See [Market Studio](/product/using-peakcommerce/market-studio) to configure markets and sentences. # Payments & Payment Methods How customers pay is a core part of the buying experience. PeakCommerce supports a range of payment methods and captures them securely on the billing provider's **hosted payment page**, so sensitive card and bank details go straight to the provider and never touch PeakCommerce — keeping your PCI scope minimal. This section covers the methods you can offer, how payment capture works, and the stored-credential records that keep recurring billing compliant. ## Payment methods * [Credit Card](/product/using-peakcommerce/payments-and-payment-methods/credit-card-payment-method) * [ACH](/product/using-peakcommerce/payments-and-payment-methods/ach-payment-method) · [Direct Debit](/product/using-peakcommerce/payments-and-payment-methods/direct-debit-payment-method) · [SEPA](/product/using-peakcommerce/payments-and-payment-methods/sepa-payment-method) · [PAD](/product/using-peakcommerce/payments-and-payment-methods/pad-payment-method) * [Apple Pay](/product/using-peakcommerce/payments-and-payment-methods/apple-pay-payment-method) * [Pay by Purchase Order (PO)](/product/using-peakcommerce/payments-and-payment-methods/pay-by-purchase-order-po) * [No Payment Method Required](/product/using-peakcommerce/payments-and-payment-methods/no-payment-method-required) — for free or invoice-later flows ## How capture works * [Hosted Pages](/product/using-peakcommerce/payments-and-payment-methods/hosted-pages) — the embedded, provider-hosted form that securely collects payment details. * [Setting up the Zuora GoCardless gateway & hosted payment page](/product/using-peakcommerce/payments-and-payment-methods/setting-up-zuora-gocardless-payment-gateway-and-hosted-payment-page) ## Stored credentials Reusing a saved payment method for recurring billing carries compliance requirements. These pages explain how PeakCommerce records consent and tracks stored-credential use: * [Stored Credential Profile](/product/using-peakcommerce/payments-and-payment-methods/stored-credential-profile) * [Stored Credential Acknowledgement](/product/using-peakcommerce/payments-and-payment-methods/stored-credential-acknowledgement) * [Stored Credential Transactions Overview](/product/using-peakcommerce/payments-and-payment-methods/stored-credential-transactions-overview) # Hosted Pages ### Overview Hosted Pages allow for customers to send payment details (such as providing a credit card) to purchase a company's product or put on file for recurring payments or update an existing payment method. It ensures that the payment gateways set up in the integrated billing system are also used in PeakCommerce. To view and configure Hosted Pages, navigate to Payments > Hosted Pages. Hosted Pages can be added, edited or deleted. See the example below. #### Adding a Hosted Page To add a hosted page click the “Add Payment Page” button in the upper right corner. ### Components A description of each field can be found in the order they appear when creating a hosted page. **Hosted Page** This field has dropdown options that include the Hosted Pages previously set up in the billing system. Select the Hosted Page of choice and the next three fields will auto-fill accordingly. **Page Name** This field is automatically filled with the same name from the billing system. However, it may be changed to have a different name displayed in PeakCommerce. **Type** This field is automatically filled in when the hosted page is selected. This information is taken from the billing system. **Version** This field is automatically filled in when the hosted page is selected. This information is taken from the billing system. **Partner Admin** This field is no longer in use. **Payment Gateway** This field has dropdown options that include the payment gateways already set up in the billing system. This field is **required.** **Hosts** This field is not required. ### Assigning Hosted Page to Profile #### USD Currency To assign a Hosted Page to a Profile first navigate to User > Profile. Under Profiles, choose the desired profile and click "Edit". Navigate to the Configurations tab. Locate the section called Hosted Payment Page at the top. Select a Hosted Page from the dropdown list corresponding to the Type of Payment Method: Credit Card, ACH, SEPA, or Direct Debit. **For each type of payment method, there must be a different hosted page.** **Example:** If adding an ACH Hosted Page, go to the Configurations tab, and add the proper ACH HP to the field labeled "ACH Hosted Payment Page ID" from the dropdown options. This profile must also have the following two permissions set to enable use of ACH. **Pay Invoices** * For customers to pay invoices using ACH, the Pay Invoices with ACH setting must be must be marked "Full" on the Pay Invoices tab. See below. **Payment Method Permission** * For customers to be able to view the ACH payment methods they have on file, add a new ACH payment method to their account, edit existing ACH payment methods on their account, or do all of the above, the ACH Payment Method Permission on the My Account tab must be marked accordingly: View, Create, Edit, or Full. See below. ### Foreign Currency To assign a Hosted Page to a Profile first navigate to User > Profile. Under Profiles, choose the desired profile and click "Edit". Navigate to the Currencies tab. Choose the proper currency tab. Locate the section called Hosted Payment Page at the top. Select a Hosted Page from the dropdown list corresponding to the Type of Payment Method: Credit Card, ACH, SEPA, or Direct Debit. **For each type of payment method, there must be a different hosted page.** Do not make any changes to the Configurations tab for foreign currency Hosted Pages. **Example:** If adding a Direct Debit Hosted Page, go to the Currencies tab, click the GBP tap, and add the proper Direct Debit HP to the field "DirectDebitUK Hosted Payment Page ID" from the dropdown options. This profile must also have the following two permissions set to enable use of Direct Debit. **Pay Invoices** * For customers to pay invoices using Direct Debit, the Pay Invoices with Direct Debit UK setting must be must be marked "Full" on the Pay Invoices tab. See below. **Payment Method Permission** * For customers to be able to view the Direct Debit payment methods they have on file, add a new Direct Debit payment method to their account, edit existing Direct Debit payment methods on their account, or do all of the above, the Bank Transfer Payment Method Permission on the My Account tab must be marked accordingly: View, Create, Edit, or Full. See below. # Pay by Purchase Order (PO) #### Overview Payment options during a checkout flow include Credit Card, ACH, Direct Debit, SEPA, PAD, ApplePay, Skip Payment, and Pay by PO. If paying by PO, a PO Number and a PO Name can be collected from the end-user before they checkout in an e-commerce flow, or when adding, updating, or renewing subscriptions in-app. #### Prerequisites In the billing system, custom fields (Text) should be created for PO Number and PO Name (optional) at the object of choice. Options include Account, Subscription, Rate Plan Charge, Amendment, or Order. You will need the API name of the custom field(s). #### Configuration To configure Pay by PO, navigate in the admin portal to Payments > Payment Methods. For PO click Actions > Edit. Check the Active checkbox. Select from the dropdown list the billing object to be used for PO. The options include Account, Subscription, Rate Plan Charge, Amendment, or Order. Paste in the API names for the custom field(s) from the billing system. Then click OK to save changes. #### Enablement To enable this option for certain users or certain e-commerce pages, navigate to Profiles > select the profile of choice > Actions > Edit > Configurations tab > Payment Methods > Pay by PO. Check the PO checkbox and Update the page. # No Payment Method Required This option allows users to complete the purchase (checkout) process without a payment method. This can either be used in conjunction with other payment methods to provide a choice to the end user, or can exclude all payment methods together. This is useful if billing is handled outside of the default billing system and the payment gateway. If it is an existing user who's billing information is already in the system and this is the only option enabled, then the payment step will be skipped altogether. # Apple Pay Payment Method ### Overview Provided in this article are the steps to enable Apple Pay as a payment method in PeakCommerce's in-app experience after it has been configured in Zuora. For more information about configuring Apple Pay in Zuora, review the following article from Zuora's Knowledge Center: * [Apple Pay on Web](https://knowledgecenter.zuora.com/Billing/Billing_and_Payments/L_Payment_Methods/Payment_Method_Types/Apple_Pay_on_Web) ### 1. Assign the Apple Pay Approved Gateway to a Profile * Navigate to Users > Profiles, select the profile of choice and click "Edit". * Open the Configurations tab. * In the Payment Gateway (Apple Pay) field, copy/paste the exact gateway name from Zuora. * Click "Update" to save the profile. ### 2. Enable Apple Pay in Profile Permissions This profile must also have the following permission set to enable use of Apple Pay in-app. #### **Payment Method Permission** For users to be able to use the Apple Pay integration in their portal, the Apple Pay Payment Methods Permission on the My Account tab must be marked as Full. This permission provides the following abilities: * View the Apple Pay payment methods on file * Add a new Apple Pay payment method to the account * Use a new or existing Apple Pay payment method to pay an invoice ### 3. Test Payment #### 1. Make payment as a customer * Log in as a customer with an open invoice. * Click "Pay an Invoice" * Enter an amount * Choose Pay With New Payment Method * Click the ACH option then click "Continue" * Fill in the payment information then click "Confirm" ### Review the Transaction in the Billing System *The following instructions are specific to Zuora.* #### **1. Open Zuora** #### **2. Find the customer** * Search for the customer by Name or Account Number. #### **3. Review the Default Gateway** * If the permission on the associated profile has "One-Time Purchase Persistent Permission" set to Full , or the user chose to process a one-time payment with the permission "One-Time Purchase Configurable Permission" set to Full, then the Default Payment Gateway should not have changed on the profile. #### **4. Review the Default Payment Method** * If the permission on the associated profile has "One-Time Purchase Persistent Permission" set to Full , or the user chose to process a one-time payment with the permission "One-Time Purchase Configurable Permission" set to Full, then the Default Payment Method should not have changed on the profile. If it is set to None or not chosen, the Default Payment Method should be the newly created ACH payment method. #### **5. Check that ACH was used for this particular payment** * Under Transactions, go to the Payments tab, and click on the payment number. Make sure the Payment Method information aligns with the Apple Pay payment information that was entered. * View the Additional Fields and verify that the payment gateway is the Apple Pay one. # Setting up Zuora GoCardless Payment Gateway and Hosted Payment Page GoCardless powers recurring payments for over 20,000 merchants, including some of Europe's largest media, software and technology-driven companies. Zuora’s integration to GoCardless makes it simple to accept recurring and one-off payments across the UK and Europe via Bacs, SEPA and AutoGiro Direct Debit. ### Supported Payment Methods * ACH * Bank Transfer, including: Direct Debit UK (BACS), SEPA, AU Direct Entry (BECS), Direct Debit NZ (BECS), Denmark Direct Debit (Betalingsservice), Sweden Direct Debit (Autogiro), Canadian Pre-Authorized Debit (PAD) For the SEPA payment method, you must use the International Bank Account Number (IBAN) to create payment methods. Different schemes are used on the GoCardless side corresponding to different country codes in IBAN. For example, if the IBAN is set to "GB60BARC20000055779911", the scheme used by GoCardless will be “Bacs". If IBAN is set to "FR1420041010050500013M02606", the scheme used by GoCardless will be "sepa\_core". ### Supported Currencies GoCardless supports the following currencies: * GBP (Direct Debit UK, SEPA) * EUR (SEPA) * AUD (AU Direct Entry) * SEK (Autogiro) * DKK (Betalingsservice) * NZD (Direct Debit NZ) * CAD (Canadian PAD) ### Supported Payment Operations * Set up of Service User Number (for Bacs) and Creditor ID (for SEPA) * Set up Direct Debit mandate and validate bank details, either online, over the phone or via paper * Collect payments automatically * One-off, ad-hoc, recurring and pre-payments * Real-time alerts for failed or cancelled payments and check status of all payments in Zuora Retry failed payments automatically * Refund payments (full or partial refunds) via Faster Payments or SEPA Credit Transfer * Simple to transfer existing Direct Debit mandates from another provider to GoCardless and Zuora * Sandbox environment available for full testing * Support for the following ACH payment operations: Validation Payment Refund Credit Void ### Supported Gateway Reconciliation Event Types GoCardless Gateway supports the following Gateway Reconciliation event types: * Settlement * Rejection * Chargeback * Mandate Rejected * Mandate Cancelled * Mandate Expired * Mandate Reinstated * Mandate Transferred * Mandate Replaced ### Prerequisites You will need to obtain the following information from GoCardless before configuring the GoCardless payment gateway in Zuora: * Access token: The password to access our API for your bank account. Available from [https://manage.gocardless.com/develo...-tokens/create](https://manage.gocardless.com/developers/access-tokens/create) * Creditor ID: This is the ID for the bank account set up in your GoCardless account. Available from ### Configure the GoCardless Gateway Instance * Navigate to Zuora Payments Settings > Setup Payment Gateway. * Select GoCardless from the Gateway Type drop-down menu. * Click create gateway. ### Zuora Payment Gateway Configuration Fields There are some common fields you must complete for every gateway configuration. * Type * Name * Use Gateway Test Environment * Default Authorization Amount * Verify new payment method (required) * Verify updated payment method (optional) * Enable gateway reconciliation: If you select this checkbox, it will trigger a daily job to reconcile all payment events processed through the gateway. In addition to the common fields, you must provide the required information to configure the GoCardless gateway in Zuora. * Access token * Creditor ID Once you have entered the necessary information, click save gateway information. ### GoCardless Refunds GoCardless payments can only be refunded two days after the payment has been processed. If a refund is performed prior to the two day delay, the call will fail and return the following error message: "invalid\_state – A refund is not possible on this payment." For further information on getting the most out of the GoCardless integration for Zuora, contact the GoCardless team on . ### Hosted Page Setup #### Enable Bank Transfer Payment Method You will need to enable the "Bank Transfer" Payment method in your tenant Payment method settings. To navigate to the payment method page: * Click your user name at the top right-hand side of the application. * Navigate to Settings > Payments Settings > Payment method * Click on edit and enable "Bank Transfer" payment method To check your Hosted Page to ensure that the default payment gateway setting is pointing to your new payment gateway. To access, navigate to Settings > Payments > Setup Hosted Pages, then click on Edit under the applicable hosted page. # Direct Debit Payment Method ### Overview Provided in this article are the steps to set up a Direct Debit Hosted Page in PeakCommerce, assigning it to a Profile, making a payment using Direct Debit, and checking the billing system records to ensure it was processed correctly. This article assumes the Direct Debit Hosted Page and Payment Gateway have already been created in the billing system. ### Set up Hosted Page #### 1. Create a Direct Debit Hosted Page * Navigate to Payments > Hosted Pages and click "**Add Payment Page**" * Choose the Direct Debit HP you wish to use from the dropdown list. This list is pulled from your billing system Hosted Pages list. * The Page Name will auto-fill the same name from the billing system. This name may be changed in PeakCommerce. * Type and Version will auto-fill * Partner Admin is not required * Select the Direct Debit Payment Gateway in the billing system from the dropdown list * Adding a Host is not required * Click "**ADD HPM**" #### 2. Assign Direct Debit Hosted Page to a profile * Navigate to **Users > Profiles**, select the profile of choice and click "**Edit**" * Open the **Currencies tab** * In the **Direct DebitUK** Hosted Payment Page field, select the **Direct Debit HP** that was just created from the dropdown list * Click "**Update**" to save the profile Note: Do not make any changes to the Configurations tab for foreign currencies. #### 3. Enable Direct Debit in Profile Permissions This profile must also have the following two permissions set to enable use of Direct Debit. **Pay Invoices** * For customers to pay invoices using Direct Debit, the Pay Invoices with Direct Debit UK setting must be must be marked "Full" on the Pay Invoices tab. **Payment Method Permission** * For customers to be able to view the Direct Debit payment methods they have on file, add a new Direct Debit payment method to their account, edit existing Direct Debit payment methods on their account, or do all of the above, the Bank Transfer Payment Method Permission on the My Account tab must be marked accordingly: View, Create, Edit, or Full. ### Test payment #### 1. Make payment as a customer * **Log in** as a customer with an open invoice. * Click "**Pay an Invoice**" * Enter an **amount** * Choose Pay With **New Payment Method** * Click the Direct Debit option then click "**Continue**" * Fill in the payment information then click "**Confirm**" ### Review the transaction in the billing system *The following instructions are specific to Zuora.* #### **1. Open Zuora** #### **2. Find the customer** * Search for the customer by Name or Account Number. #### **3. Review the Default Gateway** * If the permission on the associated profile has "One-Time Purchase Persistent Permission" set to **Full**, or the user chose to process a one-time payment with the permission "One-Time Purchase Configurable Permission" set to **Full,** then the Default Payment Gateway should not have changed on the profile. #### **4. Review the Default Payment Method** * If the permission on the associated profile has "One-Time Purchase Persistent Permission" set to **Full**, or the user chose to process a one-time payment with the permission "One-Time Purchase Configurable Permission" set to **Full,** then the Default Payment Method should not have changed on the profile. If it is set to **None** or not chosen, the Default Payment Method should be the newly created Direct Debit payment method. #### **5. Check that Direct Debit was used for this particular payment** * Under Transactions, go to the Payments tab, and click on the payment number. Make sure the Payment Method information aligns with the Direct Debit payment information that was entered. * View the Additional Fields and verify that the payment gateway is the Direct Debit one. # PAD Payment Method ### Overview Provided in this article are the steps to set up a PAD Hosted Page in PeakCommerce, assign it to a Profile, make a payment using PAD, and check the billing system records to ensure it was processed correctly. This article assumes the PAD Hosted Page and Payment Gateway have already been created in the billing system. ### Set up Hosted Page #### 1. Create a PAD Hosted Page * Navigate to Payments > Hosted Pages and click "Add Payment Page" * Choose the PAD HP you wish to use from the dropdown list. This list is pulled from your billing system Hosted Pages list. * The Page Name will auto-fill the same name from the billing system. This name may be changed in PeakCommerce. * Type and Version will auto-fill * Partner Admin is not required * Select the PAD Payment Gateway in the billing system from the dropdown list * Adding a Host is not required * Click "ADD HPM" #### 2. Assign PAD Hosted Page to a Profile * Navigate to Users > Profiles, select the profile of choice and click "Edit" * Open the Configurations tab. * In the PAD Hosted Payment Page ID field, select the PAD HP that was just created from the dropdown list * Click "Update" to save the profile #### 3. Enable Direct Debit in Profile Permissions This profile must also have the following two permissions set to enable use of Direct Debit. ### Pay Invoices For users to pay invoices using PAD, the Pay Invoices with PAD setting must be must be marked "Full" on the Pay Invoices tab. ### Payment Method Permission For users to be able to view the Direct Debit payment methods they have on file, add a new PAD payment method to their account, edit existing Direct Debit payment methods on their account, or do all of the above, the Bank Transfer Payment Method Permission on the My Account tab must be marked accordingly: View, Create, Edit, or Full. ### Test Payment #### **1. Make payment as a customer** * Log in as a customer with an open invoice. * Click "Pay an Invoice" * Enter an amount * Choose Pay With New Payment Method * Click the PAD option then click "Continue" * Fill in the payment information then click "Confirm" #### 2. Review the Transaction in the Billing System *The following instructions are specific to Zuora.* **1. Open Zuora** **2. Find the customer** * Search for the customer by Name or Account Number. **3. Review the Default Gateway** * For PAD to be a payment method option, a gateway which supports PAD (such as GoCardless) must become the Default Payment Gateway on the account. **4. Review the Default Payment Method** * If the permission on the associated profile has "One-Time Purchase Persistent Permission" set to Full, or the user chose to process a one-time payment with the permission "One-Time Purchase Configurable Permission" set to Full, then the Default Payment Method should not have changed on the profile. If it is set to None or not chosen, the Default Payment Method should be the newly created PAD payment method. **5. Check that PAD was used for this particular payment** * Under Transactions, go to the Payments tab, and click on the payment number. Make sure the Payment Method information aligns with the PAD payment information that was entered. * View the Additional Fields and verify that the payment gateway is the PAD one. # Stored Credential Profile ### Overview If the payment gateway mandates 3D Secure 2.0 and it's activated on Hosted Pages within Zuora, a Stored Credential Profile becomes necessary for new payment methods. Related Zuora Knowledge-based articles: * [Zuora's Implementation of 3D Secure 2.0](https://knowledgecenter.zuora.com/Billing/Billing_and_Payments/PSD2_and_strong_customer_authentication_overview/A_Zuora%E2%80%99s_implementation_of_3D_Secure_2.0) * [Stored Credential Transactions](https://knowledgecenter.zuora.com/Billing/Billing_and_Payments/L_Payment_Methods/Stored_credential_transactions) PeakCommerce facilitates this requirement by enabling configuration and assignment of Stored Credential Profiles to PeakCommerce Hosted Pages, which may mirror Hosted Pages in Zuora. Since Hosted Pages are profile-specific, this setup allows for selective application based on customer groups. This acknowledgment includes a mandatory checkbox and customizable text. For payment flows utilizing a PeakCommerce Hosted Page with this acknowledgment enabled, end users must agree to Stored Credential terms before adding or processing payments with new methods, with the checkbox displayed at the Hosted Page's bottom. ### Configuration Below are the steps to configure the Stored Credential Profile checkbox: #### Acknowledgments 1. Go to Company Settings > Acknowledgments. Click "+ New Acknowledgment." 2. Choose the Stored Credential acknowledgment type. Provide a Name (for internal use), customer-facing text for the checkbox, and an error message for missing entries (if desired). #### Hosted Pages 1. Navigate to Payments > Hosted Pages. 2. Create a new Hosted Page using Zuora's Hosted Page setup and select a Stored Credential Acknowledgment from the dropdown. Upon usage within PeakCommerce for tasks such as adding payment methods or checking out, this field will become mandatory. ### Profile Configurations Assign the Hosted Page to a Profile's Configurations so that any user or e-commerce page with this profile will utilize the Stored Credential checkbox, while those with a different Hosted Page won't. ### Logging Ultimately, end-user acknowledgments are tracked in PeakCommerce, and the Stored Credential profile is automatically established in Zuora. You can monitor user acknowledgments by accessing the admin user list and selecting "View" for the respective user. # Credit Card Payment Method ### Overview Provided in this article are the steps to set up a Credit Card Hosted Page in PeakCommerce, assign it to a profile, make a payment using the Credit Card, and check the billing system records to ensure it was processed correctly. This article assumes the Credit Card Hosted Page and Payment Gateway have already been created in the billing system. ### Set up Hosted Page #### 1. Create a Credit Card Hosted Page * Navigate to **Payments > Hosted Pages** and click "**Add Payment Page**". * Choose the Credit Card HP you wish to use from the dropdown list. This list is pulled from your billing system Hosted Pages list. * The Page Name will auto-fill the same name from the billing system. This name may be changed in PeakCommerce. * Type and Version will auto-fill. * Partner Admin is not required. * Select the Credit Card Payment Gateway in the billing system from the dropdown list. * Adding a Host is not required. * Click "**ADD HPM**". #### 2. Assign Credit Card Hosted Page to a profile * Navigate to **Users > Profiles**, select the profile of choice and click "**Edit**". **For USD currency:** * Open the Configurations tab. * In the Credit Card Hosted Payment Page ID field, select the Credit Card HP that was just created from the dropdown list. * Click "Update" to save the profile. **For foreign currency:** * Open the Currencies tab and click on the appropriate sub-tab. * In the Credit Card Hosted Payment Page ID field, select the Credit Card HP that was just created from the dropdown list. * Click "Update" to save the profile. Note: Do not make any changes to the Configurations tab for foreign currencies. #### 3. Enable Credit Card in Profile Permissions This profile must also have the following two permissions set to enable use of Credit Card. **Pay Invoices** * For customers to pay invoices using a Credit Card, the Pay Invoices with CC setting must be must be marked "Full" on the Pay Invoices tab. **Payment Method Permission** * For customers to be able to view the Credit Card payment methods they have on file, add a new Credit Card payment method to their account, edit existing Credit Card payment methods on their account, or do all of the above, the CC Payment Methods Permission on the My Account tab must be marked accordingly: View, Create, Edit, or Full. ### Test payment #### 1. Make payment as a customer * Log in as a customer with an open invoice. * Click "Pay an Invoice" * Enter an **amount** * Choose Pay With New Payment Method * Click the Credit Card option then click "**Continue**" * Fill in the payment information then click "**Confirm**" ### Review the transaction in the billing system *The following instructions are specific to Zuora.* #### 1. Open Zuora #### 2. Find the customer * Search for the customer by Name or Account Number. #### 3. Review the Default Gateway * If the permission on the associated profile has "One-Time Purchase Persistent Permission" set to **Full**, or the user chose to process a one-time payment with the permission "One-Time Purchase Configurable Permission" set to **Full,** then the Default Payment Gateway should not have changed on the profile. #### 4. Review the Default Payment Method * If the permission on the associated profile has "One-Time Purchase Persistent Permission" set to **Full** , or the user chose to process a one-time payment with the permission "One-Time Purchase Configurable Permission" set to **Full,** then the Default Payment Method should not have changed on the profile. If it is set to **None** or not chosen, the Default Payment Method should be the newly created Credit Card payment method. #### 5. Check that the Credit Card was used for this particular payment * Under Transactions, go to the Payments tab, and click on the payment number. Make sure the Payment Method information aligns with the Credit Card payment information that was entered. * View the Additional Fields and verify that the payment gateway is the Credit Card one. # SEPA Payment Method ### Overview Provided in this article are the steps to set up a SEPA Hosted Page in PeakCommerce, assigning it to a Profile, making a payment using SEPA, and checking the billing system records to ensure it was processed correctly. This article assumes the SEPA Hosted Page and Payment Gateway have already been created in the billing system. ### Set up Hosted Page #### 1. Create a SEPA Hosted Page * Navigate to **Payments > Hosted Pages** and click "**Add Payment Page**" * Choose the **SEPA HP** you wish to use from the dropdown list. This list is pulled from your billing system Hosted Pages list. * The Page Name will auto-fill the same name from the billing system. This name may be changed in PeakCommerce. * Type and Version will auto-fill * Partner Admin is not required * Select the **SEPA Payment Gateway** in the billing system from the dropdown list * Adding a Host is not required * Click "**ADD HPM**" #### 2. Assign SEPA Hosted Page to a profile * Navigate to **Users > Profiles**, select the profile of choice and click "**Edit**" * Open the Currencies tab click on the EUR sub-tab. * In the **SEPA** Hosted Payment Page field, select the **SEPA HP** that was just created from the dropdown list * Click "**Update**" to save the profile Note: Do not make any changes to the configurations tab for foreign currencies. #### 3. Enable SEPA in Profile Permissions This profile must also have the following two permissions set to enable use of SEPA. **Pay Invoices** * For customers to pay invoices using SEPA, the Pay Invoices with SEPA setting must be must be marked "Full" on the Pay Invoices tab. **Payment Method Permission** * For customers to be able to view the SEPA payment methods they have on file, add a new SEPA payment method to their account, edit existing SEPA payment methods on their account, or do all of the above, the Bank Transfer Payment Method Permission on the My Account tab must be marked accordingly: View, Create, Edit, or Full. ### Test payment #### 1. Make a payment as a customer * **Log in** as a customer with an open invoice. * Click "**Pay an Invoice**" * Enter an **amount** * Choose Pay With **New Payment Method** * Click the **SEPA** option then click "**Continue**" * Fill in the payment information then click "**Confirm**" #### Review the transaction in the billing system *The following instructions are specific to Zuora.* **1. Open Zuora** **2. Find the customer** * Search for the customer by Name or Account Number. **3. Review the Default Gateway** * If the permission on the associated profile has "One-Time Purchase Persistent Permission" set to **Full** , or the user chose to process a one-time payment with the permission "One-Time Purchase Configurable Permission" set to **Full,** then the Default Payment Gateway should not have changed on the profile. **4. Review the Default Payment Method** * If the permission on the associated profile has "One-Time Purchase Persistent Permission" set to **Full**, or the user chose to process a one-time payment with the permission "One-Time Purchase Configurable Permission" set to **Full,** then the Default Payment Method should not have changed on the profile. If it is set to **None** or not chosen, the Default Payment Method should be the newly created SEPA payment method. **5. Check that SEPA was used for this particular payment** * Under Transactions, go to the Payments tab, and click on the payment number. Make sure the Payment Method information aligns with the SEPA payment information that was entered. * View the Additional Fields and verify that the payment gateway is the SEPA one. # ACH Payment Method ### Overview Provided in this article are the steps to set up an ACH Hosted Page in PeakCommerce, assign it to a Profile, make a payment using ACH, and check the billing system records to ensure it was processed correctly. This article assumes the ACH Hosted Page and Payment Gateway have already been created in the billing system. ### Set up Hosted Page #### 1. Create an ACH Hosted Page * Navigate to **Payments > Hosted Pages** and click "**Add Payment Page**". * Choose the ACH HP you wish to use from the dropdown list. This list is pulled from your billing system Hosted Pages list. * The Page Name will auto-fill the same name from the billing system. This name may be changed in PeakCommerce. * Type and Version will auto-fill. * Partner Admin is not required. * Selected the ACH Payment Gateway in the billing system from the dropdown list. * Adding a Host is not required. * Click "**ADD HPM**". #### 2. Assign ACH Hosted Page to a profile * Navigate to **Users > Profiles**, select the profile of choice and click "**Edit**". * Open the Configurations tab. * In the ACH Hosted Payment Page ID field, select the ACH HP that was just created from the dropdown list. * Click "**Update**" to save the profile. #### 3. Enable ACH in Profile Permissions This profile must also have the following two permissions set to enable use of ACH. #### **Pay Invoices** * For customers to pay invoices using ACH, the Pay Invoices with ACH setting must be must be marked "Full" on the Pay Invoices tab. #### **Payment Method Permission** * For customers to be able to view the ACH payment methods they have on file, add a new ACH payment method to their account, edit existing ACH payment methods on their account, or do all of the above, the ACH Payment Method Permission on the My Account tab must be marked accordingly: View, Create, Edit, or Full. ### Test payment #### 1. Make payment as a customer * Log in as a customer with an open invoice. * Click "**Pay an Invoice**" * Enter an **amount** * Choose Pay With New Payment Method * Click the ACH option then click "**Continue**" * Fill in the payment information then click "**Confirm**" ### Review the transaction in the billing system *The following instructions are specific to Zuora.* #### 1. Open Zuora #### 2. Find the customer * Search for the customer by Name or Account Number. #### 3. Review the Default Gateway * If the permission on the associated profile has "One-Time Purchase Persistent Permission" set to **Full** , or the user chose to process a one-time payment with the permission "One-Time Purchase Configurable Permission" set to **Full,** then the Default Payment Gateway should not have changed on the profile. #### 4. Review the Default Payment Method * If the permission on the associated profile has "One-Time Purchase Persistent Permission" set to **Full** , or the user chose to process a one-time payment with the permission "One-Time Purchase Configurable Permission" set to **Full,** then the Default Payment Method should not have changed on the profile. If it is set to **None** or not chosen, the Default Payment Method should be the newly created ACH payment method. #### 5. Check that ACH was used for this particular payment * Under Transactions, go to the Payments tab, and click on the payment number. Make sure the Payment Method information aligns with the ACH payment information that was entered. * View the Additional Fields and verify that the payment gateway is the ACH one. # Stored Credential Acknowledgement #### Add a new acknowledgment To add a new stored credential acknowledgment: * Navigate to Company Settings > Acknowledgements. Click "+ New Acknowledgement." * Select the **Stored Credential** acknowledgment type * Fill out the remaining fields Field Definitions: | Field | Description | | ---------------------- | ----------------------------------------------------------------- | | Acknowledgment Type | This should be set to **Stored Credential** | | Name | The name of the acknowledgment for internal purposes only. | | Text | The verbiage to display next to the acknowledgment checkbox. | | Field Required Message | The error message to display if the required checkbox is skipped. | If nothing is added for the Field Required Message, then PeakCommerce's default error message will be displayed. #### Hosted Pages To link a hosted page to a Stored Credential Acknowledgement: * Navigate to Payments > Hosted Pages. * Create a new Hosted Page using the Hosted Pages set up in Zuora * Select a Stored Credential Acknowledgement from the dropdown list The Stored Credential Acknowledgement field will be mandatory for the following cases: * Add a payment method on file * To pay an invoice with a new payment method * To checkout with a new payment method #### Profile Configurations The Hosted Page gets assigned to a Profile's Configuration so that any e-commerce page or user with this profile will use the Stored Credential checkbox. Those with a different Hosted Page without Stored Credential confugration will not. #### Logging The acknowledgment is tracked in PeakCommerce and the Stored Credential profile is automatically set up in Zuora. You can track a user's acknowledgments by "Viewing" the user in the administrator user's list. You can also verify the Stored Credential profile in Zuora. # Stored Credential Transactions Overview #### Overview When creating a payment method, if you do not implement the support for SCTs on the payment method, the payment method will be created without the stored credential profile.\ \ For payment methods created before Zuora released the support for SCTs, if you have not implemented Zuora's SCTs support on these payment methods, the payment methods do not have stored credential profiles within them. #### Payment methods Zuora supports stored credential transactions for the following types of payment methods: * Credit Card * Apple Pay - Support for stored credential transactions for Apple Pay is only available on the CyberSource Payment API v2.0 gateway integration. For the supported card brands on the specific payment gateway integrations, see Payment gateways in the following section. #### Stored credential profiles Zuora supports the following types of stored credential profiles: * Recurring profile: Indicates that you have obtained the customer’s consent to initiate future transactions at regular intervals. * Unscheduled profile: Indicates that you have obtained the customer’s consent to initiate future transactions that do not occur on scheduled or regularly occurring transaction dates. Only one Unscheduled profile is allowed for each payment method. Currently, the Unscheduled profile is only supported in Chase Orbital Gateway integration. When configuring your Zuora tenant, the goal is to contain an Active stored credential profile for the payment methods created on the preceding gateway instances. #### PeakCommerce Overview If 3D Secure 2.0 is required by the payment gateway and enabled on Hosted Pages in Zuora, then a Stored Credential Profile is required for new payment methods.\ \ PeakCommerce accomodates this by allowing an acknowledgement for Stored Credential Profiles to be configured and assigned to PeakCommerce Hosted Pages (which can be proliferations of the same Hosted Pages in Zuora). Because Hosted Pages are assigned at the profile level, then this acknowledgement can be used for certain cohorts of customers and not used for others.\ \ This Acknowledgement features a mandatory checkbox and a custom message. For any payment flows that use a PeakCommerce Hosted Page with this acknowledgment enabled, the end user will be required to agree to Stored Credential terms before adding the payment method or processing payment with the new payment method. The checkbox will be featured at the bottom of the Hosted Page. #### Related PeakCommerce articles: * [Add a stored credential acknowledgement](https://knowledgecenter.peakcommerce.com/en/main/add-a-stored-credential-acknowledgement) #### Related Zuora Knowledgebase articles: * [Zuora's Implementation of 3D Secure 2.0](https://knowledgecenter.zuora.com/Billing/Billing_and_Payments/PSD2_and_strong_customer_authentication_overview/A_Zuora%E2%80%99s_implementation_of_3D_Secure_2.0) * [Stored Credential Transactions](https://knowledgecenter.zuora.com/Billing/Billing_and_Payments/L_Payment_Methods/Stored_credential_transactions) # Products & Bundles Your sellable products live in the **Product Catalog** (**Commerce → Product Catalog**) — either **Synced** from your billing provider, created as **Internal** PeakCommerce products, or assembled as a **Bundle** that sells several products as one item. Group products into **Product Sets** to control what buyers see in storefronts and journeys. This section covers: * [Products Overview](/product/using-peakcommerce/products-and-bundles/products-overview) — the catalog model and product types * [Managing Products](/product/using-peakcommerce/products-and-bundles/managing-products) — find, filter, sync, and edit products * [Product Brands](/product/using-peakcommerce/products-and-bundles/product-brands) — which brand each product and rate plan is sold under * [Product Bundles Overview](/product/using-peakcommerce/products-and-bundles/product-bundles-overview) — when and why to bundle * [Creating a Product Bundle](/product/using-peakcommerce/products-and-bundles/creating-a-product-bundle) — build a bundle step by step * [Offers & Discounts](/product/using-peakcommerce/products-and-bundles/offers-and-discounts) — promo codes and retention discounts, the offer page, and the offer editor # Products Overview The **Product Catalog** (**Commerce → Product Catalog**) is your tenant-wide list of sellable products and the single source of truth for what PeakCommerce can put in front of a buyer. Everything a journey, offer, or payment page can sell starts as a product here, so getting the catalog right is the foundation for accurate pricing, clean checkout, and correct billing. {% embed url="" %} Each product carries a **SKU**, a **category** (for example Base Products or Add On Services), one or more priced **charges**, a **status**, and — when it originates in a billing system — a link to its provider record and last-synced time.
The Product Catalog under Commerce → Product Catalog, listing products with their type (Synced, Recurring, Bundle, or One-Time Purchase), pricing, status, and last-updated date

The Product Catalog (Commerce → Product Catalog) — each product's type, pricing, and status in one list.

## The catalog model: where products come from A product's **Type** tells you its origin and how it's maintained: * **Synced** — mirrored from your billing provider (e.g. Zuora rate plans + charges) via **Sync from Provider**, and kept in step with the provider catalog. Synced products show their provider, source instance, and last-synced time. PeakCommerce prices most charges locally and falls back to the billing system for any charge it can't model. * **Recurring** — a PeakCommerce-native subscription plan billed on a recurring cadence, created directly with **Create Product** and priced here with a Flat Fee, Per Unit, Volume, or Tiered pricing model. (This type was previously labeled *Internal* — same products, clearer name.) * **Bundle** — a product that groups other products together to sell as one item, with optional per-item activation timing. See [Product Bundles Overview](/product/using-peakcommerce/products-and-bundles/product-bundles-overview). * **One-Time Purchase** — a single, non-recurring purchase: a physical or one-time digital good with a flat price, imagery, and storefront details, rather than a plan that renews. ## How you work with the catalog Search by name, SKU, or description, and filter by **Type, Status, Provider, Category, Support Level,** or **Instance**. Expand a row to inspect its charges, or open a product to land on its **view page** — which includes a **live preview of the exact customer-facing card**, a pricing table with the full tier bands, and a **Used In** card showing which [Product Sets](/product/using-peakcommerce/products-and-bundles/product-sets) carry the product. A Synced product with **No plans synced** signals a sync gap worth resolving before you try to sell it. ## Grouping products for sale To present a curated set of products in a storefront or journey, group them into a **Product Set** (**Commerce → Product Sets**) rather than tying products to a single flow. Product Sets carry their own status and commerce rules, and are how **Offers** and **Audiences** target who sees what. This replaces the legacy journey-scoped "Categories" model. See [Product Sets](/product/using-peakcommerce/products-and-bundles/product-sets) for the full picture. ## Who and when Catalog and commerce admins curate products as your offerings evolve — after a billing-system catalog change, re-run **Sync from Provider**; for native offerings, create Recurring, Bundle, or One-Time Purchase products as needed. **Related:** [Managing Products](/product/using-peakcommerce/products-and-bundles/managing-products) · [Product Bundles Overview](/product/using-peakcommerce/products-and-bundles/product-bundles-overview) · [Market Studio](/product/using-peakcommerce/market-studio) · [Ecommerce & Payment Pages](/product/using-peakcommerce/ecommerce-and-payment-pages) · [Journeys Overview](/product/journeys-and-pages/journey-basics/journeys-overview) # Managing Products The **Product Catalog** is the tenant-wide list of everything you can sell. Keeping it accurate matters because every journey, storefront, and Change-Plan flow draws on these records — a product's charges, status, and provider link decide what a customer or CSR can actually buy and at what price. You manage it all from **Commerce → Product Catalog**.
A product detail page showing the product's SKU, category, provider, sync status, and effective dates, with its plans and charges listed below

A product's detail — its catalog metadata and provider link up top, then each plan and its charges below.

## Add products There are two ways to get a product into the catalog, surfaced as buttons at the top of the page: * **Sync from Provider** — pull products from your billing system (e.g. Zuora) into the catalog and keep them in step. **Synced** products carry their provider link, the source integration name, and a **last-synced** timestamp; the provider stays the source of truth for their underlying charges. Re-run **Sync from Provider** (or **Re-sync from** *\[integration name]* on a single row) to pick up provider changes. * **Create Product** — add a product directly in PeakCommerce. The form opens with a **Product Type** picker, and the type you choose shapes the rest of the form: * **Recurring** — a subscription plan billed on a recurring cadence, priced with one of the pricing models below. * **Bundle** — groups two or more products to sell together, each with its own activation timing — see [Creating a Product Bundle](/product/using-peakcommerce/products-and-bundles/creating-a-product-bundle). * **One-Time Purchase** — a single, non-recurring purchase: a physical or one-time digital good with a flat price and storefront imagery. The type is **locked once the product is created** — on the edit page it shows as a read-only field with a lock icon. If a product was created as the wrong type, create a new one rather than trying to convert it. ## Pricing a Recurring product Creating a Recurring product includes a **Recurring Pricing** card with a real **pricing-model picker**: * **Flat Fee** — one price, regardless of quantity. * **Per Unit** — price × quantity. * **Volume** — one flat rate for the **whole quantity**, based on which band the total quantity falls in. * **Tiered** — **cumulative**: each band's rate applies only to the units that fall within that band. Flat Fee and Per Unit take a simple price and currency. Choosing **Volume** or **Tiered** opens a **band editor**: each band has a **From** (min quantity), a **To** (max quantity — only the last band may be left unlimited), and a **price**. Bands must be contiguous — no gaps or overlaps — and the editor validates this inline before you save, suggesting the next band's From automatically. Below the bands sits a live **"Try a quantity" calculator**: type a quantity and it shows the exact amount that quantity would price at under your bands — the same computation the pricing engine uses at order time — or tells you plainly when no band matches. > **Volume vs Tiered — the distinction admins get wrong.** The two models use the same band table but bill very differently. Say you have bands **1–100** and **101 and up**, and a customer buys **150**: > > * **Tiered** charges *cumulatively*: 100 units at the first band's rate **plus** 50 units at the second band's rate. > * **Volume** finds the *single* band that contains 150 (the second one) and applies that band's rate to the entire quantity — the first band contributes nothing. > > Before activating a banded product, put a few realistic quantities through the **Try a quantity** calculator and confirm the results match your intent. ## Pricing a One-Time Purchase A One-Time Purchase product gets its own **One-Time Purchase Pricing** card instead: * **Price** and **currency** — a single flat price; no recurrence, no bands. * **Image URL** — the primary card thumbnail for the storefront grid. * **Gallery images** — additional image URLs (one per line) for the item's gallery. * **Recommended** — a toggle that highlights the item in the storefront grid. ## The product view page Opening a product from the catalog lands on its **view page** — the read-oriented counterpart to the edit form: * A header with a **breadcrumb** back to the Catalog, the product's type and Active/Inactive badges, its metadata (SKU, category, provider and source instance, external ID, last-synced and effective dates), and **Edit**/**Delete** actions where your permissions allow. * A **metrics strip** tuned to the product's type — active plans, charge counts, and live-priced charges for Synced products; pricing-row and bundle-item counts; the price for a One-Time Purchase — plus a **Used in** count on every product. * **Live Preview** — for PeakCommerce-native products, the page renders the **actual customer-facing card** (the same component the plan picker and storefront use), so what you see here is exactly what customers see and the preview can never drift from the real thing. * A **Pricing** table that renders the full **From / To / Price** bands for banded models, not just a summary figure. * **Storefront Details** — for One-Time Purchase goods, the imagery and merchandising fields as they'll appear in the storefront. * **Used In** — every [Product Set](/product/using-peakcommerce/products-and-bundles/product-sets) that carries this product, with the item's classification and the set's status, each linking straight to the set. Check it before deactivating or deleting a product: it tells you exactly which selling surfaces you'd affect. ## Edit a product The edit page shows **Delete** in the header (for users with the delete permission) and the product type as a **locked, read-only field** — type can't be changed after creation. From here you can change the **name, SKU, category, description**, and **charges/pricing**. The **Plan presentation** section controls how the product appears in the customer/CSR Change-Plan journey — bullet-list **features**, a **quantity unit** and **price-tier** table for tiered base plans, an add-on **markup %**, and a **non-renewable** flag for trials and one-shots. Recurring products manage their pricing rows in the **Pricing Tiers** section, using the same charge models and From/To band editor as at create time. For **Synced** products, edit charges in the billing system and re-sync instead. ## Status and filters A product's **Status** (for example Active) controls whether it can be sold. Use the **Type, Status, Provider, Category, Support Level,** and **Instance** filters — plus search by name, SKU, or description — to find what you need, and expand a row to see its charges. Last-synced times honor your [Zuora tenant timezone](https://gitlab.com/peakcommerce/peak-help-docs/-/tree/main/integrations/zuora-integration/zuora-billing-integration.md). ## Gotchas * Only **Active** products are sellable. A draft or inactive product won't resolve in a journey or storefront even if it's added to a Product Set. * **Volume and Tiered use the same band table but bill differently** — see the callout above, and verify with the **Try a quantity** calculator before going live. * The **product type is permanent.** Pick Recurring vs One-Time Purchase vs Bundle deliberately at create time; the edit page won't change it. * To present a curated group of products in a flow, build a **Product Set** (**Commerce → Product Sets**) — don't tie products to a single journey. * Bulk spreadsheet import/export of products is no longer required — products are synced from the provider or created in the catalog directly. ## Related * [Products Overview](/product/using-peakcommerce/products-and-bundles/products-overview) * [Creating a Product Bundle](/product/using-peakcommerce/products-and-bundles/creating-a-product-bundle) * [Commerce actions in journeys](/product/journeys-and-pages/journey-steps/commerce-actions) # Product Sets A **Product Set** is a curated group of products you present together — the menu of plans and add-ons a customer chooses from in a storefront or a journey. Rather than tying products to a single flow, you assemble them once into a set and reuse that set wherever you sell. Product Sets are also the unit that **Offers** and **Audiences** target, so they're how you control *who* sees *which* products. Manage them under **Commerce → Product Sets**.
A Product Set detail page with its base products and add-ons, each showing classification, pricing tiers, charges, and commerce rules

A Product Set (Commerce → Product Sets) — the base products and add-ons in the set, each with its pricing tiers and commerce rules.

## What's in a set A set is organized into two groups: * **Base products** — the core plans a customer picks one of (for example a Starter and an Advanced tier). Each shows its classification, pricing tiers, and charges. * **Add-ons** — optional services layered on top of a base plan (priority support, advanced analytics, extra usage), often priced as a percentage of MRR or on usage. For each product in the set you can see its **classification**, **pricing tiers**, the underlying **charges**, and any **commerce rules** that apply — and the set carries a **status** of its own. ## How sets are used * **Offers** and **Audiences** target a Product Set to decide who is eligible for it and what pricing they get — so the same set can power different experiences for different customers. * A journey or storefront resolves a Product Set to render the available plans, instead of hard-coding products into the flow. This replaces the legacy journey-scoped "Categories" model. ## Per-item visibility Every item in a set has its own **Visibility** setting, so a single set can show a slightly different menu to different customers without you maintaining separate sets: * **Always shown** (the default) — the item appears for every customer the set is offered to. * **Only during an active trial** — the item appears in customer-facing plan pickers only while the customer is in a trial (see below for how "in a trial" is determined), and is hidden from paying customers. This is how you gate trial-specific choices — for example a free-trial plan that should be selectable while someone is evaluating, but shouldn't clutter (or tempt) the plan picker once they're paying. Two behaviors worth knowing: * **The customer's current plan is always shown**, regardless of its visibility setting — so the "you're on this plan" state renders correctly even after a trial-only plan's window has passed. * **"In a trial" is a catalog decision you make, not something inferred.** Each set item carries a **Free trial — converts to paid** toggle, right beside its Visibility setting. The trial-only gate shows trial-only items when the customer's **current plan matches an item you've flagged** as a genuine trial — so you define once, per item, what counts as a trial, and that single definition applies consistently across the [customer portal](/product/customer-self-service/subscription-management/customer-subscription-management), CSR tools, and journeys. Because nothing is guessed from billing-system structure, a scheduled plan change can't be mistaken for a trial, and a real trial is recognized even when its billing shape looks unremarkable. The same plan can be flagged as a trial in one set and left unflagged in another, since the flag lives on the set item, not the product. ### Free trial vs. free plan Beside it sits a second toggle, **Free plan — never charged**. Both look "free" to a customer, but they behave in opposite ways at checkout, so the toggles are labelled by what they *do*: | Toggle | What the customer pays | Signup | | --------------------------------- | -------------------------------------------------- | --------------------------------- | | **Free trial — converts to paid** | nothing now, your normal price when the trial ends | a payment method **is** collected | | **Free plan — never charged** | nothing, ever | no payment method is collected | A plan can be one or the other, not both — turning one on turns the other off. Leave **both** off for an ordinary paid plan, **and also for a promotion that happens to make a paid plan $0 for a while**: that customer still converts, so a card must be collected or there will be nothing to charge when the promotion ends. Journeys read these toggles — not the price — to decide whether to show a payment step, so a $0 price on its own never skips checkout. ## How each line is booked Each item in a set has two settings that decide how its line is booked when a journey places the order. They sit together on the item's card, **Order grouping** directly above **Effective Date Timing**. | Setting | Options | Default | What it does | | ------------------------- | ------------------------------------------------------------------------------------------------------------------ | ---------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Order grouping** | **Default — grouped with other lines** · **Its own order line** | Default — grouped with other lines | **Its own order line** books the line as its own order action (an **Add Product**) within the same order and subscription. Takes effect only in journeys whose create-order action has [Honor order grouping](/product/journeys-and-pages/journey-steps/commerce-actions#honor-order-grouping) turned on; everywhere else the line is booked with the rest. | | **Effective Date Timing** | **Same as Order Date** · **Set Period (After Subscription Date)** — a number of **Days**, **Months**, or **Years** | Same as Order Date | When the line starts, counted from the order date. A set period (for example 30 days after a trial) defers that line's start. | On the item card: * A line set to **Its own order line** shows an **Its own order line** tag. * A line with a set period shows an **Activates +N** tag (for example **Activates +1 months**). Lines on the default for both settings show no tag, so the lines that behave differently stand out without opening them. **Adding products:** the **Add products** panel has its own **Order grouping** select. The value you pick there is applied to every plan added in that batch; change individual lines afterwards on their cards. **Bundles:** a bundle's face and each of its members are separate lines, and each has its own **Order grouping** and **Effective Date Timing**. A member does not inherit the face's values, so a bundle's free trial and its paid plan can start on different dates and be booked in different order actions. **No republish needed.** A journey reads the set when a customer starts checkout, so changes to these settings apply to every checkout started after you save. Checkouts already in progress keep the values they started with. For how the order is assembled from these settings, with a worked example, see [Guide: Booking a Line as Its Own Order Action](https://docs.peakcommerce.com/guides/feature-guides/billing-setup/guide-booking-a-line-as-its-own-order-action). ## Create and manage 1. Go to **Commerce → Product Sets** and open or create a set. 2. Add **base products** and **add-ons** from your [Product Catalog](/product/using-peakcommerce/products-and-bundles/products-overview). 3. Set the order and any commerce rules, then set the set's **status** to **Active**. ## Gotchas * **A set must be Active to resolve.** A storefront or journey pointed at a draft or inactive Product Set won't return products (it resolves to nothing) — activate the set before wiring it into a flow. * Products in a set still come from the catalog: a product's own status and provider link govern whether it can actually be sold. See [Managing Products](/product/using-peakcommerce/products-and-bundles/managing-products). ## Related * [Products Overview](/product/using-peakcommerce/products-and-bundles/products-overview) * [Managing Products](/product/using-peakcommerce/products-and-bundles/managing-products) # Product Brands If you sell under more than one brand, every rate plan in your catalog carries the brand it's sold under. That brand decides which brand's portal shows the subscription, which brand's payment page and gateway collect for it, and where its revenue is reported. Open it from **Product Catalog → Brands**. ## How a rate plan gets its brand | Level | What you do | | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Billing system** | Link each brand to the billing system it bills in, on the brand's page in **Settings → Brands**. If only one brand bills in a billing system (for example a Stripe account per brand), every product from it takes that brand automatically. There's nothing to tag. | | **Product** | In a billing system shared by several brands, give each product its brand. The product's brand fills in every rate plan under it. | | **Rate plan** | When one product spans brands, set the rate plans that belong to another brand individually. A rate plan set individually keeps its brand when the product's brand changes. | **Example:** one product, *Marketing plans*, has five rate plans: three for Brand A and two for Brand B. Set the product to Brand A, which fills in all five, then set the two Brand B plans individually. New products and rate plans from a catalog sync fill in the same way: a new rate plan takes its product's brand, and a new product from a single-brand billing system takes that brand. ## Assign brands in bulk 1. Filter the list by name or SKU, billing system, category or product set. 2. Tick the products (or tick the header to select every one shown). 3. Choose a brand and select **Preview**. The preview shows how many rate plans will change and how many are set individually and won't. 4. Select **Apply**. If the catalog changed after you previewed (for example a sync added plans), **Apply** is refused and you're asked to preview again, so nothing changes that you haven't seen counted. **Suggestions.** When a product's name contains exactly one brand's name, the list offers that brand as a suggestion. It's only a suggestion: select it to see the preview, and nothing changes until you apply. A brand can only go on products from the billing system it bills in. If a brand isn't linked to a billing system yet, link it first on its page in **Settings → Brands**. ## Product sets show the brand; they don't set it In the product-set editor each item shows its rate plan's brand, read from the catalog. Change it here, in the catalog. A product set can include rate plans from several brands (for example a set your support team uses). ## Who can change this Viewing needs **Products: Read**; assigning brands needs **Products: Update**. Every change is recorded in the audit log. # Product Bundles Overview A **bundle** is a catalog product (Type: **Bundle**) that groups several products or charges so customers buy them together as a single item. Bundles are first-class catalog entries: they appear, filter, search, and sell like any other product, and they slot into Product Sets, offers, and journeys the same way. ## Why bundles matter Bundles let you package related offerings — a base plan plus add-ons, or a curated combination — into one purchasable unit. That means one item to choose, one line to manage, and a simpler buying decision for the customer. Use a bundle when you want to: * Sell a set of plans / add-ons as one purchasable item. * Present one item and one decision for a combination of charges. * Control **when each bundled product activates** — immediately on purchase, or on a delay relative to another item in the bundle. ## How it fits the catalog model A bundle sits alongside **Synced** products (mirrored from your billing system) and **Internal** products (PeakCommerce-native) as one of the three product **Types**. Its child items can themselves be Synced or Internal products, so a bundle is a composition layer over the rest of your catalog rather than a separate kind of thing to maintain. ## Bundle vs. Product Set — don't confuse them > To group products for **display** in a storefront or journey — without combining them into a single purchasable item — use a **Product Set** (**Commerce → Product Sets**) instead. A Product Set curates what a buyer *sees*; a bundle is one thing a buyer *buys*. See [Creating a Product Bundle](/product/using-peakcommerce/products-and-bundles/creating-a-product-bundle) to build one, and [Managing Products](/product/using-peakcommerce/products-and-bundles/managing-products) to find and edit it afterward. **Related:** [Products Overview](/product/using-peakcommerce/products-and-bundles/products-overview) · [Creating a Product Bundle](/product/using-peakcommerce/products-and-bundles/creating-a-product-bundle) · [Journeys Overview](/product/journeys-and-pages/journey-basics/journeys-overview) # Creating a Product Bundle A **bundle** is a catalog product (Type: **Bundle**) that groups two or more products so customers buy them as a single item. Bundles matter most for **trial → paid** offers: you combine a trial product and a paid product into one purchasable thing, then control *when* each member activates — so the trial starts now and the paid plan kicks in later, without maintaining a separate "bundle code" in the billing system. ## Build a bundle 1. Go to **Commerce → Product Catalog** and click **Create Product**. 2. Set **Product Type** to **Bundle**. 3. Give the bundle a **name**, **SKU**, and **category**. 4. Under **Select Products for Bundle**, check the **member products** to include. Members can be Internal or Synced products (a bundle can't contain another bundle). 5. For each member, set its **Activation Timing** (see below). 6. Save, then set the bundle **Active** when it's ready to sell. You can revisit a saved bundle to add or remove members and adjust each one's timing from the **Bundle Products** section. ## Activation timing (the trial → paid model) Each member product carries its own activation rule, so the bundle can stage a lifecycle rather than activating everything at once: * **Immediate** — the member activates with the bundle (typical for the trial member). * **Delayed** — the member activates after a set **delay** (a value plus **days**, **weeks**, or **months**). Use this to start a paid plan a fixed time after purchase. * **Triggered** — the member activates when another **trigger product** in the bundle activates or ends — e.g. the paid plan begins when the trial completes. Delays and triggers are evaluated against the contract/service dates in your billing system, so activation offsets depend on the [Zuora tenant timezone](https://gitlab.com/peakcommerce/peak-help-docs/-/tree/main/integrations/zuora-integration/zuora-billing-integration.md) being set correctly — otherwise an offset can land a day early or late. ## How pricing works A bundle has no single "bundle price" field. Its price comes from its members' charges (and any **Pricing Tiers** you define), so a delayed or triggered paid member is billed only when it actually activates. Mark trial members **non-renewable** in their **Plan presentation** so they don't appear as a renewing Current plan in the Change-Plan journey. ## Gotchas * A bundle won't sell until its **Status** is **Active** — and neither will an inactive member inside it. * **A bundle can't contain another bundle — and the server enforces it.** The member picker only offers non-bundle products, and the same rule is applied server-side, so a bundle created or modified through the API is rejected if it tries to nest a bundle — integrations get exactly the rule the picker gives admins. * Set **trigger products** carefully: a member can't trigger itself, and removing the trigger product later leaves the dependent member without an activation rule. ## Related * [Product Bundles Overview](/product/using-peakcommerce/products-and-bundles/product-bundles-overview) * [Products Overview](/product/using-peakcommerce/products-and-bundles/products-overview) * [Commerce actions in journeys](/product/journeys-and-pages/journey-steps/commerce-actions) # Offers & Discounts An **Offer** defines a discount a customer can receive — a promo code at checkout or a retention discount applied to an active subscription. Offers live under **Commerce → Offers**. Watch a retention offer being built — 30% off for three billing cycles, with the live customer preview and billing impact: {% embed url="" %} There are two kinds of offer: * **Cart Promo** — a one-time discount applied at checkout when the customer enters the offer code (or automatically, with **Auto-Apply**). * **Subscription Discount** — a retention offer applied to an existing subscription through the retention flow, with support for recurring discount cycles, conflict rules, and audience targeting. Watch a cart promo built end to end — code, discount, and a live customer preview: {% embed url="" %} ## The offer page Open an offer from the list (row menu → **View**) to see everything about it without entering edit mode: * A plain-English summary of the offer's terms — what the customer gets, how it's granted, and the guardrails in effect. * Tiles for **redemptions**, the **per-customer cap**, **audience targeting**, and the offer's **window** (active, scheduled, or expired). * Sections for the **Discount** definition, **Usage Limits & Guardrails**, and **Audience & Eligibility**, plus **Recent Redemptions**. * For subscription discounts, the **Discount Instrument** panel shows the resolution chain — discount product → rate plan (pinned or fallback) → charge — and whether the pinned instrument conforms to the offer's definition. Page actions: **Activate/Deactivate**, **Edit Offer**, and **Delete**.
An offer's dedicated page showing its plain-English terms, redemption and audience tiles, the Discount section, and the Discount Instrument rail with a pinned rate plan

The offer page (Commerce → Offers → View) — terms, stats, guardrails, and the discount-instrument chain, without entering edit mode.

## The offer editor **Create Offer** (or **Edit Offer** on the offer page) opens a full-page editor. The form is grouped into sections — Definition, Discount, Guardrails, Instrument (subscription discounts only), Targeting, and Schedule — with a section navigator on the left. Save actions live in the top bar: **Cancel** and **Create/Update Offer**; an *Unsaved changes* indicator appears once you edit. The right pane is a **live preview** that updates as you type: * **Customer Preview** — how the offer reads to the customer: the retention-flow offer card for subscription discounts, or the checkout promo line for cart promos. * **Billing Impact** — an illustrative example showing the discounted charge per cycle and the total give-back. Actual amounts always resolve from the billing system at apply time. * **Checks** — advisories such as a missing per-customer cap, no end date, or an instrument mismatch. Advisories never block saving.
The full-page offer editor with a section navigator on the left, the Definition and Discount forms in the middle, and a live customer preview with billing-impact example on the right

The full-page offer editor — the customer preview and billing-impact example on the right recalculate as you type.

## Key fields * **Discount Type / Value** — percentage, fixed amount (in cents), or free trial extension (in days). * **Recurrence / Duration** (subscription discounts) — apply once to the next billing period, or recur for N billing cycles (blank = indefinite). * **Max Total Uses / Max Uses Per Customer** — usage caps; blank = unlimited. **Cap Basis** controls whether the per-customer cap counts every grant ever (**Lifetime**) or only grants in a trailing window (**Rolling window**). * **Conflict Scope / Re-offer Window** (subscription discounts) — which active discounts suppress this offer, checked against live billing state; the re-offer window lets the offer surface again shortly before the blocking discount ends. * **Cooldown** — minimum days between grants to the same customer. * **Discount Instrument** (subscription discounts) — the catalog discount product, an optionally **pinned rate plan** (pinning makes apply-time resolution deterministic), and an optional pinned charge. The editor flags any mismatch between the instrument and the offer's definition; at apply time the offer's definition overrides the instrument's baked terms. * **Target Audiences / Priority** — leave empty for all customers; with audiences selected the customer must belong to at least one, and priority breaks ties when a customer matches several targeted offers. Watch the full churn-prevention loop — churn-risk signals, an audience on live billing data, and a retention offer targeted to it with priority: * **Active / Start / End dates** — inactive offers are never granted, regardless of schedule. ## Discounts during a free trial A subscription discount can be accepted while the customer is still in a **free trial** — for example, a trialing customer who starts to cancel and takes a save offer in the [retention flow](/product/customer-self-service/subscription-management/customer-retention-journey). Applying a discount to a period that bills $0 would be meaningless (and "30% off $0" is not a compelling offer), so the discount doesn't try to apply mid-trial. Instead it is **parked**: the grant is confirmed in the billing system immediately, but the discount's activation is future-dated to the **paid-start date** — the day the paid subscription begins. The billing system itself holds and fires the activation; there is no app-side scheduler that could miss. What this means in practice: * **The customer sees honest numbers.** The offer card in the retention flow computes the discount against the **steady-state (paid) price**, not the current $0 trial period, and the flow shows **when the discount will start** — the discount begins when the paid subscription does. * **The grant is real at accept time.** The discount order is created the moment the customer accepts, and the per-customer usage cap is consumed then — not later when the charge activates. If the acceptance isn't confirmed by the billing system, no usage is recorded. * **A parked discount counts as an active discount.** For conflict checks, a deferred discount waiting to activate at paid start blocks a second grant exactly like a live one — a customer can't re-run the cancel flow during their trial to stack another discount on top. ## Conformance checks For subscription discounts, the offer's **definition** (what you configure in Peak) and its **instrument** (the discount product, rate plan, and charge in the billing catalog) describe the same discount from two sides — and they can drift apart. The **Checks** pane in the editor and the **Discount Instrument** panel on the offer page run a conformance assessment and surface any mismatch as an **advisory warning**: * **No pinned instrument** — apply-time resolution falls back to a product-level guess, which is non-deterministic when the discount product has several rate plans. Pin a rate plan to make it exact. (This is a note, not a warning.) * **Inactive or unsynced plan** — the pinned rate plan is inactive in the synced catalog, or has no synced billing-system id (the catalog may need a re-sync; apply will fail until it resolves). * **Charge-model or discount-type mismatch** — e.g. the offer is a percentage discount but the pinned charge is a fixed-amount model, or the offer is a free-trial extension (which has no discount-charge realization, so the pin won't be used). * **Baked value or duration drift** — the instrument's baked-in percentage or period count differs from the offer's definition. The offer's value is what actually gets applied, but the catalog configuration is misleading to anyone reading it there. * **Zero or multiple discount charges** — the pinned rate plan has no discount-type charge (the offer's value/duration override has nothing to attach to, so apply will fail), or several (without a pinned charge, the first is used — pin the exact charge to make it deterministic). Two things to keep in mind about these checks: * **They warn, never block.** Saving is never prevented by an advisory, because at apply time the offer's definition **overrides** the instrument's baked terms — a mismatch doesn't change what the customer receives. The warnings exist to flag drift worth cleaning up, not to stop you. * **A genuinely broken pin is rejected at save time.** A pinned rate plan that doesn't exist in your synced catalog, or a pinned charge that doesn't belong to the pinned plan, fails the save with a clear error. That's deliberate: a stale or foreign pin that slipped through would only surface later as an apply-time failure — in front of a cancelling customer, at the worst possible moment. # Plan Entitlements **Commerce → Plan Entitlements** (admin only) Plan entitlements answer one question for your application: *what does this customer's plan actually let them do?* Without them, the answer usually lives inside your app as a hard-coded list — "Starter means five seats, Pro means unlimited." That works until you want to change what a plan includes, at which point you need a code change and a deploy to sell something different. Moving the answer into PeakCommerce means changing a plan is a settings change. PeakCommerce never interprets what your feature keys *mean*. You define your own vocabulary; PeakCommerce stores it, resolves it per customer, and only ever looks at a feature's **type** — which it uses to reject values that would break your app. ## The two halves Setting this up is two steps, and the page is laid out in that order. 1. **Feature vocabulary** — the things your product can gate on, named once. 2. **What each plan grants** — the value each product carries for each feature. You need step 1 before step 2 will do anything. ## Step 1 — Register your feature vocabulary Give each feature a **key**, a **display name**, and a **type**. The **key** is what your application code will ask for, so treat it as an API contract rather than a label — `max_seats`, not "Max Seats". It must be lower\_snake\_case. Once other systems are reading it, it is not editable: see [Changing your mind](#changing-your-mind) below. Pick the **type** carefully, because it decides what values are legal: | Type | Use it for | Legal values | | ----------- | ------------------------------------------------------------ | ------------------------------------------ | | **Boolean** | A capability that is simply on or off — "can export reports" | `On` / `Off`. There is no third state. | | **Limit** | A countable ceiling — seats, projects, API calls | A whole number, **or blank for unlimited** | | **Config** | Anything structured — a theme, a tier name, a list | Any JSON value | ### "Blank means unlimited" is the one to remember For a **Limit** feature, leaving the value empty does not mean "not set" — it means **unlimited**, and it is delivered to your app as an explicit `null`. This trips people up in a way that matters: if your application treats a missing or null limit as zero, an unlimited plan will lock your best customers out of the feature they are paying most for. Decide deliberately how your app reads `null`, and read [the Entitlements API reference](https://gitlab.com/peakcommerce/peak-help-docs/-/tree/main/developers/api-reference/entitlements.md) before you write that gating code. ## Step 2 — Set what each plan grants Choose a product from the picker. **Your products are your plans** — there is no separate plan object to maintain. Set a value for each feature. Values save as you go. A feature you leave untouched shows *"Not set — this plan grants nothing for it"*, which is different from a Limit set to blank/unlimited. If you enter something the feature's type does not allow, the save is rejected with the reason. That check happens on write on purpose: a bad value that gets stored is served to your app immediately, and from inside your app it is nearly impossible to work out where a nonsense number came from. ## What happens next — how your app uses this Defining entitlements is not the end of the job; something has to read them. **Your application reads the resolved values** from the Entitlements API and gates its own features on them: ``` GET /api/v1/entitlements/subscription/{subscriptionId} GET /api/v1/entitlements/contact/{contactId} ``` Both need an API key with the `read` scope. The response is a flat map of your keys to their final values, along with `resolvedFrom`, which names the product the values came from. **Subscription webhooks carry the same resolved set**, so an app reacting to `subscription.created` can gate immediately without a second call. See [Webhooks overview](https://gitlab.com/peakcommerce/peak-help-docs/-/tree/main/developers/api-reference/webhooks-overview.md). Two behaviours worth knowing before you build against it: * A customer holding **several subscriptions** gets one resolved set **per subscription**, never merged. Two plans can disagree, and PeakCommerce will not silently pick a winner for you. * **Add-on products do not contribute** to a resolved set today. The values come from the subscription's base product. If a customer needs more than their plan grants, use an override. ## Granting one customer more — overrides You will eventually need to give a specific customer something their plan does not include: an apology after an outage, a promotional bump, a negotiated exception. That is an **override**, and it is deliberately not on this page. Overrides are granted against a customer's subscription by staff with the *Customer Entitlement Overrides* permission — tenant admins, Sales, and CSR — with a reason recorded and an optional expiry. An expiring override simply stops applying when its time is up; nothing needs cleaning up. Keeping the two apart is the point: a CSR can grant one customer an exception without being able to redefine what a plan means for everybody. ## Changing your mind * **Renaming** a feature's display name is safe — it is only a label. * **The key and type cannot be edited.** Your app gates on the key, and every stored value was validated against the type; changing either would silently invalidate data already written and break a live integration with no error anywhere. To genuinely change one, delete the feature and register it again. * **Deleting a feature** also removes every plan default and every per-customer override for it, and any app gating on that key stops receiving it. The confirmation says so. ## Who can see this page Plan Entitlements is **admin only**. It appears under Commerce for users whose profile grants the *Plan Entitlements* resource; it is not available to CSR, Sales, partner, or customer profiles, and cannot be granted to them. # Orders & Transactions Every purchase a customer makes — through a journey, the customer portal, or the API — becomes a **commercial order** that PeakCommerce records and dispatches to your billing system. **Orders** and **Transactions** (under **Commerce**) are where you see what was sold, where it was routed, and whether billing succeeded.
The Orders page under Commerce, with summary tiles for order volume, billed, in-flight, and failed dispatch, and a table of orders showing customer, product, amount, billing destination, status, and source

Orders (Commerce → Orders) — each order's billing destination, status, and source, with dispatch health summarized up top.

## Orders An order captures the **intent** of a purchase — the customer, the products and amounts, and the journey or channel it came from. PeakCommerce is the system of record for that intent, its rule resolution, and its routing to a billing destination. Each order shows: * **Customer / account** — who the order is for. * **Product and amount** — what was sold and for how much. * **Destination** — the billing system the order is dispatched to (for example Zuora, Stripe, or Peak Billing). * **Status** — where the order is in its lifecycle: *Billed*, *Processing*, *Pending*, or *Failed* (needs attention). * **Source** — how it originated: a checkout, a subscription change, or the API. Summary tiles track order volume, how many billed successfully, how many are still in flight, and how many **failed dispatch** and need attention. Failed orders stay visible so you can diagnose and re-dispatch them — billing failures are never hidden. ## Transactions Where Orders track what was sold, **Transactions** track the money: invoices, payments, refunds, and credit memos reconciled back from your billing system and payment gateways. Use them to confirm that an order actually billed and was paid, and to investigate a disputed or failed charge. ## Who and when Admins and CSRs use **Orders** to confirm a sale dispatched correctly and to triage anything that failed; **Transactions** give finance and support a reconciled view of invoices and payments tied back to each order. ## Related * [Products Overview](/product/using-peakcommerce/products-and-bundles/products-overview) * [Payments & Payment Methods](/product/using-peakcommerce/payments-and-payment-methods) # Users & User Roles Everyone who signs in to your PeakCommerce tenant — your own staff, your resellers, and your end customers — is a **user**. Managing users well is how you control who can configure the platform, who can act on customer accounts, and who can only see their own subscription. Get it right and the platform stays secure and tidy; get it wrong and people see too much or too little. You manage users from the **user menu** (your name, bottom-left) → **Settings → Users**. Click **Add User** to invite someone. Each user has two settings that work together: * A **Role** — one of **Admin**, **CSR**, **Partner**, or **Customer** — which sets the broad experience and portal they land in. * A **Profile** — which fine-tunes exactly what they can see and do within that role. Sign-in is handled by **Auth0**: new users receive an email to set their own password, so you never handle passwords directly. **Start here** * [User Roles](/product/using-peakcommerce/users-and-user-roles/user-roles) — what each role is for * [Administrator Users](/product/using-peakcommerce/users-and-user-roles/administrator-users) · [Customer Users](/product/using-peakcommerce/users-and-user-roles/customer-users) · [Partner Users](/product/using-peakcommerce/users-and-user-roles/partner-users) * [Creating a new user](/product/using-peakcommerce/users-and-user-roles/creating-a-new-user) · [Editing a user](/product/using-peakcommerce/users-and-user-roles/editing-a-user) * [Profiles & Permissions](/product/using-peakcommerce/profiles-and-permissions) # User Roles Every user has a **role** and a **profile**, and the two do different jobs. The **role** sets the broad kind of access a person has — which portal they sign in to and the overall experience they get. The **profile** fine-tunes the specific permissions *within* that role — what they can actually see and do. Understanding the split matters because the role alone never grants detailed permissions; the profile always does. You set both when you create or edit a user (**Settings → Users → Add User**), and you manage permission profiles separately in **Settings → Profiles**. ## The five roles | Role | For | | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Admin** | Tenant administrators who configure the platform — catalog, content, journeys, integrations, users, profiles, and settings. | | **CSR** | Customer service reps who work their assigned customer accounts — search, view, assist with subscriptions and orders, and respond to support cases. | | **Sales** | Sales reps who work their assigned book of business from their own **Sales portal** — an account workspace kept separate from support, so sales access and screens can be managed and evolved independently of the CSR portal. Sales users start from the seeded *Sales Default* profile, which gives a new sales team similar coverage to CSR support staff but is managed on its own. | | **Partner** | Resellers and channel partners who manage their assigned customers from the partner portal. | | **Customer** | End customers managing their own account and subscriptions in the customer portal. | The role list is fixed — these five are the only roles. (Customer and Partner users also get an **External Account** link to a billing account; Admin, CSR, and Sales users do not.) ## How the profile fine-tunes the role Roles are broad; **profiles** carry the detailed permissions. Each user is assigned exactly one profile, and you can create several profiles per role — for example a *CSR Senior* profile with refund permissions alongside a *CSR Junior* profile without them. The same applies to Sales — every tenant starts with a *Sales Default* profile (seeded with similar coverage to *CSR Default*, managed independently); create additional Sales profiles the same way you would for CSR if you need finer-grained variants. When you change a user's role, you reselect their profile, since profiles belong to a specific role. **Gotcha:** picking the role is only half the job. A user with the right role but a thin profile may still be missing the permissions they expect — check the profile, not just the role. See [Profiles & Permissions](/product/using-peakcommerce/profiles-and-permissions) and [Portal action permissions](/product/using-peakcommerce/profiles-and-permissions/portal-action-permissions). # Viewing Your Users List The users list is your single roster of everyone with access to the tenant — admins, CSRs, partners, and customers — and the starting point for editing, deactivating, or impersonating any of them. It's where you confirm who has access, at what level, and whether their account is active. ## Open the list Open the **user menu** (your name, bottom-left) → **Settings → Users**. Each row shows: * **User** — avatar, name, and email, with a small dot indicating active status. * **Role** — Admin, CSR, Partner, or Customer. * **Profile** — the permission profile assigned to the user (see [User Profile Overview](/product/using-peakcommerce/profiles-and-permissions/user-profile-overview)). * **Status** — a pill showing **Active** or inactive. * **External Account** — the linked billing/identity account, shown for customers and partners. * **Created** — when the user was added. ## Find and manage users Use the search box to filter by **email** or **profile name**. Each row's menu (**⋯**) lets you **View**, **Edit**, **Impersonate** ("Log in as"), or **Delete** the user; click the row itself to open the full detail page with its Activity, Logins, and Impersonations tabs. ## Gotchas * Search matches email and profile name — not display name — so search by email address when looking for a specific person. * The Status dot and pill reflect platform access; a customer can still appear here as inactive if they were deactivated in the billing system. * See [User Roles](/product/using-peakcommerce/users-and-user-roles/user-roles) to understand what each role column value implies. # Creating a New User Every person who signs in to your PeakCommerce tenant — administrators, customer-service reps, partners, and end customers — needs a user record. Creating one provisions their sign-in and decides, from the first login, exactly what they can see and do. Getting the role and profile right up front saves you from over- or under-granting access later.
The Add User form under Settings → Users, with fields for first name, last name, email, role, and profile

The Add User form (Settings → Users) — set the person's details, then their role and profile.

## Add a user 1. Open the **user menu** (your name, bottom-left) → **Settings → Users**, then click **Add User**. 2. Enter the user's **Email**. This is both their identity and their sign-in name, so make sure it's correct — it's how the platform (and Auth0) recognizes them. 3. Choose a **Role** — **Admin**, **CSR**, **Partner**, or **Customer**. The role sets the broad kind of access; see [User Roles](/product/using-peakcommerce/users-and-user-roles/user-roles). 4. Choose a **Profile**. The list is filtered to active profiles for the role you picked, so you only ever see relevant options. The profile carries the detailed permissions — what this user can actually open and change (see [User Profile Overview](/product/using-peakcommerce/profiles-and-permissions/user-profile-overview)). 5. For a **Customer** or **Partner**, enter the **External Account ID** that links the user to their billing/identity account (and an External Contact ID if applicable). This connects the person to the right account data in your billing system. 6. Click **Create**. ## How it works PeakCommerce tenants use **Auth0** for sign-in, so you don't set a password. The new user receives an email to establish their own credentials and verify their address. They appear in the [users list](/product/using-peakcommerce/users-and-user-roles/viewing-your-users-list) immediately and can sign in as soon as they've set their password. See [Authentication & Security](/product/using-peakcommerce/authentication-and-security) for password policy and SSO. ## Gotchas * There's no separate "name" field — a user's display name comes from their Auth0 profile after they sign in. * Pick the Role first; the Profile dropdown only populates with profiles built for that role. * Adding many users at once? Use the Agent API (`/api/v1`) — there's no spreadsheet import in the admin UI. # Editing a User People change teams, change responsibilities, and occasionally need their access reset. Editing a user lets you adjust what they can do without recreating their account — their history, audit trail, and identity stay intact. ## Open a user Open the **user menu** (your name, bottom-left) → **Settings → Users**, then click a row to open the user's detail page, or use the row menu (**⋯ → Edit**). The detail page has tabs for **Activity**, **Logins**, **Impersonations**, and **Details**; the header carries the quick actions and the **Actions** menu described below. ## What you can change * **Role and Profile** — choose **Edit** to change what the user can access. As with creating a user, the Profile list filters to the selected role. See [User Roles](/product/using-peakcommerce/users-and-user-roles/user-roles) and [User Profile Overview](/product/using-peakcommerce/profiles-and-permissions/user-profile-overview). * **Email** — because sign-in is via Auth0, updating the email updates their login; use **Actions → Change Email** (below) so the change syncs to the identity provider and the user re-verifies the new address. * **External Account** — for customers and partners, update the linked External Account ID to point the user at the right billing account. * **Deactivate / Reactivate** — revoke or restore access without deleting the record (see [Suspending Users](/product/using-peakcommerce/users-and-user-roles/suspending-users)). You can't deactivate yourself. * **Impersonate** ("Log in as") — for support staff with permission, sign in as the user to reproduce what they see. This is recorded in the audit trail. ## Header quick actions The detail-page header carries one-click actions (each destructive one confirms first): * **Impersonate** — shown when you hold the impersonate permission and the target isn't you or a system administrator. * **Reset password** — on Auth0-backed tenants, emails the user a secure link to set a new password. You never see or type the password — Auth0 manages it — and this is the **only** way to change a credential; there is no admin "set password" field anywhere in PeakCommerce. * **Edit** — opens the edit form for role, profile, and details. * **Deactivate / Reactivate** — as above. ## The Actions menu On Auth0-backed tenants, the header also carries an **Actions** menu with identity-level operations: * **Send Verification Email** — re-sends the address-verification email for the user's current address. * **Change Email** — updates the address in Auth0 (marking it unverified and sending a fresh verification email), then syncs it to PeakCommerce. The user keeps the same account and history. * **Change Phone Number** — stored on the Auth0 identity and mirrored here. It's contact metadata, not a sign-in factor. * **Block / Unblock** — stops the user signing in at the identity provider without touching their PeakCommerce record. If the sync to Auth0 fails you'll see a warning — the block isn't effective until it succeeds, so retry. * **Reset MFA Enrollment** — after a confirmation dialog, removes all of the user's enrolled multi-factor authenticators; they'll be prompted to enroll a new factor at next sign-in. Use this for a lost or replaced device. * **Delete** — permanently removes the user from PeakCommerce **and** deletes their Auth0 identity. You must type the user's email address to confirm, and the option never appears on your own account. Delete is also still available from the list row's **⋯** menu on the Users page — the detail page's type-to-confirm flow is the safer route. Prefer **Deactivate** when you may need the record later. ## Gotchas * Changing a role narrows or widens access immediately — re-check the assigned Profile after switching roles, since a profile built for one role won't fit another. * **Block** and **Deactivate** are different levers: Deactivate is PeakCommerce-side and reversible in place; Block acts at the identity provider and is what stops an SSO sign-in. * Users can edit a limited set of their own details (display name, login email, password) from **My Profile** in their own portal. # Suspending Users Suspending a user revokes their access without deleting the record — the right move when an employee leaves, a contract ends, or you need to pause someone temporarily. Their role, profile, and history are preserved, so reactivating later restores them exactly as they were. In PeakCommerce this is done with the **Deactivate** / **Reactivate** controls. ## Why deactivate instead of delete Deactivating keeps the user in your records for auditing and lets you restore access in one click. Deleting is permanent and removes the account from PeakCommerce and Auth0. When in doubt, deactivate. ## Deactivate a user 1. Open the **user menu** (your name, bottom-left) → **Settings → Users**, then open the user. 2. In the header, choose **Deactivate** and confirm. Their **Status** changes to inactive and they can no longer sign in. They still appear in the [users list](/product/using-peakcommerce/users-and-user-roles/viewing-your-users-list) for record-keeping, and the change is written to the audit trail (see [User History](/product/using-peakcommerce/users-and-user-roles/user-history)). ## Reactivate a user Open the inactive user and choose **Reactivate**. Their status returns to **Active** and access is restored with the same role and profile they had before. ## How it works Deactivation flips the user's active state in PeakCommerce; on the next sign-in attempt the platform refuses the session. For **Customer** users, deactivation in the connected billing system can also remove the customer's portal access, since the user is tied to an External Account — so a billing-side change may take effect even if you didn't touch the user here. See [Authentication & Security](/product/using-peakcommerce/authentication-and-security). ## Gotchas * An active impersonation session is not a way to bypass deactivation — once a user is inactive, new sign-ins (theirs or an impersonator's) are blocked. # Administrator Users Administrator users are the people who build and run your tenant. The **Admin** role gives broad configuration access, so it's the role you assign to employees who set up the catalog, design journeys, wire up integrations, and manage other users. Because admins can change how the whole platform behaves, keep this group small and scope each admin with a profile. ## How to create one Open the **user menu** (your name, bottom-left) → **Settings → Users**, click **Add User**, set **Role** to **Admin** and choose an Administrator **profile**. The admin receives an Auth0 email to set their own password — you never set it for them. ## What admins can do With the Admin role, a user can reach platform configuration — catalog and offers, content (pages and components), journeys, integrations and API keys, users and profiles, audit logs, and tenant settings. Admins do *not* carry an **External Account** link; that field is only for Customer and Partner users tied to a billing account. ## Scope each admin with a profile The role grants the *area* of access; the **profile** decides exactly what each admin can see and do. Pair the Admin role with a permission profile to limit one admin to, say, content and journeys while another manages billing and integrations. Don't rely on the role alone — two admins with different profiles can have very different reach. **Who and when:** assign Admin to trusted internal staff who configure the platform, not to people who only assist customers (use **CSR** for that). See [User Roles](/product/using-peakcommerce/users-and-user-roles/user-roles), [Profiles & Permissions](/product/using-peakcommerce/profiles-and-permissions), and [Authentication & Security](/product/using-peakcommerce/authentication-and-security). # Customer Users Customer users are your end customers. They sign in to the **customer portal** to manage their own account — view and change subscriptions, see invoices and payments, and reach support. Because a customer should only ever see *their* account, this role is tightly scoped to the billing account it's linked to. That link is the most important part of setting one up correctly. ## How to create one Open the **user menu** (your name, bottom-left) → **Settings → Users**, click **Add User**, set **Role** to **Customer**, choose a customer **profile**, and link the user to a billing account in the **External Account** field. The customer receives an Auth0 email to set their own password. ## The External Account link A Customer user's portal access is tied to their linked billing account, shown in the **External Account** column of the users list. This link is what scopes the portal to the right subscriptions and invoices — without it, the customer has nothing to manage. ## One user, several accounts A single user can be linked to more than one billing account. When they are, a **Switch account** option appears in the portal so they can move between accounts, and their choice persists across sessions. See [Multiple account access for a single user](/product/using-peakcommerce/users-and-user-roles/multiple-account-access-for-a-single-user). **Gotcha:** a customer's permissions still come from their **profile**, not the role alone — the profile decides whether they can change plans, cancel, or only view. See [User Roles](/product/using-peakcommerce/users-and-user-roles/user-roles), [Editing a user](/product/using-peakcommerce/users-and-user-roles/editing-a-user), and [Profiles & Permissions](/product/using-peakcommerce/profiles-and-permissions). # Partner Users Partner users are your resellers and channel partners — people outside your company who manage a book of customers on your behalf. They sign in to the **partner portal**, where they work their assigned accounts rather than the whole tenant. Use this role whenever someone needs to act for customers they're responsible for, but should never see your full admin configuration. ## How to create one Open the **user menu** (your name, bottom-left) → **Settings → Users**, click **Add User**, set **Role** to **Partner**, choose a partner **profile**, and link the user to their billing account in the **External Account** field. The partner receives an Auth0 email to set their own password. ## What partner users do From the partner portal, a Partner user manages their assigned customer accounts and their own subscription. Their reach is bounded by their **profile** — so two partners can have different permissions even though they share the role. Like Customer users, Partners carry an **External Account** link; Admin and CSR users do not. **Gotcha:** the single **Partner** role now covers what used to be split into separate partner-administrator and account-executive distinctions. There's no separate partner role to choose — differentiate seniority or reach through the **profile** instead. **Who and when:** assign Partner to external reseller staff; assign **CSR** to your own internal support reps, since the two have different portals and scopes. See [User Roles](/product/using-peakcommerce/users-and-user-roles/user-roles), [Profiles & Permissions](/product/using-peakcommerce/profiles-and-permissions), and the [Partner Portal overview](/product/partner-portal/partner-portal-overview). # Multiple account access for a single user Some customers manage more than one billing account — a parent company with several subsidiaries, an agency handling multiple clients, or a buyer who owns separate subscriptions. Rather than maintaining a separate login per account, PeakCommerce lets a single user reach all the accounts they're entitled to, so they sign in once and move between them. ## How a user is linked to an account A customer user is tied to a billing account through the **External Account** linked on their user record — the same value shown in the **External Account** column of **Settings → Users**. To grant one person access to several accounts, link the additional accounts to that user's record so each one resolves to the same identity. ## Working across accounts When a user is entitled to more than one account, the customer portal lets them choose which account to work in and remembers that choice across sessions until they switch again. Everything they see — subscriptions, invoices, payment methods — reflects the account they currently have selected. ## How it works Access is resolved per account: the platform checks which External Accounts a user is bound to and scopes the portal to those accounts only. Granting or removing an account changes what the user can reach immediately on their next visit — there's no separate per-account password. ## Gotchas * Multiple-account access applies to **Customer** users tied to billing accounts; staff roles (Admin/CSR/Partner) get their breadth from roles and profiles instead. See [User Roles](/product/using-peakcommerce/users-and-user-roles/user-roles). * Deactivating any one of the linked accounts in the billing system can remove that account from the user's reach without affecting the others. # User History When access goes wrong — a permission that shouldn't have been granted, a user who was deactivated unexpectedly — you need to know who changed what, and when. PeakCommerce records every change to users (and to the rest of your tenant) so you can answer those questions with evidence. ## Where to look * **Per-user activity** — open a user from the **user menu** (your name, bottom-left) → **Settings → Users**. The detail page's **Activity**, **Logins**, and **Impersonations** tabs show that user's recent events: profile and password changes, sign-ins, and any times they were impersonated or impersonated others. * **Tenant-wide audit log** — for the full record, open the **user menu** (your name, bottom-left) → **Settings → Audit Logs** (under Observability). Each entry shows the time, the actor, the item changed, the type of change, and the before/after values. Open an entry for its full detail. ## How long it's kept Retention is governed by **Settings → Audit Log Retention**. Older entries age out according to that policy, so export or review anything you need to keep beyond the retention window. ## Gotchas * Impersonation ("Log in as") sessions are attributed to the operator who started them, not silently logged as the customer — check the Impersonations tab to see who acted as whom. * For sign-in and SSO events specifically, see also [Authentication & Security](/product/using-peakcommerce/authentication-and-security). # Profiles & Permissions Profiles control **what each user can see and do** inside PeakCommerce. Every user is assigned a **role** (the broad kind of access) and a **profile** (the detailed permissions within that role). Profiles let you run several permission tiers per role — for example CSR Junior, Senior, and Supervisor — without changing any code. Manage profiles from the **user menu** (your name, bottom-left) → **Settings → Profiles**. * [Profiles Overview](/product/using-peakcommerce/profiles-and-permissions/user-profile-overview) — what profiles are and how they work * [Permission Levels & Record Access](/product/using-peakcommerce/profiles-and-permissions/access-levels-for-permissions) — the access model * [Creating a Profile](/product/using-peakcommerce/profiles-and-permissions/creating-a-profile) — build and configure one * [Comparing Profiles](/product/using-peakcommerce/profiles-and-permissions/comparing-profiles) — see every profile side by side in the Permissions Grid # Profiles Overview A **profile** defines the detailed permissions a user has — which parts of the platform they can see, which records they can view or edit, and the scope of records they can act on. Every user is assigned one profile in addition to their [role](/product/using-peakcommerce/users-and-user-roles/user-roles): the role sets the broad experience, and the profile fine-tunes it. ## Why profiles Profiles let you express permission tiers without code. Common patterns: * **Tiered staff** — CSR Junior (view + limited actions), CSR Senior, and CSR Supervisor (full subscription management). * **Scoped admins** — a Default Admin with minimal permissions versus a full Administrator with access to everything. * **Customer tiers** — a standard customer profile versus a read-only "managed customer" who can view subscriptions and pay invoices but not change or cancel plans. Because **Change Plan** and **Cancel Plan** are [separate permissions](/product/using-peakcommerce/profiles-and-permissions/portal-action-permissions), you can also grant one without the other. * **Partner access** — partner profiles scoped to their assigned accounts. ## How profiles work Each profile is tied to a **role type** (Admin, CSR, Partner, or Customer) and carries permissions across the platform's navigation groups (CRM, Commerce, Content, and so on). For each area you control: * **Navigation visibility** — whether the group appears in that user's sidebar. * **Resource access level** — View or Edit for each resource (Organizations, Orders, Subscriptions, Invoices, and so on). * **Record access scope** — all records, only records they created, or records created by or assigned to them. See [Permission Levels & Record Access](/product/using-peakcommerce/profiles-and-permissions/access-levels-for-permissions) for the full model, and [Creating a Profile](/product/using-peakcommerce/profiles-and-permissions/creating-a-profile) to build one. ## System and default profiles PeakCommerce seeds a baseline set of profiles for every tenant, so each role works out of the box and newly created (or auto-provisioned) users always have a profile to land on: * **Administrator** — full access to every resource. This is a **locked** system profile: it can't be edited, renamed, or deleted, and the name "Administrator" is reserved. Assign it to the people who should hold unrestricted admin access. * **Default Admin** — a minimal-permission admin baseline, for administrators who shouldn't have access to everything. * **CSR Default**, **Partner Default**, and **Customer Default** — the starting profile for each non-admin role, scoped to a sensible baseline (CSR account management, partner access tied to assigned accounts, and customer transaction visibility, respectively). The Default profiles are **yours to tune** — edit any of them to set the baseline you want new users of that role to inherit, or leave them as-is. Administrator is the only profile that's fully locked; everything else you can adjust or extend with your own [custom profiles](/product/using-peakcommerce/profiles-and-permissions/creating-a-profile). Manage profiles from the **user menu** (your name, bottom-left) → **Settings → Profiles**, where each profile shows its role, how many users are assigned, and a summary of its permissions. # Permission Levels & Record Access A profile's permissions are set per resource and combine three controls. ## Navigation visibility Each **navigation group** (CRM, Commerce, Content, Rules & Automation, and so on) has a visibility toggle that controls whether it appears in the user's sidebar. Turn a group off to hide it entirely from that profile. ## Access level For each resource within a group, choose how much the user can do. The levels are cumulative — each one includes everything below it: * **View** — see existing records; no changes. * **Create** — view, plus add new records. Cannot change or delete existing ones. * **Edit** — view and create, plus modify existing records. Cannot delete. * **Full** — everything, including delete. Some resources (such as the Dashboard) are view-only. ## Record access scope For record-based resources, set *which* records the user can act on: * **All records** — every record in the tenant. * **Created by them** — only records the user created. * **Created or assigned to them** — records the user created or that are assigned to them. Record scope is how you keep a CSR or partner limited to their own book of business while still giving them Edit access to the records they own. # Portal Action Permissions Beyond navigation visibility and View/Edit access, a profile controls which **portal actions** its users can perform — the self-service and CSR-assisted operations exposed in the customer, partner, and CSR portals, such as changing a plan, cancelling one, or revoking a scheduled cancellation. ## Change Plan vs Cancel Plan Changing a plan and cancelling a plan are **separate permissions**, so you can grant one without the other: | Who | Permission | Allows | | --------------------- | -------------------------------------- | ----------------------------------------------------------- | | **Customer** | **Change My Plan** | The customer upgrades or downgrades their own subscription. | | **Customer** | **Cancel My Plan** | The customer cancels their own subscription. | | **Partner** (own) | Change / Cancel My Plan | A partner acting on their own subscription. | | **Partner** (managed) | Change / Cancel Customer Subscriptions | A partner acting for the customers they manage. | | **CSR** | Change / Cancel Customer Subscriptions | A CSR acting on a customer's behalf. | Because they're independent, you can, for example, offer a profile that can **cancel** but not change plan (route upgrades through a CSR), or one that can **change** plan but must send cancellations to a retention flow. > Previously this was a single combined "manage subscription" grant. Existing profiles were **automatically split** into the separate Change and Cancel permissions, so no access was lost — you simply have finer control now. ## The third grant: Revoke Scheduled Cancellation Undoing a scheduled cancellation is a **third, independent permission** — being able to cancel does not imply being able to un-cancel, and vice versa: | Who | Permission | Allows | | ------------ | -------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | **Customer** | **Revoke Scheduled Cancellation** | The customer un-cancels their own subscription while the cancellation's effective date is still in the future. | | **CSR** | **Revoke Customer's Scheduled Cancellation** | A CSR revoking a customer's scheduled cancellation from the agent console. | | **Sales** | **Revoke Customer's Scheduled Cancellation** | A sales rep doing the same for the accounts they work. | > **Unlike Change and Cancel, this grant isn't on/off — it has three levels.** Change and Cancel are binary: you have the action or you don't. Revoke Scheduled Cancellation is graded **none / view / manage**: > > * **None** (the default on every profile) — no revoke-specific UI at all; the subscription card shows only the standard pending-cancellation banner. > * **View** — the user sees the **cancellation-scheduled banner**, including *why* a revoke is currently blocked (an unpaid invoice, an unreadable billing state), but gets no button. > * **Manage** — the user also gets the **Revoke Cancellation** button. > > View-without-manage is genuinely useful: it lets a rep (or a read-only customer role) **see the scheduled state and its blockers** — enough to explain the situation on a call or chase down an unpaid invoice — **without the power to execute the revoke**, which stays with the profiles you've deliberately granted manage. Two things to remember when wiring it up: * **The permission is the second of two gates.** The retention journey's *Allow revoking a scheduled cancellation* setting must also be enabled — the permission alone shows nothing if the journey doesn't offer the action. See the [Customer Retention Journey](/product/customer-self-service/subscription-management/customer-retention-journey). * **The default is none everywhere** — customer, CSR, and sales profiles all start without it, so rolling out revoke is an explicit decision per profile, not something that arrives silently with an upgrade. Set these on a profile from the **user menu** (your name, bottom-left) → **Settings → Profiles**. They sit alongside the [permission levels and record access](/product/using-peakcommerce/profiles-and-permissions/access-levels-for-permissions) (visibility, View/Edit, and record scope) that govern the rest of the platform. # Creating a Profile Build profiles from the **user menu** (your name, bottom-left) → **Settings → Profiles**. 1. Click **Create Profile**. 2. On the **Details** tab, set: * **Name** — for example "CSR Senior". * **Role Type** — Admin, CSR, Partner, or Customer. * **Description** — what the profile is for (shown in the profiles list). 3. On the **Permissions** tab, configure access: * Toggle each **navigation group** on or off to control sidebar visibility. * For each resource, set the **access level** (View or Edit). * For record-based resources, set the **record access scope** (All records / Created by them / Created or assigned to them). 4. Click **Create Profile**. Assign the profile to users when you create or edit them (see [Creating a New User](/product/using-peakcommerce/users-and-user-roles/creating-a-new-user)). A user's profile can be changed at any time from **Settings → Users**. See [Permission Levels & Record Access](/product/using-peakcommerce/profiles-and-permissions/access-levels-for-permissions) for what each control does. # Comparing Profiles The **Permissions Grid** shows every profile side by side, so you can answer "how do these profiles differ?" without opening each one in turn. Open it from **Settings → Profiles → Permissions Grid**. Profiles run across the top as columns; permissions run down the left as rows. Each cell is what that profile is granted for that permission. The grid is **read-only** — make changes by opening the profile itself. ## What the rows cover The rows are grouped into three blocks: * **Sidebar Sections** — whether each navigation group (CRM, Commerce, Content, and so on) appears in that profile's sidebar. * **Resource Permissions** — the access level and record scope for each resource, grouped by the section it lives in. * **Capabilities** — the named actions a profile can perform, such as *Change Customer Subscriptions* or *Place Order on Behalf of Customer*. ## Reading a cell Access levels are shaded by how much they grant, from View through to Full. See [Permission Levels & Record Access](/product/using-peakcommerce/profiles-and-permissions/access-levels-for-permissions) for what each level means. Two cells look empty but mean different things, and the difference matters: | Cell | Meaning | | -------------- | ----------------------------------------------------------------------------------------------- | | **None** | The profile's role *could* hold this permission, but it has not been granted. You can grant it. | | **—** (shaded) | Not available to that role at all. It cannot be granted, no matter what you do. | For example, Quotes is available only to Admin, CSR, and Sales profiles — so on a Partner profile it shows as unavailable, not as "None". **Click any cell** for the detail: what the level allows, what the record scope means, or — for an unavailable cell — exactly which roles *can* hold it. ## Comparing The **Rows** control is the main tool for comparison: * **All** — every row. * **Granted only** — hides rows no visible profile has. * **Differences only** — keeps just the rows where the profiles actually disagree. **Differences only** is usually the fastest way in: it takes a grid of a hundred-odd rows down to the handful that genuinely differ. Outside that mode, rows that differ are tagged **DIFFERS** so you can spot them while browsing normally. Cells that are unavailable to a role are ignored when working out whether a row differs — a row is never flagged just because the profiles have different roles. ## Narrowing what you see * **Search** — matches the permission name, its description, and its underlying key, so searching *discount* finds **Offers** even though the word is not in its name. * **Role** — limits the columns to a single role. This is also what makes the Capabilities block useful: capabilities belong to one role each, so they only compare meaningfully within a role. * **Compact** — tightens the rows to fit more on screen. ## Exporting **Export CSV** downloads exactly what is on screen, with whatever filters are active — useful for an access review, or for attaching to a change request. ## Related * [Profiles Overview](/product/using-peakcommerce/profiles-and-permissions/user-profile-overview) * [Permission Levels & Record Access](/product/using-peakcommerce/profiles-and-permissions/access-levels-for-permissions) * [Creating a Profile](/product/using-peakcommerce/profiles-and-permissions/creating-a-profile) # Authentication & Security PeakCommerce secures every sign-in through **Auth0** as its identity provider, then governs what each signed-in person can see and do through roles and profiles. Authentication answers *who are you?*; [roles](/product/using-peakcommerce/users-and-user-roles/user-roles) and [profiles](/product/using-peakcommerce/profiles-and-permissions/user-profile-overview) answer *what are you allowed to do?* — keeping the two separate is what lets you adopt enterprise SSO without re-modelling permissions. * **Sign-in** runs on Auth0 Universal Login — staff (Admins and CSRs) and customers alike. Social and enterprise SSO are supported. * **Password and MFA policy** are enforced by Auth0, or by your own identity provider when you bring one. * **End customers** can be signed into the customer portal automatically from your own app via SSO (operator-configured). * **Administrative changes** are recorded in the audit log (**Settings → Audit Logs**). Explore this section: * [Single Sign-On for PeakCommerce Sites](/product/using-peakcommerce/authentication-and-security/single-sign-on-for-peakcommerce-sites) * [Login Pages](/product/using-peakcommerce/authentication-and-security/types-of-login-pages-for-your-peakcommerce-account) * [What Your Web Team Needs for SSO](/product/using-peakcommerce/authentication-and-security/what-will-our-web-team-need-to-do-over-and-above-the-sso-setup) * [Session Management](/product/using-peakcommerce/authentication-and-security/session-management) * [Password Policies](/product/using-peakcommerce/authentication-and-security/understanding-and-configuring-password-policies-in-peakcommerce) * [Viewing Audit Logs](/product/using-peakcommerce/authentication-and-security/viewing-audit-logs) * [Security and Data Protection](/product/using-peakcommerce/authentication-and-security/security-and-data-protection) — how PeakCommerce protects your data and connected systems # Session Management A **session** represents an authenticated user's connection to PeakCommerce. While a session is active, the user moves through the app without signing in again. Sessions matter for security because a session that never ends is a standing invitation to anyone who gets hold of a device — so PeakCommerce ties every session to a defined lifetime and ends it the moment credentials change. ## How sessions work PeakCommerce delegates authentication to **Auth0**. When a user signs in, Auth0 establishes a login session on its authorization server, and the application keeps its own server-side session so it can tell, on each request, whether the user is authenticated. That local session is backed by the database (not just a cookie), and the session cookie is sent over HTTPS, marked HTTP-only, and scoped so it can't be read by page scripts. Signing in with a social or enterprise identity provider (for example Google or an OIDC IdP) adds that provider's session as well — which is what enables a seamless **single sign-on** experience: a user already signed in to Auth0 (or to a linked provider) can be signed into PeakCommerce without re-entering credentials. ## Session lifetime Sessions have an **absolute lifetime** of 24 hours. Once that limit is reached, the user must sign in again regardless of recent activity. There is no separate idle-timeout window today — the clock is fixed from sign-in, not from last action. ## When a session ends * **The user signs out.** Logout destroys the local session and, for SSO users, also clears the Auth0 session (federated logout) so the next sign-in re-authenticates rather than silently resuming. * **The 24-hour lifetime is reached.** * **The user's password or email is reset**, or the account is deactivated. When a user is signed in across paired branded hosts, signing out of one coordinates logout across the linked hosts in the same session group. ## Related * [Single Sign-On for PeakCommerce Sites](/product/using-peakcommerce/authentication-and-security/single-sign-on-for-peakcommerce-sites) * [Password Policies](/product/using-peakcommerce/authentication-and-security/understanding-and-configuring-password-policies-in-peakcommerce) # Single Sign-On for PeakCommerce Sites **Single sign-on (SSO)** lets people reach PeakCommerce without maintaining a separate password here — they authenticate once with an identity provider they already use, and PeakCommerce trusts that result. The benefit is fewer passwords to manage, centralized control of access and MFA in your own identity system, and faster onboarding and offboarding of staff and customers. PeakCommerce has **two independent SSO paths** because two different audiences sign in to two different surfaces. Both are arranged with your PeakCommerce implementation team — neither is self-service in the admin UI. ## Staff / enterprise SSO (Admins & CSRs) Your internal Admins and CSRs sign in on the **staff plane** (the admin portal hosts). PeakCommerce connects to your corporate identity provider over **OpenID Connect (OIDC)** — for example **Okta**, Microsoft Entra ID, or any compliant OIDC provider — so staff use their existing corporate credentials and your IdP enforces password and MFA policy. * The login surface decides the population: staff hosts pin Auth0 to your staff connection, so users go straight to your IdP rather than a connection picker. * PeakCommerce reads **identity claims only** (`sub`, `email`, `name`) from the token. **Roles and permissions are never taken from the token** — they are resolved from the PeakCommerce database when the session is established, so your IdP cannot escalate a user's access. * New staff can be provisioned just-in-time on first login into a least-privilege "pending access" profile, then promoted by an Admin. See [What your web team needs for SSO](/product/using-peakcommerce/authentication-and-security/what-will-our-web-team-need-to-do-over-and-above-the-sso-setup) for the exact handshake values. ## End-customer portal SSO Separately, your **end customers** can be signed into the **customer portal** automatically from inside your own product — they click a link in your app (where *your app is the identity provider*) and land in PeakCommerce already authenticated. This is a silent, app-initiated handoff suited to "My Account" style links. * The handoff is a **signed token (signed-JWT / OIDC)** your app mints and PeakCommerce verifies (signature, audience, expiry, and single-use replay protection) before establishing the portal session. * Identity is joined **by email**; an existing portal user is matched, otherwise one is provisioned automatically. * An SSO'd customer lands on the **Customer Default** profile unless a profile claim in the token maps them to another in-tenant, customer-role profile. A token can never grant a staff-level or out-of-tenant profile. * The token can also carry the customer's external account reference, linking the portal session to their subscriptions and invoices. This path is configured by the implementation team (secrets, audience, and issuer are set per environment); it is not exposed as a tenant-facing setting. ## Related * [Login Pages](/product/using-peakcommerce/authentication-and-security/types-of-login-pages-for-your-peakcommerce-account) * [What your web team needs for SSO](/product/using-peakcommerce/authentication-and-security/what-will-our-web-team-need-to-do-over-and-above-the-sso-setup) * [User Roles](/product/using-peakcommerce/users-and-user-roles/user-roles) · [User Profiles](/product/using-peakcommerce/profiles-and-permissions/user-profile-overview) # What Your Web Team Needs for SSO This page covers the technical handshake your web or identity team performs **once** to connect enterprise (staff) SSO. It assumes you have already decided to enable SSO with your PeakCommerce implementation team — see [Single Sign-On for PeakCommerce Sites](/product/using-peakcommerce/authentication-and-security/single-sign-on-for-peakcommerce-sites) for the bigger picture. ## What PeakCommerce needs from you To connect your **OpenID Connect (OIDC)** provider, the implementation team needs: * **Issuer URL** — the base URL of your provider, used to fetch its OIDC discovery document. * **Client ID** — the application/client identifier PeakCommerce will present. * **Client secret** — supplied securely; it is stored only by reference and never exposed in the admin UI. ## What your team configures on your IdP Allow-list this exact **callback (redirect) URL** in your OIDC application: ``` https://.auth0.com/login/callback ``` PeakCommerce uses a single canonical callback host (callback URLs are exact-match allow-listed, never one per tenant subdomain), so register the value the implementation team gives you verbatim. If a branded custom login domain is in use, the implementation team will tell you whether the callback should reference that domain instead. ## Good to know * **Identity only.** PeakCommerce reads `sub`, `email`, and `name` from the token. Group, role, and permission claims are ignored — access is granted inside PeakCommerce by [role](/product/using-peakcommerce/users-and-user-roles/user-roles) and [profile](/product/using-peakcommerce/profiles-and-permissions/user-profile-overview), so your IdP cannot raise a user's privileges. * **Logout.** If you want sign-out to also clear the session at your IdP, register your post-logout return URL with the implementation team as well. * **Customer portal SSO is a separate setup.** The signed-token handoff that signs *end customers* into the portal is configured differently from staff OIDC — see [Single Sign-On for PeakCommerce Sites](/product/using-peakcommerce/authentication-and-security/single-sign-on-for-peakcommerce-sites). ## Related * [Single Sign-On for PeakCommerce Sites](/product/using-peakcommerce/authentication-and-security/single-sign-on-for-peakcommerce-sites) * [Login Pages](/product/using-peakcommerce/authentication-and-security/types-of-login-pages-for-your-peakcommerce-account) # Login Pages PeakCommerce serves sign-in through **Auth0 Universal Login**, so the same hardened, hosted login experience covers everyone — Admins, CSRs, partners, and end customers — and password handling never lives in the application itself. The login page a person sees depends on which **surface** (host) they arrive on, and that surface decides which population and identity provider apply. PeakCommerce supports: * **Standard hosted login** — the default Auth0-hosted page for admins, CSRs, partners, and customers. * **Branded / custom-domain login** — serve sign-in from your own domain so the experience matches your brand. Custom domains affect the *login* experience only; they do not change how PeakCommerce identifies the tenant or your account. * **SSO sign-in** — when a surface is connected to an identity provider, users are sent straight to that provider instead of seeing a password screen. Staff hosts route to your enterprise IdP; the customer portal can be entered via an app-initiated handoff with no visible login at all. See [Single Sign-On for PeakCommerce Sites](/product/using-peakcommerce/authentication-and-security/single-sign-on-for-peakcommerce-sites). ## Forgot password Every password-based login page offers a **forgot-password** link. The user receives a reset email and securely sets a new password — all handled by Auth0. Users who sign in through SSO reset their password (and manage MFA) in your own identity provider, not here. ## Related * [Single Sign-On for PeakCommerce Sites](/product/using-peakcommerce/authentication-and-security/single-sign-on-for-peakcommerce-sites) * [Password Policies](/product/using-peakcommerce/authentication-and-security/understanding-and-configuring-password-policies-in-peakcommerce) * [Session Management](/product/using-peakcommerce/authentication-and-security/session-management) # Password Policies A password policy sets the rules every account password must satisfy — minimum length, character mix, reuse history, and how often a password must change. Strong policies are your first line of defense against credential-stuffing and brute-force attacks, so it's worth getting them right before you invite staff and customers onto the platform. PeakCommerce delegates all authentication to **Auth0**, so password rules are enforced by Auth0 rather than stored inside PeakCommerce. Length, complexity, history, and expiration are configured during implementation to match your security requirements. Customers don't edit these directly in PeakCommerce unless they bring their own identity provider. ## Policy levels Auth0 offers predefined policies to choose from: | Policy | Requirements | | ------------- | ------------------------------------------------------------- | | **None** | No restrictions | | **Low** | At least 8 characters | | **Fair** | 8+ characters, with upper- and lower-case letters and a digit | | **Good** | Fair, plus a special character | | **Excellent** | Good, plus no more than two identical characters in a row | **Custom policies** can add a higher minimum length (10+), required character types, password history (no reuse of recent passwords), expiration periods, a dictionary of common passwords to block, and exclusion of the user's personal data (name, email). ## Multi-factor authentication Because authentication runs through Auth0, you can layer **multi-factor authentication (MFA)** on top of any password policy. MFA enrollment status is read back into PeakCommerce per user, so administrators can confirm who has a second factor in place. ## Who controls the policy * **PeakCommerce-managed (default)** — your implementation team configures the Auth0 policy with you. We recommend **Good or stronger** as a minimum (or a custom policy); avoid None, Low, and Fair for production accounts. * **Your own IdP** — connect your own identity provider and you keep full control of password and MFA policy within it. To change your policy, contact your account team. ## Related * [Session Management](/product/using-peakcommerce/authentication-and-security/session-management) * [Single Sign-On for PeakCommerce Sites](/product/using-peakcommerce/authentication-and-security/single-sign-on-for-peakcommerce-sites) # Viewing Audit Logs The **audit log** is a tamper-evident record of who changed what across your tenant — configuration edits, user and permission changes, security events, and commerce actions. It's the first place to look when you need to answer "who did this, and when?" for a security review, a support escalation, or a compliance request. Every entry is scoped to your tenant, so you only ever see your own organization's activity. Open the log from the **user menu** (your name, bottom-left) → **Settings → Audit Logs** (under **Observability**). ## What each entry records | Field | Description | | -------------- | ------------------------------------------------------------------- | | **Time** | When the change was made | | **Actor** | The user who made the change (system actions appear without a user) | | **IP Address** | The IP address the change came from | | **Item** | The record or field that changed (resource type and id) | | **Type** | The kind of change (Created, Field Updated, Deleted, …) | | **Action** | The before/after values (From → To) and any additional detail | ## Working with the log Entries are listed newest-first. Open any entry to see its full detail, including related events — other actions taken by the same actor from the same IP address around the same time, which helps you reconstruct a sequence rather than a single change. You can export the log (CSV or JSONL) for offline review or to hand to an auditor. ## Retention and categories Entries are grouped into categories — authentication, security, admin, data access, data change, and system — and each category can keep records for a different length of time. A background sweeper purges entries once they pass their cutoff, so retention is enforced automatically rather than relying on manual cleanup. Control how long entries are kept under **Settings → Audit Log Retention** (default 90 days; configurable from 1 day up to 10 years per category). Security and admin events default to a longer 365-day window; short-lived access events default to 30 days. ## Related * [Audit Log Retention](/product/settings/observability/audit-log-retention) * [Audit Trail and Logs](/product/reporting-and-analytics/audit-trail-and-logs) # Security and Data Protection This page summarizes how PeakCommerce protects your data and the systems you connect to it, and what your team controls. Each section links to the page where you set it up. ## Data in transit * **Your team and your customers reach PeakCommerce over HTTPS.** * **Our connection to the database is encrypted.** Every deployed PeakCommerce environment requires an encrypted connection to its database. * **Webhooks only go to HTTPS endpoints.** When you add or edit a webhook subscription — in **Settings → Webhooks** or through the API — the URL must use `https://`. Loopback and private network addresses are refused, with the reason shown. ## Proving a message came from PeakCommerce Every webhook delivery is signed with a secret that PeakCommerce generates for that subscription. Your endpoint verifies the signature before trusting the payload, and you can rotate the secret at any time: the old and new secrets both sign deliveries for 24 hours, so you can deploy the new one without dropping anything. See [Webhooks](/product/settings/developer-tools/webhooks). Events PeakCommerce receives work the same way in reverse: for example, every event from Stripe is verified against your integration's own signing secret before it changes anything. See [Stripe subscription sync](https://gitlab.com/peakcommerce/peak-help-docs/-/tree/main/integrations/stripe/stripe-subscription-sync.md). ## Credentials and keys * **Each API key is limited to its scope**, and revoking a key takes effect immediately. Use one key per integration so you can revoke one without disrupting the others. See [API Keys](/product/settings/developer-tools/api-keys). * **Webhook signing secrets are generated for you**, never typed in, and are shown only when you create a subscription or choose **Reveal signing secret**. * **Credentials are masked in API call records.** Fields that carry secrets, tokens or keys are masked in the API call records PeakCommerce keeps. ## Who can see and do what * **Sign-in** runs through your identity provider or PeakCommerce's hosted login (Auth0), with the password policy and session rules you set. See [Single Sign-On for PeakCommerce Sites](/product/using-peakcommerce/authentication-and-security/single-sign-on-for-peakcommerce-sites), [Password Policies](/product/using-peakcommerce/authentication-and-security/understanding-and-configuring-password-policies-in-peakcommerce) and [Session Management](/product/using-peakcommerce/authentication-and-security/session-management). * **Profiles and permissions** decide what each user can see and change. See [Profiles & Permissions](/product/using-peakcommerce/profiles-and-permissions/user-profile-overview). * **Changes are recorded.** The audit log shows who changed what, and when. See [Viewing Audit Logs](/product/using-peakcommerce/authentication-and-security/viewing-audit-logs). ## Limits that protect your tenant Rate and concurrency limits stop a runaway script or a burst of traffic from crowding out your customers' checkouts. You can see how close you are to them on [API Usage](/product/settings/observability/api-usage). Limits for API keys are described in [Rate limits](https://gitlab.com/peakcommerce/peak-help-docs/-/tree/main/developers/api-reference/rate-limits.md). ## Questions from your security team For a security questionnaire or anything not covered here, contact your PeakCommerce account team. # Market Studio **Market Studio** is where you configure how PeakCommerce sells in more than one currency. It answers, for every market you operate in, three questions: * **Where do customers arrive?** — which signup journeys and portals belong to this market. * **How do they pay?** — which hosted payment page serves each of those places, in this market's currency. * **Who gets what?** — which language, profile, and other experience settings apply, written as plain-language sentences. Open it from **Commerce → Market Studio**. {% embed url="" %} ## A market is a currency The core idea in Market Studio: **one market, one currency**. "Canada" is the market that sells in CAD; "United States" is the market that sells in USD. A visitor's currency decides their market, and their market decides everything else — the payment page they see, the language they read, the profile they get. Because a market *is* its currency, adding a currency to your business always means adding a market, and vice versa. There is never a question of "which config wins": the market the visitor resolved to is the single source of truth for their checkout. See [Adding a market or currency](/product/using-peakcommerce/market-studio/adding-a-market-or-currency) for the end-to-end setup. ## The Studio at a glance The left rail lists your **markets**. Select one and everything in the tabs is about that market only: | Tab | What it does | | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | [How they pay](/product/using-peakcommerce/market-studio/how-they-pay) | One payment page for each place a customer can arrive, in this market's currency — with live health. | | [Who gets what](/product/using-peakcommerce/market-studio/who-gets-what) | Ordered sentences that assign language, profile, and other facets. | | [Where they arrive](/product/using-peakcommerce/market-studio/where-they-arrive) | The journeys and portals that belong to this market. | | [Trace a customer](/product/using-peakcommerce/market-studio/trace-a-customer) | Follow one hypothetical visitor from arrival to payment page. | Below the market list, **Payment configurations** is a shared view of every payment page registration across markets — provider, currencies, and health in one place. ## The setup checklist A new market starts inactive, with a checklist showing exactly what it still needs before it can serve customers: * **Surface assigned** — at least one journey or portal points at this market. Without an entry point, no visitor can ever reach it. * **Payment pages** — every place has a payment page in this market's currency. * **Payment route** — the routing that connects arrivals to those pages exists. The **Activate** button stays disabled while gaps remain, so a half-configured market can never silently take live traffic. ## Health — trust what actually happened Every payment page in Market Studio carries a live health signal, driven by real traffic: each time a checkout requests that page, the outcome is recorded. **Healthy** means the last real request succeeded. **No traffic yet** means exactly that — nothing has exercised the page, so nothing is known; it is not an error, and it flips to healthy the first time a checkout (or a smoke test) touches the page. ## The market assistant The Studio includes an AI assistant, docked at the bottom of the screen, that can answer questions about your configuration and stage changes for your review. It works the same way as the assistant in the page and component editors: it proposes, you approve. ## Where configuration lives Payment-page selection has exactly one home: Market Studio. At checkout the platform resolves the visitor's market and serves the page your routing names for that place; if no market resolves (for example, a tenant that has not configured markets), the billing integration's default page is used. Individual pages and components do not carry their own payment-page settings — so what you see in Market Studio is always what a customer gets. # How They Pay **How they pay** shows one row for each **place** a customer of this market can arrive — each signup journey and each portal — and the hosted payment page that place serves, in this market's currency. ## Places, not grids A place is anywhere a payment form can appear: * a **signup journey** (your public acquisition checkout), * the **Customer portal** (a customer adding or replacing a card in self-service), * the **CSR**, **Sales**, and **Partner portals** (your teams taking a payment method on a customer's behalf). Each place needs a payment page that matches the market's currency, because a hosted payment page validates and tokenizes the card against a specific billing-system page — and that page carries its own currency, styling, and allowed domains. A Canadian customer in your customer portal and a Canadian prospect on your signup page are both in the Canada market, but they are on different hosts, so they get different pages. ## Reading a row Each row shows the place, the payment page routed for it, and the page's live **health**: * **Healthy** — the most recent real request for this page succeeded. * **No traffic yet** — nothing has exercised this page since it was configured. Not an error; it flips to healthy on the first successful checkout. * An error state names the failure from the last attempt, so a misconfigured page is visible before a customer finds it. Select a row to open the **inspector**, which shows the full resolution for that place: the route that matched, the payment configuration it names, and the underlying page registration. ## Payment configurations A **payment configuration** is the registration of one hosted payment page with the platform: its provider (for example, a Zuora Hosted Payment Page), the page reference, and the currencies it serves. Configurations are shared across markets — the **Payment configurations** view in the left rail lists all of them with their health. If a place shows **no page**, the market has a gap: either no configuration exists in this currency for that kind of place, or no route connects them. The [setup checklist](/product/using-peakcommerce/market-studio#the-setup-checklist) counts these gaps, and the market cannot activate while any remain. ## Routing by brand If your tenant has [brands](/product/settings/organization/brands), each route can serve one brand or **Any brand**. Choose it in the route's **Brand** field; the route row shows a brand badge. * A checkout on a brand's domain uses routes for **that brand** or for **Any brand**. If a brand route and an any-brand route would both match, the brand's own route wins. * A brand's checkout **never falls back** to the market's default configuration. With no matching route, the customer sees that payment isn't set up rather than getting another brand's page. * A configuration that a brand route points at belongs to that brand, and isn't used as the default for checkouts that have no brand. When customers pick a payment method on the page first (for example **Debit or credit card**, **American Express** or **Bank account**), the route's configuration must offer that method. To give one brand three methods, create three routes for that brand, each pointing at a configuration that declares one method (Card, Amex or ACH). The **By brand** table under **How they pay** shows, for each brand and method, which configuration a checkout resolves to in this market. **No route** marks a gap; **shared** means an any-brand route answers it. Use **＋ Route** on a row to add a route for that brand. ## One important property The page shown here is the page a customer actually gets. Checkout resolves the visitor's market and serves this routing — there is no per-page override that can silently substitute a different payment page. If you want a place to serve a different page, change it here. --- [Next Page](https://docs.peakcommerce.com/llms-full.txt/1)