Emulation

Emulation features are only available in Sandbox environment.

Tip – You can also rely on webhooks

For operations that cannot be emulated in the Sandbox, webhook examples are provided.

Credit funds

To credit funds, check out the transfer emulations page.

Operations

You can emulate Operations in Sandbox for a given period (monthly, quarterly, semestral, or annual). This is a prerequisite to test the Account Statements.

Simulation periods

Operations simulation supports 4 period types. Provide date for a monthly simulation, or provide year alone for an annual simulation, or combine year with one of the period parameters below. date, quarterly, and semestral are mutually exclusive.

The requested period must be entirely in the past — the current period is not allowed.

Period type	Parameter	Values	Date range
Annual	(none)	—	Jan 1 – Dec 31
Quarterly	quarterly	1–4	Q1: Jan 1–Mar 31 | Q2: Apr 1–Jun 30 | Q3: Jul 1–Sep 30 | Q4: Oct 1–Dec 31
Semestral	semestral	1–2	S1: Jan 1–Jun 30 | S2: Jul 1–Dec 31
Monthly	date	YYYY-MM	First to last day of the month

Parameters

Attribute	Type	Description
walletId	string	The Wallet for which you wish to emulate operations.
date	string	The month for which to simulate operations (format: YYYY-MM). Monthly simulation. Mutually exclusive with year, quarterly, and semestral.
year	integer	The year for which to simulate operations (4 digits, e.g., 2024). Must be a past year. Mutually exclusive with date.
quarterly	integer	The quarter for the quarterly simulation (1–4). Use with year. Mutually exclusive with semestral and date.
semestral	integer	The semester for the semestral simulation (1 or 2). Use with year. Mutually exclusive with quarterly and date.
operations	object	In this object, you can list the number of operations to generate per operation as in the example. As Treezor generates operations with random values (including for types and statuses), it is recommended to have a reasonably high number of payins and payouts for data diversity.

Caution – Uniqueness is checked month by month

Uniqueness is verified for each individual month within the requested period. If any single month in the period already has simulated operations, the entire request is rejected with an HTTP 400 error.

Request example

Endpoint: /simulation/operations

CURL

curl -X POST {baseUrl}/simulation/operations \
	--header 'Authorization: Bearer {accessToken}' \
	--header 'Content-Type: application/json' \
	-d '{payload}'

Here is an example of {payload}:

Monthly

{
	"walletId": "{walletId}",
	"date": "2024-03",
	"operations": {
		"payin": 5,
		"payinrefund": 2,
		"payout": 6,
		"payoutrefund": 1,
		"transfer": 3,
		"cardtransaction": 7,
		"transferfees": 2,
		"transfercreditnote": 1
	}
}

Quarterly

{
	"walletId": "{walletId}",
	"year": 2024,
	"quarterly": 1,
	"operations": {
		"payin": 5,
		"payinrefund": 2,
		"payout": 6,
		"payoutrefund": 1,
		"transfer": 3,
		"cardtransaction": 7,
		"transferfees": 2,
		"transfercreditnote": 1
	}
}

Semestral

{
	"walletId": "{walletId}",
	"year": 2024,
	"semestral": 1,
	"operations": {
		"payin": 5,
		"payinrefund": 2,
		"payout": 6,
		"payoutrefund": 1,
		"transfer": 3,
		"cardtransaction": 7,
		"transferfees": 2,
		"transfercreditnote": 1
	}
}

Annual

{
	"walletId": "{walletId}",
	"year": 2024,
	"operations": {
		"payin": 5,
		"payinrefund": 2,
		"payout": 6,
		"payoutrefund": 1,
		"transfer": 3,
		"cardtransaction": 7,
		"transferfees": 2,
		"transfercreditnote": 1
	}
}

Returns an HTTP 201 Created status code. You can now view your operations by either:

• Generating an account statement
  /core-connect/statements/{walletId}/raw
• Retrieving operations
  /core-connect/operations

Status

Wallets are created in a pending status that is usually very shortly after validated.

To emulate a different status, prefix the Wallet eventName attribute with the following characters.

Prefix	walletStatus	codeStatus	Description
p.1	PENDING	120001	Information control
p.2	PENDING	120002	Late information control
c.3	CANCELED	120003	Wallet was closed internally
c.4	CANCELED	120004	Wallet was closed by the User
v.5	VALIDATED	120005	Wallet is valid

Wait a few minutes and make a GET /v1/wallets request for the Wallet you've just created. The API returns the Wallet with the emulated status.

Example

Let's take an example in which we'd like to simulate a Wallet closed by the User.

CURL

curl -X POST {baseUrl}/v1/wallets \
	--header 'Authorization: Bearer {accessToken}' \
	--header 'Content-Type: application/json' \
	-d '{payload}'

With a {payload} containing the prefixed eventName:

JSON

{
    "walletTypeId": "10",
    "userId": 100113410,
    "currency": "EUR",
    "eventName": "c.4Test Wallet"
}

The request returns the validated Wallet for now.

You need to retrieve the Wallet a few moments after the creation with the following request:

CURL

curl -X GET '{baseUrl}/v1/wallets/{WalletId}' \
	--header 'Authorization: Bearer {accessToken}' \

The Wallet object returned is CANCELED, with the mocked codeStatus:

JSON

{
    "wallets": [
        {
            "walletId": 2643119,
            "walletTypeId": 9,
            "walletStatus": "CANCELED",
            "codeStatus": 120003,
            "informationStatus": "",
            "walletTag": "",
            "userId": 100113410,
            "userLastname": "Alex",
            "userFirstname": "Oak",
            "tariffId": 136,
            "eventName": "c.3test",
            "eventMessage": "",
            "contractSigned": 0,
            "bic": "TRZOFR21XXX",
            "iban": "FR7616798000010000264311929",
            "currency": "EUR",
            "createdDate": "2024-02-06 06:57:56",
            "modifiedDate": "2024-02-06 06:58:16",
            "payinCount": 0,
            "payoutCount": 0,
            "transferCount": 0,
            "solde": 0.0,
            "authorizedBalance": 0.0,
            "totalRows": 1,
            "country": "FR"
        }
    ]
}