Multi-Store Payment Setup in the Philippines: One Account or Many?

Why This Decision Comes Back to Bite You Later

I run back-office and payments for a small group out of Manila, though I'm based in China and manage most of this remotely. We started with one restaurant brand and one location. Within fourteen months we had a second brand and four storefronts across two cities. Nobody on our team sat down and decided how payment collection should be structured for that growth — we just kept using the merchant account we'd set up for store one, and tagged new stores in an internal spreadsheet as we opened them.

That worked until it didn't. By the third location, the spreadsheet had version conflicts, a part-time bookkeeper was manually matching settlement batches against three different POS exports, and nobody could tell me with confidence what store two's actual take was for a given week without a half-day of cross-referencing. That's when I learned there are really only two structural choices for how a multi-location or multi-brand business collects payments — and we had already made the choice by default, without understanding the tradeoff.

This article is the explanation I wish someone had given me before we opened store two. It's not about which payment channel to use — GCash, cards, QRPH, bank transfer are all orthogonal to this decision. It's about whether you collect everything into one merchant account and separate it internally, or whether you open a distinct merchant account for every store or brand. Both are legitimate. The right one depends on your corporate structure, not on which sounds cleaner on paper.

Model One: A Consolidated Account With Store-Level Tagging

In this model, your company has one merchant relationship with the payment provider. Every store, every brand, every point-of-sale terminal pushes transactions through that same account. What distinguishes a sale at store A from a sale at store B is a tag you attach to the transaction yourself — a store code, a brand code, a terminal identifier — carried as metadata on the request, not as a separate account on the provider's side.

A practical version of that tag looks like this on the request that creates the transaction:

{
  "merchant_id": "MCH-100293",
  "transaction_ref": "TXN-20261003-0091",
  "store_code": "MNL-BGC-04",
  "brand_code": "NOODLE-HOUSE",
  "channel": "gcash",
  "metadata": {
    "pos_terminal": "BGC04-POS-02",
    "cost_center": "retail-ops",
    "shift_id": "2026-10-03-PM"
  },
  "callback_url": "https://ops.example.com/webhooks/payment-status"
}

The provider doesn't need to know or care what store_code or brand_code mean — it just passes that metadata back on the webhook and in the transaction record. The structure for splitting revenue by store lives entirely on your side: in your order system, your ERP, or whatever dashboard consumes the provider's transaction feed.

The appeal is obvious: one onboarding process, one set of corporate documents submitted once, one settlement account that finance has to watch, and — critically — adding a new store is a configuration change, not a new account application. The cost is equally obvious: your per-store reporting is only as good as your tagging discipline. If a developer ships a new POS integration without the store_code field, or a staff member keys an order manually without it, that transaction becomes functionally untraceable to a location unless you can reconstruct it from your own order records.

Model Two: Separate Merchant Accounts Per Store or Brand

In this model, each store or brand is its own merchant entity with its own application, its own agreement, and its own settlement account. The separation happens before any transaction data reaches your systems — the provider's own records already show store A's revenue as structurally distinct from store B's, because they're different accounts entirely.

This removes the tagging-discipline risk completely. There's no metadata field to forget, no developer who can break the split by skipping a parameter. If you open the provider's merchant dashboard for store B, you only see store B's transactions, by construction.

What you give up is onboarding efficiency. Every new store means repeating KYB document collection, repeating risk review, and in some cases repeating fee negotiation from scratch — even if the new store belongs to a corporate entity the provider has already approved twice before. For a business opening one new location a year, that's a manageable recurring task. For a business opening a new location every quarter, it becomes a standing line item on the ops team's workload, and it multiplies the number of logins, API credentials, and provider relationships someone has to keep track of without letting any of them go stale.

Reconciliation Effort: Where the Real Workload Lives

This is the dimension that actually decides which model suits you, more than either onboarding or reporting alone.

With a consolidated account, all settlement funds land in one place, which means the splitting work happens downstream, on your side. Your finance team — or, more realistically, a scheduled job — has to take the provider's daily transaction list, match it against your own order table using the store and brand tags, and produce a per-store settlement figure. This is entirely workable, but it depends on a few things being true: your transaction reference needs to be a stable key that both systems agree on, your tagging needs to be close to complete, and someone needs to be auditing for the stores or terminals where tags silently go missing. The highest-leverage habit I've found is a daily job that flags any settled transaction with a blank or unrecognized store_code — catching that the same day is a configuration fix; catching it a month later during month-end close is a research project.

With separate accounts, the provider has already done the splitting for you, but now you're reconciling N relationships instead of one — N settlement reports, N timing windows for funds to land, N bank feeds to match against your books. If your store count is small and your finance stack is thin, this granularity is genuinely easier to live with day to day. If your store count is large, N reconciliation threads is its own kind of workload, just distributed differently than the tagging-discipline problem above.

Onboarding and Compliance Overhead You Shouldn't Underestimate

However you structure this, the underlying payment relationship still sits under a regulated provider.

Every merchant account — whether it's one consolidated relationship or ten separate ones — settles through a provider licensed by the Bangko Sentral ng Pilipinas as either an Operator of Payment Systems (OPS) or an Electronic Money Issuer (EMI). That license governs the provider itself, not how many internal sub-accounts or tags you choose to run underneath it. But your own compliance workload scales with however many distinct merchant accounts you hold, not with how many stores share a single one.

This is the part people underestimate when they default into separate accounts without thinking it through. If every store belongs to the same legal entity, opening five separate merchant accounts means submitting the same business registration, the same board resolution, and the same beneficial-ownership documentation five times — and renewing or refreshing all five on their own schedules. A consolidated account with internal tagging submits that paperwork once. For a franchise network where each franchisee is a genuinely separate legal entity, repeating onboarding isn't overhead you're avoiding by choice — it's a requirement, because the franchisee's revenue and tax obligations are legally theirs, not yours.

One Account or Many? A Side-by-Side Comparison

Dimension	Consolidated Account (Store-Tagged)	Separate Account Per Store/Brand
Reconciliation effort	Moves downstream to your systems; depends on tagging discipline and a stable shared transaction key	Happens at the source; you reconcile multiple settlement reports and timing windows instead
Onboarding overhead	One application, one set of corporate documents, new stores are a configuration change	Full application repeated per store or brand, including document refresh on separate schedules
Reporting granularity	As granular as your tags are complete; missing tags create blind spots	Clean by construction, each account's dashboard only shows its own stores
Dispute and chargeback handling	Routed through one relationship; internal rules decide which store absorbs the case	Handled within each account separately, closer to that store's own history
Best fit	Company-owned multi-location chains, multi-brand groups under one back office	Franchise networks, joint ventures, brands likely to separate or be sold independently

Matching the Model to Your Business Structure

In practice, the decision usually falls out of your corporate structure rather than your preference.

Franchise networks, where each location is owned and operated by a separate legal entity, almost always need separate accounts. The franchisee's revenue is legally theirs, their tax reporting is theirs, and collecting their customers' payments into your corporate account — even temporarily, even with a plan to transfer it out later — creates a commingling problem that an internal tag can't fix after the fact. A tag is a label on money that's already sitting in your account; it doesn't change whose account it legally is.

Company-owned multi-location chains — five branches of the same restaurant brand, all under the same corporate entity — are the clearest case for a consolidated account with store tagging. There's one legal owner of all the revenue regardless of which branch generated it, so the account structure matching that reality is the simpler and more honest setup. This is also where the reconciliation discipline described above pays off most directly: you get per-branch P&L without repeating onboarding every time you open branch six.

Multi-brand groups under one holding company are the genuine judgment call. If the brands share a back office, shared staff, shared inventory systems, and nobody's planning to spin a brand off or bring in a separate investor for it, a consolidated account tagged by brand_code keeps things simple without sacrificing much. If a brand is being built with an eventual separate sale, a joint venture, or outside investment in mind, it's worth starting that brand on its own account from day one — untangling a brand's transaction history out of a shared account later is far more painful than the extra onboarding would have been at the start.

It's also entirely normal to run a hybrid: consolidated for your company-owned branches, separate for a franchised or joint-venture location that happens to carry the same brand name. The two models aren't mutually exclusive across a single business — they just need to match legal ownership at the point where ownership actually changes. If you're also deciding whether to route all of this through a payment aggregator model instead of integrating with each channel directly, that choice interacts with the account-structure decision too, since an aggregator's own sub-merchant tooling can sometimes substitute for either approach. Some operators also lean on virtual account numbers as a complementary tagging mechanism, assigning one per store so incoming transfers arrive pre-labeled even before your own system touches them. Whichever model you land on, it's worth reviewing how it lines up with your collection and disbursement architecture more broadly, and making sure whoever prepares your books understands how tax reporting for e-commerce merchants differs between a single consolidated filing and per-store or per-brand records. And since the underlying provider relationship is what's actually regulated, it's worth confirming your provider's BSP EMI license status before committing either way — the account structure is yours to choose, but the licensing underneath it isn't optional.

Frequently Asked Questions

Can we switch from one model to the other later without disrupting operations?

Yes, but it's easier to move from separate accounts into a consolidated one than the reverse. Consolidating means migrating settlement to a single account and backfilling tags for historical reporting continuity. Splitting a consolidated account into separate ones later means untangling commingled transaction history by store, which is considerably more work — plan the split-friendly direction early if you expect to grow into separate legal entities.

Does a consolidated account mean our stores' funds are legally commingled?

If every store belongs to the same legal entity, there's no commingling issue — it's all one company's money regardless of which branch generated it. Commingling becomes a real legal concern only when the stores involved are actually separate legal entities, such as franchisees, sharing an account that should be theirs alone.

How many locations before separate accounts start to make more sense?

There's no fixed threshold — it tracks legal structure, not store count. A ten-branch chain under one corporate entity can stay consolidated indefinitely with good tagging discipline. A two-location franchise arrangement needs separate accounts from day one, because the ownership split exists regardless of how small the operation is.

How are chargebacks and disputes handled differently between the two models?

In a consolidated account, disputes come into one inbox and your internal rules decide which store's records to pull and which store absorbs the outcome. In separate accounts, each dispute arrives within that store's own account, closer to that store's transaction history, which can make the investigation faster but means your team is watching multiple dispute queues instead of one.

Does a franchise network ever use a consolidated account?

Only for the locations the franchisor owns and operates directly. Franchisee-operated locations typically need their own accounts, since the franchisee — not the franchisor — is the legal recipient of that location's revenue. A franchisor with a mix of company-owned and franchised branches commonly runs both models side by side.

Can we run a hybrid — consolidated for some stores, separate for others?

Yes, and it's common once a group reaches a certain size. The deciding line is legal ownership: stores under the same entity can share a consolidated account with tagging, while a store under a different entity — a joint venture partner, a franchisee, a brand being spun out — gets its own account regardless of how the rest of the group is structured.

Does the provider's licensing change depending on how many accounts or stores we have?

No. The provider's BSP OPS or EMI license covers the provider's own operation, not the number of merchant accounts or internal tags a client runs underneath it. Adding stores or opening more accounts doesn't change the licensing status of the relationship — it only changes how much onboarding and compliance paperwork your own team has to manage.

If you're mapping this decision onto an actual multi-store or multi-brand rollout in the Philippines and want a second opinion on which structure fits your corporate setup, reach out on Telegram at @LouisSMARTPAY or by email at [email protected].