This article describes the following topics:
Users
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.
For information on setting up Users, access Set Up Users and Access Templates.
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 has 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 removes access from all associated child users to their respective entity (merchant).
For an example of the difference between a parent-child relationship and a multilocation merchant structure, see the Multilocation Merchant Structure section.
User Structure
Users can be broken down into 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 Set Up Users and Access Templates for new user setup steps.
User Information
When an entity wants to add a new user, the user needs to provide some information to get started, such as their name, phone number, and email. From here, the user is provided with a Role, username, and password, and their account is tied to the entity that created the User.
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. | User Roles:
|
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
User roles determine how much access a user has to see, edit, create, or delete information on the portal. Roles can be assigned to users to provide or extract the access capabilities they're intended to have. Each User has a set of default roles with customizable parameters to restrict or allow access to specific pages and functions of the portal and the greater platform. For example, if you wanted to enable a merchant-level user that can create reports and only view all other information, you would assign a Merchant View Only default role and enable the custom Reports role resource with the Create detail permission enabled.
For information on assigning user roles, access Set Up Users and Access Templates.
Default Roles
Default roles determine the level of portal access for a user. Partner-level access roles are roles available to users of a partner-level entity, while merchant-level access roles are available to users of a merchant-level entity.
Notes
Partners can manage all merchants and sub-partners, while merchant user roles are limited to their respective merchant and sub-merchants.
Referrer is the system title for partner-level user roles. They will be used interchangeably throughout this article.
Referrer-Level Default Roles
See the default user roles available for referrer-level users:
Referrer Admin Full Access: Enables the user to view and modify all merchants under a partner hierarchy and any sub-partner accounts under their Division.
Referrer Admin View Only: Enables the user to view only all merchants under a partner hierarchy and any sub-partner accounts under their Division.
Referrer Full Access: Enables the user to view and modify all merchants under their partner account.
Referrer View Only: Enables the user to view only all merchants under their partner account.
For example, a user with the Referrer Admin Full Access role can view, edit, and manage all merchants and account configurations within their platform portfolio. A user with the Referrer Admin View Only role can access the entities and data within their portfolio for reporting and accounting purposes only.
Merchant-Level Default Roles
See the default user roles available for merchant-level users:
Merchant Admin Full Access: Enables the user to view and modify the merchant accounts they are associated with, in addition to managing sub-merchant accounts.
Merchant Admin View Only: Enables the user to view the merchant account they are associated with in addition to viewing sub-Merchant accounts.
Merchant Full Access: Enables the user to view and modify the merchant accounts they are associated with.
Merchant View Only: Enables the user to view only the merchant account they are associated with.
For example, a user with the Merchant Full Access role can add customers, accept payments, and schedule payouts for their entity. A user with the Merchant View Only role can access the platform solely to view data, including transaction data and reports, to facilitate reconciliation processes for their entity.
Note
Referrer and merchant-level users are not allowed to edit the Legal Business Name field. To update this field, submit a partner support ticket.
Access Templates
In addition to the default roles described in the previous sections, you can assign an Access Template when creating a user. An Access Template combines predefined roles and role resources into a tailored set of permissions.
Note
It's essential to understand the different purposes of Access Templates, Groups, and Teams within the platform:
Access Template: Defines what an individual user can do on the platform.
Team: A collection of logins or users that share roles and similar user properties to access the portal or API.
Group: A collection of entities where you can configure fees, risk decisions, and setup parameters that apply to all entities in the group. Remember this is sometimes called an Org.
For information on setting up Access Templates, view Set Up Users and Access Templates.
Detailed Permissions
Detailed permissions follow typical Create, Retrieve, Update and Delete (CRUD) functionality. The primary difference is that there are two View options, where one is given full visibility instead of just access to monetary totals associated with a specific role resource:
Create: Gives users access to create content for the enabled role resources.
Full View: Gives users access to view content for the enabled role resources.
Summary View: Gives user access to view monetary totals for the enabled role resources.
Update: Gives user access to update content for the enabled role resources.
Delete: Gives user access to delete content for the enabled role resources.
Note
Not all Custom Role resources offer all five Detailed Permission options. To view the available permissions for a resource, click the arrow icon next to that resource when you’re customizing a user role.
Role Resources
Role resources determine the specific abilities that a user will have when navigating the portal. In many cases, the Default Roles available for partners and merchant-level users provide the necessary access capabilities that most users need to perform daily actions. For unique cases where Default Roles don’t satisfy the specific criteria required by the Parent Entity or users, Custom Roles allow individual assignment of specific resources with sub-resources for a completely modular user setup.
The following list contains the categories with sub-resources available for individual role resource assignment:
Bank Accounts: Allows the user to add bank accounts for payouts or debits to an entity, such as a partner or merchant.
Payments: Allows the user to view transactions and payments.
Recurring Payments: Allows the user to set up recurring payments and subscriptions for a merchant.
Risk Management: Allows the user to manage merchant and transaction risk factors that are open, reviewed, approved, or blocked.
Invoices: Allows the user to manage invoices sent to clients to collect money for a specific transaction or event.
Invoice Configuration: Allows the user to configure how an invoice is created such as by providing a set address, message, token, or logo for an invoice.
Merchants: Allows the user to set up, view, and edit merchants under a partner.
Users: Allows the user to manage a specific user, or login, associated with an entity.
Groups: Allows the user to group merchants together to set up specific rules for risk management and fees, as well as enable specific parameters.
Alerts: Allows the user to manage the particular event that invokes a notification sent to an end-user.
Withdrawal Schedules: Allows the user to set a withdrawal or payout for an entity to disburse funds or collect funds from the associated account.
Withdrawal History: Allows the user to view the history of disbursements that have been processed or failed for a specific entity.
Referrers: Allows the user to view and manage details about referrers and Divisions.
Splits: Allows the user to split an entry between two entities.
Disputes: Allows the user to manage disputes, or chargebacks, that are open, closed, won, or lost.
Reserves: Allows the user to create reserves for merchants, partners or groups and review entries from previous reserves.
Track Pending Merchants: Allows the user to view the Request More Info page in the portal as a partner.
Quick Charge: Allows the user to view and use the Quick Charge section found on the user's Payrix Pro dashboard.
Underwriting: Allows the user to view underwriting information from the Risk Management and Merchant Profile pages.
Other: Provides a list of direct resources that aren’t found in the other role resource categories shown above.
Teams
A Team is a feature that enables users across different accounts, such as merchants or partners, to share access, permissions, and visibility with each other. Teams are useful for business owners or administrators managing multiple locations, franchises needing to separate merchant accounts to identify locations or users who need general shared access across different business entities.
Teams enable users to:
Share Access, Views, and Abilities: Team members can lend their views and abilities to one another, surpassing the average user's default capabilities.
Share Visibility: Teams enable users to share the visibility of merchants and partners, making it easier to collaborate and manage business operations.
Modify Access Levels: Teams enable adjustments to individual users' access levels through the Team User Addition form to customize permissions for each team member as needed.
Share Cross-Account Access: Teams share access between users from separate merchant accounts and locations, which is particularly useful for franchises.
Share Notifications: Teams enable users to set up web and email alerts for specific user actions. These alerts are tailored to individual users to ensure that team members' actions can trigger events from their respective accounts.
Note
Partners can add merchant-level users to their Team, but merchants cannot add partner-level users to their Team.
Team members are not required to have any access. You can establish one-way visibility by setting Allowed Access to None. This enables Team owners to view a user, but the user can’t view the Team owner.
For information about creating Teams, access Create Teams.
Allowed Access Levels
When adding a user to your Team, you can assign their specific Allowed Access level. This setting controls what they can do within the Team, meaning other Team members' merchant or partner accounts they now have access to. The four Allowed Access levels are:
None: The user cannot see other Team members' accounts.
View: The user can only view other Team members' accounts.
Edit: The user can make changes to other Team members' accounts.
Admin: The user has full administrative access to other Team members' accounts.
Allowed Access versus User Roles
User Roles determine what a user can do within their own merchant or partner account. However, Teams enable users to share access across multiple accounts, and in some cases, a user can gain broader access to another merchant or partner account through a Team than they would have on their own account.
This means that while User Roles normally limit a user’s abilities within their assigned merchant or partner account, their Allowed Access level within a Team can override these limitations when accessing another merchant or partner account through the Team.
Multilocation Merchant Structure
A multilocation merchant structure refers to a merchant business operating in multiple locations but under the same business entity. In this structure, each location is onboarded individually as its own merchant entity on the platform. Because each merchant location generates its own transaction data, the primary owner of the business needs a simple way to review data, generate reports, and perform reconciliation for each location. Onboarding each location separately helps with segmenting, organizing, and gathering data for more accurate risk management, reconciliation, and reporting.
Components of a Multilocation Merchant Structure
A multilocation merchant structure uses the Teams feature on the platform to group users based on specific needs and workflows. The following table describes the components involved in configuring a multilocation merchant structure.
Component | Description |
|---|---|
All Merchant Locations Team | A Team that groups all merchants from different locations based on their user account. |
Primary Admin merchant user | A user that oversees the All Merchant Locations Team, with full access to log in to any associated merchant accounts and data. |
Merchant location user | A main login enrolled in the Team and associated with a merchant location. |
The Primary Admin merchant user creates the All Merchant Locations Team and provide themselves with a Full Access user role for that Team.
Notes
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 partner for assistance with first-time user enrollments to the Team. After enrollment, the Primary Admin user can adjust each enrolled user’s permissions and roles.
This structure 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. The following table describes this example:
Merchant Account | Merchant Main Login | Team User Access Role |
|---|---|---|
Primary Admin Merchant | Primary Admin Merchant User | 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 how these accounts and users relate, see the following flow diagram:
Multilocation Merchant Structure versus Parent-Child User Relationship
While both multilocation merchant structures and parent-child user relationships take advantage of user access, these concepts have distinct differences between their purpose and usage:
Multilocation Merchant 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.
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.
Single Sign-On
Single sign-on (SSO) is an account security feature that authenticates users and grants access to applications. Only facilitators and partners can use the SSO feature to log in.
SSO uses Security Assertion Markup Language (SAML 2.0) or OpenID Connect (1.0) protocols to defer user authentication to your chosen identity provider (IdP) and provide identity data for platform access control.
To use SSO, you must set up a domain with an IdP such as OneLogin, Google, Microsoft, or Okta.
The following table provides a brief comparison of authentication protocols:
SAML 2.0 | OpenID Connect 1.0 | |
|---|---|---|
Supported Protocols | XML, HTTP, SOAP, and all other XML-friendly protocols. | XRDS and HTTP |
Validation Process | Validated through chosen IdP intermediary service response. | Validated through OAuth server response. |
Access Response | SAML authentication assertion is generated by the intermediary IdP service to grant access. | A temporary access token is granted by the IdP server to grant access. |
Supporting Identity Providers |
|
|
For information about enabling SSO in the portal, access Enable Single Sign-On (SSO).
Additional Resources
Visit the links below to learn more about different authentication protocols:
Multifactor Authentication (MFA)
Multifactor authentication (MFA) is a security measure implemented for all portal users and API-integrated partners. MFA creates an additional layer of user verification by supplying a six-digit code to an authentication method of your choice to verify you’re the user logging in or initiating a request or action.
MFA is required when using a Session ID within the portal or Payrix Pro API. MFA works with most browsers, but review pop-up blockers that might prevent the Remember Me option from displaying.
For information about enabling MFA in the portal, access Set Up Multifactor Authentication (MFA).
Recommended MFA Authenticator Apps
Many different multifactor authentication apps are available to choose from. Below is a list of trusted authentication apps we recommend for individuals to use in MFA enrollment:
Microsoft Authenticator
Google Authenticator
Okta Verify
RSA SecurID
Remember Me
After a portal login attempt, users enter a temporary authenticator code and can optionally select Remember Me for up to 30 Days. Once users complete MFA enrollment and attempt to log in to the portal, they are prompted to enter the current temporary authenticator code.
At this point, users can select the Remember Me for up to 30 Days checkbox. Users won't be prompted for a temporary MFA code on their next login within 30 days.
Note
Remember Me can be used by multiple devices under one account at a time.
To properly enable Remember Me, users must allow location sharing when prompted by their browser when accessing the portal. Ensure that your browser is not set to block location sharing from the portal URL.
Select the Remember Me for up to 30 Days checkbox before entering the authenticator app code to prevent the selection from being discarded.
Log In as Another User
After users are enrolled in MFA, they are also prompted to submit an MFA code when logging in to their child entities' portal views. For example, a partner logging in as one of their merchants must submit an MFA code if their partner account has MFA enabled. Users can still use Remember Me for up to 30 Days to only require re-authentication every 30 days.
Reset MFA Enrollment
When users encounter problems with the devices that receive authentication codes for MFA due to damage, loss, device upgrade, or theft, MFA can be disabled and re-enabled to prompt the user to re-enroll in MFA. The MFA enrollment process is shown to the user again on next login so they can re-enroll in MFA.
See the recommended points of contact for each user access level on the platform to reset their individual MFA enrollment:
Partners: Contact Payrix Pro Partner Services.
Merchants: Contact your partner.