> 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/journeys-and-pages/pages/payment-pages-by-brand.md).

# Payment Pages by Brand

A **payment page** is where a customer pays an invoice or updates the card or bank account they pay with. If you have [brands](/product/settings/organization/brands.md), each brand gets **its own payment page** on its own domain, so its wording, layout and options can differ.

## Which payment methods a page offers

Open the page's **Settings** (from the Pages list, **⋯ → Settings**) and choose the **Payment methods on this page**:

* **Debit or credit card**
* **American Express**
* **Bank account (ACH)**

When a page offers more than one, the customer picks a method first. That choice decides which hosted payment form loads.

## Which payment form opens

A payment page doesn't pick its payment form itself. When a customer chooses a method, PeakCommerce looks up the route in [Market Studio → How They Pay](/product/using-peakcommerce/market-studio/how-they-pay.md) for:

* the **brand** of the domain the page is on,
* the page's **market** and currency, and
* the **method** the customer chose,

and opens the Zuora hosted page that route leads to. To give a brand an American Express form, add a route for that brand pointing at a configuration that offers Amex.

## When a method isn't set up

If there's no route for that brand and method, the customer sees **"… isn't available on this page right now"** with a reference like `PC-7F3A-19C2`, and can choose another method. PeakCommerce never shows another brand's payment form instead.

Each of these is recorded as a failed **market-router** call in **Settings → API Call Stats**, with the page, brand, method and the same reference, so you can find and fix the gap.

## Build the page from payment blocks

In the page editor, the **Payment** group has the blocks a payment page is made of. Add the ones you need and arrange them like any other block; all of their wording can be edited in the block's settings.

| Block                     | What the customer does with it                                                                                           |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| **Payment Actions**       | Chooses to **pay invoices**, **update their payment method**, or both.                                                   |
| **Open Invoices**         | Ticks the invoices a payment applies to. Turn on **Allow paying part of an invoice** to let them enter a smaller amount. |
| **Subscription Selector** | Sees their subscriptions and, where your billing system supports it, picks which ones the new payment method is for.     |
| **Payment Authorization** | Reads your authorization text and ticks the box to accept it.                                                            |
| **Zuora Hosted Page**     | Picks a payment method and enters their card or bank details.                                                            |

A few things to know:

* **Only what's needed shows.** If the customer turns off *Pay invoices*, the invoice list hides and the payment form just saves their new payment method. Saving a payment method needs a payment link (see below).
* **The form waits until they're ready.** It stays locked until they choose an action, tick at least one invoice (when paying), and accept the authorization (when you've made it required). A short message above the form tells them what's missing.
* **Which invoice is ticked first.** In **Open Invoices → Selected when the page opens**, choose *All open invoices*, *Only the invoice in the link* (the invoice the email was sent for), or *None*.
* **Amounts are always checked.** When the customer pays, PeakCommerce checks every invoice and amount against the account's open invoices before anything is charged. A partial amount on a page that doesn't allow it is refused.
* **If the amount due changed.** When a payment or credit lands after the page opened, nothing is charged: the customer sees that the amount changed, the invoice list updates to the current balances, and the payment form reloads so they can pay again.
* **If the billing system can't be reached.** Nothing is charged, and the customer is asked to try again in a few minutes. The failure is recorded in **Settings → API Call Stats**.
* **Choosing subscriptions.** The Subscription Selector shows only when the customer is updating their payment method, and only on a page opened from a payment link. It lists the account's active subscriptions for this brand — product and amount, nothing else. Subscriptions sold under another brand aren't listed or counted; on a brand's page the block notes that subscriptions managed elsewhere aren't shown.
  * Whether customers can choose is set per page, in the block's **When a customer saves a new card** field. The default updates the card for the whole account.
  * When the page lets customers choose and your billing system supports it, the customer ticks the subscriptions they want and chooses between **Only the selected subscriptions** and **Make it the account's default payment method**. If some subscriptions couldn't be switched, the customer is told how many were, and the link keeps working so they can try again.
  * When the page updates the card for the whole account, there is nothing to choose: the block lists the subscriptions and explains that the new payment method becomes the account's default.
  * When the page lets customers choose but that isn't available any more, the page says so and refuses the new card. Nothing is changed.
  * If the list can't be loaded, the customer is told, and the payment method can't be saved until it loads.
* **Clearing a message brings back ours.** If you empty a message field, the page shows the standard wording rather than nothing, so a customer is never left without an explanation.
* **Placeholders.** Some messages fill in values for you: `{method}`, `{count}`, `{total}` and `{amount}`. Keep the braces exactly as shown.

## Payment links

A page on a brand's hostname only opens from a **payment link**: a signed link made for one account and one invoice. A plain link without one shows a message saying the link can't be used.

* **Making a link.** Your billing emails get one from the API (`POST /api/v1/payment-links` with the page slug, account and invoice). See the API reference.
* **How long it works.** Until the invoice is paid in full, or until its due date plus your grace period (7 days unless PeakCommerce support changes it), whichever comes first — never longer than 30 days. Paying part of the invoice keeps the link working for the rest.
* **Updating a payment method uses the link up.** The new method is attached to the account and made its default; only then does the customer see a success message, and the link stops working. If the method was attached but couldn't be made the default, the customer is told exactly that and the link keeps working. A failed attempt never uses the link up.
* **Every refusal looks the same.** A link that's expired, used, paid or tampered with gets the same message, so the page never reveals which one it was. Repeated failures from one visitor are slowed down and recorded.
* **After paying.** Once the invoice is paid in full the link stops working, so the confirmation tells the customer how to change their payment method later (the text is editable in the Zuora Hosted Page block). To pay and change the payment method with one link, choose both actions before paying.
* **Getting a fresh link.** When your billing system is set up for it, the message has a **Send me a new link** button. The new link goes only to the billing contact on the account — never to an address the visitor types — and is limited to a few per invoice and per account each day. Without that setup the button doesn't appear.

PeakCommerce support sets up the signing keys and the fresh-link option for your tenant. The fresh-link option is only switched on after a live check confirms your billing system accepts the update.

## Duplicate a page for another brand

From the Pages list, choose **⋯ → Duplicate for another brand…** on an existing page:

1. Pick the **Brand**. The name and slug are suggested from it.
2. Optionally pick one of that brand's **Hostnames** to serve the new page.
3. Choose **Create page**.

The copy keeps the page content, payment methods and CVV/signature settings, and takes its company name from the brand. It's independent: later changes to the original don't carry over. Review the authorization wording before you publish, since it's usually brand-specific.


---

# 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/journeys-and-pages/pages/payment-pages-by-brand.md?ask=<question>&goal=<user_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.