Zum Hauptinhalt springen
Diese Seite dokumentiert die vollständige Payload, die POST /v3/transactions/ und GET /v3/transactions/{transaction_id}/ zurückgeben. Beide Endpoints liefern dasselbe TransactionDetail-Objekt zurück. Die API-Referenz enthält das Schema für die einzelnen Felder, diese Seite erläutert es.

Struktur auf oberster Ebene

Zwei Kennungen beschreiben dieselbe Transaktion. uuid ist die stabile Didit-Kennung und wird im Pfad von GET /v3/transactions/{transaction_id}/ erwartet. txn_id ist die transaction_id, die Sie beim Erstellen angegeben haben. transaction_number ist die fortlaufende Nummer innerhalb der Anwendung, die die Konsole anzeigt. Das Subjekt und die Gegenpartei, die Sie übermittelt haben, erscheinen nicht als Schlüssel auf oberster Ebene. Sie sind Einträge des Arrays parties und werden über role unterschieden. Das vendor_data auf oberster Ebene ist eine Kopie des vendor_data des Antragstellers und dient der Bequemlichkeit.

Wichtige Felder

Finanzfelder

  • amount / currency: Transaktionsbetrag, wie übermittelt. amount ist eine Dezimalzeichenkette ohne nachgestellte Nullen ("1500", "0.5") mit bis zu 18 Dezimalstellen.
  • currency_type: fiat oder crypto, wie in currency_kind übermittelt; null, wenn er nicht angegeben wurde.
  • amount_in_default_currency / default_currency_code: der vorab umgerechnete Betrag, den Sie in der Anfrage übermittelt haben, unverändert zurückgegeben; null, wenn Sie keinen vorab umgerechneten Betrag übermittelt haben.
  • preferred_currency_amount / preferred_currency_code: amount, umgerechnet in die bevorzugte Währung Ihrer Anwendung. null, wenn für currency kein Wechselkurs verfügbar ist und Sie kein amount_in_default_currency übermittelt haben.
  • payment_details / payment_txn_id: die Freitext-Zahlungsreferenz und die externe Zahlungsreferenz (zum Beispiel ein Blockchain-Transaktionshash) aus der Anfrage.

Statusfelder

  • status: APPROVED, IN_REVIEW, DECLINED, AWAITING_USER. Transaktionen werden mit APPROVED angelegt; Regeln können den Status synchron ändern.
  • score: ganzzahliger Risiko-Score, der durch Regeln aufsummiert wird. Ein höherer Wert bedeutet ein höheres Risiko.
  • severity: UNKNOWN, LOW, MEDIUM, HIGH, CRITICAL oder null, bis eine Regel oder ein Anbieter den Wert setzt.
  • decision_reason_code / decision_reason_label: strukturierter bzw. menschenlesbarer Grund für den aktuellen Status.
  • environment: live oder sandbox, abhängig von der Anwendung, zu der die Transaktion gehört. Eine sandbox-Transaktion wird gespeichert, aber nie ausgewertet. Ihr leeres rule_runs bedeutet deshalb „nicht ausgewertet“ und nicht „keine Regel hat gegriffen“. Siehe Transaktionsüberwachung in der Sandbox.
  • source: LIVE für Transaktionen, die über die API oder das SDK übermittelt wurden, IMPORTED für Transaktionen, die über den CSV-Import in der Konsole geladen wurden.

Beteiligte

Jede beteiligte Partei einer Transaktion ist ein Eintrag in parties. Der Create-Endpoint erfasst das Subjekt als APPLICANT und die optionale Gegenpartei als COUNTERPARTY. Das Enum role enthält außerdem REMITTER und BENEFICIARY. Alle Einträge haben denselben Aufbau.
  • role: APPLICANT, COUNTERPARTY, REMITTER, BENEFICIARY. Filtern Sie danach, um das Subjekt zu finden.
  • entity_type: individual, company, external, unhostedWallet, wie übermittelt.
  • kind: USER oder BUSINESS, wenn die Partei über vendor_data mit einem Didit-Benutzer oder einem Didit-Unternehmen verknüpft ist; andernfalls EXTERNAL.
  • country_code / dob: aus dem übermittelten address.country bzw. date_of_birth.
  • address / institution_info: die Objekte wie übermittelt; {}, wenn sie nicht angegeben wurden.
  • external_party_snapshot: eingefrorene Kopie der Parteidaten für EXTERNAL-Parteien; null, solange die Partei mit einem Didit-Benutzer oder einem Didit-Unternehmen verknüpft ist.

device

device ist der device_context, den Sie für diese Partei übermittelt haben, in snake_case normalisiert und um die serverseitige IP-Anreicherung ergänzt. Es ist {}, wenn die Anfrage keinen Gerätekontext enthielt. Behandeln Sie deshalb jeden Schlüssel als optional. Es gibt kein separates Anreicherungsobjekt. Hat die Partei eine öffentliche network_context.ip_address übermittelt, löst Didit sie inline auf und schreibt die angereicherten Felder in dasselbe network_context-Objekt. Dabei werden nur Schlüssel gefüllt, die Sie nicht selbst übermittelt haben. Schlüssel, die der Resolver leer zurückgibt, werden weggelassen. Ein vollständig angereichertes network_context enthält deshalb die vier übermittelten Schlüssel (ip_address, ip_country_code, latitude, longitude) sowie alle der folgenden Felder, die aufgelöst werden konnten: ip_country, ip_state, ip_city, isp, organization, is_vpn_or_tor, is_data_center, time_zone, time_zone_offset, asn_number, asn_organization, connection_type, carrier und proxy_type. is_vpn_or_tor und is_data_center sind nach einer erfolgreichen Auflösung immer vorhanden. Die Anreicherung wird übersprungen, und network_context wird genau so zurückgegeben, wie es übermittelt wurde, wenn die IP fehlt oder nicht routbar ist, wenn die Anwendung in der Sandbox läuft oder wenn die Auflösung fehlgeschlagen ist. ip_country_code ist ein ISO-3166-1-Alpha-2-Code, wenn Didit ihn aufgelöst hat, andernfalls der von Ihnen übermittelte Wert. Regelbedingungen normalisieren beide Formen, bevor sie verglichen werden.

Zahlungsmethoden

  • role: SOURCE, DESTINATION, FUNDING, BENEFICIARY. Der Create-Endpoint vergibt SOURCE und DESTINATION anhand von direction: Bei einer ausgehenden Transaktion ist die Zahlungsmethode des Subjekts SOURCE und die der Gegenpartei DESTINATION; bei einer eingehenden Transaktion ist es umgekehrt.
  • payment_method_type: bank_card, bank_account, e_wallet, crypto_wallet, unhosted_wallet, other.
  • fingerprint: SHA-256 über type:account_id:issuing_country. Der Wert bleibt über alle Transaktionen hinweg stabil, damit Sie die Wiederverwendung desselben Zahlungsinstruments korrelieren können. null, wenn keine account_id übermittelt wurde.
  • owner_kind / vendor_data / owner_name: Eigentümer des Instruments, nach derselben Konvention USER / BUSINESS / EXTERNAL wie bei Beteiligten.
  • details: das ursprüngliche payment_method-Objekt, wie übermittelt.

Regelausführungen

  • rule: UUID der ausgeführten Regel; rule_title, rule_description und rule_category werden aus ihr übernommen.
  • matched: Ein Lauf wird nur aufgezeichnet, wenn die Bedingungen der Regel erfüllt waren. Live-Auswertungen tragen deshalb immer matched: true. Regeln, die ausgewertet wurden, ohne zu greifen, hinterlassen keinen Eintrag. Demodaten können Zeilen mit matched: false enthalten.
  • is_test / mode: true und TEST, wenn die Regel im Testmodus lief. Ein Testlauf wird aufgezeichnet, hat aber keine Auswirkung auf status, score oder severity.
  • score_delta / status_target / severity: was dieser Lauf beigetragen hat. status_target wird gesetzt, wenn eine Aktion change_status ausgeführt wurde oder wenn der hinzugefügte Score einen Schwellenwert überschritten hat.
  • action_summary: eine Zeichenkette mit einer Zusammenfassung der ausgeführten Aktionen, verbunden mit ; (score +30, change_status:IN_REVIEW, add_tag:<name>, add_note, add_to_list, open_case); null, wenn die Regel keine Aktion ausgeführt hat.
  • metadata: die Auswertungsdetails: scope_match sowie conditions[] und aggregations[]. Die beiden Listen verwenden unterschiedliche Wertschlüssel:
    • conditions[]: ein Eintrag pro Bedingung mit field, operator, expected_value, dem current_value, der aus der Transaktion gelesen wurde, matched, group_index und group_logic. field_source ist bei Regelausführungen für Transaktionen immer null; es wird nur für Monitoring-Ereignisse klassifiziert.
    • aggregations[]: ein Eintrag pro Velocity-, Zähl- oder Summenaggregation mit metric, field, operator, expected_value, dem computed_value, zu dem die Aggregation ausgewertet wurde, window, filters, matched und sample_references. Aggregationen, die nur asynchron berechnet werden konnten, tragen computed_value: null und deferred: true.

Alerts

alerts ist derzeit immer ein leeres Array. Ein offener Alert ist eine zurückgehaltene Transaktion. Lesen Sie daher stattdessen status (IN_REVIEW oder AWAITING_USER). Siehe Alerts.

Aktivitäten

Das Aktivitätsprotokoll der Transaktion: Erstellung, Notizen, manuelle Prüfungen und Statusänderungen.
Analystennotizen erscheinen hier als TRANSACTION_NOTE_ADDED-Einträge. Ein separates notes-Array gibt es nicht.

Dokumente

Über die Konsole an die Transaktion angehängte Dateien. [], wenn keine vorhanden sind.
file_url ist eine kurzlebige signierte URL. Rufen Sie sie ab, wenn Sie sie benötigen, statt sie zu speichern.

Anbieterergebnisse

Ausgaben externer Anbieter (Screening von Transaktions-Hashes, Wallet-Screening, Fiat-Überwachung, Sanktionsscreening).
result_type: FIAT_MONITORING, WALLET_SCREENING, TRANSACTION_SCREENING, TRAVEL_RULE, NETWORK_GRAPH, CUSTOM. payload.risk_factors ist die nach Rang geordnete Erklärung von score: Was zum Urteil geführt hat, wobei Treiber mit hohem Risiko zuerst stehen, danach nach dem bewegten Wert. Ein hoher score ohne is_high_risk-Eintrag bedeutet, dass der Anbieter die Entität anhand des eigenen Risikomodells bewertet hat, ohne einen Sanktions- oder Zuordnungstreffer zu melden. summary sagt das ausdrücklich. Feldreferenz: Risikofaktoren. Ergebnisse, die vor der Einführung dieses Feldes geprüft wurden, enthalten den Schlüssel nicht. Beim Screening von Transaktions-Hashes für Kryptowährungen wird transaction_flows befüllt, sofern eine On-Chain-Anreicherung verfügbar ist. Es normalisiert die Chain-Aktivität, damit die Konsole sowohl die Transaktionsübersicht als auch die Visualisierung des Graphen aus derselben Antwort-Payload darstellen kann. Unterstützte Anreicherungsquellen:
  • EVM-Chains verwenden Blockscout, um die Haupttransaktion, interne Aufrufe und Token-Transfers zu normalisieren.
  • Bitcoin verwendet mempool.space, um Transaktionseingänge und -ausgänge zu normalisieren.
  • Solana verwendet Helius, um native SOL-Transfers, SPL-Token-Transfers und verfügbaren NFT-Ereigniskontext zu normalisieren.
Jedes Element in transaction_flows[] enthält stabile, normalisierte Felder (flow_type, from_address, to_address, amount, amount_usd, currency, token_name, token_address, transaction_hash, block_timestamp, index, success) sowie anbieterspezifische metadata. Häufige metadata-Beispiele:
metadata ist additiv und anbieterspezifisch. Bauen Sie keine kritischen Integrationen, die voraussetzen, dass für jede Chain jeder Schlüssel vorhanden ist.

Travel Rule

null, wenn die Transaktion weder einen Travel-Rule-Transfer noch eine Prüfung hat. Das Feld wird befüllt, wenn Sie travel_rule_details übermitteln, und auch dann, wenn Travel Rule für die Anwendung aktiviert ist und die Transaktion mit transaction_category: "travelRule" erstellt wurde. Didit initiiert dann den Austausch selbst, mit oder ohne travel_rule_details, und meldet dessen status hier. Lesen Sie dieses Feld statt der von Ihnen gesendeten Anfrage. Bei einer eingehenden Überweisung bleiben die originator_data und beneficiary_data der Gegenpartei maskiert (data_masked: true), bis die Wallet-Inhaberschaft bestätigt ist (siehe Maskierte Daten der Gegenpartei).
direction, rail, counterparty_vasp, delivery, discovery, reason und next_actions haben dieselbe Struktur wie beim Transfer-Endpoint. reason und next_actions erläutern, warum ein Transfer mit COUNTERPARTY_VASP_NOT_FOUND oder COUNTERPARTY_VASP_NOT_REACHABLE feststeckt und was ihn weiterbringt. Für alle anderen Status sind sie "" bzw. []: siehe Warum ein Transfer feststeckt. Jede Zeile von GET /v3/transactions/ enthält denselben Block. Siehe Travel Rule.

Netzwerk-Snapshot

Der gespeicherte Graph selbst, nicht ein Verweis darauf. Er stammt aus einer der beiden Quellen:
  • einem network_snapshot, den Sie zusammen mit der Transaktion übermittelt haben, oder
  • dem Graphen, den Didit erstellt, wenn das AML-Screening für Wallets für eine Kryptotransaktion erfolgreich ist, auch wenn die Anfrage kein network_snapshot enthielt. Ein durch das Screening erstellter Graph ersetzt einen übermittelten, und ein asynchrones erneutes Screening aktualisiert ihn.
null, wenn keines von beiden vorhanden ist:
Die Transaktionsdetailseite der Konsole zeigt denselben Graphen an.

Tags, Metadaten, Props

  • tags[]: zugeordnete Tags (durch eine Regelaktion oder durch einen Analysten): { "uuid", "name", "color", "description", "source" }, wobei source didit für ein Preset-Tag und custom für eines Ihrer eigenen ist.
  • metadata: ein Snapshot der Payloads subject und counterparty, genau so, wie Sie sie beim Erstellen übermittelt haben, unter diesen beiden Schlüsseln.
  • props: die custom_properties, die Sie beim Erstellen angegeben haben. Jeder Schlüssel ist in Regelbedingungen als custom_values.<key> adressierbar.

Behebung

Wenn eine Regel AWAITING_USER auslöst, erstellt Didit die verknüpfte Verifizierungssitzung und gibt sie in zwei Feldern zurück:
  • remediation: die verknüpfte Sitzung: { "session_id", "session_token", "url", "status" }. Bleibt für die gesamte Lebensdauer der Transaktion befüllt, sodass Sie jederzeit sehen, wie die Aktion des Benutzers ausgegangen ist.
  • action_required: die Aktion, die der Benutzer jetzt ausführen muss, oder null, sobald nichts mehr aussteht: { "type": "verification_session", "url", "session_id", "session_token", "status" }. Leiten Sie den Benutzer zu url weiter oder übergeben Sie session_token an ein Didit-SDK. Travel-Rule-Aktionen zur Wallet-Inhaberschaft verwenden { "type": "wallet_ownership", "url", "widget_session_id", "expires_at" } und haben Vorrang, wenn beide zutreffen könnten. Wenn eine Aktion zur Wallet-Inhaberschaft aussteht und die Gegenpartei des Transfers nicht gefunden werden konnte, enthält derselbe Block außerdem reason und next_actions (siehe Ermittlung der Gegenpartei).
Dieselben beiden Felder werden auch in den Webhook-Payloads für transaction.created und transaction.status.updated mitgeliefert (action_required); siehe Webhooks.

Kostenaufschlüsselung

null, bis für die Transaktion eine kostenpflichtige Funktion ausgeführt wurde. Andernfalls { "total_price", "items": [ { "usage_type", "price", "details" } ] }, mit einem Eintrag pro nutzungsabhängig abgerechneter Funktion (Screening, Anreicherung usw.).

Währungsumrechnung

preferred_currency_amount ist der amount, umgerechnet in die bevorzugte Währung Ihrer Anwendung zu Mittelkursen. Wenn Sie amount_in_default_currency angegeben haben, wird stattdessen dieser bereits umgerechnete Wert unverändert verwendet. Regelbedingungen für amount vergleichen den Betrag in der Originalwährung. Verwenden Sie preferred_currency_amount in Bedingungen, wenn Sie einen einheitlichen Schwellenwert über alle Währungen hinweg benötigen.

Nächste Schritte

Transaktionen übermitteln

Vollständiges Anfrageschema.

Status

Bedeutung der einzelnen Status.

Risiko-Scoring

Wie der Score berechnet wird.
Zuletzt geändert am 7. November 2026