When onboarding any entity onto the platform, a User is crucial for accessing the Portal and API. Users serve as a Portal login and a distinct identifier for each user in your business entity and overall portfolio. This grants you full transparency into business activities and the individuals driving them, ensuring unmatched security and visibility to manage risks effectively and empower your staff to carry out vital tasks on our platform.
User Access Levels
A user's access level on the Portal is dictated by the entity level associated with their account. This means that a merchant User will have access to merchant capabilities, but not partner or Facilitator capabilities, whereas a partner can access both merchant and partner capabilities and functions of the Portal (except directly accepting payments).
Parent and Child Users
The relationship between Parent-Child users, also referred to as user hierarchy, is crucial in determining access levels and interactions among users. It highlights the importance of each role within your organization. Understanding the dynamics of Parent and Child users reveals a structure that controls capabilities and shapes how your organization operates.
A Parent User is the first user set up when boarding an entity (merchant or partner level).
A Child User is any user created by a Parent User for an entity.
The parent (admin) user of any child (standard) user can access and view the child user’s associated entity (merchant) because its hierarchy is the source of the child user’s access to the portal. As a result:
The parent user will have full view of the child user’s merchant account, but the child user is unable to view the parent user’s view.
Deactivating partner-level parent users that are associated with the entity’s API key or are the primary parent user login will remove access from all associated child users to their respective entity (merchant).
Parent-Child User Relationship versus Multi-Merchant Location Structure
While both concepts take advantage of user access, there are some distinct differences between their purpose and usage:
Parent-Child User Relationship
Purpose: Limit access to particular features and functionalities on a per-user basis within the same entity account.
Use Case: One business with one location and multiple users, with only one needing access to create a payout.
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: One business with multiple locations, where the primary business owner needs access to each location’s Portal account.
User Structure
Users are made up of two major components, the user’s information and the roles assigned to that user:
User Information: Contact information to associate the user account with a real-world person
User Roles: Settings that determine the capabilities of the user for that entity account
These components provide the necessary information to quickly locate and communicate with platform users within your business and the functions they are capable of using through the Portal or API. See Add a New User for new user setup steps.
User Information
When an entity wants to add a new user, the user will need to provide some information, name, phone number, and email as examples, to get started. From here, the user will be provided with a Role, username, and password associated with that information and tied to the entity that created the User. The steps below will demonstrate how to set up a new User with a login.
The following information is required to create a new user:
Required Information | Description | Notes |
|---|---|---|
Role | A comprehensive configuration template that defines the access privileges of a user to view, edit, create, or remove information within the Portal. | Valid Values:
|
Full Name | The full legal name of the user whom the login is being created for. | None |
Username | The username for the new login. | This field will be auto-generated from the text in the Full Name field. This can be modified manually if needed. |
Multifactor Authentication Enabled | Whether the user will need to enroll in multifactor authentication (MFA) for a two-step authentication process during Portal login. | Enabling this for all users is recommended for maximum risk mitigation. |
Password | The password that a new user will use alongside their username to access the Portal. | Recommended Requirements:
|
Phone | The phone number associated with the new user. | This phone number will be automatically used when the user initiates the MFA enrollment process during their first Portal login. |
The email address associated with the new user. | This email address will be automatically used when sending the user confirmation email during their first Portal login. |
User Roles
When creating a user, you must assign a user role, which defines the user’s default permissions. A user role determines what resources a user can view, edit, create, or delete. By assigning user roles, you can tailor each user’s access level to meet your organization’s requirements. See User Roles for details on available roles and how to adjust user access to specific resources.
User Management Use Cases
The use case tutorials outlined below can assist you in navigating the process of creating, modifying, and securing your users and their permissions on the platform: