Get Transaction (SDK Token)
Device-facing read endpoint, authenticated with the same X-Transaction-Token used to submit. The SDKs poll it after an auto-launched action flow completes or its window closes, so the final state never depends on a single notification. Returns the same transaction detail as the submit response, including the current action_required block (null once the action is resolved).
Authorizations
Short-lived scoped token minted by your backend via POST /v3/transactions/sdk-token/. Used by the Didit SDKs on the device-facing /v1/transactions/ endpoints.
Path Parameters
Didit-stable transaction UUID (the uuid from the submit response, not your txnId).
Response
The full transaction detail, including action_required (null once the pending action is resolved).
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. Superseded by action_required, which is the canonical block; kept for backward compatibility.
Pending end-user action required to complete this transaction, or null when there is none. The Didit SDKs auto-launch the action by default and refresh the transaction when it finishes. Two variants, discriminated by type: verification_session (a hosted verification session created by a rule action) and wallet_ownership (a wallet-ownership widget session auto-minted for a Travel Rule transfer that needs proof of wallet control, gated by the auto_wallet_verification Travel Rule setting). When both could apply, wallet_ownership takes precedence because it blocks the Travel Rule exchange.
- Verification session
- Wallet ownership
Per-feature credit cost breakdown for this transaction.