Crassula Release Week 1-2

core v.24.12.11-25.01.3
client v.24.12.8-25.01.2

Improvements

API

• The performance of Crassula's API requests has been improved to reduce server load and enhance latency.

• A new API endpoint has been introduced for exporting historical transaction reports:

  • Enqueue export: POST /api/reports/banking/historical-transactions-accounting/export-requests/{format}

  • Check export status: GET /api/reports/banking/historical-transactions-accounting/export-requests/{id}

• The POST:/api/clients/{clientId}/identification-requests method now requires the type parameter (string: "company") in the request body. The URL must include the level specified in the configuration (sumsub_levels > MAIN > ... > application_level).

• To comply with PCI DSS 4.0 (requirement 8.3.2), stored API keys are now unreadable.

• A new API method, POST /api/clients/{{clientId}}/identification-requests/import, allows importing existing applicant data from Sumsub into Crassula's system.

• A new API method, GET /api/clients/{clientId}/list-sepa-methods/{iban}, provides a list of supported API methods for a given IBAN.

See Banking API for additional details on the methods.

Cards

The REAP card functionality has been expanded:

• PIN code changes are now supported for both virtual and plastic cards.

• Webhooks have been implemented for REAP card transactions.

• Holds are now supported, and a complete transaction flow for REAP cards has been established.

Payments

• Bank correspondent data is now sent to the provider for Clearbank transactions.

• The intermediary SWIFT code is now verified according to ClearJunction system requirements for USD SWIFT payments. If verification fails, an issue is logged in Banking > Issues for WLs to address with the service provider.

• The "Finalized At" field has been migrated to older transactions, ensuring consistency across all records.

• PDF statement generation now uses the Finalized At filter. Statements are filtered and created based on this field across the web interface, mobile app, Admin Panel, and API.

• A device ID parameter has been implemented for transactions processed through Huntli.

Web Interface

Added warnings for the FPS method in Local and Dynamic payments to comply with PSR regulations on fraud reimbursement.

Fixes

Client details

Corrected an issue where valid Swedish postal codes were not processed correctly.

Direct debit

Fixed a bug where users with inactive accounts could see all direct debit mandates of other users when accessing the direct debit mandate list.

Web Interface

Fixed incorrect or missing commission display on the dynamic payments tab.

Upcoming Updates

Improvements

API: Requisites

The GET /api/clients/{clientId}/accounts/{accountId}/requisite method will soon include a new hint parameter. This parameter will provide tips or guidance related to specific requisites, which can be pre-configured by technical support in system settings. These hints are intended to enhance the user experience and may also be displayed in the front-end interface in future updates.

API: Fee Creation Updates

The logic for creating fees will be refined to ensure better control over percentage values:

• Transfer Fees:

  • In the Admin Panel, the Percent field in the Transfer Fees section will allow values up to 100.00%. Any value exceeding 100.00% will be rejected.

  • The POST /api/client-fee/transfer-fee method will enforce the same restriction, returning an error for percentages above 100.00%.

• FX Markup Fees:

  • In the Admin Panel, the Percent field in the FX Markup Fees section will accept values from 0.00% to 98.99%. Percentages exceeding 98.99% will not be permitted.

  • The POST /api/client-fee/fx-markup method will also enforce this range, rejecting values above 98.99% and returning an error.

The API documentation for the methods will be updated to reflect these limitations, ensuring users can access the valid percentage ranges.