> ## Documentation Index > Fetch the complete documentation index at: https://waffo.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Running Multiple Brands Under One Account > How to run several brands or business lines under one Waffo account using SubMIDs: per-brand checkout name and logo, which level wins, what happens before you configure anything, what becomes fixed, extra information some payments collect, and how the USD amounts in your reports are converted. This page is for accounts that sell under more than one brand, storefront or business line. Page-level styling controls are covered by the Customizing the Checkout Page docs; this page is about the account structure that makes those controls differ per brand. ## I have several brands. Do I need a separate Waffo account for each? No, and you do not need to change your merchant type either. The supported structure is to keep your existing MID and attach a **SubMID per brand or business line**. Each SubMID can carry its own customer-facing identity while your account, contracts and reporting stay in one place. What a SubMID gives you: | Per SubMID | Effect | | - | - | | Cashier display name | The name your buyers see on the checkout page and receipt | | Merchant logo | Its own logo list, uploaded separately from the MID's | | Checkout styling | Its own colors and sizes, or inheritance from the MID | | Payment-method ranking | Its own ordering, per country | | Order creation | Orders can be created against the MID or against a SubMID | ## Which name and logo does the checkout show for a SubMID order? Resolved highest-first: | Priority | Source | | - | - | | 1 | What you sent on the order — `brandInfo.cashierDisplayName` (max 128 chars) and `brandInfo.cashierLogoUrl` (max 512 chars) | | 2 | The **SubMID's** configured value | | 3 | The **MID's** configured value | So the MID acts as the fallback identity: a SubMID with nothing configured presents the MID's name and logo rather than presenting nothing. If neither level has a display name configured, the merchant-name field is simply hidden — your KYB-registered legal name is not substituted in. Both order-level fields are per session and change nothing stored. They are the right tool when brand is a property of the individual transaction rather than of a business line. ## Does the MID always act as the fallback identity? For a standard merchant account, yes: an order on a SubMID with no display name of its own shows the MID's. There is one exception — accounts set up as **institutional merchants** resolve the display name from the **SubMID only**. If that SubMID has no display name configured, the merchant-name field is hidden rather than falling back to the account level. If you are unsure which applies to your account, check whether a SubMID with no configuration shows your account-level name on a test checkout page. ## My brand varies per transaction, not per business line. Do I still need SubMIDs? Not necessarily. If the deciding factor is the individual order rather than a lasting business line, send the identity on the order instead: | Field | Limit | Note | | - | - | - | | `brandInfo.cashierDisplayName` | 128 characters | Overrides the configured display name for that session | | `brandInfo.cashierLogoUrl` | 512 characters | Accepts either an image URL (`http://`/`https://`) or a pre-created logo ID (`logo_…`) | An invalid value in either field is **dropped silently** and the order is still created — it renders with your configured identity, with no error to explain the difference. Validate what you send. The logo ID form, and how IDs are allocated per MID and per SubMID, are covered in the Customizing the Checkout Page docs. Use SubMIDs when the difference is durable (a brand, a storefront, a business line with its own look and its own reporting cut); use the order fields when it is per transaction. ## I am about to attach my first SubMID. Will anything change for my existing traffic? No. Until you configure something at the SubMID level, everything continues to resolve to your existing MID configuration — same checkout name, same logo, same styling, same ranking. Attaching a SubMID is not itself a customer-visible change; configuring it is. In the Portal each SubMID is listed with its state, so you can see at a glance what has diverged: | Tag | Meaning | | - | - | | **Using MID config** | Nothing configured at this level yet | | **Customized** | This SubMID has its own logos or styling | **Reset** on a customized SubMID returns it to Using MID config. ## What becomes fixed once I start using a SubMID? The structure. Once a SubMID has completed its initial onboarding steps, or has processed live transactions, the arrangement is **locked and cannot be reversed** — you cannot unwind that SubMID back into the MID afterwards. Consequence for planning: decide your brand-to-SubMID mapping before you go live rather than after. Adding further SubMIDs later is fine; collapsing existing ones is not. ## Can each brand have a different set of payment methods and a different order? Ordering, yes — payment-method ranking is configured per country and can be set per SubMID, independently of the MID. Which methods exist at all is governed by your agreements, not by the SubMID structure, so a SubMID cannot make a method available that your account does not have. See the Checkout Payment Method Display Rules page for how ranking, grouping and availability interact. ## Some of my transactions ask the buyer for extra details. Why only some? Certain payment methods require information Waffo cannot supply from the order — most commonly a verified email address — before they will accept the payment. When a payment routes to such a method, the checkout collects what that method requires, and where the method requires verification, it also asks the buyer to confirm the address with a one-time code sent to it. Two consequences for your integration: * It varies **per transaction**, because it follows the routed payment method, not your account or your brand. Two orders of the same amount from the same buyer can differ. * Sending a usable `userInfo.userEmail` at order create reduces typing: it can prefill the field. For some methods the address is fixed for that payment and cannot be replaced by the buyer. The mechanics of that step — code lifetime, the verified window, length limits — are in the Checkout Forms, Prefill & Error Handling page. ## Your report shows a USD amount that does not match what I calculated. Why? Because report USD figures are not converted at the rate of the moment of the transaction, and not at a rate we quote. The basis is: ``` TPV (USD) = Σ [ order amount / market closing rate on the day the transaction succeeded, in Waffo's reporting time zone ] ``` Three things in that formula explain almost every discrepancy: | Element | Detail | | - | - | | **Rate** | The **market closing rate** for the day — not an intraday rate, and not the rate applied to the payment itself | | **Day** | The day the transaction **succeeded**, in Waffo's reporting time zone — not your local calendar day, and not the day the order was created | | **Per transaction** | Each transaction is converted on its own day, then summed. A period total is not the period's amount at one single rate | Fallback: when the relevant day is not a trading day, or the rate cannot be retrieved, the most recent available closing rate is used instead. So a month's report total will normally differ from "total local currency × the rate I looked up today", and both numbers can be right. Reconcile transaction-by-transaction, on the success date, if the figures must agree. ## Which transactions are counted in the report volume? Only transactions that reached a **successful** state, converted on the day that success occurred. A transaction that was created in one period and succeeded in the next is counted in the period it succeeded — which is a second common reason a month-boundary total does not match an order-creation-based count of your own. ## Is the report USD amount the same as what my buyer paid or what I get settled? No — treat them as three different numbers with three different purposes: | Number | What it is | | - | - | | Report USD amount | A reporting conversion of the order amount, on the basis above. For comparing volumes across currencies | | What the buyer paid | The amount in the buyer's payment currency, at the rate applied to that payment. Shown on the checkout page and the receipt | | What you are settled | Determined by your settlement currency and cycle. See the settlement documentation | Only the second one is money that moved at that rate. The first is a measurement. ## Where do I see per-brand numbers? Transaction and report data carry the SubMID, so you can separate business lines in the Portal and in exports without splitting accounts. Report subjects, delivery and subscription options are covered by the reporting documentation. *** Planning a multi-brand setup, or seeing report figures you cannot reconcile? [Contact support](mailto:support@waffo.com) — for reconciliation, include the order IDs and the success dates you are comparing against. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.