Create Transaction
Submit a transaction for synchronous AML/risk monitoring. The transaction is created APPROVED, then your rules (and crypto screening, when applicable) run inline and may flip the returned status to IN_REVIEW or DECLINED. transaction_id is your idempotency key (max 128 chars, unique per app); reusing it returns 400. A transaction.created webhook is dispatched on success (sandbox applications are not billed and do not emit webhooks).
Authorizations
Body
Your unique identifier for this transaction (max 128 characters).
"your-txn-2026-05-17-001"
Category of the transaction. CamelCase aliases (travelRule, userPlatformEvent, gamblingBet, …) are also accepted; the stored/echoed value is camelCase for multi-word categories.
finance, kyc, travel_rule, user_event, audit_trail_event, gambling_bet, gambling_limit_change, gambling_bonus_change "finance"
Core financial details of the transaction.
The subject (applicant) of the transaction.
When the transaction occurred. Defaults to now if omitted.
IANA time zone identifier, e.g. Europe/Madrid.
The counterparty of the transaction (optional).
Arbitrary key-value pairs attached to the transaction. Each key can be referenced in rule conditions with the field path custom_values.<key>.
{
"merchant_id": "test",
"bank_name": "test_2"
}
Travel Rule compliance metadata.
Pre-computed network graph snapshot.
Per-transaction override for crypto blockchain analytics screening. When true, crypto screening is performed regardless of the application default. When false, crypto screening is skipped even if enabled in the application settings. When omitted or null, the application-level default configured in the Console is used. Crypto screening requires transaction_details.direction, currency_kind: "crypto", a chain/currency, and the wallet address selected by the direction: inbound pre-transfer screening uses counterparty.payment_method.account_id, inbound transaction-hash screening uses subject.payment_method.account_id, and outbound screening uses counterparty.payment_method.account_id. When transaction_details.payment_reference_id contains a blockchain transaction hash, Didit performs transaction screening and returns transaction summary enrichment when available.
Response
Transaction submitted and monitored. The body is the full transaction detail (same shape as GET /v3/transactions/{transaction_id}/), reflecting any rule outcomes already applied.
Full monitoring record for one transaction, as returned by GET /v3/transactions/{transaction_id}/ and POST /v3/transactions/.
Didit-stable transaction identifier. Use as {transaction_id} for follow-up calls.
Application-scoped sequential transaction number shown in Console (e.g. 4123).
The transaction_id you supplied at create time (max 128 chars). Unique per application.
When the transaction occurred (from transaction_at; defaults to submission time).
IANA time zone identifier provided at create time.
Top-level category as stored: finance, kyc, travelRule, userPlatformEvent, gamblingBet, gamblingLimitChange, gamblingBonusChange, auditTrailEvent. Note multi-word values are echoed back in camelCase even when submitted in snake_case.
Sub-type within the category (e.g. deposit, withdrawal, transfer). Defaults to the category when not supplied.
Direction relative to the subject. Stored uppercase regardless of the casing submitted (in/out/inbound/outbound are accepted on input).
INBOUND, OUTBOUND Current monitoring verdict. Transactions are created APPROVED; rules may flip them to IN_REVIEW/DECLINED synchronously.
APPROVED, IN_REVIEW, DECLINED, AWAITING_USER Transaction amount as a decimal string with trailing zeros stripped (e.g. "1500", "0.5", "0.123456789012345678"). Up to 18 decimal places.
Currency code of amount (e.g. EUR, USD, BTC).
fiat or crypto, as submitted in currency_kind.
Pre-converted amount you supplied, as a decimal string with trailing zeros stripped.
amount converted to the application's preferred currency, when available.
Free-text payment reference or memo from the submission.
External payment system reference (e.g. blockchain transaction hash) from payment_reference_id.
Risk score accumulated by rules (typically 0–100). Higher = riskier.
Categorical risk severity set by rules/providers (UNKNOWN, LOW, MEDIUM, HIGH, CRITICAL). null until something sets it.
UNKNOWN, LOW, MEDIUM, HIGH, CRITICAL Machine-readable reason for the current status.
Human-readable label for decision_reason_code.
Convenience copy of the applicant's vendor_data.
Snapshot of the subject and counterparty payloads as submitted at create time.
The custom_properties you supplied at create time. Each key is addressable in rule conditions as custom_values.<key>.
Tags attached to the transaction (manually or by rules).
Transaction parties (applicant, counterparty).
Payment methods linked to the transaction.
Activity log entries (creation, notes, manual reviews, status changes).
Alerts raised by rules and providers.
Per-rule execution results — which rule fired, with what score impact.
Raw provider payloads (AML screening, blockchain analytics, etc.).
Travel Rule compliance check, present when travel_rule_details was submitted.
Graph snapshot of related transactions/parties used by the rules engine, present when submitted.
Remediation session offered to the user when re-verification is required.
Per-feature credit cost breakdown for this transaction.