Short answer: whoever's merchant ID the funds settle into is the merchant of record, and in a multi-vendor venue that is a choice, not a default. There are three workable structures — the venue as merchant of record with vendor remittance, each vendor as their own merchant of record, and a hybrid split by revenue stream. The right one depends on your lease terms, your entity structure and whether you take cash.
Why This Question Has No Good Answer Online
Search for "merchant of record" and you get material written for a single independent business selling to a single customer. That is not the situation in a food hall, a public market, a stadium concourse, a brewery with a resident kitchen, a hotel with licensed outlets, or a festival with thirty rotating trucks. In all of those, one guest pays once and the money has to reach several legally separate businesses.
The operators asking are not confused about payments. They are asking a structural question that payment content does not cover. A nonprofit public market running ten stalls put it in one sentence: "But if the money then has to go to somebody else, that's where it becomes an issue."
That is the whole problem. Taking the payment is easy. Getting it to the right entity, with the right documentation, under the right lease terms, is the part that decides your structure.
What Does "Merchant Of Record" Actually Mean?
The merchant of record is the legal entity in whose name a card transaction is processed. Practically, it is whoever:
- Holds the merchant account the funds settle into
- Appears on the guest's card statement
- Is liable for chargebacks on that transaction
- Receives the 1099-K for that volume
- Carries the PCI compliance obligation for it
Those five things travel together. You cannot take the settlement without taking the chargeback liability, and you cannot hand off the chargeback liability while keeping the deposit. Every argument about multi-vendor structure is really an argument about which entity is willing to carry that bundle.
The Three Settlement Architectures
Almost every multi-vendor venue lands on one of three shapes.
| Structure | Who is merchant of record | How vendors get paid | Best when |
|---|---|---|---|
| Parent as MoR | The venue entity, for all sales | Remittance on a set cycle, net of rent and fees | Vendors are licensees, not tenants; the venue controls the guest relationship |
| Vendor as MoR | Each vendor, for their own items | Funds settle directly to the vendor; venue invoices rent separately | Vendors are independent businesses with their own EINs and liquor or food licences |
| Hybrid by stream | Venue for one category, vendors for the rest | Split at the item level by accounting stream | The venue holds the liquor licence but food is licensed out |
The hybrid is more common than people expect, and it is almost always driven by alcohol. If the venue holds the liquor licence, alcohol sales generally have to settle to the venue's entity regardless of who sold the food alongside them. That single constraint dictates the structure at a large share of food halls and markets.
When Do You Actually Need Separate Merchant IDs?
A four-location family entertainment group asked this precisely, and the way they asked it is instructive: "Each department has its own merchant ID. So the grill is on one merchant ID, ice cream's another. The arcade is another, the country store's another… How would the GoTab system support that?"
Note that this is one company. They are not splitting money between separate businesses at all — they are splitting it between departments inside one business. There are four reasons operators end up wanting separate MIDs, and only two of them are about vendors:
- Separate legal entities. Different EINs cannot share a merchant account. This is not a preference; it is a rule.
- Separate licences. Alcohol, tobacco and lottery sales frequently have to settle to the licence-holding entity.
- Clean departmental accounting. One entity, several MIDs, so deposits reconcile to departments without a spreadsheet in between.
- Different processing rates by category. Retail, food service and amusement can price differently; separate MIDs let each sit in its correct classification.
Reasons three and four are solvable with reporting rather than structure, and often should be — every additional MID is another underwriting file, another statement to reconcile, another PCI scope. Ask which of the four you are actually solving before you add one.
Cash: The Case Every Model Breaks On
Card money follows whatever rails you configure. Cash does not, and it is where every multi-vendor structure gets ugly.
A bar working with fifteen to twenty rotating food-truck vendors named the problem exactly: "We're doing an 80/20 revenue split, right? 80 goes to him, 20 comes to me. It seems like to me that's going to work really easy on the credit card… What if it's a cash ticket?"
An operator running a food-truck hub attached to a 36-key lodge described living with it: "It's just a pain in the butt that I have to hold onto that cash… it's just much easier if I had a system that whenever order, I get my money, they get their money. There's no swapping hands here."
There are three workarounds and each has a real cost:
- Cash is a receivable against the next remittance. Whoever physically took the cash owes it, and it is netted from what they are paid. Cleanest on paper; requires that both parties trust the count.
- Cash settles at the point of sale. The vendor keeps the drawer and pays the venue its share separately. Simple, and the venue loses visibility into a whole revenue stream.
- Cashless venue. Removes the problem entirely and costs you the guests who pay cash — a real number in some markets, close to nothing in others. Measure it before you decide, not after.
Whichever you pick, write it into the vendor agreement. Almost every multi-vendor dispute we hear about is a cash dispute.
How Rent Changes The Money Path
The lease and the settlement structure are the same decision, and they are usually made by different people at different times.
| Rent model | What the venue needs from the POS | Where it goes wrong |
|---|---|---|
| Flat rent | Nothing — invoice monthly | Venue carries the downside in a slow quarter |
| Percentage of sales | Auditable per-vendor sales the vendor can see too | Disputes over what counts as sales — gross, net of comps, net of tax? |
| Base plus percentage over a breakpoint | Running sales totals against the breakpoint, visible mid-period | Nobody knows they crossed it until the month closes |
| Licence fee, no lease | Remittance netting and a clear fee schedule | The fee looks like rent to a tax authority if the paperwork is loose |
Define "sales" in the agreement in the same words your reporting uses. Gross, net of comps, net of discounts, net of tax, before or after third-party delivery commission — every one of those is a percentage-rent argument waiting to happen, and the POS report is the document both sides will point at.
Revenue Share, 1099s, And The Structure Some Operators Cannot Use
This is where the choice stops being an operational preference. A multi-EIN operator running a kitchen inside a brewery was blunt about the constraint they were under: "We legally aren't doing… we can't do revenue share. Our businesses have to say absolutely no."
Reasons a business refuses revenue share are usually one of: a franchise agreement that forbids it, a lender covenant, an alcohol licence condition, or a tax position they do not want to disturb. It does not matter which — if one vendor cannot participate, your structure has to accommodate a vendor settling directly while the rest remit.
Two things worth raising with your accountant before you commit, not after:
- Whose 1099-K reflects the volume. If the venue is merchant of record, the venue's 1099-K includes sales it will pay out to vendors. That is normal, and it needs to be reconcilable, or the venue's reported revenue looks inflated by the whole vendor pool.
- Whether remittances are a cost of sale or a pass-through. The answer changes the venue's stated revenue substantially, and it is not the POS's decision to make.
This is a structuring question, not a software question. Nothing here is legal or tax advice — your counsel and your accountant decide, and the platform's job is to produce records that support whichever answer they give.
Who Pays The Interchange On A Split Tab?
One guest, one card, one authorisation, several vendors. The processing fee is charged once on the whole amount. Allocating it is a policy choice, and there are three defensible ones:
- Pro rata by vendor share. Fairest, and the one most vendors accept without argument.
- Venue absorbs it. Simplest for vendors, and it becomes a real line item at scale — worth pricing into the rent rather than discovering later.
- Flat percentage deducted from each vendor. Predictable for everyone, but it either over- or under-recovers against actual interchange, which varies by card type.
Whichever you choose, the vendor should be able to see the deduction on their own statement. Opaque fee deductions are the fastest route to a vendor who wants their own terminal, and one vendor with their own terminal breaks the single-tab guest experience the venue was built around.
What To Settle Before You Sign Anything
These are the questions to answer with your vendors, your landlord and your platform, in writing, before a menu gets built:
- Which entity is merchant of record for each revenue stream — food, alcohol, retail, amusement?
- Who carries chargeback liability, and who decides whether to fight one?
- On what cycle are vendors remitted, and what is netted before they are paid?
- How is cash handled, and who holds it between the sale and the settlement?
- What is the agreed definition of "sales" for percentage rent?
- How is the processing fee allocated on a tab that spans vendors?
- Can a vendor see their own sales, fees and remittances without asking the venue for a report?
- What happens to an open tab when a vendor leaves mid-period?
Question seven is the one that quietly determines whether the arrangement lasts. Vendors who can see their own numbers stop asking for their own terminal.
GoTab was built for venues where more than one business shares a checkout — separate merchant IDs, automated vendor remittance, per-vendor reporting, and one tab for the guest across all of it. See how multi-vendor ordering and payment works, or read more about GoTab for food halls and public markets.
