Skip to main content
This page documents the full payload returned by POST /v3/transactions/ and GET /v3/transactions/{id}/.

Top-level structure

Key fields

Financial fields

  • amount / currency — transaction amount as submitted.
  • amount_in_default_currency / default_currency_code — amount converted to your app’s default currency (for cross-currency thresholding).
  • preferred_currency_amount — optional per-rule / per-app preferred reporting currency.

Status fields

  • statusAPPROVED, IN_REVIEW, DECLINED, AWAITING_USER.
  • score — integer score.
  • decision_reason_code / decision_reason_label — structured + human reason for the current status.

Parties

Each party (applicant, remitter, beneficiary, counterparty) has the same shape. See IP enrichment for the enrichment fields.

Payment methods

role: SOURCE, DESTINATION, FUNDING, BENEFICIARY. type: BANK_CARD, BANK_ACCOUNT, EWALLET, CRYPTO_WALLET, UNHOSTED_WALLET.

Rule runs

Every rule that evaluated is included — matched: false rules appear too, so you can audit selectivity.

Alerts

Provider results

External provider outputs (transaction hash screening, wallet screening, fiat monitoring, sanctions screening).
For crypto transaction-hash screening, transaction_flows is populated when on-chain enrichment is available. It normalizes chain activity so the console can render both the transaction overview and visualization graph from the same response payload. Supported enrichment sources:
  • EVM chains use Blockscout to normalize the main transaction, internal calls, and token transfers.
  • Bitcoin uses mempool.space to normalize transaction inputs and outputs.
  • Solana uses Helius to normalize native SOL transfers, SPL token transfers, and available NFT event context.
Each transaction_flows[] item includes stable normalized fields (flow_type, from_address, to_address, amount, amount_usd, currency, token_name, token_address, transaction_hash, block_timestamp, index, success) plus provider-specific metadata. Common metadata examples:
metadata is additive and provider-specific. Do not build critical integrations that require every key to be present for every chain.

Travel rule

Only present for virtual-asset transfers.
See Travel rule.

Network snapshot

For crypto transactions, network_snapshot_id points to the stored network graph (nodes, edges, metrics). View the graph in the console transaction detail page.

Tags, notes, metadata

  • tags[] — attached tags (either by rule action or by analyst).
  • notes[] — analyst notes.
  • metadata — free-form JSON you submitted on the request.
  • custom_values — rule-engine-consumable JSON (typed fields you can reference in conditions).

Remediation

When a rule triggers AWAITING_USER, Didit creates the linked verification session and returns it in two fields:
  • remediation — the linked session: { "session_id", "session_token", "url", "status" }. Stays populated for the life of the transaction, so you can always see how the user action ended.
  • action_required — the action the user must take right now, or null once nothing is pending: { "type": "verification_session", "url", "session_id", "session_token", "status" } (Travel Rule wallet-ownership actions use "type": "wallet_ownership"). Redirect the user to url, or feed session_token to a Didit SDK.
The same two fields ride on the transaction.created and transaction.status.updated webhook payloads (action_required) - see webhooks.

Currency conversion

amount_in_default_currency uses mid-market rates from our FX provider at the transaction’s txn_date. Rules that threshold on “amount” operate on amount_in_default_currency by default; rules can opt into the native amount via rule scope.

Next steps

Submit transactions

Full request schema.

Statuses

What each status means.

Risk scoring

How score is computed.