> For the complete documentation index, see [llms.txt](https://docs.peakcommerce.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.peakcommerce.com/product/using-peakcommerce/products-and-bundles/offers-and-discounts.md). # 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. ## 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.md). 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.peakcommerce.com/product/using-peakcommerce/products-and-bundles/offers-and-discounts.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.