Multi-location payments — one Payment Hub, many locations, every transaction posting to the right entity

No. Payment Hub is a single centralized deployment that serves every location in your organization — one login model, one admin, one audit trail, one version of the software. Location identity is attached per-transaction (by URL, by staff login, by terminal ID, or by customer ship-to), and that identity drives per-location routing into your gateway, ERP, and tax systems.

Adding a new location takes configuration, not a new installation — and the new location inherits the central policies and branding while getting its own ERP entity / MID / tax / GL routing.

Yes. Payment Hub supports two common multi-location MID models. Model 1: One shared merchant account across all locations (simpler, unified pricing, single settlement bank account) — Payment Hub tags each transaction with a location identifier for ERP posting but all transactions settle to the same merchant statement. Model 2: Per-location merchant account (separate MID per branch / store / entity — common for retail chains and franchise models where each location is a separate legal entity or requires separate settlement banking).

Payment Hub routes each transaction to the correct MID based on the originating location. Some merchants run hybrid: shared MID for most locations with a separate MID for locations in a different state or legal entity.

Payment Hub maintains a location routing table that maps each location to the right ERP constructs. When a transaction happens at Location 12 (Dallas branch), Payment Hub knows from the routing table that this posts to: ERP company code DLX-01, warehouse DLX-WH-A, tax jurisdiction Dallas County TX, GL account 1010-DLX for cash receipts, and customer-default-branch DLX-01 for new customer creation.

Clarity Connect writes the transaction to the correct ERP entity / subsidiary / company / branch record automatically — real-time, with no reconciliation spreadsheet. Supports multi-entity ERPs (NetSuite OneWorld, Dynamics 365 F&O multi-company, Acumatica multi-branch, Sage Intacct multi-entity, SAP company codes) and single-entity ERPs with multi-branch / multi-warehouse / cost-center structures.

Payment Hub handles per-location tax jurisdiction automatically. Each location's originating address / ZIP drives tax determination — Dallas branch transactions calculate Texas state tax + Dallas County tax + city-of-Dallas local tax; Oakland branch transactions calculate California state tax + Alameda County tax + city-of-Oakland local tax.

Payment Hub integrates with the tax engine in your ERP (or with Avalara, Vertex, TaxJar where you use a dedicated engine) and uses the correct jurisdiction per location. For interstate shipments, destination-based tax follows the ship-to ZIP rather than the originating location.

Controlled by role. The default Payment Hub deployment scopes counter staff to their home location only — Dallas staff see Dallas transactions, Dallas customers, Dallas open invoices. A cross-location role (typically "branch manager roaming" or "district supervisor") allows access to a defined set of locations. Head-office roles (controller, CFO, director of operations) see all locations with consolidated reporting.

The audit trail logs which staff member took each action at which location, so you always know who did what where — even if the user accessed a transaction outside their home location with elevated permissions.

Each location has its own cash-drawer context. Staff clocking in at the Dallas counter opens a drawer; transactions processed by that staff during the shift accumulate in that drawer's running totals. At shift-end, the drawer reconciles against Payment Hub's recorded totals — expected cash, expected card, expected check, expected charge-on-account.

Variances are flagged in the audit log and surfaced in the Payment Hub operations dashboard and the ERP cash-GL reconciliation. Multi-drawer locations (multiple counter stations at a busy branch) each get their own context; the branch-manager role can consolidate all drawers for a given day.

Head office sees everything, sliced the way they need. Payment Hub's dashboard defaults to consolidated views — total revenue by location, transaction count by location, commercial vs consumer card mix by location, on-time payment rate by location, open aging by location — all refreshed in near-real-time as transactions flow in from every branch.

The same data is exposed to your BI / data-warehouse layer (reports into Power BI, Tableau, Looker, Snowflake) for organizations that blend payment operations data with inventory, HR, and ERP-side analytics. Every number drills down from head-office aggregate to the originating transaction at the originating location.

A new location is a configuration change, not a deployment. The work is: (1) assign an ERP entity / warehouse / branch code, (2) confirm tax jurisdiction, (3) decide MID strategy (share existing or new MID), (4) assign staff roles, (5) provision terminals / Virtual Terminal / portal URL. Typical time from decision to first-transaction-at-new-location is 24–48 hours once the ERP-side record is created.

For acquiring-company scenarios where you're adding a newly-acquired entity, Clarity supports a longer structured onboarding that includes historical-data backfill if needed, but the go-live on payment acceptance at the new location is still fast.

Yes. Not every multi-location business runs on a multi-entity ERP. Many 3–20-location operations run a single-company ERP (NetSuite, Dynamics BC, Acumatica, Sage Intacct, etc.) with multi-branch / multi-warehouse / multi-cost-center structures. Payment Hub's routing matrix adapts to whichever accounting structure your ERP presents — posting to the right branch + warehouse + cost-center combination rather than a separate subsidiary.

You only need a multi-entity / multi-company ERP structure if your legal or tax structure actually requires entity separation. Payment Hub works cleanly across both patterns without changing the customer-facing or counter-facing experience.

Yes, and in fact it's recommended for larger consolidations. Payment Hub deployments typically start with 1–3 pilot locations to validate routing logic, ERP posting, and staff training; additional locations are added in batches (often 5–10 at a time) until the full footprint is consolidated. The already-onboarded locations continue running normally while new locations come online.

Phased rollouts avoid the "big bang" risk that often derails multi-location consolidation projects. They also surface any location-specific tax, entity, or workflow quirks early, before they affect the full footprint. Typical full-consolidation timelines for 20–50 locations run 60–120 days; the 48-hour per-location onboarding is fast once the central routing architecture is configured.

Payment Hub supports mixed-gateway deployments. Most multi-location operations standardize on a single gateway for operational simplicity, but in post-acquisition scenarios (rolling up two companies with different gateway contracts) or regulatory-driven splits (one state on one gateway, another on another), Payment Hub can route per-location to different gateways automatically.

Over time, most clients consolidate to a single gateway for pricing leverage and operational simplicity, but the platform doesn't force it. Each location's routing table entry specifies the gateway; Payment Hub handles the rest.

Central platform go-live with the first 1–3 pilot locations: 48 hours once Clarity receives ERP sandbox credentials, gateway credentials, and the routing-table configuration. Adding subsequent locations: 24–48 hours per location, typically in batches of 5–10 to stay ahead of staff training.

For a typical mid-market consolidation (10–50 locations), expect 60–120 days end to end for full footprint consolidation — including staff training, parallel-run periods at pilot locations, and reporting validation across a full month-end close cycle. Larger deployments (100+ locations) run 4–9 months with a structured rollout plan that Clarity helps design with your operations team.