Account Types and Client Management
To understand how Azupay's dashboard and platform access works, it is useful to understand a little about how our system handles permission scopes and what platform features are enabled. The general unit of configuration in our platform is known as a 'Client Account', which is identified via a unique client identifier, your clientId.
Depending on the type of client you are, you may only have a single clientId and dashboard (typically if you are a direct client with a simple business structure and requirement) or you may have several sub accounts you can access that you need to manage from a parent account.
If you have more than one clientId you can manage when logging into our platform, your accounts will be organised into an account hierarchy, with a top level parent, and then one to many sub accounts below this parent. In some circumstances, you may have multiple levels in your client hierarchy. How you may use sub accounts will normally be tied to the type of client you are.
Types of Clients
Azupay has several different types of clients that may use our product, which can be broadly divided into End Clients (Direct Clients and Sub Clients) and Partners.
Transacting Clients are clients that use our payment products - Azupay provides a designated service to these clients. These clients typically have access to one or more of our payment APIs and will likely use the Single Account Pattern or Multi Account Pattern. Note that the term client is used in this page to indicate a user of our platform, but may be used interchangeably with merchant or partner elsewhere in our documentation or this page depending on your relationship with Azupay.
- Direct clients that integrate with our product directly and have a direct commercial relationship with Azupay. Direct clients will have a client type in our system of Merchant (Merchant), or Sub Account (Sub_Account) for sub clients of the Merchant.
- Sub clients that integrate with our products via a partner and may have a commercial relationship with either the partner or with us, depending on the partnership type and distribution mechanism. These clients will have a client type of Sub Merchant (Sub_Merchant) in our platform.
Partners are clients that provide products and services to their sub clients clients to help them integrate with Azupay - Azupay does not provide a designated service to these clients.
- Partners will typically use the Multi Account Pattern - Partners if they are responsible for managing System Integration options for their clients, such as in the case of Distribution(Distribution_Partner) and System Integration Partners (System_Integration_Partner).
- Partners will typically use the Technical Administrative Account Pattern in the case of a Technical Integration Partner (Technical_Integration_Partner), where they only need a subset of administration functionality, such as the ability to provision API keys and configure account settings, but don't require access to reporting, transaction search or financial functions from the dashboard.
Partners that onboard clients directly will have their clients onboarded as a Sub Merchant.
We only allow some client types to onboard their own sub clients via our Clients API. This is not enabled by default for all client types, so if you need to be able to onboard your own sub clients, please talk to your account manager or sales manager.
Client Types Reference and Access to Clients API
As a summary of the different client types we support, and their ability to onboard client accounts directly, refer to the following table.
| Client Type | Description of Client | Azupay System Identifier | Access to Clients API available? |
|---|---|---|---|
| Merchant | A transacting client who maintains a commercial relationship directly with Azupay. Will use our Payment APIs and or our hosted apps. | Merchant | Yes - requires approval. Can onboard Sub Accounts. |
| Sub Account | A transacting client's sub accounts. See Merchant. | Sub_Account | No |
| Distribution Partner | A Distribution Partner (DP) owns the relationship and onboarding journey of their sub-clients. Azupay need to be informed of the sub-clients' preferred choice of configuration settings. Azupay will also perform their own high-level risk assessment on the sub-clients. See * Distribution Partners for more information. | Distribution_Partner | Yes - Distribution Partner is responsible for client KYC. |
| Technical Integration Partner | A Technical Integration Partner (TIP) is a business that enables their clients to gain access to Azupay services by providing them with an overall payment's platform. The client will be setup on Azupay dashboard as a sub-client of the partner. Key difference from a System Integration Partner is that Azupay will manage a separate relationship with client for onboarding, support & billing. See * Technical Integration Partner for more information. | Technical_Integration_Partner | Yes - Azupay is responsible for client KYC. |
| Sub Merchant | A transacting client who has been onboarded and may be managed by a partner. Will use our Payment APIs and or our hosted apps. | Sub_Merchant | No |
| Sub Partner | A partner's sub accounts not used for transacting. | Sub_Partner | No |
| System Integration Partner | A System Integration Partner (SIP) is a business that enables another business to gain access to Azupay services by providing them with an overall payments platform. SIPs own the relationship with their clients but require Azupay to perform the Know Your Customer and Due Diligence checks. See * System Integration Partners for more information | System_Integration_Partner | Yes - Azupay is responsible for client KYC. |
| Referring Partner | A partner type that refers Direct Merchants to Azupay. | Referring_Partner | No |
Additional Information on Partnership Types is available from Merchant Help Centre: Partners
Account Hierarchy Patterns
What is an account hierarchy?
Clients in our system can belong to an 'account hierarchy'. This is a parent to child relationship between one to many accounts, and allows users of a parent client account to 'drill' down into any sub clients below their level in the account hierarchy, or potentially onboard new clients if approved to. Azupay segments most capabilities at a client account level, and there are several situations when having more than one account may be useful.
Features tied to client account levels
The following table outlines some considerations on when it may make sense as a direct client to request a sub account to be provisioned for you.
Feature | Permission Level | Overview | Considerations for Multi Account setup |
|---|---|---|---|
Liquidity | Account Level | Liquidity (your account balance with us) is managed at a client account level as each client account has its own dedicated BSB and Account Number and Top Up PayID. | If you have seperate products, services or businesses you want to maintain liquidity for separately, this is achieved via use of sub accounts. |
Transactions & Agreements | Account Level | All transactions in our system, such as PaymentRequests, Payments, PaymentInitiations and Payment Agreements are tied to the client level they are made. | If you need to seperate any events related to transactions, such as liquidity, webhooks, reporting or whitelisted domains. |
PayId Domains | Account Level | While you can re-use a PayID domain across multiple accounts, if you want to limit the domains available for use for a specific API key or checkout process, this can be achieved through multiple accounts, as each domain is explicitly whitelisted for an account. | When domain use must be separated. |
API Key Scoping | Account Level | API keys used to access our API are tied to a specific client account. Outside of specific APIs that can be called on child accounts, client API keys can only be used to perform actions at the account level they are provisioned. They do NOT have access to accounts lower, higher, or adjacent to them in an account hierarchy. All transaction and reporting APIs operate at an account level. | If you want to segment the security of your API key access, for example for two business units, system integrations, or products. If you want to use a single set of API keys for all transactions, a Single Account should be considered. |
Apps - Checkout Configuration | Account Level | If you use our checkout apps, these are configured at a client level. | If you want to have checkouts with seperate branding. |
Apps - Batch Configuration | Account Level | If you use our Batch app, this is configured at a client level. | Mutli Account setups will require one SFTP connection per account level requiring this feature. As Batch by default pulls from your SFTP server, you can reuse SFTP names and keys across accounts and point each of them to a unique client sub directory on your server to simplify access management and orchestration. |
SFTP Job Configuration | Account Level | If you use our SFTP services for reporting, configuration is at a client account level, as Azupay configures and scopes SFTP access and associations of transactions to the client level the transactions take place at. | Mutli Account setups will require one SFTP connection per account level requiring this feature. |
Reporting | Account Level | All reporting occurs at an account level. While users in a parent account can drill into a sub account, reporting currently requires you to access the associated capability from the client account the transaction took place. Sub accounts or using the clientBranch field on payment requests should be considered if you need the ability to break up reporting for transactions. | Mutli Account setups will require you to implement a way to aggregate reporting, as Azupay does not currently support. Note that using the clientBranch field available on Payment Requests allows you to categorise reports in a single account configuration. |
Webhooks | Account Level | Webhook event subscriptions are configured at an account level. | If you have seperate production systems integrating with Azupay and want a specific set of transaction types to only send webhooks to one system, but are not using request level webhooks, seperate accounts can be used to achieve this |
IP Whitelisting | Account Level | IP Whitelisting allows you to restrict what IP addresses can call our APIs. | You will need to whitelist IP addresses at each client level if using IP whitelisting. |
Dashboard User Access | Account Level and All Sub Accounts below your Account Level | You can invite users to a specific level in your hierarchy. If you are an enterprise client using our SAML integration for SSO, this is also configured at a client level. | This is used to scope account access as users can only access accounts at or below their level in the hierarchy. |
Dashboard User Permissions | Account Level and All Sub Accounts below your Account Level | A user with permissions, such as an Admin User with API key management permissions, will have those permissions for the Account level they were invited and all sub accounts. | Users can be invited at a sub account level to limit their access. |
Note that distribution partners are always configured as a parent of their sub client accounts.
Single Account Pattern - Direct clients
This is the default recommendation for clients, as it allows simplified user and api key management at a single account level.
If you have been onboarded by a Distribution or System Integration Partner, your partner will have administrative access to your account as outlined in the Multi Account Pattern - Partners section, although from your perspective, you will have access to a single account.
Multi Account Pattern - Direct clients
The Multi Account Pattern allows a Client to have one to many sub accounts, one level deep. This is useful when you need to segregate accounts into specific products, business units, legal entities, reporting units or user groups.
Multi Account Pattern - Partners
As a Distribution Partner, you will onboard sub clients into your account via our Clients API or via Service Desk. If you require the ability to manage or administrate the sub client's account, such as managing reporting, dashboard users, or API keys, having them configured as a sub client will allow users of your distribution account to manage your sub clients.
Technical Administrative Account Pattern
A Technical Integration Partner may provide implementation and support for a direct client or one of their sub client accounts, and can be provisioned a special administrative level permission to accounts they are not parents of to provide support for a client. Technical Administrative account access is typically used when a Technical Implementation partner has multiple clients they assist with Azupay solutions, or when a direct client needs to provide access to a technical partner team rather than a single technical partner user, and wants the technical partner to manage their own users.
Security Considerations for Account Access
Account login email addresses must be globally unique
Your user dashboard login for the Azupay platform uses your email address as a unique identifier. Your email address is associated with one **and only one ** client ID. If you have a mutli-account hierarchy, you will have access to the specific client account you are onboarded to, and any sub accounts that exist below it in your account hierarchy via the Switching Clients functionality, which lets you access all sub accounts belonging to your account hierarchy, regardless of their depth in the hierarchy.
User permissions are inherited
When your account is configured, it will be given a specific user role. You will have permissions associated with that user role for all sub accounts you have access to. For example, if a user is configured as an admin, they can access all sub accounts as an admin.
Email Plus Addressing can be used to allow multiple accounts associated with a single email address.
Most major email providers allow a concept called plus addressing, where a user can add +<word> to their email prefix to support multiple email address aliases to be associated with a single email account. Plus address emails are recognised as unique, distinct accounts by our system, and can be used as a work around to email addresses needing to be globally unique.
If you have specific needs to have a least permissions login for specific accounts, or want a user to be an admin for a specific level of sub account but have non admin permissions on the parent account, you can use plus addressing to invite your email to have a secondary account on the sub account (or same account for that matter). For example, [email protected] may use the email address [email protected] to access their admin role, or [email protected] to access their customer service operator role. Be aware that user permissions are still inherited for all sub accounts of the account the user is invited to if using this pattern.
Updated about 15 hours ago