> ## 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. # Merchant Switcher, Demo Mode & Environments > The merchant ID dropdown at the top of the Portal and the alias beside it, how it differs from the sub-merchant filter, what the Demo Mode badge means and how to leave it, whether sandbox and production are the same account, and what to do when an administrator leaves. Questions about *which* account you are looking at: the switcher at the top of the Portal, the two environments, and the badge that tells you the account cannot transact yet. Roles, invitations, passwords and two-step verification are in [Merchant Portal Operations](/docs/en/support/portal-operations-faq); how brands and sub-merchants relate is in [Multiple Brands & Sub-Merchants](/docs/en/support/multi-brand-and-sub-merchant-faq). ## What is the merchant ID dropdown at the top of the Portal? It selects **which merchant account you are working in**. It only appears when your user is attached to more than one, so a single-account user never sees it. Everything below the header follows the selection: transactions, settlements, balances, agreements, integration keys and settings all belong to the selected merchant ID. There is no combined "all merchants" view — you look at one account at a time. You can type in the dropdown to filter, and it matches on the merchant ID, the merchant name, and the alias in brackets, so any of the three finds the row. ## What is the name in brackets next to a merchant ID? An alias for the account, shown so you can tell two similarly named entities apart. It is displayed in the dropdown, in the collapsed selector, and in the hover text, and it is searchable — but it is **not editable from the Portal**: there is no field for it anywhere in the interface. If the alias is wrong or you want your own project name there, ask your Waffo contact to change it. ## How is that different from the `Sub Merchant Id` filter on the lists? They operate at different levels: | Control | Level | Effect | | - | - | - | | Header merchant switcher | The merchant account (MID) | Changes which account's data the whole Portal shows | | `Sub Merchant Id` filter | A sub-merchant under the current account | Narrows one list to traffic of one sub-merchant, inside the account you are already in | So the switcher moves you between accounts; the filter narrows within one. The filter is only rendered on accounts that actually operate sub-merchants — see [Multiple Brands & Sub-Merchants](/docs/en/support/multi-brand-and-sub-merchant-faq). ## Why was I sent back to Home and my filters cleared when I switched? Both are deliberate. Switching resets the Portal to Home and clears the filters kept from the previous account, because a filter set built for one account — a sub-merchant, a payment method, a currency it used — will not be meaningful in the next one and would silently return nothing. The same reset happens if you switch account in one browser tab and then return to another tab that is still on the old account: that tab reloads onto Home rather than showing stale data. If you want two accounts side by side, use two browser profiles rather than two tabs. ## Why does my account show a Demo Mode badge, and can I still receive real money? The badge appears when your user holds the **read-only demo role**. Hovering it says you are in Demo Mode and need to verify your business details before you can transact. In that state the Portal is for looking around: screens are populated so you can see what each one does, and several of them carry an extra explanatory tooltip that only demo users get. It answers your question directly: **no real money moves while the account is in this state.** Live payments require verification and payment enrollment to complete — see [Payment Enrollment](/docs/en/support/payment-enrollment-faq) for the exact gates. ## How do I leave Demo Mode? By completing the onboarding path, not by changing a setting. In order: 1. Submit account verification (your entity, ownership, and documents). 2. Wait for the verification result and clear anything sent back to you. 3. Let payment enrollment complete for the methods you want. [Getting Started as a Self-Serve Merchant](/docs/en/support/getting-started-self-serve-faq) walks the whole path, [KYB Document Requirements](/docs/en/support/kyb-document-requirements-faq) covers the documents, and [Payment Enrollment](/docs/en/support/payment-enrollment-faq) covers the stage after approval. There is nothing to click in the Portal to remove the badge itself. ## Is my sandbox sign-in the same account as my production sign-in? No. The two environments are separate Portals on separate hostnames, and your sign-in belongs to one of them. The sign-in screen tells you which environment you are on and offers a link to the other; self-serve **sign-up always lands in the sandbox** — submitting the registration form on the production host sends you to the sandbox host to register. What follows from that: | | Consequence | | - | - | | Passwords | Set and changed per environment; changing one does not change the other | | Two-step verification | Configured per environment in the same way | | Merchant ID and credentials | Different per environment — see [Sandbox Environment & Access](/docs/en/support/sandbox-environment-and-access-faq) | | Configuration you make in the sandbox | Stays sandbox configuration; it does not become your live capability set | Which URLs belong to which environment, whether enabling a payment method in the sandbox enables it in production, and where to read your merchant ID for the environment you are in are all covered in [Sandbox Environment & Access](/docs/en/support/sandbox-environment-and-access-faq). What you can actually accept in production comes from what you are contracted and enrolled for — see [Payin Agreements & Limits](/docs/en/support/payin-agreements-and-limits-faq). ## Can one email address reach several merchant IDs? Yes. A user can be attached to more than one merchant account, and that is exactly what the header switcher is for — you sign in once and move between them. You do not need one login per merchant ID. Two consequences worth knowing: * Your **role is per merchant account**, so you can be an administrator on one and read-only on another. * Two-step verification belongs to the **user**, not the account, so it applies wherever that email signs in — see [Merchant Portal Operations](/docs/en/support/portal-operations-faq). ## We are adding another legal entity. New merchant ID, or a new Portal account? Neither requires a second login. A new entity becomes an additional merchant account reachable from your existing user through the switcher, and it goes through verification on its own — an entity is approved as an entity, so the documents are submitted for the new one even where the group is the same. Whether a second entity is the right structure at all, versus sub-merchants under the account you have, is answered in [Multiple Brands & Sub-Merchants](/docs/en/support/multi-brand-and-sub-merchant-faq): sub-merchants separate brands inside one account, additional merchant accounts separate legal entities. Sub-merchant identifiers themselves are not self-allocated from the Portal — there is no screen that creates one. ## Our administrator has left the company. What can we do ourselves? From `Settings → Team`, an administrator can: | Action | Notes | | - | - | | **Remove** the departed user | Ends their access; their rows are struck from the team list | | **Edit** their role | Changing a role signs that user out immediately | | **Resend** an invitation | Only for users still in `Pending` | | Turn **off** two-step verification for a user | The fallback when their codes are undeliverable | Two rows resist all of this: **your own**, and any row the Portal marks as not modifiable — the account's original super administrator among them. On those, Edit and Remove are visibly disabled rather than hidden. So the answer splits in two: * **An ordinary administrator left** — remove or re-role them yourself; nothing is lost, because Portal records belong to the merchant account rather than to the user who happened to be looking at them. There is nothing to "hand over". * **The super administrator's own mailbox is gone** — that cannot be reassigned or reset from the Portal by anyone, including another administrator. Raise it with support with the new contact. ## Can we have more than one administrator? Yes, and it is worth doing. Roles are assigned per invited user from the role list, so you can hold an administrator role on more than one user and avoid the situation where a single person's absence blocks every administrative action. The one row you cannot duplicate or move is the original super administrator. What each role can do, and how invitations work, is in [Merchant Portal Operations](/docs/en/support/portal-operations-faq). ## How do I check who has been signing in? The user menu at the top right has **Login History**. It lists, for the account, the sign-in email, the source IP, the timestamp, and whether the attempt **succeeded or failed** — so failed attempts are visible, not just successful ones. The drawer is explicitly scoped to the **last 90 days** and has no date picker, so it cannot be widened from the interface. For a longer period, or for an evidence export, raise it with support. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.