You (as the Administrator) create a ‘user profile’ for each member of staff that needs to use our applications, giving each user the roles you want the user to perform, from the list of roles we present. Roles enable you to control the applications to which a user has access and, within the Merchant Admin Interface, the merchant codes (accounts) to which they have access and the parts of the interface they can use.
The Merchant Code is a unique identifier for a particular merchant account within the Worldpay payment service. You can have one or more merchant codes, depending on how many accounts you have, but not all your users may need access to all of them. For more details of merchant codes, see Specifying merchant codes and Merchant Codes.
You can create other users with only the same or more limited roles and access to accounts than you have – not more. And you can specify if such users can change users created by others or only the users they created.
For example, you may have staff who manage payments and cash flow (rather than system / technical tasks). And within this group, only certain individuals have the authority to refund payments. To cater for this situation you can create several users with the role “manage payments” and several with an additional role “manage refunds”.
As a result, all the users will have access to the Merchant Admin Interface. However, only those users assigned the role of “manage refunds” will have access to the parts of the Merchant Admin Interface that enable you to make refunds. None in the group would have access to functions related to system administration. None would have access to the Hosted Call Centre. For a list of the roles available, please refer to Roles and Permissions.
As well as specifying the role(s) a user will play, you also specify the merchant code(s) (accounts) to which they will have access / with which they can perform those roles.
Some organisations have only one merchant code while others have several. For example, an organisation may have one merchant code for payments made in Euros, and another for those made in Sterling GBP. In this situation, you could create two users with exactly the same role, but assign each to a different merchant code, giving one of them access to the Euro account only and the other access to the GBP account only. A third role could be created, for a senior member of staff perhaps, to access both merchant codes.
Once logged on, users can access the applications specified in their user profile using menu options. However, we also provide different login pages to suit different types of user. For example, by logging on through one login page, Administrators are provided with system status and product news, as well as a list of all the applications to which they have access. A call centre operator logging in through another login page is logged into the Hosted Call Centre only.
The details about each user of the Merchant Admin Interface are stored in a user profile which is created initially either by you as the Administrator, or by a user you have created and assigned the user management role.
The user profile contains:
Login credentials - the username and password that enable a user to login to the MAI.
Assigned roles - a list of the roles assigned to them and the roles not assigned to them.
Assigned merchant codes – a list of the merchant codes (accounts) to which they have access and those they do not.
Each user can change their own password to make it easier to remember, without having to refer to whoever created their user profile, using the User Profile page. When a user logs on for the first time, they will be prompted to change the password they were given (by whoever created their user profile) before getting access to our applications. Each user is prompted to change their password when their current password is due to expire.
We provide a predefined set of roles. For a complete list of the roles available, refer to Roles and Permissions.
Generally speaking, most of the roles correspond directly to pages in the Merchant Admin Interface – for example, Dispute Management, Payments and Profile – so that you can specify which users can access which pages. But roles are also used to control access to specific fields and/or buttons in the MAI – the Refund button for example – so giving low level control over who can use what.
Finally, roles are used to specify the applications to which a user has access (Hosted Call Centre, Merchant Admin Interface).
There are two types of role: ‘monitor’ roles enable read-only access to pages, while ‘manage’ roles enable write access so that the assigned users can update information / change settings.
The ‘Manage Payments’ role, for example, enables assigned users to use the features in the Payment Details page that enable you to capture a payment manually (to enable this facility, contact your Relationship Manager or corporatesupport@worldpay.com). The ‘Monitor Payments’ role enables assigned users to use the Payments Details page but not to capture a payment. The ability to refund a payment is determined by another role, Manage Refunds.
Both the Worldpay production environment and the test environment have their own Merchant Admin Interface. We provide a set of predefined roles for each environment. To provide your users with access to the test environment you simply assign selected Test roles to them in the user profile.
If your organisation has several merchant codes (accounts) with us, User Management also enables you to assign the merchant codes to which a user has access.
If a member of staff plays the same role for each of several merchant codes, you can simply assign a user with the appropriate roles to those accounts. However, if the same member of staff needs different roles for one merchant code when compared with the other, you will need to create two users each with different role and account assignments for their use.
For example, the head of the American office accounts department may have ‘full rights’ on your US Dollar account; being authorised to make refunds, manage disputed payments and so on, but allowed only read-only access to the Euro account. In this case you would need to create two users for his/her use, each with the appropriate roles and account assignations.
Most merchants that have several merchant codes with us, have a single administration code that links those accounts together. In this situation, users can be assigned to one or more of these merchant codes and the assignment easily changed at any time.
However, you may also have several administration codes. These may be, in effect, several totally ‘unconnected’ top-level identifiers, each having a set of one or more merchant codes, each with a different Administrator. (Although they may be used by the same person, each set of accounts is accessed by a two separate sets of login credentials). In this situation, users created by the Administrator of one administration code are physically separate from the users created by the Administrator of the other administration code. You would need to create one user for one administration code and another user for the other administration code.
Similarly, a user with the role 'manage - users (any user at own administration level)' has the ability to create, edit and de-activate users created under one administration code. If your organisation is one of the few that has more than one administration code, a user would need a login profile for each administration code, each specifying the 'manage - users (any user at own administration level)' role, in order to be able to create, edit and de-activate all users.
When we set up your Worldpay account we create a ‘master user’ to which we assign all available roles for both the test and production environments, and issue the associated username and password. These login credentials can then be used to create the users required by your organisation. We refer to this ‘master user’ as ‘the Administrator’, throughout our documentation.
The Administrator can delegate a user the ability to create, change and de-activate other users, by assigning the Manage Users role to that user. Such a parent user can create other users with the same or more limited roles and access to accounts than they have – but not more. While this keeps users' access to the system very controlled, it may not be convenient in some organisations where several managers / supervisors share management of users and need to be able to change users created by another manager / supervisor.
To cater for this need, in place of the Manage Users role, the Administrator can assign the 'manage - users (any user at own administration level)' and the 'manage - users (any user at own merchant level)' roles.
Users assigned the 'manage - users (any user at own merchant level)' role can create, change and de-activate users that have access to any of the same merchant codes (accounts) they themselves have access to. Users assigned 'manage - users (any user at own administration level)' are able to create, change and de-activate any other user created under the same administration code.
Most merchants have only one administration code so assigning a user the 'manage - users (any user at own administration level)' role will often mean that the user assigned this role can modify any other user of our Merchant Admin Interface within their company.
Many organisations have several merchant codes (an account for each currency, for example), so assigning a user the role 'manage - users (any user at own merchant level)' is a way of limiting the users the assigned user can modify, to those using a particular account or group of accounts. For example, if the user assigned this role has access to a merchant code MYCOGBP (only), they can create, edit and deactivate a user that has access to MYCOGBP, MYCOEUR and MYCOUSD because they both have access to MYCOGBP. The user could not modify another user who has access to merchant code MYCOUSD only, for example, because they have no merchant code in common.
Usually the Administrator will not grant the ability to set user policies via the User Management Policy page since policies apply to all users created in an administration code.
If a role is removed from a parent user, the same role will be automatically removed from any user created by that parent user.
Only a parent user can list or update the users they created – no one else, including the Administrator, can do so. This hierarchical arrangement enables you to delegate the creation of users to your operational departments – it may be convenient for your customer support team manager to control access by the support team to the MAI, for example.
For details about creating users, please refer to the Creating a user page.
| Guide feedback?
Email us at: guides@worldpay.com |
   
|
|
© FIS 2023, and/or its subsidiaries. All rights reserved. |
