Release Version 4.25.0 (December, 2024)

Feature

Description

Benefits

Ability to initiate Refund for Purchase via provider operation was added

Service user with appropriate permission is able to initiate a Refund for the “Purchase via provider” operation manually, as a separate operation linked to the original one.
After the creation Refund is available in the transaction history, as a separate operation, for both the business and service users.

Refund means paying back to a customer unsatisfied with goods or services bought. This dispute operation can be initiated only when the bank day (operational day) of the original transaction is closed.

During refund operation system refunds the funds that were debited from the customer (Individual or Merchant) when the transaction “Purchase via provider” was performed. While refund processing in case the commission for Purchase operation was OUT, only the product price that was debited from the customer wallet must be credited back (REFUND AMOUNT DOES NOT INCLUDE COMMISSION AMOUNT)

Contact us to get more information about the Refund processing accounting model.

Allows team members to initiate a refund on purchase via provider operation and credited the price of the product to the customer’s wallet balance.

Ability for Administrator to set Monthly Fee for System Vendor

Administrators can now configure and manage monthly fees, specifying a fixed fee amount and currency, which is applied as a platform service charge to Business users. This fee setting feature is available exclusively for the platform owner (System Vendor). Administrators have control over fee setup, including editing and managing the status of monthly fees.

1. The monthly fee is charged every month according to the contract, to which it was added

2. From the accounting perspective, the monthly fee must be charged from the client’s wallet to a commission wallet. This charge transaction will be visible in the client transaction history as a new separate type of operation.

The day for the monthly fee charge can be configurable on the Vendor configuration level

To create monthly fees, the Administrator is allowed to specify the following parameters:

• Monthly fee name – required – the name of the monthly fee (e.g. Merchants support fee, etc.)

• Currency – required – currency, in which the monthly fees will be charged from the Client

• Amount – required – fee amount

• Key selling point (1, 2, 3) – only one required – three separate fields, key points included into the plan for this monthly cost

By default, Monthly fee should be created with status “Active“

Administrator is allowed to edit the following parameters of the Monthly Fees (on the Vendor level):

• Monthly fee name – the name of the monthly fee (e.g. Merchants support fee, etc.)

• Currency – currency, in which the monthly fees will be charged from the Client

• Amount – fee amount

• Status – active/inactive (enable/disable to charge this particular fee)

• Key selling point (1, 2, 3)

Parameters to view Monthly Fees with filter and pagination:

• Monthly fee name (with sorting)

• Create date (with sorting)

• Amount (with sorting)

• Status (Active, Disabled) (with sorting)

• Currency (with sorting)

• Key selling point (1, 2, 3)

Parameters to filter by:

• Period (create date)

• Status (Active, Disabled)

• Search by (for now only by fee name, “like“)

Ability to Retrieve Detailed Refund Information by Transaction ID, Including Original Transaction Details

Administrators can now retrieve detailed information for a specified refund by transaction ID, with additional contextual details from the original transaction. This includes key attributes such as the original transaction ID, creation date, transaction type, amount, currency, product ID, commission details, and relevant parties (e.g., sender or recipient). The front-end design supports these enhanced views, while backend updates ensure accurate data retrieval.

This feature enables administrators to access comprehensive refund and transaction details in one place. It reduces time spent navigating between transactions and improves operational efficiency by offering a unified view of related transactions and refunds.

Ability for service user to view and update Status for Assets rates.

This update introduces the ability for authorized service users to manage the status of asset rates, enabling them to set rates as “Active” or “Disabled” after initial creation. Initially, all asset rates will be automatically assigned a default status of “Created” upon setup, preventing use in exchange operations until manually activated. Additionally, a new status, “Unavailable,” is now available in the system, marking rates that are unsupported by specific rate sources (to be fully implemented in a future task).

Service users with appropriate permission will be able to see and update the status of the asset rate for certain asset pairs after the creation, so that they can set the status as “Disabled” and PROHIBIT exchange operation with such asset pair.

Service user is not allowed to specify rate status manually when they setup rate at the first time – all newly created asset rates should have the status “Created“ before the user will not update it.

This feature improves control and compliance over asset rate management, ensuring only valid rates are used for exchange operations.

Ability to view all asset pairs available for exchange with rates against the main asset, including filters and pagination.

This update introduces the ability for service users to view all asset pairs available for exchange and their rates against the main asset. The feature includes filter and pagination capabilities for efficient navigation and management. It applies to both manual and integration rate sources.

Key Features:

1. View Asset Pairs:

   • Display all asset pairs with the following details:

     • Currency: The currency code of the paired asset.

     • Rate: The exchange rate against the main asset (if set; otherwise, empty).

     • Last Rate Update: Date-time of the last rate update for the asset pair (empty if no rate is set).

     • Disabled At: Date-time when the rate status was changed to “Disabled.”

     • Status: The current status of the rate (Active, Disabled, Created, Unavailable).

2. Main Asset Configuration:

   • Service users configure the main asset by setting isMain=true and availableForExchange=true.

   • The main asset serves as the source currency for exchange operations.

3. Filters and Pagination:

   • Available Filters (multi-choice):

     • Currency (currency code of the paired asset).

     • Status (Active, Disabled, Created, Unavailable).

   • Pagination support for efficient handling of large datasets.

4. Manual and Integration Sources:

   • Behavior is consistent for both manual and integration-based rate sources.

5. Conditions for Asset Pair Inclusion:

   • All assets with availableForExchange=true are shown against the main asset (isMain=true).

   • If a rate is not set for an asset pair, the pair is still displayed, but the rate parameter will be empty.

If the rate is missing for an asset pair, the API returns the pair with an empty rate parameter.

Affected Endpoint:

Changed API:
POST /exchange-rates/view (added filtering, pagination)

New API:
POST /assets/exchange-rates/view

This feature enhances visibility into asset pair rates and improves management efficiency for service users, ensuring streamlined exchange operations.

Ability for service users to configure exchange rates manually for multiple asset pairs at once

Users can now manage exchange rates efficiently, viewing all existing rates and updating them in bulk when the rate source is set to “manual”.

Key Features:

1. Bulk Rate Configuration:

   • Users can pass multiple asset pairs and their corresponding rates in a single API request.

   • Each asset pair configuration includes:

     • Rate: Exchange rate value.

     • inCurrencyId: Source currency.

     • outCurrencyId: Target currency.

2. Validation Rules:

   • If an asset pair is not found or either asset (inCurrencyId or outCurrencyId) does not have availableForExchange=true:

     • The system returns an error, and no rates are updated.

3. Default Status for New Rates:

   • All newly created rates are assigned the status “Created” (status transition logic handled in a separate task).

4. View Existing Rates:

   • A new API allows users to fetch all existing rates for available exchange asset pairs against the main asset.

   • Displays current rates and details to assist users in setting up new rates.

5. Rate Update Tracking:

   • When a user updates rates, the system records the date-time of the “Last rate update” for each pair.

Error Handling:

• If any validation fails for the provided asset pairs (e.g., missing pairs, availableForExchange=false), the system:

  • Rejects the entire request.

  • Returns an error response with details of the invalid asset pairs.

Affected Endpoints:

POST /exchange-rates/rate (changed request/response)

This enhancement streamlines the process of managing exchange rates, saving time for service users and improving operational efficiency.

Ability to Modify Rate for Specific Currency Pair

Service users with the appropriate permissions can now manually modify the rate for specific currency pairs, provided that the rate is set up manually (not through an integration source). Each rate modification automatically updates and displays the date of the last rate change. This ensures that users see the most current rates and the timing of the last modification in the system.

The system changes rate and saves the date every time when the value of the asset rate is changed (other parameters, e.g. rate status do not impact the date of the last rate update.

All new currency exchange operations created after rate update should use new rate for this asset pair.

Affected Endpoint:

POST /exchange-rates/view fields for filtering added:

statuses (array of rate statuses)

currencyCodes (array of currency codes)

This feature enhances operational flexibility by allowing service users to update asset rates on demand.

Cash Desk Creation and Management

This feature allows service users with appropriate permissions to create and manage cash desks, link cashiers, and update additional details. Cash desks represent physical locations where cashiers operate. Service users can also view a comprehensive list of cash desks with relevant parameters and apply filters for efficient management.

Cash Desk Creation:

• Service users can create a cash desk by providing a cashier login (required) to link an existing user or create a new one.

• The cashier must have the Cashier role and be linked to the Cash Desk organization type.

• Newly created cash desks start with empty parameters except for the linked cashier.

Details Modification:

• Service users can update cash desk details, including organization name, phone, email, and location (country, city, address, postal code).

Cash Desk List:

• View all cash desks with details like contact info, location, organization, cashiers (name, contact, working days), pending requests, and working hour status (open/closed).

Filters and Search:

• Filter by working hour status (open/closed).

• Search by organization, address, cashier name, phone, or email (full/partial match).

New APIs were added to create and manage cash-desks.

This update enhances operational efficiency by streamlining the management of cash desks and ensuring that cashiers and their associated operations are seamlessly organized.

Enable registered but not logged-in users to create a request to change their registered phone number used for login.

This feature allows users who cannot access their current phone number to initiate a request to update it. The process generates a temporary token enabling users to proceed with the next steps, including identity verification, to complete the phone number change.

1. User Flow:

   • Users initiate the phone number change request by providing a valid login.

   • If valid, the system:

     • Issues a temporary token with a 60-minute expiration.

     • Returns a success response.

   • If invalid or missing login:

     • Returns an error response with a relevant error message.

2. Temporary Token Behavior:

   • Token allows users to proceed to the next step but does not grant access to other operations.

   • Token becomes invalid after the expiration time.

This feature enhances the user experience by providing a secure and streamlined process for updating phone numbers when the current number is inaccessible.

Enable registered but not logged-in users to upload a selfie and identification document for identity verification as part of the phone number change request process.

This feature allows users to securely upload a selfie and an identification document using a temporary token, enabling identity verification to proceed with a phone number change request.

Key Features:

1. Request Parameters:

   • temporary_token (required): A valid token issued during the phone number change request.

   • selfie (required): A file containing the user’s selfie for identity verification.

   • document (required): A file containing the user’s identification document (e.g., passport or ID).

2. Response Parameters:

   • status: Indicates the result of the upload (success or error).

   • error_message (optional): Provides details if the upload fails (e.g., “Invalid file type” or “File size too large”).

   • file information: Detailed metadata for each uploaded file, including:

     • File ID, owner ID, media type, name, URL, checksums (md5, sha1), size, usage status, creation and expiration timestamps, and associated tags.

This feature enhances security and usability by enabling users to complete identity verification seamlessly as part of the phone number change process.

Allow registered but not logged-in users to provide a new phone number for login and initiate OTP verification.

This feature enables users in the phone number change process to submit a new phone number and link it to their account. The system sends a one-time password (OTP) to verify the new phone number, ensuring secure account updates.

Request Parameters

1. temporary_token: (required) – the temporary token issued in a previous step (request for phone number change) that allows the user to proceed with providing a new phone number.

2. new_phone_number: (required) – the new phone number the user wants to use for login. The phone number should be specified without a “+” sign or additional symbols and should start with the country code.

3. selfie_file_id: (required) – file ID of uploaded at the previous step selfie

4. document_file_id: (required) – file ID of uploaded at the previous step identity document

Response parameters:

• action: OTP_SENT
  Indicates whether the message with OTP was successfully sent to the new phone number.

• status:
  The result of the request, either success or error.

• error_message: (optional)
  Provides details on why the request failed, such as an invalid phone number format or an issue with sending the OTP.

This feature enhances the security and reliability of the phone number change process, ensuring only verified users can update their login credentials.

Phone Number Change Request – OTP Verification.

Added ability for not logged-in users to verify their new phone number and create a request to change the registered phone number used for login.

This update allows registered users who are not logged in to change their phone number used for login. After requesting a phone number change, users will receive an OTP on their new phone number, which they can use to verify the change. If the OTP is valid, a request to change the phone number is created.

Key Features:

1. OTP Verification for Phone Number Change:

   • Users can now verify their new phone number by entering the OTP sent to it.

   • The verification is required to create a request for phone number change.

2. Request Creation:

   • Once the OTP is successfully validated, a phone number change request is created. The request includes:

     • Old Phone Number (the phone number currently used for login)

     • New Phone Number (the phone number the user wishes to use for login)

     • Link to the Existing User Profile (for verification purposes)

     • Uploaded Selfie (for identity verification)

     • Uploaded Document (user identification document)

3. Request Parameters:

   • Temporary Token: The temporary token generated during the first step of the phone number change process is required to proceed with the OTP verification and request creation.

   • OTP: The OTP sent to the new phone number for verification.

4. Response Parameters:

   • request_id (optional): Unique identifier of the created request if the OTP is valid and the request is successfully created.

   • status: Indicates whether the request creation was successful or failed.

   • error_message (optional): Provides a detailed error message if the OTP validation or request creation fails (e.g., “Invalid OTP” or “Failed to create request”).

New API:

POST login-change/request

This feature ensures users who are unable to access their current registered phone number can securely change it and continue to use the system with their updated credentials.

This release introduces the Reports Module, which can now be included or excluded from the build based on your configuration needs. The module provides robust reporting functionality, integrating with Kafka for real-time data processing and consumption.

To be able to use the Reports module it should be configured.

• Optional Inclusion in Build
  The Reports Module can now be included in the build or excluded based on your configuration needs.

• General Properties
  The following general properties need to be configured:

  spring:
    kafka:
      bootstrap-servers: ${SPRING_KAFKA_BOOTSTRAPSERVERS}
      enabled: ${KAFKA_ENABLED}
      client-id:
      ssl-endpoint-identification-algorithm:
      sasl-mechanism: ${SPRING_KAFKA_PROPERTIES_SASL_MECHANISM}
      sasl-jaas-config: ${SPRING_KAFKA_PROPERTIES_SASL_JAAS_CONFIG}
      security-protocol: ${SPRING_KAFKA_PROPERTIES_SECURITY_PROTOCOL}
  

• Module-Specific Properties
  The following properties are specific to the Reports Module:

  reports:
    kafka:
      topic: ${KAFKA_REPORTS_TOPIC:transaction-topic-dev}
      group-id: ${REPORTS_GROUP_ID:reports-kafka-consumer-group}
  

Notes:

• The ssl-endpoint-identification-algorithm and reports.kafka.include properties are intentionally left without default values to allow for customization based on your environment.

• Ensure all environment-specific variables are properly set for seamless integration.

Introduced new Reports API to manage reports:

POST /report
GET /report/{id}

This update enhances the reporting capabilities within the system by integrating it with Kafka for real-time processing, giving users the flexibility to customize configurations based on their specific envi

Ability for Business User to View Pool Bank Account Details for Manual Top-up

This release introduces the ability for a registered and logged-in business user to view pool bank account details when performing a manual bank transfer to top-up their wallet in FIAT currency. If no bank account is linked to the wallet, the system will display the necessary pool bank account details to allow the user to proceed with the top-up.

Key Features:

• Manual Bank Transfer:

  • When a business user selects the Manual Bank Transfer option to add funds to their wallet in FIAT currency, the system will check if there is a linked bank account.

  • If no bank account is linked to the wallet, the system will display the pool bank account details needed for the transfer.

• Pool Bank Account Details Displayed:

  • The following details will be shown to the user for completing the bank transfer:

    • Recipient Name

    • Recipient Currency

    • Wallet Number (to which the funds should be added)

    • IBAN

    • Bank Name

    • SWIFT/BIC

This enhancement improves the flexibility for users who need to manually top up their wallet but have not linked a bank account, ensuring seamless wallet funding through pool bank accounts.

Ability for Service Users to Manage Pool Bank Accounts

In this release, we have introduced the ability for service users with appropriate permissions to manage the list of POOL bank accounts in the system. These accounts can now be linked to in-system accounts and used for top-up operations. Service users with the appropriate permissions will be able to view, add, edit, and delete pool bank accounts.

Key Changes:

1. Permissions for Managing Pool Bank Accounts:

   • New Permission: POOL_BANK_ACCOUNT_MANAGER
     A new permission has been added to manage POOL bank accounts. This permission allows users to:

     • View the list of pool bank accounts.

     • Add new pool bank accounts.

     • Edit existing pool bank accounts.

     • Delete pool bank accounts.

   • Roles Assigned to Permissions:

     • The Administrator and Accountant roles are granted all the permissions related to managing POOL bank accounts.

2. Default Values for POOL Bank Accounts:

   • isDefault: Always set to false for new POOL bank accounts.

   • status: Always set to APPROVED for new POOL bank accounts.

   • bankAccountNumber and IBAN: These fields are now optional when creating a POOL bank account.

   • usedForTopUp: This field is set to false by default for POOL bank accounts. It is also present for PERSONAL bank accounts and can be used to specify whether a bank account can be used for top-up operations.

Added new API:

POST {{host}}/bank-accounts

Added new permission POOL_BANK_ACCOUNT_MANAGER to

POST {{host}}/bank-accounts/view
POST {{host}}/bank-accounts
PATCH {{host}}/bank-accounts/{bankAccountId}/with-bank
DELETE {{host}}/bank-accounts/{bankAccountId}

Ability for Service Users to Specify, View, and Manage Currency Type

In this release, we’ve introduced the ability for service users with appropriate permissions to specify, view, and manage the currency type during currency creation and editing. This update allows users to properly classify currencies based on their functional purpose within the system.

Key Changes:

1. Currency Type Classification:

   • The following currency types are now available:

     • FIAT: For traditional currencies like USD, EUR, etc.

     • CRYPTO: For cryptocurrencies like Bitcoin, Ethereum, etc.

     • BONUS: For bonus points or other reward systems.

     • VIRTUAL: For system-specific entities like virtual goods or game points.

2. Currency Creation:

   • When creating a new currency, users must select a currency type from the available options: FIAT, CRYPTO, BONUS, or VIRTUAL.

   • If no currency type is selected, FIAT will be set as the default type.

3. Currency Editing:

   • Users can now modify the currency type of an existing currency during editing.

   • The currency type is visible in the edit form and can be changed as needed.

4. Currency List Display:

   • The currency list now includes a “Currency Type” column, showing the currency type (FIAT, CRYPTO, BONUS, or VIRTUAL) for each currency.

   • Users can filter the list of currencies by their type, making it easier to manage and categorize different currencies.

Affected Endpoints:

POST: /v1/currencies/view POST: /v1/currencies PATCH: /v1/currencies/{currencyId} PATCH: /v1/currencies/{currencyId}/set-main GET: /v1/currencies

These changes enhance the flexibility of currency management, enabling service users to classify and organize currencies more effectively, making it easier to distinguish their functional roles within t

Ability to view account details for currency types other then FIAT (CRYPTO, BONUS, VIRTUAL)

In this release, we have introduced a new feature allowing registered and logged-in users to add money to their wallets for CRYPTO, BONUS, and VIRTUAL currencies. When users select a non-FIAT currency type (such as cryptocurrency, bonus points, or virtual goods) to add money, they will now be able to specify the amount to top-up, choose a different wallet if needed, and view detailed account information for the wallet they are topping up.

Key Changes:

1. Currency Type Selection:

   • Users can now choose to add money to their wallet in CRYPTO, BONUS, or VIRTUAL currency types from the drop-down menu.

   • If the selected currency type is not FIAT, the user will see the option to top-up the wallet with that currency type.

2. Amount and Wallet Selection:

   • Users can specify the amount they want to add to the wallet.

   • Users are given the option to choose another wallet to add money to, apart from their default wallet.

3. Wallet Details Display:

   • Upon selecting a wallet for the top-up, the following wallet details will be displayed:

     • Recipient Name: The name specified in the user’s profile.

     • Currency: The type of currency selected for the top-up (CRYPTO, BONUS, or VIRTUAL).

     • Wallet Number: The number of the wallet to which the money will be added.

Affected Endpoints:

POST /v1/coins/view
GET /v1/organizations/system/coins
GET /v1/organizations/{organizationId}/coins
GET /v1/coins

Ability to get list of users in the system by the list of credentials (emails or phones)

This release introduces the ability for registered and logged-in users to search for contacts using a list of email addresses or phone numbers. This functionality enables users to view only the contacts that are registered in the system, making it easier to choose recipients for money transfers.

Key Changes:

1. Recipient Search by Credentials:

   • New API: A new API has been added that accepts a list of email addresses or phone numbers.

   • The API will return only those credentials (emails or phone numbers) that correspond to registered users in the system, ensuring that the search results only show valid contacts who have an account.

2. Search Results Handling:

   • The system will return results based on the provided list of emails or phone numbers, but will exclude those credentials that:

     • Are not associated with any registered user.

     • Are specified in the user profile as a contact phone or email address for the user.

3. No Results Handling:

   • If no contacts match the provided email or phone credentials in the system, the system will return no results and only display the search parameters (email or phone) that were entered by the user.

Exchange Transfer Between Different User Wallets

Description: This release introduces the ability for registered and logged-in users to send money to another user’s wallet, even if the destination wallet uses a different currency from the source wallet. The system will automatically handle the currency conversion during the transfer, eliminating the need for users to perform a separate exchange operation before making the transfer.

Key Changes:

• Users can now send funds to another user’s wallet, even if the destination wallet’s currency differs from their source wallet.

• The system will automatically perform the currency exchange and complete the transfer seamlessly.

Ability for business user to create a template for Bank withdrawal

This release enables registered and logged-in business users to create templates for IBAN transfers by saving the parameters used in a performed transfer. The user can specify a name for the template, allowing them to easily reuse the details for future transactions.

Key Changes:

• Users can now save their performed IBAN withdrawal requests as templates with a custom name.

• The following transfer parameters will be stored behind the template:

  • Source wallet

  • Amount

  • IBAN

  • Recipient full name

  • Bank parameters (BIC, SWIFT, Bank Country, Bank City, Bank Address, Bank Zip Code)

  • Transfer description

New API was added:

POST: /v1/templates/withdrawal/operation/{id}

Ability for service user to unban another service user if it was banned after several attempts of specifying wrong password.

Option “Unban user” added for the team member in the Team member list, if they are banned and the current service user has permission to unban (USER_MANAGER).

Bank accounts menu is moved to the Clients section

Added default filters to the Transactions and Log history sections.

If there are no filters defined for these views, the current-day filter is applied by default starting from 00:00:00.0000 to 23:59:59.9999