लेन-देन सबमिट API: Payload और डेटा मॉडल

आप Create Transaction API के माध्यम से Didit को लेन-देन भेजें। हर लेन-देन में संरचित पक्ष, भुगतान और संदर्भ डेटा होता है, जिसका नियम इंजन रीयल टाइम में मूल्यांकन करता है।

जब लेन-देन किसी अंतिम उपयोगकर्ता के डिवाइस पर शुरू होता है, जैसे क्रिप्टो निकासी या इन-ऐप भुगतान, तो SDK लेन-देन सबमिशन पर विचार करें। इसमें API कुंजी की जगह एक सीमित टोकन उपयोग होता है, डिवाइस इंटेलिजेंस अपने-आप एकत्र होता है, और आवश्यक उपयोगकर्ता कार्रवाइयाँ (वॉलेट स्वामित्व प्रमाण, स्टेप-अप सत्यापन) तुरंत शुरू हो जाती हैं।

लेन-देन श्रेणियाँ

हर लेन-देन में एक transaction_category होता है, जो तय करता है कि नियम और एनालिटिक्स उसके साथ कैसा व्यवहार करेंगे:

श्रेणी	विवरण
`finance`	मानक वित्तीय लेन-देन (जमा, निकासी, स्थानांतरण)
`kyc`	पहचान सत्यापन से जुड़ी घटना
`travel_rule`	वर्चुअल एसेट स्थानांतरण जिसके लिए Travel Rule अनुपालन आवश्यक है
`user_event`	कस्टम प्लेटफ़ॉर्म घटना (लॉगिन, प्रोफ़ाइल बदलाव, आदि)
`gambling_bet`	जुए की बाज़ी या शर्त लगाना
`gambling_limit_change`	खिलाड़ी की जमा, हानि या बाज़ी सीमा में बदलाव
`gambling_bonus_change`	बोनस प्रदान करना, भुनाना या ज़ब्त करना
`audit_trail_event`	सिस्टम या अनुपालन ऑडिट घटना

लेन-देन विवरण

transaction_details ऑब्जेक्ट वित्तीय डेटा रखता है:

फ़ील्ड	प्रकार	विवरण
`direction`	string	`inbound` या `outbound`
`amount`	string	दशमलव स्ट्रिंग के रूप में लेन-देन मूल्य (उदाहरण: `"1500.50"`)
`currency`	string	ISO मुद्रा कोड (उदाहरण: `USD`, `EUR`, `BTC`)
`currency_kind`	string	`fiat` या `crypto` (उपनाम `currencyType`); यह तय करता है कि क्रिप्टो स्क्रीनिंग शुरू होगी या नहीं
`action_type`	string	विक्रेता द्वारा परिभाषित कार्रवाई लेबल (उदाहरण: `deposit`, `withdrawal`, `purchase`)
`payment_details`	string	भुगतान का मुक्त-पाठ विवरण (उदाहरण: `"Bank transfer from ABC Corp"`)
`payment_reference_id`	string	बाहरी भुगतान संदर्भ पहचानकर्ता। स्थानांतरण के बाद की क्रिप्टो स्क्रीनिंग के लिए ब्लॉकचेन लेन-देन हैश का उपयोग करें।

विषय और प्रतिपक्ष

हर लेन-देन में एक विषय (अनिवार्य) और एक वैकल्पिक प्रतिपक्ष होता है। दोनों एक ही पक्ष मॉडल का उपयोग करते हैं:

फ़ील्ड	प्रकार	विवरण
`entity_type`	string	`person` या `company`
`vendor_data`	string	इस पक्ष के लिए आपका पहचानकर्ता, जो लेन-देन को एक उपयोगकर्ता या व्यवसाय प्रोफ़ाइल से जोड़ता है
`full_name`	string	पक्ष का पूरा नाम
`first_name`	string	पहला नाम
`last_name`	string	अंतिम नाम
`date_of_birth`	string	ISO तिथि (उदाहरण: `1990-01-15`)
`country_code`	string	ISO 3166-1 alpha-2 देश कोड
`address`	object या string	`street`, `city`, `state`, `country`, `postal_code` वाला संरचित पता। साधारण स्ट्रिंग भी स्वीकार होती है, जैसे क्रिप्टो प्रतिपक्ष के लिए वॉलेट पता। Didit उसे पक्ष पर बिना बदले सहेजता है।

जब address ऑब्जेक्ट होता है, तब Didit पक्ष का country_code, address.country से निकालता है। जब address स्ट्रिंग होता है, तब उस पक्ष का country_code null वापस आता है। जब vendor_data किसी मौजूदा उपयोगकर्ता या व्यवसाय से मेल खाता है, तब Didit लेन-देन को उस इकाई की प्रोफ़ाइल से अपने-आप जोड़ देता है, जिससे सत्रों के पार नियम मूल्यांकन और वेलोसिटी जाँच संभव होती है। रिस्पॉन्स में दोनों पक्ष parties ऐरे में APPLICANT और COUNTERPARTY भूमिकाओं के साथ वापस आते हैं।

भुगतान विधियाँ

हर पक्ष से जुड़े भुगतान साधन का वर्णन करने के लिए payment_method जोड़ें:

फ़ील्ड	प्रकार	विवरण
`method_type`	string	`bank_card`, `bank_account`, `e_wallet`, `crypto_wallet`, `unhosted_wallet`, या `other` (उपनाम `type`); `ewallet`, `card` और `crypto` भी स्वीकार होते हैं, और कोई अपरिचित मान `other` के रूप में सहेजा जाता है
`account_id`	string	खाता संख्या, वॉलेट पता, या कार्ड टोकन
`issuing_country`	string	वह देश जिसने भुगतान साधन जारी किया

travelRule लेन-देन पर, method_type: "unhosted_wallet" (उपनाम type) वाली प्रतिपक्ष भुगतान विधि घोषित करती है कि प्रतिपक्ष का वॉलेट स्व-होस्टेड है। जब Travel Rule सक्षम हो और आपके एप्लिकेशन की डिफ़ॉल्ट मुद्रा में राशि threshold_amount से कम न हो, तब स्थानांतरण सीधे UNCONFIRMED_OWNERSHIP पर जाता है और स्वामित्व-प्रमाण प्रवाह शुरू होता है। देखें घोषित स्व-होस्टेड वॉलेट। क्रिप्टो लेन-देन के लिए, वॉलेट पते account_id में डालें और currency_kind को crypto पर सेट करें, ताकि ब्लॉकचेन स्क्रीनिंग अपने-आप चल सके। दिशा तय करती है कि कौन-सा वॉलेट स्क्रीन होगा: inbound की प्री-ट्रांसफ़र स्क्रीनिंग counterparty.payment_method.account_id में मौजूद भेजने वाले वॉलेट का उपयोग करती है; outbound स्क्रीनिंग counterparty.payment_method.account_id में मौजूद गंतव्य वॉलेट का उपयोग करती है। यदि आप transaction_details.payment_reference_id में ब्लॉकचेन हैश भेजते हैं, तो inbound लेन-देन स्क्रीनिंग के लिए subject.payment_method.account_id में आपका सर्विस डिपॉज़िट पता आवश्यक है, जबकि outbound लेन-देन स्क्रीनिंग के लिए counterparty.payment_method.account_id में गंतव्य वॉलेट आवश्यक है।

क्रिप्टो स्क्रीनिंग ओवरराइड

अनुरोध के शीर्ष स्तर पर include_crypto_screening का उपयोग करें, ताकि कंसोल में Transactions > Settings में सेट डिफ़ॉल्ट को बदला जा सके:

मान	विवरण
`true`	इस लेन-देन के लिए क्रिप्टो स्क्रीनिंग अनिवार्य रूप से चलाएँ
`false`	इस लेन-देन के लिए क्रिप्टो स्क्रीनिंग छोड़ें
अनुपस्थित या `null`	एप्लिकेशन-स्तरीय डिफ़ॉल्ट का उपयोग करें

डिवाइस संदर्भ

डिवाइस इंटेलिजेंस नियमों को सक्रिय करने के लिए विषय (और वैकल्पिक रूप से प्रतिपक्ष) पक्ष पर डिवाइस की जानकारी शामिल करें। प्रत्येक पार्टी का अनुरोध फ़ील्ड device_context है। camelCase उपनाम device भी स्वीकार होता है, और SDK का वायर फ़ॉर्मैट यही उपयोग करता है। रिस्पॉन्स इसे parties ऐरे में प्रत्येक पार्टी के लिए device के रूप में लौटाता है।

फ़ील्ड	प्रकार	विवरण
`device_context.fingerprint`	string	अनोखा डिवाइस फ़िंगरप्रिंट
`device_context.persistent_device_id`	string	स्थिर, सत्रों के पार चलने वाला डिवाइस पहचानकर्ता (v2 फ़िंगरप्रिंट स्कीमा)
`device_context.user_agent`	string	ब्राउज़र या ऐप का user agent स्ट्रिंग
`device_context.browser_family`	string	ब्राउज़र परिवार (जैसे `Chrome`, `Firefox`, `Safari`)। स्पष्ट रूप से भेजना आवश्यक है। यह `user_agent` से नहीं निकाला जाता। `subject_browser_family` जैसे नियमों को शक्ति देता है।
`device_context.browser_version`	string	ब्राउज़र संस्करण स्ट्रिंग (जैसे `131.0`)। स्पष्ट रूप से भेजना आवश्यक है।
`device_context.platform`	string	प्लेटफ़ॉर्म पहचानकर्ता (`web`, `ios`, `android`, `macos`, `windows`, `linux`)। स्पष्ट रूप से भेजना आवश्यक है। यह `user_agent` से नहीं निकाला जाता। `subject_platform` जैसे नियमों को शक्ति देता है।
`device_context.os_family`	string	ऑपरेटिंग सिस्टम परिवार (जैसे `iOS`, `Android`, `Windows`)
`device_context.os_version`	string	ऑपरेटिंग सिस्टम संस्करण स्ट्रिंग
`device_context.accept_language`	string	Accept-Language हेडर का मान (जैसे `en-US,en;q=0.9`)। SDK के माध्यम से यह अपने आप एकत्र होता है।
`device_context.session_id`	string	उपयोगकर्ता के मौजूदा सत्र का सत्र पहचानकर्ता। मेटाडेटा में संग्रहीत। CamelCase उपनाम: `sessionId`।
`device_context.session_age_ms`	number	लेन-देन के समय उपयोगकर्ता के सत्र की आयु मिलीसेकंड में। `subject_session_age_ms` जैसे नियमों को शक्ति देता है।
`device_context.network_context.ip_address`	string	क्लाइंट IP पता
`device_context.network_context.ip_country_code`	string	IP से जियो-रिज़ॉल्व किया गया देश (ISO 3166-1 alpha-3)
`device_context.network_context.latitude`	number	IP का भौगोलिक अक्षांश
`device_context.network_context.longitude`	number	IP का भौगोलिक देशांतर

browser_family और platform को user_agent से नहीं निकाला जाता। device intelligence नियमों के सक्रिय होने के लिए इन्हें device_context के भीतर स्पष्ट टॉप-लेवल कुंजियों के रूप में भेजना होगा। यदि आप Didit SDK का उपयोग करते हैं, तो ये फ़ील्ड अपने आप एकत्र हो जाते हैं।

हर फ़ील्ड के लिए CamelCase उपनाम स्वीकार होते हैं: userAgent, browserFamily, browserVersion, osFamily, osVersion, acceptLang, sessionId, sessionAgeMs। network_context सब-ऑब्जेक्ट ip / countryCode3 / lat / lon उपनाम स्वीकार करता है, और टॉप-लेवल ipInfo ब्लॉक भी network_context में जोड़ दिया जाता है। डिवाइस संदर्भ से ऐसे नियम सक्रिय होते हैं जैसे कई-खाते का पता लगाना (अलग-अलग विषयों में एक ही फ़िंगरप्रिंट), नए ब्राउज़र और नए IP का संयोजन पहचानना, कम सत्र आयु पर उच्च-मूल्य का ट्रांसफ़र, और स्थान-आधारित जोखिम स्कोरिंग।

कस्टम गुण

custom_properties ऑब्जेक्ट में कोई भी अतिरिक्त कुंजी-मान युग्म जोड़ें। नियम अपनी शर्तों में इन फ़ील्ड का संदर्भ दे सकते हैं। यह व्यवसाय-विशिष्ट संदर्भ पास करने के लिए उपयोगी है, जैसे उत्पाद श्रेणी, मर्चेंट ID या चैनल।

"custom_properties": {
  "product_category": "electronics",
  "merchant_id": "MER456",
  "channel": "mobile_app"
}

नियम की शर्तों में हर कुंजी का संदर्भ फ़ील्ड पाथ custom_values.<key> से दें। उदाहरण के लिए, ऊपर दिया गया payload custom_values.product_category eq "electronics" से मेल खाता है। Console के नियम बिल्डर में, हाल में आए लेन-देन की कुंजियाँ शर्त फ़ील्ड चयनकर्ता में कस्टम गुण के अंतर्गत दिखती हैं। उसी ग्रुप में कस्टम प्रॉपर्टी दर्ज करें से आप कोई भी कुंजी मैन्युअल रूप से टाइप कर सकते हैं (केस-सेंसिटिव)। विवरण के लिए नियम और स्कोरिंग देखें।

उदाहरण अनुरोध

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "TXN-20260410-001",
    "transaction_at": "2026-04-10T15:30:00Z",
    "transaction_category": "finance",
    "transaction_details": {
      "direction": "outbound",
      "amount": "1500.50",
      "currency": "EUR",
      "currency_kind": "fiat",
      "action_type": "withdrawal"
    },
    "subject": {
      "entity_type": "person",
      "vendor_data": "user-123",
      "full_name": "John Doe",
      "country_code": "US",
      "payment_method": {
        "method_type": "bank_account",
        "account_id": "DE89370400440532013000",
        "issuing_country": "DE"
      }
    },
    "counterparty": {
      "entity_type": "company",
      "full_name": "John Doe",
      "country_code": "GB"
    },
    "custom_properties": {
      "order_id": "ORD-7891"
    }
  }'

रिस्पॉन्स

API बनाया गया लेन-देन उसके प्रारंभिक मूल्यांकन परिणामों के साथ लौटाता है:

फ़ील्ड	प्रकार	विवरण
`uuid`	string	Didit का अनोखा लेन-देन पहचानकर्ता
`txn_id`	string	आपके द्वारा दिया गया लेन-देन ID
`status`	string	`APPROVED`, `IN_REVIEW`, `DECLINED`, या `AWAITING_USER`
`score`	number	मेल खाने वाले सभी नियमों से बना संचयी जोखिम स्कोर
`severity`	string	मेल खाने वाले नियमों की उच्चतम गंभीरता (`LOW`, `MEDIUM`, `HIGH`, `CRITICAL`)
`decision_reason_code`	string	स्थिति निर्णय का मशीन-पठनीय कारण
`decision_reason_label`	string	निर्णय का मानव-पठनीय विवरण

पूरे अनुरोध और रिस्पॉन्स स्कीमा के लिए API संदर्भ देखें, और एनोटेटेड payload के चरण-दर-चरण विवरण के लिए समर्पित रिस्पॉन्स स्कीमा संदर्भ देखें।

किसी समीक्षक को लेन-देन असाइन करें

होल्ड पर रखे गए लेन-देन को अपने एप्लिकेशन के किसी सदस्य को असाइन करें, या असाइनमेंट हटाएँ। इसके लिए write:transactions अनुमति वाली API कुंजी का उपयोग करें। हर बदलाव लेन-देन की टाइमलाइन पर TRANSACTION_ASSIGNED के रूप में दर्ज होता है।

कॉल	उपयोग
`POST /v3/transactions/{transaction_uuid}/assign/`	एक लेन-देन असाइन करें।
`POST /v3/transactions/assign/`	एक सदस्य को अधिकतम 500 लेन-देन असाइन करें।

दोनों कॉल assignee_email लेते हैं, यानी उस एप्लिकेशन सदस्य का ईमेल जिसने Didit में साइन इन किया हो। असाइनमेंट हटाने के लिए null या खाली स्ट्रिंग भेजें। बल्क कॉल transaction_ids भी लेती है, जो 1 से 500 लेन-देन UUID की सूची है।

curl -X POST "https://verification.didit.me/v3/transactions/assign/" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"transaction_ids": ["<transaction-uuid>"], "assignee_email": "analyst@example.com"}'

सिंगल कॉल uuid, transaction_number, assignee और changed लौटाती है (false तब होता है जब लेन-देन को पहले से यही व्यक्ति असाइन था)। अगर लेन-देन एप्लिकेशन में मौजूद न हो, तो 404 लौटता है। बल्क कॉल transactions (ऊपर जैसी एक-एक प्रविष्टि), updated_count और not_found_transaction_ids लौटाती है। लेन-देन सूची को assignee से फ़िल्टर करें। यह कॉमा से अलग की गई सूची है, जिसमें कोई भी मान निम्न में से किसी एक से मेल खाता है: me, unassigned, rules (केवल नियमों द्वारा तय, जिसमें कोई समीक्षक शामिल नहीं), या किसी सदस्य का ईमेल।

आइडेम्पोटेंसी

txn_id (आपका भेजा गया transaction_id) हर एप्लिकेशन के लिए अद्वितीय होता है। पहले से मौजूद transaction_id को दोबारा सबमिट करने पर transaction_id फ़ील्ड पर A transaction with this transaction_id already exists. संदेश के साथ 400 लौटता है, और दो एक-जैसे अनुरोध एक साथ आने पर दूसरे अनुरोध को 409 मिलता है। दोनों में से कोई भी रिस्पॉन्स मौजूदा लेन-देन नहीं लौटाता। सुरक्षित रूप से पुनः प्रयास करने के लिए, किसी डुप्लिकेट transaction_id के लिए 400 या 409 को “पहले से बनाया गया” मानें और दोबारा सबमिट करने के बजाय मौजूदा लेन-देन खोजें: पहले रिस्पॉन्स के uuid का उपयोग करके GET /v3/transactions/{uuid}/ से उसे पढ़ें, या transaction.created webhook में आपके txn_id के साथ आने वाला transaction_id (Didit uuid) इस्तेमाल करें। हमेशा txn_id अपनी ओर से जनरेट करें (उदाहरण के लिए, आपका अपना लेन-देन DB ID, UUID, या डिटरमिनिस्टिक हैश)।

ऐतिहासिक बैकफ़िल

ऐतिहासिक लेन-देन इनजेस्ट करने के लिए अतीत की तारीख वाला txn_date पास करें। डिफ़ॉल्ट रूप से नियम अब भी मूल्यांकित होते हैं। यदि बल्क ऐतिहासिक लोड के दौरान नियम मूल्यांकन छोड़ना चाहते हैं, तो ड्राई-इंजेस्ट मोड के साथ कंसोल CSV इंपोर्ट का उपयोग करें। देखें इंटीग्रेशन गाइड।

अगले चरण

नियम और स्कोरिंग

सबमिट किए गए लेन-देन नियमों के विरुद्ध कैसे मूल्यांकित होते हैं।

रिस्पॉन्स स्कीमा

पूरा एनोटेटेड रिस्पॉन्स payload।

क्रिप्टो स्क्रीनिंग

क्रिप्टो लेन-देन के लिए स्वचालित वॉलेट और लेन-देन स्क्रीनिंग।

Travel Rule

वर्चुअल एसेट ट्रांसफ़र में Travel Rule अनुपालन डेटा जोड़ें।

IP एन्रिचमेंट

IP से प्राप्त संदर्भ जो नियमों के लिए उपलब्ध है।

API संदर्भ

Create Transaction endpoint के लिए पूरी अनुरोध स्कीमा।

शुरुआत करें

सुविधाएँ

संदर्भ

कंसोल

लेन-देन सबमिट API: Payload और डेटा मॉडल

लेन-देन श्रेणियाँ

लेन-देन विवरण

विषय और प्रतिपक्ष

भुगतान विधियाँ

क्रिप्टो स्क्रीनिंग ओवरराइड

डिवाइस संदर्भ

कस्टम गुण

उदाहरण अनुरोध

रिस्पॉन्स

किसी समीक्षक को लेन-देन असाइन करें

आइडेम्पोटेंसी

ऐतिहासिक बैकफ़िल

अगले चरण

नियम और स्कोरिंग

रिस्पॉन्स स्कीमा

क्रिप्टो स्क्रीनिंग

Travel Rule

IP एन्रिचमेंट

API संदर्भ

​लेन-देन श्रेणियाँ

​लेन-देन विवरण

​विषय और प्रतिपक्ष

​भुगतान विधियाँ

​क्रिप्टो स्क्रीनिंग ओवरराइड

​डिवाइस संदर्भ

​कस्टम गुण

​उदाहरण अनुरोध

​रिस्पॉन्स

​किसी समीक्षक को लेन-देन असाइन करें

​आइडेम्पोटेंसी

​ऐतिहासिक बैकफ़िल

​अगले चरण

नियम और स्कोरिंग

रिस्पॉन्स स्कीमा

क्रिप्टो स्क्रीनिंग

Travel Rule

IP एन्रिचमेंट

API संदर्भ

लेन-देन श्रेणियाँ

लेन-देन विवरण

विषय और प्रतिपक्ष

भुगतान विधियाँ

क्रिप्टो स्क्रीनिंग ओवरराइड

डिवाइस संदर्भ

कस्टम गुण

उदाहरण अनुरोध

रिस्पॉन्स

किसी समीक्षक को लेन-देन असाइन करें

आइडेम्पोटेंसी

ऐतिहासिक बैकफ़िल

अगले चरण