Release Version 4.24.0 (October, 2024)
Pre-deployment steps
Post-deployment steps
New functionality
Feature |
Description |
Benefits |
The ability for the service user to create a new service role with the specified existing permissions |
A service user with appropriate permission is able to create a new service role with the specified:
so that these roles can create users with the created role and users with the created role can access the platform and functionality defined by the specified permissions. After the role is created service users can create multiple users in this new role. |
It provides the ability to configure different service roles with a set of permissions and create users with these roles to meet the needs of the business as much as possible. |
The ability to specify the date from which the new contract will be applied to the user after the contract change and the ability to change contracts for clients in bulk were added |
Service users can provide a new contract begin date when changing the contract for the client (for a single client or in bulk). A new contract will be applied to the client when the date is reached. Until the start date for a new contract, the client will use the existing contract. If a new contract begin date is not provided – a new contract will be applied immediately. Every time a service user sets a contract change the old settings, if it exists, will be overwrited. Contracts can be changed in bulk only if all selected users have exactly the same contract. |
Allows service users to schedule contract changes for clients in advance. |
The ability for a service user to change role for another existing service user was added |
Service users can change roles for another existing service user (except cashier), so that this service user will have access to the functionality according to permissions from the new role. Roles to be able to change roles:
The roles of existing service users can be changed only within the bounds of one organization. |
Now you can change roles for existing team members and give them access to the corresponding back-office features |
The ability for user with service roles to change permissions for other existing service roles except administrator was added |
Service user with appropriate permission can:
so that users in the changed roles have access to functionality according to the new permissions after re-login. Any role can not change permissions for the administrator role. |
Now you can change permissions for any roles (except Administrator) for existing team members via UI and API and give them access to the corresponding back-office features |
The ability to display back-office functionality for service users depends on the permissions implemented |
Now display functionality for service users on UI depends on the permissions instead of roles, so if permissions for a role were changed functionality is displayed according to the new permissions with the next login. |
Allows more flexible configuration of feature availability for service users |
New default roles were added to the system configuration |
The following service roles (team members) are available in the system configuration and will be created when the system starts: Customer Help team
*corresponding two old roles: Customer_support, Customer_support_manager Scam-prevention team
*corresponding three old roles Compliance_specialist, Head_of_compliance, Compliance_manager
Finance team
Revenue team
Administrative team
All default service roles (including Customer Success specialist) are linked to the organization with type “System“. Except for the Cashier role – it is linked to “Cash desk” organization. In the current release old default roles that are mentioned as “corresponding” to new ones will be available too. But if your business is using these roles you need to switch to new, relevant roles to be able to use the back-office features to their full advantage. The following old roles will be deleted in future releases:
Also new business role was added as default:
Corporate is linked to an organization with the type “Corporate” The system creates all listed roles with the set of appropriate permissions granted to each role by default. So that the service user can create users with these roles (more than one) and all of them will be able to perform actions according to permissions. |
The system has a pre-configured wide range of service roles that can be used immediately after system startup, to cover different business scenarios and allow to meet the business demands better. |
The ability for a business user to withdraw from a wallet via the cash desk without double confirmation by the Accountant was added |
Business user can withdraw from wallets via the cash desk without double accountant’s confirmation (only Cashier confirmation is required). The feature is available via API only, UI will be provided in the following releases. Use APIs to perform withdraw via the cash desk without double accountant’s confirmation only with Cashier confirmation:
Flow with Accountant confirmation is also available by using a separate set of APIs:
|
Improving the overall user experience |
The ability to specify and manage trusted domains was added |
Service users are able to specify and manage domain names with which team members are allowed to register their emails as contacts for login into the system (trusted domains). In the current release service user can manage trusted domain names:
|
Ability to control under which e-mail team members will get access to the system. Allows to avoid using personal email as a login to the application, only corporate emails. |
Validation of the team member’s emails by the trusted domains list was added |
To activate trusted domains validation property Validation of the provided user email for login credential purposes has been applied to APIs:
Email validation fails when:
|
Improvements
Feature |
Description |
Selfie was added as required for KYC document type by default in the system configuration for the pre-prod instance |
– |
Filter by currency was added to “Contract – Vendor – Operations” list form UI |
– |
Filter by main currency was added to POST /v1/currencies/view |
– |
The ability to provide nationality, tax residence country and tax number in user profile was added |
Business user can provide nationality, tax residence country, and tax number in his profile, view and modify it
Service user with appropriate permission also can modify these parameters in a business user profile. Note: |
The ability for service user to unban banned user on UI was added |
– |
Additional parameters were added to the view of the list of system accounts (with filter and pagination) |
Service user can view the following parameters for the list of system accounts (accounts of all organizations, except Individual and Merchant organizations) with filter and pagination:
Available Filters:
|
API to get list of all permissions and for the specified role was added |
API accepts role (no matter service or business) and returns list of permissions for the provided role. If role is not provided, API shall return list of all permissions. |
The ability for service user to get the list of existing roles was added |
Service user with appropriate permission can get list of existing roles with number of users created in the roles |
The ability for service users to delete other service roles without users linked to this role except administrator was added |
Service users can delete another service role except for administrator if no users are linked to the deleted role. |
The ability for service user to activate/deactivate other service roles except administrator was added |
The service user can deactivate/activate another service role except administrator so that deactivated role can’t be assigned to the user. |
The ability to view the list of roles who can create the current role and who can be created by the current role was added |
Service user can see the following for the provided service role:
|
The ability to see provider commissions on the Contract forms was added on the UI |
Service user can view Vendor commission (active for the current period) on the “Contracts/[Contract name]/[Vendor name]/[Operation name]/Commissions and limits” form (on view, create and edit forms) |
Change mail service configuration does not perform SMTP health check when LOG or AmazonSES providers are selected |
The issue if LOG is selected and health checks are not completed – app can not launch was fixed. Mail service configuration was changed to does not perform SMTP health check when LOG or AmazonSES providers are selected |
The structure of POST /transactions/view API response was enhanced |
See API Changes to know more. |
Filter by |
See API Changes to know more. |
API was switched to the “Team member profile details” form of the Back-office |
Service user with appropriate permission can view the following information about team members:
Also service user can:
|
The ability to see all service roles when creating service user via UI was added |
Service user with appropriate permission can select all available service roles (including custom roles), users with which he can create when creating team via Back-office UI. |
The ability to duplicate the existing contract with all commissions and limits (optionally) was added |
Service user with appropriate permission can specify whether or not to copy commissions and limits from existing contract. User can copy limits only together with commissions.
|
System refactoring was done: when client wallet is created, the system creates system_commission wallet in the same currency as the client wallet |
Operation processing accounting refactoring was done to eliminate the optimistic lock at the commission wallets. Contact us to get more information about the changes in the accounting model for different operations and new wallet types. |
System refactoring was done: for operation processing the system uses system_commission wallet at the business user level instead of the system level |
|
System refactoring was done: when a commission wallet at the business user level is not found for operation processing, the system creates a wallet and processes the operation |
|
Process to sum balances at the system_commission wallets at the business users level and update balance at the system_commission wallets at the system level was implemented |
Fixes
- Pagination was added on the “Asset details” page of the Back-office UI
- Issue with the “View transaction details” link was fixed in case reconciliation was performed using device order ID
- The issue with reconciliation statuses for transactions was fixed
- The issue with reconciliation statuses for transactions was fixed
- The reconciliation statuses for transactions were added
- Legacy commission profile artifacts were removed from the code
- Displaying of amounts in the Individual UI according to currency fraction and scale was fixed
- The issue with scrolling the left sidebar with the menu position was fixed
- Multiple issuers with button components were fixed (margin, stroke)
- The issue with the ability to copy information was fixed
- The issue with ‘Allowed to create new roles’ toggle was fixed
- Role name displaying was fixed
- Vue-query error when trying to refresh the “Member details” page was fixed
- Permissions to view “Change role” and “Delete role” buttons were fixed
- Alerts were changed appropriate to the design
- The issue with pagination in the POST /role-groups/aggregation/view was fixed
- The issue with removing a batch of roles when updating user permissions was fixed
API changes
Endpoint |
Updated |
PUT /v1/management/organization-settings/{organizationTypeCode}/roles/{roleName} |
API endpoint was changed to update the permissions and creation methods of an existing role in the system based on the organization type and role name.
Required Permissions:
request body:
|
POST /v1/role-groups-is-able-to-create |
New new parameters Permission required: ROLE_GROUPS_IS_ABLE_TO_CREATE_VIEWER request:
|
POST /v1/currencies/view |
Filter by
Permission required: CURRENCY_VIEWER request:
response:
|
PATCH profiles/my/person PATCH profiles/{userId}/person |
The following fields were added to the request and response:
request:
response:
|
GET profiles/my GET profiles/{userId} |
The following fields where added to the API response:
response:
|
POST /transactions/view |
API response was changed:
|
POST /v1/business-requests/{requestIdentifier}/approve POST /v1/business-requests/{requestIdentifier}/decline POST /v1/cash-desk-withdrawals/{requestIdentifier}/perform-withdrawal |
Added optional request body to provide resolution parameters for cash desk withdrawal requests.
request:
response:
|
POST /v1/users/view |
New filter by
Possible value
request:
response:
|
POST /contracts/{contractId}/copy |
API request and response were changed. Added ability to specify whether or not to duplicate commissions and limits from an existing contract.
Where request:
response:
|
Endpoint |
Added |
POST /v1/role-groups |
Added a new API to create a new service role with the specified existing permissions. Permission required: SYSTEM_ROLE_INITIATOR When creating a new role,
If at least one of the operations is set, request:
response:
|
PATCH /v1/contracts/{contractId}/organization |
New API to change the contract for the provided organizations was added. Permission required: ORGANIZATION_CONTRACT_MANAGER
request:
response:
|
GET /v1/my/role-groups/permissions |
New API to get list of permissions assigned to the caller role was added. Permission required: PRIVILEGES_VIEWER response:
|
POST /v1/role-groups/aggregation/view |
New API to get list of roles with details was added Permission required: ROLE_VIEWER request body:
response body:
|
PATCH /v1/role-groups/{roleCode}/toggle |
New API to change the activation status of the specified role based on the provided parameters was added Permission required: TOGGLE_ROLE_PERMISSION The role must have permission to manage other roles. The role being updated must appear in the list of manageable roles of the caller, and the update operation must be permitted for that specific role. request:
response: no content |
PATCH /v1/members/{id}/role |
New API to change organization member roles in the bounds of one organization was added. Permission required:
request:
response:
|
DELETE /v1/role-groups/{roleCode} |
New API to delete service roles that have no users linked to them was added. Deletion of the administrator role is not allowed. Permission required:
To remove another system role, the current role must have both the update permission for that role (manageable link) and the manage permission enabled. request: No parameters response: No content |
POST /v1/organizations/system/coins |
New API to view system accounts with filter and pagination was added. API returns all wallets according to filters (except client-related wallets such as client, and prepaid). Permission required:
request:
response:
|
POST /api/v1/trusted-domain |
New API to add new trusted domain in the system was added. Provide the domain name in the
Permission required:
To activate team members email validation new property was added to the system configuration
When team member inputs email to use it as account credentials validation will fail IF:
Validation of user email for login credential purposes has been applied to below APIs:
IF
request
response:
|
GET /api/v1/trusted-domain |
New API to get trusted domain list was added. Permission required:
response:
|
DELETE /v1/trusted-domain/{trustedDomainId} |
New API to delete domain from the list of trusted domain was added. Permission required:
response: No content |
PUT /v1/management/organization-settings/service-roles/{roleCode} |
New API to change permissions for other existing service roles was added. permission required:
request:
response:
|
GET /v1/permissions |
API to get list of all existing permissions was added. response:
|
Endpoint |
Deprecated/Deleted |
PATCH /contracts |
API was marked as deprecated. deprecated API will be deleted in further releases. Use new PATCH /contracts/{contractId}/organization instead of old. |