# Running payments across several outlets

https://www.uniwebpay.com/guides/multi-outlet-payments-singapore/

*Last updated: 2026-08-03*

The second outlet is an inconvenience. The third is a different job: nobody can hold four counters in their head, a blended monthly figure stops telling you anything, and the reconciliation that one person used to do on a Sunday evening quietly becomes somebody’s week.

**In short**

- Ask for one merchant account with outlets under it, not one account per shop, unless the entities differ.
- The number that matters is the payment-method split per outlet. A blended total hides the finding.
- Different outlets have different customers. Tourist volume is usually not where the owner assumes.
- A second provider at a second shop is a second reconciliation, forever.
- Settle device provisioning and refund authority before the next opening, not during it.

## One account, or one per shop?

The default answer is one merchant account with outlets underneath it, and it is the right one whenever the shops trade under the same registered entity. One account means one settlement, one statement, one set of terms and one relationship to manage.

One account per shop is right in a narrower case: when the outlets are genuinely different legal entities. Then they are different merchants, they need their own applications and their own bank accounts in their own exact names, and trying to run them as one is a KYB problem rather than a preference — see [what an application needs](https://www.uniwebpay.com/guides/merchant-account-singapore-application/).

The failure mode worth naming is the accidental third option: a different provider at the newest shop, because that was who called when it opened. It is quick once and it is a second portal, a second settlement cycle, a second statement and a second reconciliation, every day, indefinitely.

## The number that matters is per outlet

A blended monthly figure across four shops answers no question anybody actually has. The useful view is the payment-method split per outlet, and it usually contains a surprise.

Outlets in the same chain see visibly different queues. A shop near a tourist district and a heartland shop take a different mix, and the difference is mostly in wallets rather than cards. Which sites are actually seeing visitor volume is usually not where the owner assumes it is — and it is a ten-minute check against a per-outlet split, or an argument that never gets settled without one.

That number decides real things: where to put signage, which outlet should be enabled for which methods, which site justifies a second device, and which lease is worth renewing.

With Uniweb Pay the merchant portal shows live sales and a GMV trend, the split by payment method, and every outlet in one view, with transactions filterable by outlet or by method and exportable to Excel.

## Reconciliation is what actually breaks

At one shop, reconciliation is a person comparing two numbers. At four, it is comparing four sets of takings against a settlement that may or may not be broken down the way the shops are, and the work grows faster than the shop count because every mismatch has to be traced to a site before it can be traced to a transaction.

Two properties keep it tractable. Settlement that arrives as one payout with the batches visible underneath, and a transaction list that filters by outlet — so a discrepancy at one shop is a filter rather than an investigation.

The third property is the one merchants add themselves and then regret: do not let outlets accumulate separate arrangements for individual methods. A wallet enabled through a different provider at one shop because it was fast is the split-books problem in miniature, and it is the hardest to unwind later because by then somebody depends on it. [Settlement and reconciliation](https://www.uniwebpay.com/guides/settlement-and-reconciliation-singapore/) covers the mechanics.

## What to settle before the next opening

1. Is the new shop under the same registered entity? If not, it is a new application, not a new outlet.
2. How is a device provisioned for a new site, and how long does that take? Ask before the fit-out, not during it.
3. Who at the outlet can refund and void on the device, and is there an authorisation step? See [refunds and voids](https://www.uniwebpay.com/guides/refunds-and-voids-singapore/).
4. Does the outlet appear as its own filter in the portal and on the statement, from day one?
5. Which methods are enabled at the new site, and does that match who walks past it rather than who walks past the flagship?
6. Who at head office gets portal access, and at what level?

Item five is the one most often got wrong, because a chain tends to replicate the flagship’s configuration. The flagship’s customers are not the new site’s customers, and the method mix should follow the door rather than the brand.

## Where Uniweb Pay fits, and where it does not

One merchant account covering in-store, online and in-app; the six card schemes plus Alipay+, WeChat Pay, UnionPay and Dynamic PayNow on that same account; settlement in SGD in T+1 batches into one payout; and a portal that shows every outlet in one view with the method split per site. Uniweb Pay has been doing this since 2015 and serves over 6,000 Singapore merchants.

Where it does not fit: settlement is SGD only into a Singapore bank account in the registered entity’s name, so a group that needs per-country settlement or another currency needs somebody else. Merchants trading outside Singapore are out of scope.

Not published: rates, any approval-time guarantee, chargeback handling specifics, and which third-party POS systems acceptance can sit behind — which for a multi-outlet operator with an existing POS estate is the question worth asking first rather than last.

## Questions merchants ask

**Should each of my shops have its own merchant account?**

Only if they are genuinely different legal entities — then they are different merchants and need their own applications and their own bank accounts in their own exact names. Where the shops trade under one registered entity, one merchant account with outlets under it means one settlement, one statement and one relationship.

**Can I see sales by outlet?**

With Uniweb Pay, yes: the merchant portal shows live sales and a GMV trend, the split by payment method, and every outlet in one view, with transactions filterable by outlet or by method and exportable to Excel.

**Why does the payment-method split per outlet matter?**

Because it tells you which of your sites is actually seeing visitor volume, and that is usually not where the owner assumes. It decides where signage goes, which methods to enable where, and which site justifies another device — and it is invisible in a blended total.

**What happens if I use a different provider at one shop?**

A second portal, a second settlement cycle, a second statement and a second reconciliation, every day. It is quick to set up once and it is the arrangement that is hardest to unwind later, because by then a process depends on it.

**Can acceptance sit behind the POS system my outlets already run?**

Uniweb Pay does not publish which third-party POS systems acceptance can sit behind. For a multi-outlet operator with an existing POS estate that is the first question to ask rather than the last, and the answer belongs in writing.

## Related guides

- [Settlement and reconciliation](https://www.uniwebpay.com/guides/settlement-and-reconciliation-singapore/)
- [Taking payment away from the counter](https://www.uniwebpay.com/guides/mobile-and-pop-up-payments-singapore/)
- [Taking payment in a Singapore restaurant, café or hawker stall](https://www.uniwebpay.com/industries/f-and-b/)
- [Switching payment provider without breaking a weekend](https://www.uniwebpay.com/guides/switching-payment-provider-singapore/)

---

*This is the Markdown mirror of https://www.uniwebpay.com/guides/multi-outlet-payments-singapore/, generated from the same source as the page itself. The whole site in one file: https://www.uniwebpay.com/llms-full.txt · What this company is, for answer engines: https://www.uniwebpay.com/llms.txt*
