Glossary 

FSP

Technical system behind the Financial Split Payments product.

Aggregator

Legal entity that aggregates one or more clients.

Client

Entity that receives its allocated share of credits from a specific Money In through a first-level split payment operation. A client may have multiple contracts in relation to different aggregators.

Money In

Credit received in the aggregator’s account. Each Money In is typically split among the aggregator’s clients based on their respective shares.

Money Out

The portion of funds allocated to a client. Money Outs are processed through the cashout flow.

This concept corresponds to “Cash In” in the Financial Split Payments contract.

Within FSP, it is the technical entity used to trigger fund distribution, or cashout, based on split rules, applied fees, and residual allocations.

Cash Out

A second-level split payment in which each Money Out is allocated to one or more beneficiaries.

Introduction

Financial Split Payments is a product that enables the collection of incoming payment flows originating from various gateways, generated either through alternative payment methods, cards, or account-to-account transactions, in order to credit them via a single payout flow to clients and all other stakeholders involved in the client business process (aggregators, intermediaries, platforms, etc.).

The FSP product can be used in combination with Fabrick’s transactional products, such as Fabrick Orchestra, that automatically notify FSP about the expected credit (Money In) to be validated.

The FSP product may be used as well via the so called “standalone mode”. In this situation, it is the aggregator’s ownership to communicate the Money-In attributes and specify the allocation of related shares among the various clients.

This article explains how to integrate with Financial Split Payments in standalone mode; it describes the integration via REST services that the aggregator must implement to manage Money In.

Creating money-in request

The CreateMoney-in service enables the aggregator to communicate an expected credit to FSP; that is, the data needed to verify the aggregator’s account movements.

Below is an example of how to use the CreateMoney-in service.

Input example:

{
    "reconciliationCallbackUri": "https://callback.uri",
    "money-in": {
    "amount": {
      "value": 100,
      "currency": "EUR"
        },
    "creditTransferId": "EA24020312345678912345678912IT",
    "description": "test",
    "referenceDate": "2026-04-01"
    },
    "splitToClients": [
    {
      "clientId": "IT01234567890",
      "amount": {
        "value": 50,
        "currency": "EUR"
            }
        },
    {
      "clientId": "IT01234567891",
      "amount": {
        "value": 50,
        "currency": "EUR"
            }
        }
    ]
}   

The details of the fields included in the request are explained in the technical documentation of the service.

Here, some notes on how to use the service:

• The currencies used must be among those supported by FSP.
• All amounts in the CreateMoney-in request must use the same currency.
• FSP does not support currency conversion.
• The reconciliationCallbackUri attribute, if provided by the caller, allows FSP to send a callback to the client system to notify the outcome of the accounting reconciliation.
• The service may result in either OK or KO. OK means that the reconciliation process has been taken in charge; if it is successful, FSP initiates Cashin and Cashout as specified in the contract with the clients.
• Clients are identified by their VAT number. Only identifiers of clients active in the aggregator’s domain are allowed.
• ClientIds must not be repeated within the request

The “createMoney-in” request is identified by the “creditTransferId” field. This value can be reused only after the previous request has completed reconciliation with a KO outcome.

FSP reconciliation process

Once the expected credit data has been acquired, FSP reviews the observed credits received in the aggregator’s account. Reconciliation is performed between an expected credit and an observed credit that share the same unique identifier (transferId).

The reconciliation then verifies that the two credits match according to the following rules:

• The acquirer associated with the expected credit must be correctly identified and recognized.
• Both credits must be denominated in the same currency.
• Expected and observed credit amounts must be identical.

The reconciliation process may result in three outcomes:

• OK, indicating that reconciliation has been successfully completed.
• KO, indicating that at least one reconciliation rule has been violated; in this case, the request can be resubmitted with corrected data.
  • IN_PROGRESS, indicating that reconciliation is still ongoing, as not all required data regarding the credits is yet available.

 When reconciliation is eventually completed, the outcome is automatically updated to either OK or KO.

Reconciliation callback

FSP may send a callback to the caller to notify the outcome of the reconciliation process. This occurs if the reconciliationCallbackUri field is provided in the CreateMoney-in request.

The structure of the callback payload is illustrated below.

{
    "reconciliationOutcome": {
    "creditTransferId": "TRN/CRO",
    "reconciliationStatus": "OK||KO||IN_PROGRESS",
    "moneyIn": {
      "amount": {
        "value": 100,
        "currency": "EUR"
            }
        },
    "observedTransfer": {
      "amount": {
        "value": 100,
        "currency": "EUR"
            }
        }
    }
}   

The following table describes the struct of the callback payload

The status IN_PROGRESS is reported by the callback when reconciliation has not been completed within the defined time threshold.

Technical aspects related to the callback invocation

Invocation method. 

The callback is sent using the POST method to the endpoint specified in the CreateMoneyIn request. If the invocation fails, FSP applies its retry policies.

Security and network requirements. The callback is invoked without an authorization mechanism. However, Fabrick can provide the list of IP addresses to be whitelisted.