Skip to main content
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; how brands and sub-merchants relate is in Multiple Brands & Sub-Merchants.

​
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: 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.

​
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 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 walks the whole path, KYB Document Requirements covers the documents, and Payment Enrollment 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: 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. What you can actually accept in production comes from what you are contracted and enrolled for — see Payin Agreements & Limits.

​
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.
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: 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: 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.

​
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.