Release Version 4.22.0 (July 30, 2024)
30. 07. 2024
What’s new
Refactoring of the Vendors and Contract logic was made:
- ability to create and manage vendor’s commissions without specifying the Contract ID was added
- a new set of APIs was added to manage the commission profiles, rules, conditions, and limits on the Vendor and Contract level was added
Now the service user with appropriate permission can create/update/delete commission profiles, rules, and conditions for provider commissions on the Vendor level.
How it was before release ver 4.22.0:
Commissions settings (commission profiles, rules, conditions, and limits) were available only in the Contract context – first need to create a contract, select a Vendor (or System) operation, and create a commission profile with rules and conditions for it.
How it will be after release ver 4.22.0:
Creation and management of the vendor`s (provider`s) commissions (commission profiles, rules, conditions, and limits) for external operations are available in the Vendor context:
- first, select (OR create) the vendor
- then create the vendor commission profile (select operation and currency), add rules, conditions, and limits for vendor operations WITHOUT specifying contract ID
- then create a contract and select the needed vendor and operation of this vendor in the contract
- create a system commission profile for needed operation, add rules, conditions, and limits in the contract (total commission to charge from the client within this contract)
- assign the contract to the client
When the client performed the operation via a provider (vendor) total commissions will be calculated according to the contract and provider commissions will be calculated according to the vendor.
So, with that approach:
- vendor`s commission (for a particular operation of the particular vendor) will be the same in all Contracts
- system commissions will be different in each Сontract
To change the provider’s commissions it must be changed at the Vendor level. After the change, the new provider’s commission will be used in all contracts where the operation of this vendor was previously specified.
New forms to manage Contracts and Vendors (Providers) were added to the Back-office UI.
How to set up vendor commissions via Back-office UI:
- Perform authorization as a service user with appropriate permission
- Press “CRO“ → “Vendors“
- Press “Create a vendor“ (or select the existing one)
- Specify Vendor name, Integration, and Debt allowed and press “Create“
- The created vendor appears on the “Vendors” list form
- Press “View operations“
- Press “Create operation“ and select Operation type, Product (if available), Currency, and press “Create“
- Press “View details“ and “Create commissions and limits“
- Press “Set commission period” and specify the commission Start date, End date, and Direction (if available)
- Specify commission details: Commission type, Amount to, Amount from, Fixed, Percent (commissions that will be passed to vendor (PROVIDER commission))
- Add Ranges (if needed)
- Specify vendor limits for needed time units
- Press “Update commissions and limits“
- A commission profile (type VENDOR) with rules, conditions, and limits will be created for the selected operation.
How to set up system commissions (for external operation it is total commissions) via Back-office UI:
- Perform authorization as a service user with appropriate permission
- Press “CRO“ → “Contracts“
- Select needed to duplicate and press “View details“ (or select the existing one to modify)
- Press “Duplicate contract” and provide a new contract name, press “Create“
- The created contract appears on the “Contracts” list form
- Press “View details“ and see a list of all available vendors in the system
- Select vendor and press “View details“
- Press “Create operation“ and select Operation type, Product (if available) Currency, and press “Create“
- Press “View details“ and “Create commissions and limits“
- Press “Set commission period” and specify the commission Start date, End date, and Direction (if available)
- Specify commission details such as Commission type, Amount to, Amount from, Fixed, Percent (commissions that will be charged from the Client (TOTAL commission))
- Add Ranges (if needed)
- Specify system limits for needed time units
- Press “Update commissions and limits“
- A commission profile (type SYSTEM) with rules, conditions, and limits will be created for the selected operation. The commission that will be received by the system (SYSTEM commission) will be equal to TOTAL minus PROVIDER.
Important information related to changes:
Please note, that new APIs for handling commissions and limits have been added in the release ver 4.22.0.
The old APIs have been marked as deprecated and will not be supported after applying the release ver 4.22.0. If your front-end application uses APIs listed as deprecated – you need to make changes on your application side and use the new APIs.
Scripts for data migration will be executed automatically when release ver 4.22.0 is applied.
New Vendors and Contracts forms have been added to the back-office UI – use it to configure vendor and system commissions and limits (in release ver 4.22.0 old forms for “Contracts” are removed from the UI).
See “API Changes” section of the release notes to know more about changes related to API
See full API reference to know more about API flow to set up commissions and limits
Limits were refactoring:
- the limit rule is linked to the commission profile (system or vendor)
- to set limits you need to specify the commission profile ID, for system or vendor profiles accordingly
Limit usage for external operation:
- when the user performs the operation system checks and counts only limits that are set in the Contracts (NOT in the Vendor)
- limits that are in the Vendor are used only for information (limitations provided by the vendor) and to validate the limit that is set in the Contract. The value of the limit for the commission profile with type SYSTEM (set in the Contracts) should be equal OR less than the value in the commission profile with type VENDOR (set in the Vendor)
See “API Changes” section of the release notes to know more about changes related to API
See full API reference to know more about API flow to set up commissions and limits
The ability to create a System Vendor automatically from the configuration when the system first started was added.
System vendor – the vendor that represents the platform owner and is required to process all internal operations.
Refactoring of the internal operation commission settings and processing was made:
- system vendor creates automatically from the configuration when the system first started
- internal operations can be performed only via the System Vendor
- the system vendor can be the only one for the system
- system vendor is linked to a separate system gate
- set the system commissions for internal operations in the contract (select system vendor and appropriate operation) – this commission will be charged from the client
- to perform internal operations appropriate commission profiles must be set for such operation of the system vendor in the user contract
- system vendor can not be deleted (only deactivated)
The following parameters to configure System Vendor were added to gate-controllers/system/src/main/resources/application-system-gate-manager.yaml file:
sdk.finance.gate.system.SystemGateManager: _provider_name: 'SDK.Finance System Gate' _create_on_startup: true key: 'SDK.Finance System Gate' _create_vendor_on_startup: true version: 1 custom: false system: true supported-operations: - 'bank_redeem' - 'bank_topup' - 'cash_desk_redeem' - 'cash_desk_top_up' - 'exchange_transaction' - 'merchant_invoice' - 'merchant_payment' - 'prepaid_creation' - 'prepaid_use' - 'transfer'
Note, from the business point of view System vendor is the same vendor but for internal operations (on the Back-office UI System Vendor is listed with all other vendors).
To be able to perform the operation of the System vendor:
- Select system vendor in the needed Contract
- create a commission profile with the type SYSTEM for the needed operation of the system vendor in the Contract
- create commission rules and conditions for commission profile with the type SYSTEM for needed operation in the Contract
- create limit rules for commission profile with the type SYSTEM for needed operation in the Contract
Then while performing the operation of the System vendor commission to charge from the client will be taken from the Contract.
See “API Changes” section of the release notes to know more about changes related to API
The ability to set up operational days (begin date/time and end date/time) for the specified period was added (System calendar).
Service users with appropriate permission can:
- create a System calendar for a specified period
- see operational days for the period with the status
- manage period for future operational days
The 0th operational day will be created automatically when system initialization and continues until the next operational day is set. Until the next day is set, the system will store balances within the 0th day. This 0th day can’t be deleted.
How to setup the System Calendar via back-office UI:
- Perform system authorization as a service user with appropriate permission
- Open the menu “CFO“ → “System Calendar”, see the current calendar table, and choose the option “Create calendar”
- Choose Begin date and End date
- Choose time shift (hh:mm: ss – this period will be added to the operational day start)
- Press “Confirm“
How to delete the System calendar for future periods:
- Perform system authorization as a service user with appropriate permission
- Open the menu “CFO“ →“System Calendar”, and see the current calendar table
- Choose “Delete calendar” and “Choose a date” (choose any operational day in the current calendar starting from the opened day + 1 (only future days)
- Press “Delete calendar“
- The whole calendar starting from the selected day will be deleted
See “API Changes” section of the release notes to know more about changes related to API
Logic to store the beginning balance, debit, credit, and end balance for each wallet for the end of each operational day was added.
Balances are stored in a separate table and can be used for further reconciliation processes (Transaction and Assets Reconciliation logic going to be implemented in further releases).
The ability for service users with appropriate permission to view and filter operational day balances was added.
Available filters for operational day balances:
- operational day number
- date
- currency
- wallet types
- wallet serial number
How to view operational day balances via Back-office UI:
- Perform system authorization as a service user with appropriate permission
- Open the menu “CFO“ → “Operational days” and see operational day balances for the current system calendar
See “API Changes” section of the release notes to know more about changes related to API
The ability to set up the frequency of a reconciliation process for a particular asset was added.
Frequency – is a scheduled period, that shows how often the reconciliation must be done. Supported values: Daily, Weekly, Monthly, Bimonthly, None.
Every time the scheduled date is reached the System generates a new reconciliation record with calculated periods (due to the selected frequency) in the status “Not started” and sends the email notification remainder to the responsible user.
When the frequency for a specific asset is updated, the system will try to create a reconciliation record starting today. This applies only to configurations without existing records starting today. Changing the frequency type will not delete any existing reconciliation records.
The configuration will be created for existing currencies upon the first system start. For new currencies, according to frequency, reconciliation records will be created during the currency creation process.
If the frequency is set as NONE, the system won’t create new reconciliation periods.
System Timers for Reconciliation and Reminders
Two timers were added:
- Reconciliation Record Creation: automates the generation of reconciliation records.
- Reminder Emails: sends reminder emails about the end of a reconciliation period.
Reconciliation Record Creation Timer:
The timer will run daily at 1 AM and 7 AM, creating new periods for asset reconciliation.
To configure the timer, use the next environment variables:
reconciliation: period-creation-timer: enabled: true schedule-expression: ‘0 0 1,7 * * ?’ # cron expression
A reminder Email about scheduled asset reconciliation was added.
This timer runs daily at 6 AM to check for periods that ended the previous day. If any are found, it will generate an email with the following text (a reminder email will be sent to the system administrator’s email address as specified in their profile):
Subject: Asset [asset name] reconciliation remainder Message: Dear team member!The scheduled reconsolidation period for the [asset name] asset is closed. Please reconcile the liquidity amount of the [asset name] for the period [reconciliation period]. In the case of an erroneous request, please ignore this email.Sincerely, [application name] support - [application support email].
To configure the notification timer, use the next environment variables:
reconciliation: notification-timer: enabled: true schedule-expression: '0 0 6 ? * *' # cron expression
How to configure reconciliation frequency for asset reconciliation via Back-office UI:
- Perform system authorization as a service user with appropriate permission
- Open the menu “CFO“ → “Reconciliation”, select the needed asset, and press “View details”
- Select “Configure frequency“
- Select “Frequency“
- Press “Update“
See “API Changes” section of the release notes to know more about changes related to API
The ability to reconcile assets was added.
The asset reconciliation option allows you to reconcile the balance of a specific asset in system circulation (the volume of issued electronic money) with the balance on the bank account that covers the asset liquidity.
The system generates asset reconciliation records according to frequency and sends reminders to the responsible user to notify them that required to perform asset reconciliation.
To reconcile assets, the user provides a Liquidity amount – the balance of the company bank account, that covers the current asset liquidity. The system compares the entered amount with liquidity calculated by the system and shows discrepancies if they occur.
During the reconciliation process, the system checks the end balance of the issuing_balance account (which reflects the system liquidity amount (system circulation)) for the closed operational day, corresponding to the last day of the reconciliation period.
If no operational day matches the reconciliation period, the system will return an error:
No closed day for the specified period - reconciliation for this period can not be performed.
How to reconcile assets via Back-office UI:
- Perform system authorization as a service user with appropriate permission
- Open the menu “CFO“ → “Reconciliation”, select the needed asset, and press “View details”
- Select “Reconcile asset“
- Enter “Liquidity amount“
- Press “Reconcile“
When the system reconciles the liquidity reconciliation records appear in the “reconciliation/[Asset name]” list with status and result.
Available asset reconciliation statuses:
- Not started – reconciliation for the period was not started (initial state, transit to In progress)
- In progress – reconciliation for the period is in progress (transit to Warning, Reconciled)
- Warning – the discrepancy is detected after reconciliation is done, the user is allowed to start the process again and provide the corrected Liquidity amount (can transit to In progress, Reconciled)
- Reconciled – reconciliation was done without any discrepancy (terminal state)
See “API Changes” section of the release notes to know more about changes related to API
Ability to manage Limited Withdraw via bank and Withdraw via cash desk operations was added
For Withdrawal via bank and Withdrawal via cash desk operations after the business request was approved system checks the limit rule. If the limit is exceeded the service user can lift the limit for operation and repeat processing, or reject the limited operation.
For the following operations, if the limit is exceeded operation status will be rejected, it is final status without the ability to repeat processing:
- Top up via cash desk
- Top up via bank
- Currency exchange
- Transfer
If the limit is exceeded the following operations will not be created:
- Top up via provider
- Withdraw via provider
- Purchase via provider
- Issue card
- Voucher creation
- Voucher activation
- Invoice
- Merchant payment
Logic to check the limit when processing distributed operation was refactored:
- Remove old functionality to lift limits
- Added functionality to repeat the accomplishment of limited operations (for Withdrawal via bank and Withdrawal via cash desk)
- Added parameter in configuration – max allowed retries execution of a limited process to accomplish per period (day):
core: system: contracts: limited-process: allowed-number-of-attempts-per-period: 3
- Business request and business process status transition was changed
- Added new status of business request allowed_to_withdraw for Withdrawal via Cash desk operation
- Limited operations now are shown in the transactions list with the status rejected (before changes, the exception has occurred without recording limited operation in the system)
See “API Changes” section of the release notes to know more about changes related to API
Logic to work with APIs to approve or decline business requests for the following operations was added:
- TopUp via Bank
- Withdrawal via Bank
- Withdrawal via cash desk
Use Business request management APIs to approve/decline requests for these operations.
See “API Changes” section of the release notes to know more about changes related to API
The ability for Business users to view account information and initiate payments via Salt Edge Open Banking was added.
In release ver 4.20.0 Salt Edge Partners API methods for fetching account information and payment initiation were implemented:
- Salt Edge Partners Account Information API allows institutions to securely connect to PSD2 channels in the EU, without having their own license and eIDAS certificate.
- Salt Edge Partners Payment Initiation API aims to make payment providers as simple as a cURL for any company that does not need to get a PSD2 Payment Initiation Service Provider license.
Salt Edge Partners API aims to provide access to financial information and payment initiation for any company that does not need to get a PSD2 Account Information Service Provider license.
Also, there is a set of internal SDK APIs that provides Open Banking functions to the end-user via the UI of their SDK.finance account.
So the SDK.finance Core system implemented the technical integration for basic features of Open Banking through any financial institution supported by Salt Edge.
All features that will be available from the vendor (Salt Edge) to the client (for both, the source code or cloud clients) depend on the client’s needs and their agreements with the vendor (Salt Edge). On the SDK.finance side a quick way to interact with the Salt Edge platform from the SDK.finance Core system through the REST API integration.
Operation supported on the Test Environment
- Individual users can View account information via Salt Edge open banking
- Individual users can Initiate payment via Salt Edge open banking and see payment history
Contact us if you want to test integration or request a demo.
How it works (on the example of the Account information fetching):
The user of the SDK.finance platform decides to view their account information from the UI of the SDK account (web or mobile). Front-end uses the SDK internal APIs to trigger Salt Edge Integration to
The integration will redirect the user to a secure widget for authorization in the Salt Edge system and consent confirmation to access account information via Salt Edge. Once the user confirms consent Salt Edge will contact the user’s chosen bank and return the account data to the SDK system via integration. The user will be redirected to his SDK account and can see the account data in his cabinet.
Sensitive user data, including user account data received through Salt Edge is not stored in the SDK system and is available only in real-time mode through Salt Edge Partner API integration, which ensures data security and allows institutions to connect to PSD2 channels in the EU, without having their own license.
User manual
How to view account information via Salt Edge Open Banking:
- Perform authorization as an Individual
- Press the “Open banking“ tab on the main page
- Select the “Add bank“ option – you will be redirected to the Salt Edge secure widget
- Select bank in “Choose your bank“ and enter your internet banking credentials for Salt Edge to establish a secure connection
- Press “Proceed“
- Review the consent, press “Confirm“ if you agree, and press “Grant access”
- You will be returned to the “Open banking“ tab on your SDK.finance account
- Select the needed bank in the list
- Press “View bank account details“ to view more information about your bank account
How to initiate payment via Salt Edge Open Banking:
- Press the “Open banking“ tab on the main page
- Select the “Initiate payment“ option
- Press “Add bank“ (or select a bank that you added previously)
- After “Add bank“ you will be redirected to the Salt Edge secure widget
- Select bank in “Choose your bank“ and enter your internet banking credentials for Salt Edge to establish a secure connection
- Press “Proceed“
- Review the consent, press “Confirm“ if you agree, and press “Grant access”
- Press “Return to your app” or you will be returned to the “Open banking“ tab on your SDK.finance account automatically after a few seconds
- Paress on the needed bank “Banks“ sections
- Specify “Payment type“ in opened sidebar
- Specify required fields to process payment (such as Creditor Name, Currency, Creditor IBAN, Description, and Amount, fields can vary depending on the payment type)
- Press “Process payment“
- You will be redirected to Salt Edge secure widget to select your bank account and confirm payment initiation
- Press “Return to your app” OR you will be returned to “Open banking“ tab on your SDK.finance account automatically after a few seconds.
- The transfer has been sent to the bank and may take up to 3 days. You can check the progress of this payment in the “Payment History” section.
See “API Changes” section of the release notes to know more about changes related to API
See full API reference to know more about business processes and API flow.
Improvements
The ability for the Service user to view the following parameters from the Client profile was added:
- Cohort – a lifetime of the user’s profile in the system, from the day of profile creation to the current moment, in weeks
- Investigations – shows the statuses of investigation related to the client (currently not used by the logic, “Investigation” logic going to be added in further releases)
- Profile status – current user profile status (available values: active, deactivated, closed, banned, frozen, rejected)
- Last login – date and time of last user login
- Last transaction – date and time of the last transaction, initiated by this user
- Primary and secondary phone numbers
- Time zone – client time zone in ISO format
- System language – the language that the user provides (further can be used to translate to UI components)
The ability to filter Clients by the following parameters was added:
- Cohort
- Contract name
- Investigation status Profile status
- Client Name (First/Middle/Last)
- Phone (primary and secondary)
Cohort
In this context, a cohort refers to a group of users who signed up or were created in the same week. For example, if you signed up on a Monday, your cohort includes everyone from that Monday to the following Sunday.
How is a Cohort Calculated?
- Finding the Start of the Week:
- For any given date when a user signs up (let’s call this date createdAt), we determine the start of the week for that date. In our case, a week starts on Monday.
- For example, if a user signs up on a Wednesday, the start of the week is the previous Monday.
- Counting the Weeks:
- We then calculate how many weeks have passed from the start of the week to the start of the current week.
- This gives us a number representing how many weeks ago the user signed up. We then append “W” to this number to create the cohort label (e.g., “3W” means the user signed up 3 weeks ago).
Example:
- User Sign-Up Date: June 5, 2024 (Wednesday)
- Start of the Week: June 3, 2024 (Monday of that week)
- Current Date: June 10, 2024 (Next Monday)
- Weeks Difference: 1 week ago
- Cohort: “1W”
The user profile was extended with the following parameters (added ability to provide/update these parameters by business or service roles):
- Primary and secondary phone numbers (the ability to specify two phone numbers and set one of them as the primary was added). Note that only primary phone numbers or emails can be used as login credentials.
- Time zone – client time zone in ISO format
- System language – the language which the user provides to translate to UI components, in ISO format (currently not used by the logic, logic to process parameter going to be implemented in further releases)
See “API Changes” section of the release notes to know more about changes related to API
The ability for Business Users optionally to provide business and billing addresses in User Profile Details was added. To specify different addresses required parameter addressType was added.
the following address types are available:
- Personal – means the address where the person lives (contact address)
- Business – means the address of the Client`s (Individual or Merchant) business registration
- Billing – address to specify as billing or for financial operations and institutions. Business can be used as a Billing address if Billing was not specified, wherever it is required. If the Business address is not provided – the Personal address can be used as the Billing address wherever it is required.
Note, that only personal address is used for KYC verification.
The ability to filter smart cards by associatedCoinSerial was added
The ability to view reason and description for user status changes was added to the Back-office UI
The ability to see roles users of which the current user is able to create (with filter by role type: service or business) was added.
The ability to view all existing system roles with the following filters was added:
- role type – business (individual and merchant) or service (all other organization types)
- Search by role name (code)
The ability for service users to add comments during user identification decline was added to the Back-office UI
Parameter externalProcessId was added to the Transfer, Bank top-up, and Bank withdrawal creation.
Now user when creating a transfer, bank top-up, or bank withdrawal can pass the parameter externaProcseeId and see this parameter in the response of the view transactions (with the ability to filter the view by externaProcseeId) so that he can track external process ID in the SDK.finance platform.
The ability to view operations grouped by externalProcessId for the specified period with filters was added.
Available filters:
- externalProcessIds
- internalProcessIds – ID of the business process from SDK.finance system
- date from
- dateTo
- walletSerials – involved wallet serial number
Filter by product name was added to the commission profiles view
“Smart card” was renamed to the “In-system card” on the front-office and back-office UI
The ability to view the Vendor list with filters and pagination was added
The ability to see a list of vendors linked to certain gates was added
URL paths to Swagger from internal instances were corrected.
The ability to set the main asset was added.
A service user with appropriate permission is able to specify the main asset, update it, and view which asset is the main.
Main asset – is the asset regarding which asset rates will be displayed for all other currencies (“Asset rates“ functionality will be added to the Back-office in further releases)
Maine asset management:
- only one asset in the system can be the main
- first created in the System asset (from configuration or manually) marked as main by default (isMain: true), after it can be changed and another asset can be set as main
- main asset can be DELETED only, if it is the one asset in the system
- the main asset can be DEACTIVATED as other assets, behavior for DEACTIVATED assets remains as is
Ability to specify that the asset is available for exchange operation during asset creation/update.
See “API Changes” section of the release notes to know more about changes related to API
Fixes
- The issue with returning deleted commission profiles in the API response was fixed
- Using empty fields when filling out the user profile info was prohibited
- The front-end view of the “Currencies” form was fixed
- Sending request POST /invoices/view when login to the UI by Admin was removed
- The front-end issue with the “View details” of the “Bank account” modal window was fixed, now all data are visible
- Multiple back-end issues with new Commission profiles/rules/conditions were fixed
- The issue with the “Fraction” field when creating a new currency was fixed
- The issue with CommissionValueDto value when creating/updating the condition of the commission rule was fixed
- Creation of the commission profile using unsupported types of operations (flowers) was prohibited
- The front-end issue when opening details of the unpaid invoice was fixed
- Conditions values of commission rules added to the response of POST /commission-profile/view
- The front-end issue with using the error message from the property file was fixed
- The issue with duplication of the “toaster” when trying to add already existing user fas fixed
- The incorrect date format to display for Internal (Smast) cards was fixed
- Mapping for “Clients” forms on the Back-office UI was fixed
- The back-end issue with commission calculation and applying according to the user’s contract when performing gate operations was fixed
API Changes
Endpoint |
Updated |
POST /users/view |
Filters in the request body were extended with the following: · Cohort- full match (for ex. 3W) · Contract name - partial match · Investigation status - full match (open, closed, in progress) · Profile status - full match (active, deactivated, closed, banned, frozen) · Client Name - partial match (First/Last/Middle names) · Client ID - full match · Organization ID - full match · Email - partial match · Phone (primary and secondary) - full match request body: {{ "pageNumber": 0, "pageSize": 10, "filter": { "ids": [ "cca1fe9b-4e08-450c-840a-49dcefd7b126" ], "email": "individual@sdkfinance.tech", "emailVerified": true, "phone": "1111111", "phoneVerified": true, "text": "individual", "banned": false, "active": true, "roles": [ "individual" ], "organizationIds": [ "61b065de-58ef-4959-ab5e-4a2d75ab6564" ], "identificationStatus": "approved", "cohort": "16W", "contractName": "string", "investigationStatuses": [ "open" ], "profileStatuses": [ "active" ], "clientName": "string" }, "sort": { "createdAt": "asc", "active": "asc" }}
Response body was extended with the following parameters: · Cohort · Investigations · Profile status · Last login date · Last transaction date · Primary and secondary phone numbers · Time zone · System language response body: { "pageNumber": 0, "pageSize": 10, "totalPages": 1, "totalRecords": 10, "records": [ { "id": "cca1fe9b-4e08-450c-840a-49dcefd7b126", "name": "Tony Stark", "createdAt": "2021-01-28T18:12:48.985Z", "active": true, "activeReason": "AML", "activeDescription": "string", "frozen": true, "frozenReason": "AML", "frozenDescription": "string", "banned": false, "defaultUser": false, "banExpiryDate": "2025-01-01T07:15:50.555Z", "contact": { "phoneNumber": "", "phoneVerified": true, "additionalPhoneNumber": "string", "additionalPhoneVerified": false, "email": "string", "emailVerified": true, "countryCode": "SK" }, "members": [ { "id": "7653779a-8c14-4932-b536-1075e97041f5", "role": "individual", "organization": { "id": "7cf1f309-09cd-4eda-8b2c-682bf64fd7cd", "type": "individual", "name": "Tony Stark", "organizationStatus": "approved", "contract_info": { "id": "5bc369de-4fee-4d72-b5e5-73769adeec4e", "personType": "standart", "name": "standard contract for org individual" } } } ], "cohort": "16W", "investigations": [ { "id": "string", "investigator": "string", "investigationReason": "string", "investigationStatus": "open", "investigationStartDate": "2024-07-08T09:53:17.976Z", "investigationDeadline": "2024-07-08T09:53:17.976Z", "investigationEndDate": "2024-07-08T09:53:17.976Z" } ], "profileStatus": "active", "lastLogin": "2024-01-28T18:12:48.985Z", "lastTransaction": "2024-07-17T14:44:44.444Z", "timezone": "+05:30", "systemLanguage": "en" } ]}
|
POST /profiles/my/contact PATCH /v1/profiles/{userId}/contact
GET /v1/profiles/{userId}
|
The request and response body were changed, added the ability to send to the verification certain contacts: · primaryPhoneNumber · additionalPhoneNumber in the response, you will receive action that was done according to the provided contact (sent email or SMS with verification code) Note that only primary phone number or email can be used as login credentials. old request body: { "login": "test_user@mailinator.com"}
new request body: { "email": "john.doe@example.com", "primaryPhoneNumber": "string", "additionalPhoneNumber": "string"}
new response body: [ { "action": "EMAIL_SENT" }]
|
PATCH /profiles/{id}/additional
PATCH /v1/profiles/my/additional GET /v1/profiles/{userId}
|
Parameter timezone was added to the request/response body. Time zone - client time zone in ISO format request body: { "additional": { "type": "common", "birthday": "2024-07-08T11:39:25.604Z", "sex": "MALE", "paidInvoicesAmount": 0, "referenceToProfilePhoto": "https://local.sdk.finance:443/api/v1/media-files/resources/604f7bde-ffe5-4e48-9868-824bc6a2263e.png", "timezone": "+05:30" }}
response body: { "profile": {... "additional": { "type": "common", "birthday": "2024-07-08T11:39:25.608Z", "sex": "MALE", "paidInvoicesAmount": 0, "referenceToProfilePhoto": "https://local.sdk.finance:443/api/v1/media-files/resources/604f7bde-ffe5-4e48-9868-824bc6a2263e.png", "timezone": "+05:30" },... } ]}
|
PATCH /profiles/{id}/person
PATCH /v1/profiles/my/person GET /v1/profiles/{userId}
|
Parameter systemLanguage was added to the request/response body: request body: { "person": { "namePlain": { "first": "string", "last": "string", "middle": "string" }, "nameIntl": { "first": "string", "last": "string", "middle": "string" }, "description": "string", "phoneNumber": "string", "email": "string", "dateOfBirth": "2024-07-08T12:14:13.887Z", "gender": "male", "systemLanguage": "en" }}
response body: { "profile": { "person": { ... "email": "string", "dateOfBirth": "2024-07-08T12:14:13.890Z", "gender": "male", "systemLanguage": "en" } ]}
|
PATCH /v1/profiles/my/address GET /v1/profiles/my PATCH /v1/profiles/{userId}/address
GET /v1/profiles/{userId}
|
Parameter addressType was added to the request/response body. Address type (required) - type of the address provided by the user, available values: personal, business, billing. request body: { "address": { "country": "SK", "addressType": "PERSONAL", "zipCode": "string", "city": "string", "street": "string", "houseNumber": "string" }}
response body: "address": [ { "country": "UA", "addressType": "BILLING", "zipCode": "46000", "city": "Ternopil", "street": "Zelena", "houseNumber": "333" }, { "country": "UA", "addressType": "BUSINESS", "zipCode": "46000", "city": "Ternopil", "street": "Zelena", "houseNumber": "222" }, { "country": "UA", "addressType": "PERSONAL", "zipCode": "46000", "city": "Ternopil", "street": "Zelena", "houseNumber": "111" } ]
|
POST /smart-cards/view |
New filter was added to the request body: associatedCoinSerial request body: { "filter": { "associatedCoinSerial" : "609292447666" }, "sort": {}, "pageNumber": 0, "pageSize": 10}
response body: { "pageNumber": 0, "pageSize": 10, "totalPages": 1, "totalRecords": 2, "records": [ { "id": "0190072b-5eed-7234-8d5d-269eb539b6f0", "cardNumber": "2938 6523 0079 8505", "expirationDate": "07/27", "name": "Test source SMART_CARD", "expirationStatus": "ACTIVE", "active": false, "organizationId": "0190072a-20df-77d6-842f-2a744b76e283", "createdAt": "2024-06-11T12:00:01.261Z", "associatedCoinSerial": "609292447666", "availableAmount": 9903.3800, "currencyCode": "USD" }, { "id": "0190072c-1c7a-7b95-a5f2-e0d7b1a0b654", "cardNumber": "3849 4883 7054 5257", "expirationDate": "07/27", "name": "Test source SMART_CARD", "expirationStatus": "ACTIVE", "active": true, "organizationId": "0190072a-20df-77d6-842f-2a744b76e283", "createdAt": "2024-06-11T12:00:49.786Z", "associatedCoinSerial": "609292447666", "availableAmount": 9903.3800, "currencyCode": "USD" } ]}
|
POST /role-groups-is-able-to-create |
Parameter roleType was added to the request body. Available values: business and service. request body: { "roleType" : "business", "roles" : ["individual", "merchant"]}
response body: { "records": [ { "role": "merchant", "isSelfRegistrationAllowed": true, "creationMethods": [ "CREATE_NEW_ORGANIZATION" ], "hasUserManagerPermission": false, "isAbleToCreateRoles": [ "merchant" ] }, { "role": "individual", "isSelfRegistrationAllowed": true, "creationMethods": [ "CREATE_NEW_ORGANIZATION" ], "hasUserManagerPermission": false, "isAbleToCreateRoles": [ "individual" ] } ]}
|
POST /bank-top-ups POST /bank-top-ups/create-request POST /bank-withdrawals POST /bank-withdrawals/create-request POST /transfers |
Parameter externalProcessId was added to the request/response body. request body (example for transfer): { "paymentTool": { "type": "COIN", "srcValue": "029161738309", "destValue": "710664919642" }, "amount": 300, "description": "My first transfer", "customInformation": "This is my first transfer", "externalProcessId": "6e22dba-44c2-4761-b571-6b61f9b543f1"}
response body (example for transfer): { "process": { "id": "string", "createdAt": "2024-07-09T10:05:29.036Z", "updatedAt": "2024-07-09T10:05:29.036Z", "type": "string", "status": "limited", "categoryCode": "string", "categoryName": "string", "categoryImageLink": "string", "requestIdentifier": 0, "requestStatus": "pending", "internalSourceAmount": 0, "internalDestinationAmount": 0, "externalSourceAmount": 0, "externalDestinationAmount": 0,... "externalProcessId": "6e22dba-44c2-4761-b571-6b61f9b543f1" }}
|
POST transactions/view |
Filter by parameter externalProcessId was added to the request body. request body: { "filter": { "externalProcessIds" : ["1234"] }, "sort": { "createdAt": "desc" }, "pageNumber": 0, "pageSize": 10}
response body: { "pageNumber": 0, "pageSize": 10, "totalRecords": 1, "totalPages": 1, "records": [ { "id": "01903a37-f94d-7933-a4c6-afaae055951d", "createdAt": "2024-06-21T09:54:25.229Z", "updatedAt": "2024-06-21T09:54:25.153Z", "type": "bank_redeem", "status": "processed", "requestIdentifier": 385446087, "requestStatus": "processed", ... ], "externalProcessId": "1234", ... } } ]}
|
GET /v1/gate/view |
New parameter linkedVendors was added to the response body. linkedVendors - list of vendor`s IDs linked to this gate response body: { "gates": [ { "id": "56dbc134-c0c1-4a07-8908-eef066a57153", "name": "SDK.Finance Top up", "custom": true, "linkedVendors": [ "string" ] } ]}
|
POST /v1/saltedge/create-lead-and-session |
New parameter returnTo added to request body. Provide in returnTo URL to which the user will be redirected after finishing interaction with the Saltedge widget request body: { "providerCode": "string", "countryCode": "string", "returnTo": "string", "consentScopes": [ "account_details" ], "includeFakeProviders": true, "consentPeriodDays": 180}
|
POST /v1/saltedge/payment-initiation |
New parameter returnTo added to request body. Provide in returnTo URL to which the user will be redirected after finishing interaction with the Saltedge widget. request body: { "customerId": "222220182322017498", "returnTo": "string", "providerCode": "string", "paymentAttributes": { "key1": {}, "key2": {}, "key3": {} }, "templateIdentifier": "string", "countryCode": "string"}
|
POST /v1/currencies PATCH api/v1/currencies/{currencyId}
GET /v1/currencies |
New required parameters availableForExchange and isMain were added to request body. request body (example for PATCH api/v1/currencies/{currencyId}):
{ "name":"Currency name", "description":"TNDDDzzzzD", "availableForExchange": true}
response body: { "id": "string", "code": "USD", "digitalCode": "926", "symbol": "£", "name": "British Pound Sterling", "description": "British Pound Sterling", "fraction": 100, "snPrefix": "GBP", "active": true, "isMain": true, "availableForExchange": true}
|
Endpoint |
Added |
POST /commission-profile |
Due to Contract and Vendor logic refactoring new API to create a new commission profile was added. Permission required: COMMISSION_MANAGER Parameter type in the request body defines the type of commission for such operation and on which level the commission profile is set: · VENDOR - use this type for specifying the commission that will be paid to the vendor (provider commission) through which the operation is processed, provider commission is specified on the Vendor level and will be used in each Contract where such provider operation will be added · SYSTEM - use this type for specifying the commission that will be charged from the Client (including provider commission) in each separate Contract productId defines products that the user can buy from third-party providers integrated with the platform. Parameter productId is available only for Purchase via provider (operation type=PURCHASE) and only for profiles with type=VENDOR. request body: { "type": "VENDOR", "vendorId": "19130533-9e83-4bde-ac6c-03d51380f73f", "firstCurrencyId": "b51d65c1-79cd-4e96-99f3-8db991194d76", "secondCurrencyId": "b51d65c1-79cd-4e96-99f3-8db991194d76", "contractId": "b51d65c1-79cd-4e96-99f3-8db991194d76", "flowId": "b51d65c1-79cd-4e96-99f3-8db991194d76", "productId": "b51d65c1-79cd-4e96-99f3-8db991194d76", "active": true}
response body: { "profile": { "id": "19130533-9e83-4bde-ac6c-03d51380f73f", "type": "VENDOR", "vendorId": "19130533-9e83-4bde-ac6c-03d51380f73f", "firstCurrencyId": "b51d65c1-79cd-4e96-99f3-8db991194d76", "secondCurrencyId": "b51d65c1-79cd-4e96-99f3-8db991194d76", "contractId": "b51d65c1-79cd-4e96-99f3-8db991194d76", "flowId": "b51d65c1-79cd-4e96-99f3-8db991194d76", "productId": "b51d65c1-79cd-4e96-99f3-8db991194d76", "active": true, "createdAt": "2024-06-17T13:38:22.710Z", "updatedAt": "2024-06-17T13:38:22.710Z", "rules": [ { "id": "19130533-9e83-4bde-ac6c-03d51380f73f", "profileId": "19130533-9e83-4bde-ac6c-03d51380f73f", "active": true, "beginDate": "2024-06-17T13:38:22.710Z", "endDate": "2024-06-17T13:38:22.710Z", "direction": "IN", "conditions": [ { "id": "string", "beginAmount": 0, "endAmount": 0.01, "value": { "type": "fixed", "valuePercent": 0.05, "valueFixed": 3, "maxAmount": 3, "minAmount": 0.1, "collector": "TOTAL" } } ] } ], "limitRules": [ { "id": "19130533-9e83-4bde-ac6c-03d51380f73f", "profileId": "19130533-9e83-4bde-ac6c-03d51380f73f", "active": true, "name": "Transfer limit rule", "value": 10000, "qualifier": "amount", "timeUnit": "per_week" } ] }}
|
POST /commission-profile/view |
Due to Contract and Vendor logic refactoring new API to get the list of commission profiles with filtering and pagination was added. Permission required: COMMISSION_MANAGER request body: { "pageNumber": 0, "pageSize": 10, "filter": { "active": true, "type": "VENDOR", "firstCurrency": "string", "secondCurrency": "string", "currencies": [ "string" ], "operationType": "string", "productId": "string", "vendorId": "string", "contractId": "string", "createdAtFrom": "2024-06-17T14:28:31.995Z", "createdAtTo": "2024-06-17T14:28:31.995Z" }, "sort": { "createdAt": "asc" }}
response body: resp body{ "pageNumber": 0, "pageSize": 10, "totalPages": 1, "totalRecords": 10, "records": [ { "id": "19130533-9e83-4bde-ac6c-03d51380f73f", "type": "VENDOR", "vendorId": "19130533-9e83-4bde-ac6c-03d51380f73f", "firstCurrencyId": "b51d65c1-79cd-4e96-99f3-8db991194d76", "secondCurrencyId": "b51d65c1-79cd-4e96-99f3-8db991194d76", "contractId": "b51d65c1-79cd-4e96-99f3-8db991194d76", "flowId": "b51d65c1-79cd-4e96-99f3-8db991194d76", "productId": "b51d65c1-79cd-4e96-99f3-8db991194d76", "active": true, "createdAt": "2024-05-20T09:38:50.553Z", "updatedAt": "2024-05-20T09:38:50.553Z", "rules": [ { "id": "19130533-9e83-4bde-ac6c-03d51380f73f", "profileId": "19130533-9e83-4bde-ac6c-03d51380f73f", "active": true, "beginDate": "2024-05-20T09:38:50.553Z", "endDate": "2024-05-20T09:38:50.553Z", "direction": "IN", "conditions": [ { "id": "string", "beginAmount": 0, "endAmount": 0.01, "value": { "type": "fixed", "valuePercent": 0.05, "valueFixed": 3, "maxAmount": 3, "minAmount": 0.1, "collector": "TOTAL" } } ] } ], "limitRules": [ { "id": "19130533-9e83-4bde-ac6c-03d51380f73f", "profileId": "19130533-9e83-4bde-ac6c-03d51380f73f", "active": true, "name": "Transfer limit rule", "value": 10000, "qualifier": "amount", "timeUnit": "per_week" } ] } ]}
|
GET /commission-profile/{profileId}
|
Due to Contract and Vendor logic refactoring new API to get details of the specified commission profile was added. Permission required: COMMISSION_MANAGER response body: { "profile": { "id": "19130533-9e83-4bde-ac6c-03d51380f73f", "type": "VENDOR", "vendorId": "19130533-9e83-4bde-ac6c-03d51380f73f", "firstCurrencyId": "b51d65c1-79cd-4e96-99f3-8db991194d76", "secondCurrencyId": "b51d65c1-79cd-4e96-99f3-8db991194d76", "contractId": "b51d65c1-79cd-4e96-99f3-8db991194d76", "flowId": "b51d65c1-79cd-4e96-99f3-8db991194d76", "productId": "b51d65c1-79cd-4e96-99f3-8db991194d76", "active": true, "createdAt": "2024-06-17T14:29:50.227Z", "updatedAt": "2024-06-17T14:29:50.227Z", "rules": [ { "id": "19130533-9e83-4bde-ac6c-03d51380f73f", "profileId": "19130533-9e83-4bde-ac6c-03d51380f73f", "active": true, "beginDate": "2024-06-17T14:29:50.227Z", "endDate": "2024-06-17T14:29:50.227Z", "direction": "IN", "conditions": [ { "id": "string", "beginAmount": 0, "endAmount": 0.01, "value": { "type": "fixed", "valuePercent": 0.05, "valueFixed": 3, "maxAmount": 3, "minAmount": 0.1, "collector": "TOTAL" } } ] } ], "limitRules": [ { "id": "19130533-9e83-4bde-ac6c-03d51380f73f", "profileId": "19130533-9e83-4bde-ac6c-03d51380f73f", "active": true, "name": "Transfer limit rule", "value": 10000, "qualifier": "amount", "timeUnit": "per_week" } ] }}
|
PATCH /commission-profile/{profileId}
|
Due to Contract and Vendor logic refactoring new API to activate or deactivate an existing commission profile was added. active - commission profile status, if active=false it means that the operation with the type specified in this commission profile is not allowed (and it can not be added to the Contracts) Permission required: COMMISSION_MANAGER request body: { "active": true}
response body: { "profile": { "id": "19130533-9e83-4bde-ac6c-03d51380f73f", "type": "VENDOR", "vendorId": "19130533-9e83-4bde-ac6c-03d51380f73f", "firstCurrencyId": "b51d65c1-79cd-4e96-99f3-8db991194d76", "secondCurrencyId": "b51d65c1-79cd-4e96-99f3-8db991194d76", "contractId": "b51d65c1-79cd-4e96-99f3-8db991194d76", "flowId": "b51d65c1-79cd-4e96-99f3-8db991194d76", "productId": "b51d65c1-79cd-4e96-99f3-8db991194d76", "active": true, "createdAt": "2024-06-17T14:30:27.392Z", "updatedAt": "2024-06-17T14:30:27.392Z", "rules": [ { "id": "19130533-9e83-4bde-ac6c-03d51380f73f", "profileId": "19130533-9e83-4bde-ac6c-03d51380f73f", "active": true, "beginDate": "2024-06-17T14:30:27.392Z", "endDate": "2024-06-17T14:30:27.392Z", "direction": "IN", "conditions": [ { "id": "string", "beginAmount": 0, "endAmount": 0.01, "value": { "type": "fixed", "valuePercent": 0.05, "valueFixed": 3, "maxAmount": 3, "minAmount": 0.1, "collector": "TOTAL" } } ] } ], "limitRules": [ { "id": "19130533-9e83-4bde-ac6c-03d51380f73f", "profileId": "19130533-9e83-4bde-ac6c-03d51380f73f", "active": true, "name": "Transfer limit rule", "value": 10000, "qualifier": "amount", "timeUnit": "per_week" } ] }}
|
POST /commission-profile/{profileId}/rule
|
Due to Contract and Vendor logic refactoring new API to create a new commission rule was added. Permission required: COMMISSION_MANAGER request body: { "active": true, "beginDate": "2024-06-17T13:12:31.474Z", "endDate": "2024-06-17T13:12:31.474Z", "direction": "IN"}
response body: { "rule": { "id": "19130533-9e83-4bde-ac6c-03d51380f73f", "profileId": "19130533-9e83-4bde-ac6c-03d51380f73f", "active": true, "beginDate": "2024-06-17T13:12:31.475Z", "endDate": "2024-06-17T13:12:31.475Z", "direction": "IN", "conditions": [ { "id": "string", "beginAmount": 0, "endAmount": 0.01, "value": { "type": "fixed", "valuePercent": 0.05, "valueFixed": 3, "maxAmount": 3, "minAmount": 0.1, "collector": "TOTAL" } } ] }}
|
POST /commission-profile/{profileId}/rule/view
|
Due to Contract and Vendor logic refactoring new API to get the list of commission rules in the specified commission profile with filtering and pagination was added. Permission required: COMMISSION_MANAGER request body: { "filter": { "active": true, "beginAtFrom": "2024-06-17T13:13:55.207Z", "beginAtTo": "2024-06-17T13:13:55.207Z", "endAtFrom": "2024-06-17T13:13:55.207Z", "endAtTo": "2024-06-17T13:13:55.207Z" }}
response body: { "records": [ { "id": "19130533-9e83-4bde-ac6c-03d51380f73f", "profileId": "19130533-9e83-4bde-ac6c-03d51380f73f", "active": true, "beginDate": "2024-06-17T13:13:55.207Z", "endDate": "2024-06-17T13:13:55.207Z", "direction": "IN", "conditions": [ { "id": "string", "beginAmount": 0, "endAmount": 0.01, "value": { "type": "fixed", "valuePercent": 0.05, "valueFixed": 3, "maxAmount": 3, "minAmount": 0.1, "collector": "TOTAL" } } ] } ]}
|
GET /commission-profile/{profileId}/rule/{ruleId}
|
Due to Contract and Vendor logic refactoring new API to get details of the specified commission rule was added. Permission required: COMMISSION_MANAGER response body: { "rule": { "id": "19130533-9e83-4bde-ac6c-03d51380f73f", "profileId": "19130533-9e83-4bde-ac6c-03d51380f73f", "active": true, "beginDate": "2024-06-17T13:17:03.008Z", "endDate": "2024-06-17T13:17:03.008Z", "direction": "IN", "conditions": [ { "id": "string", "beginAmount": 0, "endAmount": 0.01, "value": { "type": "fixed", "valuePercent": 0.05, "valueFixed": 3, "maxAmount": 3, "minAmount": 0.1, "collector": "TOTAL" } } ] }}
|
PATCH /commission-profile/{profileId}/rule/{ruleId}
|
Due to Contract and Vendor logic refactoring new API to to activate or deactivate an existing commission rule was added. Permission required: COMMISSION_MANAGER request body: { "active": true, "beginDate": "2024-06-17T13:17:47.152Z", "endDate": "2024-06-17T13:17:47.152Z", "direction": "IN"}
response body: { "rule": { "id": "19130533-9e83-4bde-ac6c-03d51380f73f", "profileId": "19130533-9e83-4bde-ac6c-03d51380f73f", "active": true, "beginDate": "2024-06-17T13:17:47.153Z", "endDate": "2024-06-17T13:17:47.153Z", "direction": "IN", "conditions": [ { "id": "string", "beginAmount": 0, "endAmount": 0.01, "value": { "type": "fixed", "valuePercent": 0.05, "valueFixed": 3, "maxAmount": 3, "minAmount": 0.1, "collector": "TOTAL" } } ] }}
|
DELETE /commission-profile/{profileId}/rule/{ruleId}
|
Due to Contract and Vendor logic refactoring new API to to delete the specified rule from the commission profile was added. Permission required: COMMISSION_MANAGER |
POST /commission-profile/{profileId}/rule/{ruleId}/condition
|
Due to Contract and Vendor logic refactoring new API to create a rule condition in the specified commission rule was added. Permission required: COMMISSION_MANAGER request body: { "beginAmount": 0, "endAmount": 0.01, "commission": { "type": "fixed", "valuePercent": 0.05, "valueFixed": 3, "maxAmount": 3, "minAmount": 0.1 }}
response body: { "condition": { "id": "string", "beginAmount": 0, "endAmount": 0.01, "value": { "type": "fixed", "valuePercent": 0.05, "valueFixed": 3, "maxAmount": 3, "minAmount": 0.1, "collector": "TOTAL" } }}
|
DELETE /commission-profile/{profileId}/rule/{ruleId}/condition/{conditionId}
|
Due to Contract and Vendor logic refactoring new API to delete the specified rule condition from the commission rule. Permission required: COMMISSION_MANAGER |
PUT /commission-profile/{profileId}/rule/{ruleId}/condition/{conditionId}
|
Due to Contract and Vendor logic refactoring new API to update the specified rule condition in the commission rule. Permission required: COMMISSION_MANAGER request body: { "beginAmount": 0, "endAmount": 0.01, "commission": { "type": "fixed", "valuePercent": 0.05, "valueFixed": 3, "maxAmount": 3, "minAmount": 0.1 }}
response body: { "condition": { "id": "string", "beginAmount": 0, "endAmount": 0.01, "value": { "type": "fixed", "valuePercent": 0.05, "valueFixed": 3, "maxAmount": 3, "minAmount": 0.1, "collector": "TOTAL" } }}
|
POST {{host}}/commission-profile/{commissionProfileId}/limit-rule
|
New API to create limit rule was added. Permission required: LIMIT_RULE_MANAGER request body:{ "qualifier": "amount", "timeUnit": "per_week", "value": 100, "name": "Transfer limit rule", "active": true}response body:{ "rule": { "id": "1f6d2d4c-482a-4292-b86c-ed52a3809e75", "profileId": "438fab09-a353-4c63-a42f-58c50f77008e", "active": true, "name": "Transfer limit rule", "value": 100, "qualifier": "amount", "timeUnit": "per_week" }}
|
GET {{host}}/commission-profile/{commissionProfileId}/limit-rule
|
New API to get a list of limit rules was added. Permission required: LIMIT_RULE_MANAGER resp body:{ "records": [ { "id": "19130533-9e83-4bde-ac6c-03d51380f73f", "profileId": "19130533-9e83-4bde-ac6c-03d51380f73f", "active": true, "name": "Transfer limit rule", "value": 10000, "qualifier": "amount", "timeUnit": "per_week" } ]}
|
GET {{host}}/commission-profile/{commissionProfileId}/limit-rule/{limitRuleId}
|
New API to get limit rule details was added. Permission required: LIMIT_RULE_MANAGER resp body: { "rule": { "id": "19130533-9e83-4bde-ac6c-03d51380f73f", "profileId": "19130533-9e83-4bde-ac6c-03d51380f73f", "active": true, "name": "Transfer limit rule", "value": 10000, "qualifier": "amount", "timeUnit": "per_week" }}
|
PATCH {{host}}/commission-profile/{commissionProfileId}/limit-rule/{limitRuleId}
|
New API to update certain limit rule was added. Permission required: LIMIT_RULE_MANAGER request body:{ "value": 200, "name": "Transfer operation limit rule", "active": false} resp body:{ "rule": { "id": "1f6d2d4c-482a-4292-b86c-ed52a3809e75", "profileId": "438fab09-a353-4c63-a42f-58c50f77008e", "active": false, "name": "Transfer operation limit rule", "value": 200, "qualifier": "amount", "timeUnit": "per_week" }}
|
DELETE {{host}}/commission-profile/{commissionProfileId}/limit-rule/{limitRuleId}
|
New API to delete certain limit rule was added. Permission required: LIMIT_RULE_MANAGER |
POST /role-groups/view |
New API endpoint to view existing roles with filters was added. Available filters: · roleType - role type, available values: service, business · roles - role name Required permission: USER_MANAGER request body: { "roleType" : "service", "roles" : []}
response body: { "records": [ { "code": "financial_specialist" }, { "code": "customer_support" }, { "code": "cfo" }, { "code": "ceo" }, { "code": "compliance_manager" }, { "code": "cashier" }, { "code": "accountant" }, { "code": "head_of_compliance" }, { "code": "customer_support_manager" }, { "code": "compliance_specialist" }, { "code": "administrator" }, { "code": "antifraud_specialist" } ]}
|
POST /external-process/transactions/view |
New API endpoint to view and filter operations grouped by externalProcessId was added. Permission required: TRANSACTIONS_VIEWER Available filters: · externalProcessIds · internalProcessIds - ID of the business process from SDK.finance system · dateFrom · dateTo · walletSerials - involved wallet serial number request body: { "pageNumber": 0, "pageSize": 10, "filter": { "externalProcessIds": [ "6e22dba-44c2-4761-b571-6b61f9b543f1" ], "dateFrom": "2024-07-09T10:14:32.384Z", "dateTo": "2024-07-09T10:14:32.384Z", "internalProcessIds": [ "6e22dba-4565-4761-4444-6b61f9b543f1" ], "walletSerials": [ "765058479176" ] }, "sort": { "dateFrom": "asc" }}
response body: Note that totalRecords represents not the number of groups, but a cumulative number of children { "pageNumber": 0, "pageSize": 10, "totalPages": 1, "totalRecords": 8, "records": [ { "externalProcessId": "1234", "children": [ { "id": "01904f9e-60cd-7431-9007-51727edeba27", "createdAt": "2024-06-25T13:38:17.933Z", "updatedAt": "2024-06-25T13:38:17.875Z", "type": "bank_redeem", "status": "processed", "categoryCode": "1234", "categoryName": "dummyCategory", "requestIdentifier": 255026519, "requestStatus": "processed", "internalSourceAmount": 256.0000, "externalDestinationAmount": 254.0000, "sourceCurrency": { "id": "01903a3d-edf0-7a35-a99b-89a21106d299", "sn": "USD", "code": "USD", "symbol": "$" }, "destinationCurrency": { "id": "01903a3d-edf0-7a35-a99b-89a21106d299", "sn": "USD", "code": "USD", "symbol": "$" }, "transactions": [ ........ } ] } ] } ]}
|
POST /gate-providers/view |
New API endpoint to view gate providers with filters and pagination was added. Permission required: GATE_PROVIDER_VIEWER, GATE_PROVIDER_MANAGER request body: { "pageNumber": 0, "pageSize": 10, "filter": { "vendorName": "Marqeta TOPUP", "active": true, "system": false, "createdAtFrom": "2024-07-09T14:38:48.419Z", "createdAtTo": "2024-07-09T14:38:48.419Z" }, "sort": { "createdAt": "asc" }}
response body: { "pageNumber": 0, "pageSize": 10, "totalPages": 1, "totalRecords": 10, "records": [ { "id": "string", "createdAt": "2024-07-09T14:38:48.420Z", "debtAllowed": true, "active": true, "system": true, "name": "string", "supportedOperations": [ "string" ] } ]}
|
POST /v1/reconciliation/operational-days/create-calendar |
New API endpoint to generate a system calendar was added. To create a system calendar specify the parameters: · dateFrom - beginning of the period from which the calendar will be created (including the beginning date) · toDate - end of the period until which the calendar will be created (including the end date) · timeShift - time shift refers to an adjustment period (formatted as hh:mm:ss) added to the start of an operational day In the response, you will receive a list of created operational days. Permission required: OPERATIONAL_CALENDAR_MANAGER request body: { "dateFrom": "2023-03-21", "dateTo": "2023-03-21", "timeShift": "02:15:00"}
response body: { "pageNumber": 0, "pageSize": 10, "totalPages": 1, "totalRecords": 10, "records": [ { "id": "13f9aa5d-2ca2-44f3-b07f-7769b620ca42", "operationalDay": 0, "status": "OPEN", "beginDateTime": "2023-03-21T16:53:40.969Z", "endDateTime": "2023-03-21T16:53:40.969Z", "createdAt": "2023-03-21T16:53:40.969Z" } ]}
|
DELETE /v1/reconciliation/operational-days/{dateFrom}
|
A new API endpoint to delete upcoming operational days that have not yet occurred was added. Permission required: OPERATIONAL_CALENDAR_MANAGER Only operational days in status FUTURE can be deleted. Provide the date (dateFrom) from which |
POST /v1/reconciliation/operational-days/view |
New API endpoint to view the list of operational days with filtering by the period and pagination was added. Permission required: OPERATIONAL_CALENDAR_VIEWER request body: { "pageNumber": 0, "pageSize": 10, "filter": { "dateFrom": "2023-03-21", "dateTo": "2023-03-21" }, "sort": { "dateFrom": "asc" }}
response body: { "pageNumber": 0, "pageSize": 10, "totalPages": 1, "totalRecords": 10, "records": [ { "id": "13f9aa5d-2ca2-44f3-b07f-7769b620ca42", "operationalDay": 0, "status": "OPEN", "beginDateTime": "2023-03-21T16:53:40.969Z", "endDateTime": "2023-03-21T16:53:40.969Z", "createdAt": "2023-03-21T16:53:40.969Z" } ]}
|
POST /v1/reconciliation/operational-days/balances/view |
New API to view the list of account balances for operational days with filter and pagination was added. Available filters for operational day balances: · operational day number · date · currency · wallet types · wallet serial number Permission required: OPERATIONAL_DAY_ACCOUNTS_BALANCES_VIEWER request body: { "filter": { "operationalDayNumber": 1, "date": "2024-07-10", "currency": "string", "coinTypes": [ "client" ], "serial": "string" }, "sort": { "operationalDayNumber": "asc" }, "pageNumber": 0, "pageSize": 10}
response body: { "pageNumber": 0, "pageSize": 10, "totalPages": 1, "totalRecords": 10, "records": [ { "operationalDayNumber": 1, "operationalDayBeginDateTime": "2024-07-10T13:10:14.234Z", "operationalDayEndDateTime": "2024-07-10T13:10:14.234Z", "coinType": "client", "currency": { "id": "string", "sn": "string", "code": "string", "symbol": "string" }, "serial": "string", "beginBalance": 0, "debit": 0, "credit": 0, "endBalance": 0 } ]}
|
PATCH /v1/reconciliation/config/{reconciliationId}/frequency
|
New API endpoint was added to set up the frequency for the assets reconciliation. frequency - a schedule, that shows how often the reconciliation must be done Available values: NONE, DAILY, WEEKLY, MONTHLY, BIMONTHLY If the frequency is set as NONE, the system won’t create new reconciliation periods. reconciliationId can be retrieved from the API that returns all current configurations POST /v1/reconciliation/config/view Permission required: RECONCILIATION_CONFIG_MANAGER request body: { "frequency": "MONTHLY"}
|
POST /v1/reconciliation/config/view |
New API endpoint to view reconciliation configuration with filter and pagination was added. Permission required: RECONCILIATION_CONFIG_VIEWER request body: { "filter": { "status": "RECONCILED", "periodStartAt": "2024-07-10", "periodEndAt": "2024-07-10", "reconciliationDate": "2024-07-10" }, "sort": { "reconciliationDate": "asc" }, "pageNumber": 0, "pageSize": 10}
response body: { "pageNumber": 0, "pageSize": 10, "totalPages": 1, "totalRecords": 10, "records": [ { "id": "string", "name": "string", "frequency": "MONTHLY", "createdAt": "2024-07-10T13:47:21.626Z", "reconciliationType": "asset", "periodStartAt": "2024-07-10", "periodEndAt": "2024-07-10", "lastReconciledStatus": "RECONCILED", "lastReconciliationDate": "2024-07-10T13:47:21.626Z", "lastReconciledBy": "string", "currency": { "id": "25d59a93-6865-47b7-9afd-076a216fba17", "code": "USD", "digitalCode": "840", "symbol": "$", "name": "US Dollar", "description": "US Dollar", "fraction": 100 } }, { "id": "string", "name": "string", "frequency": "MONTHLY", "createdAt": "2024-07-10T13:47:21.626Z", "reconciliationType": "vendor", "periodStartAt": "2024-07-10", "periodEndAt": "2024-07-10", "lastReconciledStatus": "RECONCILED", "lastReconciliationDate": "2024-07-10T13:47:21.626Z", "lastReconciledBy": "string" } ]}
|
POST /v1/reconciliation/records/{reconciliationConfigId}/view
|
New API endpoint to view the list of reconciliation records with filter and pagination was added. reconciliationConfigId - reconciliation configuration identifier. Can be taken from the id in the response of API GET /reconciliation/config/view. Permission required: RECONCILIATION_RECORDS_VIEWER request body: { "filter": { "status": "RECONCILED", "periodStartAt": "2023-03-21", "periodEndAt": "2023-03-21", "reconciliationDate": "2023-03-21" }, "sort": { "periodStartAt": "asc" }, "pageNumber": 0, "pageSize": 10}
response body: { "pageNumber": 0, "pageSize": 10, "totalPages": 1, "totalRecords": 10, "records": [ { "id": "string", "periodStartAt": "2024-07-10", "periodEndAt": "2024-07-10", "name": "string", "reconciledBy": "string", "status": "RECONCILED", "reconciliationDate": "2024-07-10T13:45:21.210Z", "reconciliationType": "string", "liquidityAmount": 0, "enteredAmount": 0, "discrepancy": 0 } ]}
|
POST /v1/reconciliation/records/{reconciliationRecordId}/reconcile
|
New API endpoint to reconcile assets was added. To reconcile assets provide liquidityAmount in the request body. Liquidity amount - Provide reconciliationRecordId in the request parameter. reconciliationRecordId is the reconciliation record identifier. Can be taken from id in the response of API POST /v1/reconciliation/records/{reconciliationConfigId}/view
Permission required: RECONCILIATION_RECORDS_PROCESSING_MANAGER During the reconciliation process, the system checks the end balance of the issuing_balance account (which serves as the liquidity amount) for the closed operating day, corresponding to the last day of the reconciliation period. If no operational day matches the reconciliation period, the system will return an error: No closed day for the specified period - reconciliation for this period can not be performed. In the response, you will receive the reconciliation result and status: · periodStartAt and periodEndAt - Period - period to reconcile · liquidityAmount - Liquidity amount - calculated system liquidity for the current asset · enteredAmount - Entered amount - manually entered amount to compare with calculated by the system · discrepancy - Discrepancy - discrepancy revealed as a result of reconciliation (difference between Liquidity amount and Entered amount) · name - Reconciled by - the name of the user (First and Last name) by whom the reconciliation was run · reconciliationDate - Reconciliation date - current reconciliation date · status - Status - reconciliation status (see above) request body: { "liquidityAmount": 0}
response body: { "id": "string", "periodStartAt": "2024-07-11", "periodEndAt": "2024-07-11", "name": "string", "reconciledBy": "string", "status": "RECONCILED", "reconciliationDate": "2024-07-11T08:43:52.315Z", "reconciliationType": "string", "liquidityAmount": 0, "enteredAmount": 0, "discrepancy": 0}
|
PATCH /v1/currencies/{currencyId}/set-main
|
New API endpoint to set currency as main was added. Permission required: MAIN_CURRENCY_MANAGER response body: { "id": "string", "code": "USD", "digitalCode": "926", "symbol": "£", "name": "British Pound Sterling", "description": "British Pound Sterling", "fraction": 100, "snPrefix": "GBP", "active": true, "isMain": true, "availableForExchange": true}
|
POST /v1/business-requests/{requestIdentifier}/repeat
|
New API endpoint to execute the limited business request was added (use it instead of deprecated POST /v1/bank-withdrawals/{requestIdentifier}/lift-limit)
required permission: BUSINESS_REQUEST_MANAGER, BUSINESS_REQUEST_BANK_WITHDRAWAL, BUSINESS_REQUEST_CASH_DESK_WITHDRAWAL Provide requestIdentifier. It can be taken from the response of request creation or from the identifier in the response of API POST /business-requests/view Use this API to execute limited business requests for Withdrawal via bank and Withdrawal via Cash desk operations. response body: { "records": [ { "identifier": 12345, "status": "pending", "businessProcessId": "9ac46353-c9a6-4979-8d2e-a9e6c0dd0419", "businessProcessType": "bank_topup", "businessProcessStatus": "limited" } ]}
|
POST /v1/business-requests/{requestIdentifier}/reject
|
New API endpoint to reject limited business requests was added (use it instead of deprecated POST /v1/bank-withdrawals/{requestIdentifier}/reject)
required permission: BUSINESS_REQUEST_MANAGER, BUSINESS_REQUEST_BANK_WITHDRAWAL, BUSINESS_REQUEST_CASH_DESK_WITHDRAWAL Provide requestIdentifier. It can be taken from the response of request creation or from identifier in the response of API POST /business-requests/view Use this API to reject limited business requests for Withdrawal via bank and Withdrawal via Cash desk operations.
response body: { "records": [ { "identifier": 12345, "status": "pending", "businessProcessId": "9ac46353-c9a6-4979-8d2e-a9e6c0dd0419", "businessProcessType": "bank_topup", "businessProcessStatus": "limited" } ]}
|
POST /cash-desk-withdrawals/{requestIdentifier}/perform-withdrawal
|
API URL POST /cash-desk-withdrawals/{requestIdentifier}/accept was changed to POST /cash-desk-withdrawals/{requestIdentifier}/perform-withdrawal
request and response bodies were not changed. |
Endpoint |
Deprecated/Deleted |
GET /v1/contracts/{contractId}/commission-profiles/{commissionProfileId}/limit-profiles/{limitProfileId}
PATCH /v1/contracts/{contractId}/commission-profiles/{commissionProfileId}/limit-profiles/{limitProfileId}
DELETE /v1/contracts/{contractId}/commission-profiles/{commissionProfileId}/limit-profiles/{limitProfileId}
GET /v1/contracts/{contractId}/commission-profiles/{commissionProfileId}/limit-profiles
POST /v1/contracts/{contractId}/commission-profiles/{commissionProfileId}/limit-profiles
GET /v1/contracts/{contractId}/commission-profiles
POST /v1/contracts/{contractId}/commission-profiles
POST /v1/contracts/{contractId}/commission-profiles/multi-currency
POST /v1/contracts/{contractId}/commission-profiles/view
GET /v1/contracts/{contractId}/commission-profiles/{profileId}
PATCH /v1/contracts/{contractId}/commission-profiles/{profileId}
POST /v1/contracts/{contractId}/commission-profiles/{profileId}/commission-rule
POST /v1/contracts/{contractId}/commission-profiles/{profileId}/commission-rule/view
GET /v1/contracts/{contractId}/commission-profiles/{profileId}/commission-rule/{ruleId}
PATCH /v1/contracts/{contractId}/commission-profiles/{profileId}/commission-rule/{ruleId}
DELETE /v1/contracts/{contractId}/commission-profiles/{profileId}/commission-rule/{ruleId}
POST /v1/contracts/{contractId}/commission-profiles/{profileId}/commission-rule/{ruleId}/condition
DELETE /v1/contracts/{contractId}/commission-profiles/{profileId}/commission-rule/{ruleId}/condition/{conditionId}
PUT /v1/contracts/{contractId}/commission-profiles/{profileId}/commission-rule/{ruleId}/condition/{conditionId}
GET /v1/contracts/{contractId}/gate-commission-profiles
POST /v1/contracts/{contractId}/gate-commission-profiles
PATCH /v1/contracts/{contractId}/gate-commission-profiles
POST /v1/contracts/{contractId}/gate-commission-profiles/view
GET /v1/contracts/{contractId}/gate-commission-profiles/{profileId}
GET /v1/contracts/{contractId}/gate-commission-profiles/{gateCommissionProfileId}/limit-profiles
POST /v1/contracts/{contractId}/gate-commission-profiles/{gateCommissionProfileId}/limit-profiles
GET /v1/contracts/{contractId}/gate-commission-profiles/{gateCommissionProfileId}/limit-profiles/{limitProfileId}
PATCH /v1/contracts/{contractId}/gate-commission-profiles/{gateCommissionProfileId}/limit-profiles/{limitProfileId}
DELETE /v1/contracts/{contractId}/gate-commission-profiles/{gateCommissionProfileId}/limit-profiles/{limitProfileId}
POST /v1/contracts/{contractId}/gate-commission-profiles/{profileId}/commission-provider-rule
POST /v1/contracts/{contractId}/gate-commission-profiles/{profileId}/commission-provider-rule/view
GET /v1/contracts/{contractId}/gate-commission-profiles/{profileId}/commission-provider-rule/{ruleId}
PATCH /v1/contracts/{contractId}/gate-commission-profiles/{profileId}/commission-provider-rule/{ruleId}
DELETE /v1/contracts/{contractId}/gate-commission-profiles/{profileId}/commission-provider-rule/{ruleId}
POST /v1/contracts/{contractId}/gate-commission-profiles/{profileId}/commission-provider-rule/{ruleId}/condition
DELETE /v1/contracts/{contractId}/gate-commission-profiles/{profileId}/commission-provider-rule/{ruleId}/condition/{conditionId}
PUT /v1/contracts/{contractId}/gate-commission-profiles/{profileId}/commission-provider-rule/{ruleId}/condition/{conditionId}
POST /v1/contracts/{contractId}/gate-commission-profiles/{profileId}/commission-product-rule
POST /v1/contracts/{contractId}/gate-commission-profiles/{profileId}/commission-product-rule/view
GET /v1/contracts/{contractId}/gate-commission-profiles/{profileId}/commission-product-rule/{ruleId}
PATCH /v1/contracts/{contractId}/gate-commission-profiles/{profileId}/commission-product-rule/{ruleId}
DELETE /v1/contracts/{contractId}/gate-commission-profiles/{profileId}/commission-product-rule/{ruleId}
POST /v1/contracts/{contractId}/gate-commission-profiles/{profileId}/commission-product-rule/{ruleId}/condition
DELETE /v1/contracts/{contractId}/gate-commission-profiles/{profileId}/commission-product-rule/{ruleId}/condition/{conditionId}
PUT /v1/contracts/{contractId}/gate-commission-profiles/{profileId}/commission-product-rule/{ruleId}/condition/{conditionId}
POST /v1/bank-top-ups/{requestIdentifier}/accept
POST /v1/bank-top-ups/{requestIdentifier}/decline
POST /v1/bank-withdrawals/{requestIdentifier}/accept
POST /v1/bank-withdrawals/{requestIdentifier}/decline
POST /v1/bank-withdrawals/{requestIdentifier}/lift-limit
POST /v1/bank-withdrawals/{requestIdentifier}/reject
POST /v1/cash-desk-withdrawals/{requestIdentifier}/approve
POST /v1/cash-desk-withdrawals/{requestIdentifier}/decline
|
The following API endpoints were marked as deprecated. |