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
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.amountist eine Dezimalzeichenkette ohne nachgestellte Nullen ("1500","0.5") mit bis zu 18 Dezimalstellen.currency_type:fiatodercrypto, wie incurrency_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ürcurrencykein Wechselkurs verfügbar ist und Sie keinamount_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 mitAPPROVEDangelegt; 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,CRITICALodernull, 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:liveodersandbox, abhängig von der Anwendung, zu der die Transaktion gehört. Einesandbox-Transaktion wird gespeichert, aber nie ausgewertet. Ihr leeresrule_runsbedeutet deshalb „nicht ausgewertet“ und nicht „keine Regel hat gegriffen“. Siehe Transaktionsüberwachung in der Sandbox.source:LIVEfür Transaktionen, die über die API oder das SDK übermittelt wurden,IMPORTEDfür Transaktionen, die über den CSV-Import in der Konsole geladen wurden.
Beteiligte
Jede beteiligte Partei einer Transaktion ist ein Eintrag inparties. 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:USERoderBUSINESS, wenn die Partei übervendor_datamit einem Didit-Benutzer oder einem Didit-Unternehmen verknüpft ist; andernfallsEXTERNAL.country_code/dob: aus dem übermitteltenaddress.countrybzw.date_of_birth.address/institution_info: die Objekte wie übermittelt;{}, wenn sie nicht angegeben wurden.external_party_snapshot: eingefrorene Kopie der Parteidaten fürEXTERNAL-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 vergibtSOURCEundDESTINATIONanhand vondirection: Bei einer ausgehenden Transaktion ist die Zahlungsmethode des SubjektsSOURCEund die der GegenparteiDESTINATION; bei einer eingehenden Transaktion ist es umgekehrt.payment_method_type:bank_card,bank_account,e_wallet,crypto_wallet,unhosted_wallet,other.fingerprint: SHA-256 übertype:account_id:issuing_country. Der Wert bleibt über alle Transaktionen hinweg stabil, damit Sie die Wiederverwendung desselben Zahlungsinstruments korrelieren können.null, wenn keineaccount_idübermittelt wurde.owner_kind/vendor_data/owner_name: Eigentümer des Instruments, nach derselben KonventionUSER/BUSINESS/EXTERNALwie bei Beteiligten.details: das ursprünglichepayment_method-Objekt, wie übermittelt.
Regelausführungen
rule: UUID der ausgeführten Regel;rule_title,rule_descriptionundrule_categorywerden aus ihr übernommen.matched: Ein Lauf wird nur aufgezeichnet, wenn die Bedingungen der Regel erfüllt waren. Live-Auswertungen tragen deshalb immermatched: true. Regeln, die ausgewertet wurden, ohne zu greifen, hinterlassen keinen Eintrag. Demodaten können Zeilen mitmatched: falseenthalten.is_test/mode:trueundTEST, wenn die Regel im Testmodus lief. Ein Testlauf wird aufgezeichnet, hat aber keine Auswirkung aufstatus,scoreoderseverity.score_delta/status_target/severity: was dieser Lauf beigetragen hat.status_targetwird gesetzt, wenn eine Aktionchange_statusausgefü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_matchsowieconditions[]undaggregations[]. Die beiden Listen verwenden unterschiedliche Wertschlüssel:conditions[]: ein Eintrag pro Bedingung mitfield,operator,expected_value, demcurrent_value, der aus der Transaktion gelesen wurde,matched,group_indexundgroup_logic.field_sourceist bei Regelausführungen für Transaktionen immernull; es wird nur für Monitoring-Ereignisse klassifiziert.aggregations[]: ein Eintrag pro Velocity-, Zähl- oder Summenaggregation mitmetric,field,operator,expected_value, demcomputed_value, zu dem die Aggregation ausgewertet wurde,window,filters,matchedundsample_references. Aggregationen, die nur asynchron berechnet werden konnten, tragencomputed_value: nullunddeferred: 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.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.
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_snapshotenthielt. Ein durch das Screening erstellter Graph ersetzt einen übermittelten, und ein asynchrones erneutes Screening aktualisiert ihn.
null, wenn keines von beiden vorhanden ist:
Tags, Metadaten, Props
tags[]: zugeordnete Tags (durch eine Regelaktion oder durch einen Analysten):{ "uuid", "name", "color", "description", "source" }, wobeisourcediditfür ein Preset-Tag undcustomfür eines Ihrer eigenen ist.metadata: ein Snapshot der Payloadssubjectundcounterparty, genau so, wie Sie sie beim Erstellen übermittelt haben, unter diesen beiden Schlüsseln.props: diecustom_properties, die Sie beim Erstellen angegeben haben. Jeder Schlüssel ist in Regelbedingungen alscustom_values.<key>adressierbar.
Behebung
Wenn eine RegelAWAITING_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, odernull, sobald nichts mehr aussteht:{ "type": "verification_session", "url", "session_id", "session_token", "status" }. Leiten Sie den Benutzer zuurlweiter oder übergeben Siesession_tokenan 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ßerdemreasonundnext_actions(siehe Ermittlung der Gegenpartei).
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.