Multi-brand payment setup: MIDs, legal entities, statement names and reporting

A second brand or country store rarely starts as a payments project. Someone buys a company, opens in a new market or launches a sister label, and payments get bolted on: a new provider account here, a shared login there. Within a year, nobody can say which entity owns which merchant account, why a customer’s statement shows the wrong name, or what the group actually took last month.

This article sets out how to structure payments across several brands or country stores: merchant accounts and legal entities, statement names, roles and permissions, shared or separate routing, and group reporting. It is general guidance, not legal or tax advice, and each provider’s rules differ, so confirm your structure with your providers.

What does a multi-brand setup need to separate?

Six layers, and a good structure keeps them distinct. Most confusion comes from treating them as one thing.

Layer	What it is	Who decides
Legal entity	The company that sells and takes the money	Your legal and tax structure
Merchant account (MID)	The account a provider uses to process and settle	Your provider, in underwriting
Brand or store	What the customer sees and buys from	You
Statement name	What appears on the bank statement	You and your provider, within scheme rules
Routing	Which provider receives each payment	You
Users and roles	Who can see and do what	You

Providers model these layers in different ways. Adyen has a company account that holds merchant accounts and users, and payments are processed in the merchant accounts. Checkout.com uses processing channels within a legal entity, and says you can segregate traffic by payment website, brand or merchant category code. Stripe uses separate accounts, with an organisation on top for reporting and management. The names differ, but the questions are the same.

When do you need a separate legal entity or merchant account?

The decision usually comes down to five tests. The table shows what each one means, and our MID entry explains the term.

Test	What providers and schemes say	What it means for you
Different legal entity	Adyen: at least one merchant account per legal entity. Stripe: separate tax ID means a separate account	Needs its own account
Different country	Adyen: one acquiring region per merchant account	Usually needs its own account for local acquiring
Different business line	Visa: use the MCC of the highest-volume business for all sales, or a different MCC per line of business	May need its own account or channel
Different payout	Adyen and Stripe both describe separate accounts for separate payouts	Needs its own account if funds must stay apart
Limited access	Adyen: to limit user permissions, create separate merchant accounts	May need its own account on that platform

A new legal entity does not guarantee local acquiring. Visa’s Merchant Data Standards Manual, in its October 2026 edition, says a merchant may have only one principal place of business for it and its group subsidiaries, and that a multinational must use that location unless a subsidiary’s country qualifies as an additional merchant location. The criteria include a permanent location where the business is run, and assessing sales taxes on the activity. A post office box, a payments function or servers are not enough on their own. Read this alongside our guide to local and cross-border acquiring, because the wrong assumption here can undo a business case.

Stripe also has a broader rule: you must use separate accounts for projects, websites or businesses that operate independently from one another. If two brands share a legal entity, Stripe says they can use the same tax ID across accounts. Each provider will have its own view, so ask before you assume a brand can share an account.

Expect separate underwriting too. Stripe says a new account does not inherit any special status or similar considerations from your existing account, so a successful brand’s terms may not carry over to a new one.

What should each brand show on the statement?

The brand the customer bought from, not the holding company. Visa’s manual says the merchant name must be the name most prominently displayed by the merchant and by which cardholders recognise it, while also reflecting the Doing Business As name. Visa’s 2020 reminder says the legal or company registration name should not be used unless it is also the name customers see. Stripe gives the reason in plain terms: a customer who buys from “XYZ” and sees “ABC” on their statement may raise a dispute.

The limits are tight. Visa says its systems provide 25 spaces for the merchant name. Stripe’s descriptors must contain 5 to 22 characters, reflect the Doing Business As name and contain only Latin characters, with a static prefix of 2 to 10 characters if you add a dynamic suffix. Use this checklist for each brand.

1. Use one approved name per brand, and record it in a shared table.
2. Check it on every provider. A brand that uses two providers should look the same on both.
3. Test the shortest limit. Make sure the brand still reads clearly at 22 characters, and at 10 if you use a prefix.
4. Check non-card methods. Stripe’s Pix page says a customer’s statement shows its partner as the recipient, so a soft descriptor cannot always carry your brand. Use receipts and confirmation emails to fill the gap.
5. Show the merchant location. Visa says an e-commerce merchant must prominently display the merchant outlet country on the checkout screen or the page before it. For a multi-entity group, that country may not be the one the customer expects.
6. Align receipts and support. The name on the statement, the receipt and the support email should lead to the same place.

How should roles and permissions work?

Give each person access to their brand and their job, and nothing more. PCI DSS gives a useful model even where it does not formally apply to your setup. Version 4 says access should be assigned by job classification and function with the least privileges necessary, every user needs a unique ID, shared accounts are for exceptional cases only, and access should be reviewed at least once every six months.

Check how your provider handles this, because a platform can force your hand. Adyen says that to limit user permissions you need separate merchant accounts, and that you can also limit a user to specific merchant accounts or an account group. Its role list separates refunds, cancellations and captures, which is a useful guide when you design your own.

Role	Sees	Can do	Should not do
Brand support agent	One brand’s payments	Look up a payment, view its status	Change routing or see other brands
Brand manager	One brand’s reports	Edit checkout content	Add providers or users
Payments operations	All brands	Change routing, splits and limits	Approve their own large changes
Risk analyst	All brands	Manage rules and block lists	Change settlement details
Finance	All brands’ reports and settlements	Export and reconcile	Edit routing
Administrator	All brands	Manage users and roles	Share a login

Remove access on the day someone moves to another role or leaves. After an acquisition, review inherited users before you connect anything.

Should brands share routing and providers?

Share the logic, and separate what carries risk. Pooling volume can improve your terms and reduce the work, but a pooled account also pools the problems.

Element	Share when	Separate when
Provider contract	One group agreement covers all entities	Entities or markets need different terms
Merchant account	Same entity, country, category and risk	Any of the tests above differ
Routing rules	Brands sell similar products in the same markets	Risk, ticket size or methods differ
Provider limits	Rarely	Almost always, per brand and method
Fraud rules	As a shared baseline	A brand has its own fraud pattern
Block lists	Fraud seen on one brand matters to all	Local privacy rules restrict it
Customers and saved cards	Customers have consented, and it helps them	Entities or privacy notices differ

Two of these need extra thought.

Limits and ratios. If two brands share a merchant account, they share its monthly limit and its dispute ratio. Example figures, for illustration only. If one brand’s sale takes EUR 700,000 of a EUR 1,000,000 monthly limit by the 20th, the other brand has EUR 300,000 left for the rest of the month. Set a working cap per brand even when the account is shared. Ratios behave in the same way: one brand’s bad month can put the other’s processing at risk. Separating brands for genuine reasons is fine, but our MID entry explains why splitting accounts to stay under a threshold is not.

Saved cards and customer data. Letting a customer use a saved card across brands is convenient, but it is a decision about personal data. Stripe’s sharing feature shows the trade-offs. It covers all customers and supported payment methods in a group, and you cannot limit it to specific ones. Stripe says you cannot disable it through the Dashboard, and that businesses must get customer consent first, with requirements that vary by country. Accounts in a group still cannot see each other’s payments. Take legal advice before you link customers across entities, and see our article on card token portability for the token side.

How do you report across brands?

Agree the fields first, because a group report can only be as good as the least complete store. Every transaction, from every provider, should carry the same dimensions.

1. Brand and store, from your own list, not the provider’s label.
2. Legal entity, for finance and tax.
3. Provider and merchant account.
4. Country and method.
5. Presentment and settlement currency.
6. Your own order reference, as our guide to reconciliation across PSPs explains.

Adyen makes the structural trade-off clear: you can configure merchant accounts by business line or geography, and fewer accounts mean fewer reconciliation reports. Stripe offers an organisation for centralised reporting when you run several accounts for one business. Either way, you need one view that groups the same payment the same way for every team.

Who	Question	View
Group finance	What did each entity take and settle?	By legal entity and currency
Payments lead	Which provider works for which brand?	Approval by brand, provider and country
Risk	Which store is driving disputes?	Ratios per merchant account
Brand manager	How is my checkout doing?	One brand only

Calculate group approval rates from counts, not by averaging percentages, or a small store will weigh as much as a large one. Settlement stays with the entity that made the sale, so group totals need a fixed rate for each period and clear rules for transfers between companies. Our article on settlement times by region helps with the cash side.

What are the common mistakes?

• Opening accounts in the wrong entity. Moving a merchant account later can mean new underwriting.
• Using the holding company’s name on statements. Customers do not recognise it, and some will dispute the charge.
• Assuming a new company brings local acquiring. Check Visa’s location rules with your acquirer first.
• Sharing logins. You lose the record of who changed what.
• Sharing a limit without a brand-level cap. The first brand to run a sale can use up the month for everyone.
• Letting each brand name things its own way. Group reports then need manual mapping every month.

How does Omno support multi-brand payments?

Omno brings all brands, users and transactions into one place, with role-based access, so each person sees what their job requires. Your team sets routing rules and limits in the dashboard, and reports and widget analytics show results across providers. Omno does not replace your merchant accounts: each provider onboards each merchant separately, so legal entities, MIDs and contracts stay with you and the provider. The payment orchestration page explains how it fits together.