cashier.deposit.created

Direction: server → modules. External Moleculer event name: cashier.deposit.created.

Source and occurrence

C++ payload: CashierTransactionRecord. Internal EventBus name: cashier.push. Event code: EV_RECORD_ADD (0).

The event is emitted by CashierManager::AddTransaction once a new deposit transaction has been written to the Cashier store and added to the runtime cache. It is raised on every creation path; no workflow rule is involved:

Command	Who creates	status	source
CreateCashierDeposit, manual method	Customer	9, manual review	1, manual
CreateCashierDeposit, payment-module method	Customer	1, pending payment	0, provider
MngCreateManualCashierDeposit	Manager	0, created	1, manual

A rejected creation — invalid data, deposit not allowed, duplicate idempotency_key, storage failure — publishes nothing. The event carries the transaction as created:

• for a payment-module method it is published before the payment provider is called and before the customer is redirected, so it also fires for payments that are never completed or that the provider rejects;
• with process_now=1 the manager command processes the deposit afterwards, and a successful processing later publishes cashier.deposit.approved if the brand has the workflow rule for it.

A creation does not credit the account.

This is asynchronous fire-and-forget publication. It does not confirm delivery or processing by a module.

This event is not the workflow trigger deposit.created: that trigger fires on the balance operation, when the deposit is credited, not when it is requested.

JSON payload

{
  "event_id": "9e1d2c3b4a5f46e7b8c9d0a1b2c3d4e5",
  "event_code": 0,
  "occurred_at": 1789639050,
  "schema_version": 2,
  "brand": "ion4",
  "transaction_id": 111,
  "customer_id": 80,
  "login": 7777853,
  "type": 0,
  "provider": "manual",
  "method": "bank_transfer",
  "provider_config_id": 3,
  "provider_payment_id": "",
  "amount": 333.0,
  "currency": "USD",
  "account_currency": "USD",
  "converted_amount": 333.0,
  "conversion_rate": 1.0,
  "status": 9,
  "source": 1,
  "comment": "",
  "created_time": 1789639050
}

Field	Type	Meaning
brand	string	Brand resolved from the transaction account during formatting; empty if the account lookup fails
transaction_id	integer	Cashier transaction identifier
customer_id	integer	Related customer identifier
login	integer	Trading account login
type	integer	0, deposit
provider	string	Provider code of the selected method; manual for a manager-created request
method	string	Payment method; empty if it was not passed
provider_config_id	integer	Selected Cashier provider configuration; 0 for a manager-created request
provider_payment_id	string	Provider-side payment identifier; empty at creation unless a manager passed one
amount	number	Requested amount in currency
currency	string	Requested currency
account_currency	string	Trading account currency
converted_amount	number	Amount in account currency
conversion_rate	number	Conversion rate; 1.0 at creation
status	integer	Initial status, see the table above
source	integer	0 provider or 1 manual, see the table above
comment	string	Request comment
created_time	integer	Creation time in Unix seconds

occurred_at equals created_time. Payer details, payment instructions (metadata_json) and the idempotency key are not published. The event has no customer email or name: a consumer resolves them by customer_id / login.

Mailer and SMS triggers

A trigger with "event": "cashier.deposit.created" fires on every request, including payment-module deposits that are never paid. To limit it to manual requests submitted by customers, add a condition:

{ "match": { "status": "9" } }

See shared outbound rules for metadata, queue limits and delivery guarantees.