> 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/settings/organization/brands.md). # Brands **Settings → Brands** is where you manage the brands you sell under inside one PeakCommerce tenant — for example, two product lines that each have their own name, logo and website, but share your catalog, your staff and your customers. A tenant with no brands works exactly as it did before. Adding brands changes nothing until you start using them. ## What a brand is A brand groups the parts of your tenant that belong together and presents them under one name. It is not a separate account: * **Customers are shared.** One person who buys from two of your brands is one customer, with one sign-in. * **The catalog is shared.** A brand decides how products are presented, not which catalog exists. * **Staff are shared.** Your team serves every brand from the same queues. ## The Brands list **Settings → Organization → Brands** lists each brand with its logo, name, legal company name, billing connection, support contact (email and phone), how many domains serve it, and its status. **New brand** creates one. **Brand source** opens the [brand source](#brand-source) setting. The **⋯** menu on a row offers: * **View** — the brand's page. * **Edit** — the brand's edit form. * **Archive** — for a brand that accounts, subscriptions, orders or domains already use. Archiving keeps that history and stops the brand being chosen for anything new. * **Delete** — only for a brand nothing uses yet. Deleting can't be undone. * **Restore** — for an archived brand. Each of these asks you to confirm first. ## Creating and editing a brand New brand and Edit open a full page with two sections. **Identity** | Field | What it's for | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Name** | How the brand is shown in PeakCommerce and to customers. | | **Legal company name** | The legal entity behind the brand. | | **Logo** | Shown on this brand's checkout, portal and emails. Choose **Upload logo**; **Remove** clears it. PNG, JPG, SVG or WebP, up to 256 KB. SVG files that contain scripts or links to outside content are refused. | | **Support email** | Where this brand's customers should write for help. | | **Support phone** | The number this brand's customers can call. | | **Slug** | The brand's short, permanent key, used in reports, exports and the API. Lowercase letters, numbers and hyphens. It's filled in from the name; you can change it until the brand is in use. | | **Active** | On the edit form only. Turning it off archives the brand. | **Billing** | Field | What it's for | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Billing connection** | The billing integration this brand invoices and collects in (for example your Zuora tenant, a BillingPlatform instance or a Stripe account). Every brand bills in exactly one; several brands can share one. | Changes, including a new logo, are saved when you choose **Save changes** (or **Create brand**). **Cancel** leaves the brand as it was. ## Viewing a brand Choose **View** from a brand's **⋯** menu to open its page. It shows the brand's details — name, legal company name, logo, support email and phone, how many domains serve it, slug, status, and when it was created and last updated — and its billing connection and billing system. Choose **Edit** to change them. Domains are assigned to a brand from [Domains](/product/settings/organization/domains.md) with **Change Brand**. ## How records get their brand A brand is recorded automatically at the moment of sale, never chosen by the customer: * A **subscription** and its **order** take the brand of the base rate plan sold (see [Product brands](/product/using-peakcommerce/products-and-bundles/product-brands.md)). * Every **order line** records the brand of its own rate plan, so a product sold under one brand still reports under that brand even if it sits on another brand's subscription. * If the rate plan has no brand yet, the sale takes the brand of the domain it was bought on. * A **storefront cart** order records a line for each item, with that item's rate plan and its brand, the same way a journey order does, so cart sales show up in the brand report. * A subscription created in your **billing system** (not sold through PeakCommerce) takes the brand of the rate plans it's on. If its plans belong to two brands, it's reported as an exception rather than assigned to either. * An **account** carries the brand of the domain it was first created on. * Records created before you added brands, or from places with no brand (your admin site, the API) with rate plans that have no brand, carry no brand and show as **No brand**. If you set a [brand source](#brand-source), a subscription's brand comes from that field in your billing system instead. ## Brand source Your billing system may already record each subscription's brand in a field of its own, for example a **Brand** picklist on the subscription. **Brand source** tells PeakCommerce to use that field. Open it with **Brand source** on the Brands list. The Brand source page shows the billing system, the object (**Subscription**), the field, and each of the field's values with the brand it belongs to. Values that aren't mapped yet show **Not mapped**. Choose **Edit** to change it: * **Field**: choose the subscription field that holds the brand. The list comes from your billing system. * **Values**: choose a brand for each value. Two values can belong to the same brand. **Add value** adds one that isn't in the list, for a field that isn't a picklist. * **Save changes** saves it, and **Cancel** leaves it as it was. **Remove brand source** goes back to brands from rate plans. With a brand source set, each subscription's brand is the brand its value is mapped to. The invoices that bill it show that brand's logo and are paid through that brand's payment gateway. A subscription with **no value**, a value that **isn't mapped**, or a value mapped to an archived brand has no brand. Its invoices can't be paid online: the customer sees the usual "can't be paid online" message with your support contact, and the subscription is recorded in **API Call Stats** so your team can set or map the value. PeakCommerce never guesses a brand from the rate plans instead. Without a brand source, nothing changes: brands come from the rate plans, as described above. **Scan billing system** in the brand report follows the same setting. With a brand source, it counts subscriptions by their mapped brand and shows how many have no value or an unmapped value. ## Brands across your workspace Once you have brands, brand shows up wherever it helps you find things: * **Organizations**, **Journeys** and **Pages** get a **Brand** column and a **Brands** filter. Records with no brand show **No brand**, and the filter can find those too. * A journey or page can belong to a brand. Set it in the journey's **Settings → Details → Brand**, or the page's **Edit** form. Leave it as **Shared across brands** for something every brand uses. Tagging a journey doesn't decide which brand its sales carry; the domain it runs on does. * **Analytics → Overview** has a brand selector. **All brands** shows your totals plus an **MRR by brand** breakdown; pick a brand (or **No brand**) to see just its numbers. Payment page sessions count toward the brand of the page they ran on. ## The brand report **Analytics → Brands** (shown once you have brands) answers three questions for a date range: * **What each brand sold.** Products and rate plans from completed orders, grouped by the brand of each line's own rate plan. An add-on from one brand sold on another brand's order counts for the add-on's brand. * **Cross-brand exceptions.** Order lines whose rate plan belongs to a different brand from the order they're on. One subscription belongs to one brand, so each of these is revenue that sits with a different company from the one that billed it. **Scan billing system** also checks subscriptions created outside PeakCommerce and lists any whose current rate plans belong to more than one brand. The scan reads your whole billing system, so it runs only when you ask. If it fails, you see an error, never an empty list. * **Records without a brand.** How many subscriptions, orders, order lines and active rate plans carry no brand. Give rate plans a brand under **Product Catalog → Brands**; records sold earlier keep no brand. ## What customers see On a brand's customer portal, a customer sees only that brand's subscriptions. The same person can buy from two of your brands with one sign-in; each portal shows them just its own. A subscription created in your billing system shows on the portal of its rate plans' brand; one with plans from two brands shows, in full, on both. A subscription with **no brand** never appears on a brand's portal — only on your tenant's unbranded site. Invoices follow their subscriptions: a brand's portal lists the invoices that bill that brand's subscriptions. An invoice that bills subscriptions of two brands appears, in full, on both portals. An invoice with no subscription on it (a one-time charge) carries no brand, so it appears only on your tenant's unbranded site, never on a brand's portal. If your sign-in link names a brand (the optional `brand` claim), it must match the brand of the portal it's used on. A link for a different brand is refused and recorded in Login History. ## Why some changes are blocked Once accounts, subscriptions or orders carry a brand, three things are locked so your history stays correct: * **The slug can't change.** Reports and exports group records by slug; renaming it would split a brand's history in two. * **The billing system can't change** once it's set. Those records were billed there; moving the brand would split its history across two billing systems. * **The brand can't be deleted.** Deleting it would erase which brand those records were sold under. Choose **Archive** from the brand's **⋯** menu in the Brands list instead. A brand that still has hostnames can't be deleted either: move the hostnames to another brand first, so no portal quietly starts showing every brand's subscriptions. ## Why some sales are refused Each brand is its own merchant account, so PeakCommerce checks the brand of what's being sold before anything is charged: * **One brand per order.** An order that mixes plans from two brands is refused, for customers and for your staff alike: *"This order mixes brands (\[first brand] and \[second brand]). Each brand's plans need their own order."* Place a separate order for each brand. * **A brand's address sells only that brand.** On a customer-facing journey or storefront that belongs to a brand, a plan from another brand is refused with *"\[plan name] isn't available here. Nothing was charged."* CSR and sales journeys are exempt, because your staff don't collect through that address. * **Publishing checks it first.** A customer-facing journey tagged to a brand can't be published while its product set offers another brand's plans. The error names each plan and its brand; take those plans out of the set, use a set for this brand, or change the plan's brand under **Product Catalog → Brands**. * **A subscription is created where its brand bills.** If a brand's billing system (on the brand's page) isn't the one a journey's action writes to, the sale is refused and nothing is created. These checks run on every way a sale is made: storefront carts and every journey, whichever billing system the journey writes to, before anything is sent to it. * **Plan changes keep a subscription to one brand.** Changing a subscription's plan or adding an add-on is refused if the subscription would end up with plans from two brands. This covers the customer portal, your CSR and sales portals, Slack and the assistant. On a brand's customer portal, a customer can only add that brand's plans. Your staff can make a change from any address, but still can't mix brands on one subscription. Refused sales are recorded in **API Call Stats**, so you can see how often it happens and where. ## Brands that are separate companies If each of your brands is its own legal entity and you want its subscriptions on their own invoices, map **Invoice Separately** in the journey's commerce action. A journey that doesn't set it leaves the decision to Zuora's own default. When a customer moves subscriptions onto a new payment method, the payment method has to have been saved through the same payment gateway those subscriptions are charged through. Each brand charges through the gateways of the payment configurations routed to it in **Market Studio**. If they don't match, or either one isn't known, nothing is changed and the customer sees *"This payment method can't be used for one of the subscriptions you chose, because it's billed by a different company. Nothing was changed."* ## Who can see and change this Managing brands requires the **Brands** permission. Administrators have it; grant it to other profiles in **Settings → Profiles**. --- # 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 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/product/settings/organization/brands.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. 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.