Multi-Location Merchant Structure
Multi-location structure refers to a Merchant business operating simultaneously in multiple locations but under the same business entity. In this structure, each Merchant's location is boarded individually as its own entity on the platform. This is done to segment, organize, and report data individually for the most accurate risk management, reconciliation, and reporting results. When each Merchant's "location" is boarded, the primary owner of the business will want to review the transaction data, generate reports, and perform reconciliation for each Merchant in the easiest way possible.
For example, a hair salon Merchant named "HairMaster" operates a business with multiple franchise locations accepting payments in-store and online. The owner of HairMaster, "Bobbi Pin", wants to view the transaction and reporting data across all their franchises in one place to reconcile their accounts, and track each location’s progress against sales goals.
Multi-location structure utilizes the Team feature on the platform, allowing Users to be grouped based on specific needs and workflows. To configure this multi-location structure, you’ll need:
Component | Description |
---|---|
“All Merchant Locations” Team | A Team that groups Merchants from different locations based on their account user. |
Primary Admin Merchant User | A User that oversees the “All Merchant Locations” Team, with full access to login to any associated Merchant accounts and data. |
Merchant Location User | The main login enrolled in the team and associated with each Merchant location. |
The Primary Admin Merchant User will create the “All Merchant Locations” team, and provide themselves with a “Full Access” user role for the team.
Warning: Primary Admin Merchant Users in this scenario cannot directly enroll other Merchant Location Users to the Team on setup.
To add Merchant Location Users, the Primary Admin User must contact their Referrer for assistance in first-time user enrollments to the Team. Subsequently, the Primary Admin User will be able to adjust each enrolled user’s permissions and roles.
This ensures that the Primary Admin Merchant user has visibility into each Merchant location for their business, but that each individual merchant location cannot see or manipulate data or Portal settings for each other, like the examples below:
Merchant Account | Merchant Main Login | Team User Access Role |
---|---|---|
Primary Admin Merchant | Primary Admin Merchant User | Full Admin |
Merchant Location 1 | Merchant Location 1 User | None |
Merchant Location 2 | Merchant Location 2 User | None |
Merchant Location 3 | Merchant Location 3 User | None |
For a visual representation of this association, see the flow diagram below:
Setup a Multi-Location Merchant Structure
Managing multiple locations under a single entity can be a complex yet essential task. The process of setting up a Multi-Location Merchant Structure involves creating a cohesive User access framework that allows for streamlined oversight and management of various merchant locations.
By establishing distinct teams and user roles, businesses can ensure efficient data organization, risk management, and reporting across all their franchises. Let's delve into the steps required to configure this structured approach effectively.
Setup Prerequisites
Each Merchant location is fully boarded as individual Merchants.
The names of the primary users for each Merchant (can be found on the “Account” tab of the Merchant Profile).
Result: The Primary Merchant Admin (User) can now log in to and view Merchant account information for each location in the Portal.
Multi-Merchant Location Structure vs. Parent/Child User Relationship
While both concepts take advantage of user access, there are some distinct differences between their purpose and usage:
Multi-Merchant Location Structure
Purpose: Enable one main Merchant user to easily view and access other Merchant entities operating under the same corporate umbrella on the platform and generating revenue.
Use Case: 1 business with multiple locations, where the primary business owner needs access to each location’s Portal account.
Parent/Child User Relationship
Purpose: Limit access to particular features and functionalities on a per-user basis within the same entity account.
Use Case: 1 business with 1 location and multiple users, with only one needing access to create a payout.
See User Hierarchy for more information.