अवलोकन
क्लाइंट-साइड सबमिशन तीन गारंटियों पर आधारित है:- स्पूफिंग-रोधी विषय बंधन। टोकन को जारी करते समय एक
vendor_data(आपकी उपयोगकर्ता ID) तक सीमित किया जाता है। इसके साथ सबमिट किए गए हर लेन-देन की सब्जेक्ट पहचान इसी बंधन से सर्वर-साइड पर लागू होती है, इसलिए छेड़छाड़ किया गया क्लाइंट किसी दूसरे उपयोगकर्ता की ओर से सबमिट नहीं कर सकता, और payload में कभी क्रेडेंशियल भेजने की ज़रूरत नहीं पड़ती। - अपने-आप डिवाइस इंटेलिजेंस। SDK एक डिवाइस फ़िंगरप्रिंट इकट्ठा करता है और उसे सबमिशन के साथ भेजता है, और Didit IP पता व user agent सर्वर-साइड पर निकालता है। संयुक्त डिवाइस संदर्भ लेन-देन के सब्जेक्ट से अपने-आप जुड़ जाता है, बिना किसी अतिरिक्त लाइब्रेरी, अलग डिवाइस टोकन या आपकी ओर से किसी अतिरिक्त व्यवस्था के। इससे डिवाइस-आधारित नियम और सत्रों व लेन-देन के बीच डिवाइस-आधारित सहसंबंध संभव होते हैं।
- अपने-आप शुरू होने वाला वॉलेट-स्वामित्व प्रमाण। जब बनाया गया लेन-देन माँगता है कि अंतिम उपयोगकर्ता किसी वॉलेट पर नियंत्रण साबित करे, तो रिस्पॉन्स में
wallet_ownershipप्रकार काaction_requiredब्लॉक आता है और SDK उसी समय वह फ़्लो खोल देता है, फिर पूरा होने पर लेन-देन को ताज़ा करता है - आपको बार-बार जाँच करने वाले लूप या लिंक डिलीवरी खुद नहीं बनानी पड़ती। एक आवश्यकverification_sessionकार्रवाई अलग है: उसे कभी अपने-आप शुरू नहीं किया जाता, और वह उसी ब्लॉक में वापस आती है ताकि आपका ऐप उसे अपने Didit सत्यापन इंटीग्रेशन से शुरू करे।
सर्वर-साइड
POST /v3/transactions/ वह सही विकल्प बना रहता है जब कोई अंतिम उपयोगकर्ता मौजूद न हो: बैक-ऑफ़िस ट्रांसफ़र, बैच इम्पोर्ट, या आपके अपने सिस्टम द्वारा रिपोर्ट की गई घटनाएँ।
दोनों रास्ते एक ही लेन-देन रिकॉर्ड बनाते हैं, एक ही नियम चलाते हैं और एक ही webhook भेजते हैं।प्रवाह
1
लेन-देन टोकन जारी करें
आपका बैकएंड
POST /v3/transactions/sdk-token/ को आपकी API कुंजी और उपयोगकर्ता के vendor_data के साथ कॉल करता है, और लौटाया गया sdk_token आपके ऐप को देता है।2
डिवाइस से सबमिट करें
ऐप SDK पर
submitTransaction कॉल करता है, जो payload को X-Transaction-Token हेडर के साथ और अपने-आप होने वाले डिवाइस एनरिचमेंट के साथ POST /v1/transactions/ पर भेजता है।3
कोई आवश्यक कार्रवाई संभालें
यदि
action_required.type wallet_ownership है, तो SDK विजेट अपने-आप खोलता है, फिर GET /v1/transactions/{transaction_id}/ के ज़रिए लेन-देन ताज़ा करता है।
यदि यह verification_session है, तो SDK कुछ भी शुरू नहीं करता - action_required पढ़ें और उसके session_token (या वेब पर url) से अपना सत्यापन फ़्लो शुरू करें।लेन-देन टोकन जारी करना
अपने बैकएंड सेPOST /v3/transactions/sdk-token/ के ज़रिए टोकन जारी करें - /v3/ लेन-देन endpoint के बाकी हिस्सों की तरह API कुंजी प्रमाणीकरण का उपयोग करें।
camelCase उपनाम (
vendorData, ttlSeconds, maxUses) भी स्वीकार किए जाते हैं, जैसे /v3/ API के अन्य हिस्सों में।
डिवाइस से सबमिट करना
SDKX-Transaction-Token हेडर में टोकन के साथ POST /v1/transactions/ पर पोस्ट करते हैं।
वायर पेलोड camelCase में होता है; submitTransaction मेथड इसे आपके लिए बनाते हैं, इसलिए इसके साथ सीधे तभी काम करना पड़ता है जब आप अपने HTTP क्लाइंट से endpoint को कॉल करते हैं:
POST /v3/transactions/ के समतुल्य फ़ील्ड से मैप होता है:
रिस्पॉन्स वही snake_case लेन-देन विवरण है जो
/v3/ endpoints में होता है, साथ में action_required ब्लॉक:
स्व-होस्टेड वॉलेट घोषित करना
ऊपर के उदाहरण में गंतव्य को उपयोगकर्ता के अपने स्व-होस्टेड वॉलेट के रूप में घोषित किया गया है: प्रतिपक्ष काpaymentMethod.type unhosted_wallet है।
यह घोषणा बदल देती है कि Travel Rule विनिमय कैसे चलता है:
- Didit प्रतिपक्ष-VASP रूटिंग को पूरी तरह छोड़ देता है - स्व-होस्टेड वॉलेट के पीछे कोई VASP नहीं होता - और ट्रांसफ़र को सीधे
UNCONFIRMED_OWNERSHIPमें बनाता है। - जब आपकी Travel Rule सेटिंग्स में
auto_wallet_verificationचालू हो (डिफ़ॉल्ट), तो वॉलेट-स्वामित्व विजेट सत्र स्वचालित रूप से बनता है और ऊपर के रिस्पॉन्स की तरह हीaction_requiredमें लौटाया जाता है। - SDK विजेट को स्वचालित रूप से लॉन्च करता है; जैसे ही उपयोगकर्ता वॉलेट पर नियंत्रण साबित करता है, ट्रांसफ़र नाम मिलान चलाता है और
COMPLETEDपर आगे बढ़ता है, या जब नाम वॉलेट के एड्रेस बुक धारक से मेल नहीं खाता तोCOUNTERPARTY_MISMATCHED_DATAपर।
विषय प्रवर्तन
तीन चीज़ें हमेशा टोकन द्वारा तय की जाती हैं, पेलोड द्वारा नहीं:- वह एप्लिकेशन जिसके तहत लेन-देन बनाया जाता है।
- विषय की पहचान: पेलोड में
subject.externalUserIdको अनदेखा कर दिया जाता है और उसकी जगह टोकन काvendor_dataलिया जाता है। - विषय का डिवाइस संदर्भ (नीचे देखें); टकराव होने पर सर्वर से प्राप्त फ़ील्ड्स
subject.deviceमें दी गई किसी भी चीज़ पर भारी पड़ते हैं।
401 का अर्थ है कि टोकन अस्वीकार हुआ: अनुपस्थित, अज्ञात, रद्द, max_uses से अधिक उपयोग, या समय-सीमा समाप्त।
समय-सीमा समाप्त टोकन के रिस्पॉन्स में त्रुटि विवरण में हमेशा शब्द expired होता है, और इसी से SDK expired_token को invalid_token त्रुटियों से अलग पहचानते हैं।
लेन-देन वापस पढ़ना
GET /v1/transactions/{transaction_id}/ उसी X-Transaction-Token प्रमाणीकरण के साथ वही विवरण लौटाता है।
लॉन्च किए गए कार्रवाई प्रवाह के पूरा होने या उसकी विंडो बंद होने के बाद SDK इसे स्वचालित रूप से कॉल करते हैं, ताकि अंतिम स्थिति कभी किसी एक इवेंट या सूचना पर निर्भर न रहे।
टोकन वैध रहने तक किसी भी समय status और action_required दोबारा जाँचने के लिए इसे स्वयं उपयोग करें; अपने बैकएंड से, GET /v3/transactions/{transaction_id}/ वही रिकॉर्ड लौटाता है।
स्वचालित डिवाइस इंटेलिजेंस
हर सबमिशन के साथ आपकी ओर से कोई इंटीग्रेशन कार्य किए बिना डिवाइस इंटेलिजेंस भी जाती है:- SDK गोपनीयता-सुरक्षित डिवाइस फ़िंगरप्रिंट एकत्र करता है (
didit-fp-v2स्कीमा: प्लेटफ़ॉर्म और नेविगेटर सिग्नल, एक स्थायी डिवाइस id, बॉट स्कोर, और एक संयुक्त हैश) और उसे अनुरोध के साथ भेजता है। - Didit IP पता, यूज़र एजेंट और accept-language को कनेक्शन से ही सर्वर-साइड पर निकालता है, इसलिए इन्हें पेलोड से जाली नहीं बनाया जा सकता।
/v3/ लेन-देन हर प्रतिभागी के लिए स्पष्ट device_context ऑब्जेक्ट भेजते रह सकते हैं; SDK पथ पर आपको उसी डेटा का अधिक मज़बूत रूप बिना किसी अतिरिक्त प्रयास के मिलता है।
आवश्यक उपयोगकर्ता क्रियाएँ
कुछ लेन-देन तभी पूरे हो सकते हैं जब अंतिम उपयोगकर्ता पहले कोई कार्रवाई करे। कोई नियम सत्यापन सत्र माँग सकता है, या कोई Travel Rule स्थानांतरण इस बात का प्रमाण माँग सकता है कि गंतव्य वॉलेट वास्तव में उपयोगकर्ता का ही है। दोनों स्थितियाँ एक ही जगह दिखती हैं - सबमिट रिस्पॉन्स (और लेन-देन की हर बाद की रीड) केaction_required ब्लॉक में:
यदि दोनों एक ही लेन-देन पर लागू हो सकते हैं, तो
wallet_ownership को प्राथमिकता मिलती है, क्योंकि स्वामित्व प्रमाण न होने पर Travel Rule का आदान-प्रदान स्वयं रुक जाता है।
लंबित कार्रवाई हल होते ही action_required null हो जाता है।
मौजूदा remediation फ़ील्ड पिछली संगतता के लिए रखा गया है; मानक ब्लॉक action_required ही है।
ऑटो-लॉन्च अनुबंध
autoLaunchAction (डिफ़ॉल्ट true) केवल wallet_ownership कार्रवाई को ऑटो-लॉन्च करता है:
- Web - SDK के अपने ओवरले मोडल में खुलता है, और पूरा होने का पता origin-validated मैसेजिंग के साथ सीमित लेन-देन पोल से लगता है (कभी केवल एक इवेंट पर निर्भर नहीं)।
- iOS / Android (और React Native तथा Flutter रैपर, जो नेटिव SDK को सौंपते हैं) -
useNativeWalletOwnershipकेtrueहोने पर (डिफ़ॉल्ट), SDK के नेटिव वॉलेट-स्वामित्व अनुभव (SwiftUI / Jetpack Compose) के रूप में दिखता है, फिरSFSafariViewController/ Chrome Custom Tab, और अंत में डिफ़ॉल्ट ब्राउज़र पर लौटता है। प्रवाह बंद होने या ऐप के फ़ोरग्राउंड में लौटने के बाद SDK लेन-देन को अपने आप दोबारा पढ़ता है।
verification_session कार्रवाई कभी ऑटो-लॉन्च नहीं होती: यह हमेशा action_required में आती है, ताकि आपका ऐप उसे अपने Didit सत्यापन इंटीग्रेशन से शुरू करे।
SDK का अपना ऑटो-लॉन्च किया गया वॉलेट-स्वामित्व प्रवाह पूरा होने या बंद होने के बाद, वह लेन-देन को दोबारा पढ़ता है और ताज़ा परिणाम आपके onActionCompleted कॉलबैक को देता है।
verification_session कार्रवाई इस चक्र का हिस्सा नहीं है, क्योंकि उसे आपका ऐप लॉन्च करता है - अगला भाग देखें।
सत्यापन सत्र लॉन्च करना
जबaction_required.type verification_session हो, तो result.actionRequired से ब्लॉक पढ़ें और उसे अपने मौजूदा Didit सत्यापन इंटीग्रेशन को सौंपें:
GET /v1/transactions/{transaction_id}/ कॉल करें (या लेन-देन webhook का इंतज़ार करें)।
उदाहरण: उच्च-मूल्य निकासी के लिए बायोमेट्रिक अतिरिक्त जाँच
यह प्रवाह अपने सबसे अच्छे रूप में है: जोखिम भरे लेन-देन - बड़ी राशि, नए लाभार्थी, नए डिवाइस - को उसी व्यक्ति की बायोमेट्रिक पुनः जाँच के पीछे रखें, जिसे आपने ऑनबोर्डिंग के समय सत्यापित किया था। अकाउंट टेकओवर ठीक ऐसा ही दिखता है: सही पासवर्ड, सही 2FA कोड (फ़िशिंग या SIM स्वैप से प्राप्त), और ऐसे वॉलेट पर निकासी जिसे आपने पहले कभी नहीं देखा। उस बिंदु तक हर क्रेडेंशियल-आधारित बचाव विफल हो चुका होता है। चेहरे पर आधारित सुरक्षा अब भी विफल नहीं हुई है: हमलावर लाइवनेस-जाँची गई सेल्फ़ी पास नहीं कर सकता, जिसे वैध मालिक के KYC ऑनबोर्डिंग में लिए गए चेहरे से मेल खाना होगा।1
नियम एक बार कंसोल में बनाएँ
Transactions → Rules → Create Rule: शर्त
amount gte 5000, कार्रवाई Change status → AWAITING_USER, और कार्रवाई पर अपना बायोमेट्रिक प्रमाणीकरण वर्कफ़्लो चुनें।
चाहें तो अन्य जोखिम शर्तें जोड़ें - पहली बार का प्रतिपक्ष, नया डिवाइस फ़िंगरप्रिंट, IP देश में बदलाव - अतिरिक्त शर्तों या अतिरिक्त नियमों के रूप में।2
निकासी हमेशा की तरह सबमिट करें
आपके सबमिशन कोड में कोई बदलाव नहीं होता। जब नियम लागू होता है, तो रिस्पॉन्स
status: "AWAITING_USER" और verification_session प्रकार का action_required ब्लॉक लेकर आता है:3
पुनः जाँच लॉन्च करें
session_token (या url) को अपने मौजूदा Didit सत्यापन इंटीग्रेशन को सौंपें, ठीक वैसे ही जैसा सत्यापन सत्र लॉन्च करना में है।
चूँकि सत्र उसी vendor_data के लिए बनता है जो लेन-देन का विषय है, Didit के पास ऑनबोर्डिंग से उपयोगकर्ता का सत्यापित संदर्भ चेहरा पहले से है - स्वीकृत लाइवनेस सेल्फ़ी, पासपोर्ट चिप फ़ोटो, या दस्तावेज़ का पोर्ट्रेट।
उपयोगकर्ता एक लाइव सेल्फ़ी लेता है; Didit उस संग्रहीत संदर्भ के विरुद्ध लाइवनेस और 1:1 चेहरा मिलान चलाता है। दस्तावेज़ दोबारा स्कैन नहीं होता, कोई दोबारा ऑनबोर्डिंग नहीं होती - केवल उन लेन-देन पर कुछ सेकंड की असुविधा, जो इसके हकदार हैं।4
परिणाम के अनुसार निपटारा करें
सत्र पूरा होने पर लेन-देन अपने आप दोबारा मूल्यांकित होता है: पुनः जाँच पास होने पर
APPROVED, विफल होने पर DECLINED, और दोनों स्थितियों में transaction.status.updated webhook भेजा जाता है (लेन-देन की टाइमलाइन में reason: remediation_completed)।
आपका ऐप परिणाम onActionCompleted जैसे कॉलबैक, GET /v1/transactions/{transaction_id}/, या webhook के ज़रिए पाता है।वेब SDK
submitTransaction अभी Web SDK singleton पर उपलब्ध है:
{ transactionId, status, travelRuleStatus?, actionRequired? } के रूप में आता है।
SDK-स्तर के payload में आप category, details और customProperties लिखते हैं; SDK इन्हें wire aliases (type, info, props) पर अपने आप मैप कर देता है।
त्रुटियाँ DiditTransactionError के ज़रिए टाइप की जाती हैं:
नेटिव SDK
नेटिव
submitTransaction API iOS और Android SDK 4.1.0 के साथ आता है (और React Native तथा Flutter के वे रिलीज़ भी, जो इसे पिन करते हैं)।
Web SDK के विपरीत, नेटिव payloads सीधे wire फ़ील्ड नामों का उपयोग करते हैं: type, info और props।getTransaction(transactionToken, transactionId) भी उपलब्ध कराता है, ताकि उसी token से लेन-देन दोबारा पढ़ा जा सके। लॉन्च किए गए कार्रवाई फ़्लो के बाद SDK इसे अपने आप कॉल करते हैं, और आप इसे किसी भी समय खुद कॉल कर सकते हैं।
मोबाइल पर डिवाइस फ़िंगरप्रिंट ट्रांसपोर्ट पहले से ही सभी SDK नेटवर्क कॉल पर लागू होता है, इसलिए लेन-देन सबमिशन अपने आप वही डिवाइस इंटेलिजेंस साथ ले जाते हैं।
SDK के बिना
SDK जो कुछ करते हैं, वह सब सामान्य HTTPS है, इसलिए यहाँ किसी भी चीज़ के लिए SDK ज़रूरी नहीं है। दो समतुल्य इंटीग्रेशन तरीके हैं: केवल सर्वर-साइड (बिल्कुल कोई token नहीं)। अपनी API कुंजी के साथ अपने बैकएंड सेPOST /v3/transactions/ से सबमिट करें। रिस्पॉन्स (और हर बाद की GET /v3/transactions/{transaction_id}/) वही action_required ब्लॉक लेकर आता है। आप हर प्रतिभागी के लिए स्पष्ट device संदर्भ भी पास कर सकते हैं, क्योंकि आपके लिए उसे इकट्ठा करने वाला कोई SDK नहीं है।
क्लाइंट-साइड, अपने HTTP स्टैक के साथ। POST /v3/transactions/sdk-token/ से token बनाएँ, फिर डिवाइस से X-Transaction-Token हेडर के साथ POST /v1/transactions/ और GET /v1/transactions/{transaction_id}/ कॉल करें। वही subject binding और सर्वर-साइड IP/user-agent व्युत्पत्ति लागू होती है।
इसके बाद action_required को स्वयं संभालें:
और बिना किसी client callback के पूरा होने का पता लगाएँ:
- Webhooks (अनुशंसित)। जब लंबित कार्रवाई लेन-देन को हल करती है तो
transaction.status.updatedफ़ायर होता है, और हर exchange ट्रांज़िशन परtravel_rule.status.updatedफ़ायर होता है। दोनों में इतनी जानकारी होती है कि बिना पोलिंग के आप अपने रिकॉर्ड अपडेट कर सकें। - Polling। लेन-देन को दोबारा पढ़ें (आपके बैकएंड से
/v3/के ज़रिए, या token मान्य रहने तक token के साथ/v1/के ज़रिए): हल हो जाने परaction_requiredवापसnullहो जाता है, औरstatus/travel_rule.statusपरिणाम दिखाते हैं।
Webhooks
आपके बैकएंड को रिपोर्ट करने के लिए ऐप की ज़रूरत नहीं है। जब सबमिट किया गया लेन-देन उपयोगकर्ता की कार्रवाई माँगता है, तो लेन-देन webhook -transaction.created या transaction.status.updated - वही action_required ब्लॉक शामिल करता है, ताकि आपके सिस्टम को लंबित कार्रवाई की जानकारी रहे, भले ही फ़्लो पूरा होने से पहले ऐप बंद हो जाए।
verification_session कार्रवाई के साथ AWAITING_USER स्टेटस आता है, लेकिन wallet_ownership कार्रवाई अपने आप लेन-देन का स्टेटस नहीं बदलती, इसलिए स्टेटस के बजाय action_required पढ़ें।
Travel Rule ट्रांज़िशन अतिरिक्त रूप से travel_rule.status.updated भी भेजते हैं।
अगले कदम
लेन-देन सबमिट करना
सर्वर-साइड Create Transaction API और payload का पूरा संदर्भ।
Travel Rule
प्रबंधित प्रेषक-लाभार्थी आदान-प्रदान, सेटिंग्स और जीवनचक्र।
वॉलेट स्वामित्व विजेट
wallet_ownership कार्रवाइयों के पीछे का होस्टेड नियंत्रण-प्रमाण फ़्लो।
Webhooks
transaction.created, transaction.status.updated और हस्ताक्षर सत्यापन।
नियम
नियम कार्रवाइयाँ, जिनमें सत्यापन सत्र बनाने वाली कार्रवाइयाँ भी शामिल हैं।
स्टेटस
लेन-देन जीवनचक्र में AWAITING_USER का अर्थ।