मुख्य सामग्री पर जाएं
वॉलेट-स्वामित्व विजेट एक होस्टेड पेज है जो प्रमाणित करता है कि आपका कोई ग्राहक किसी विशिष्ट क्रिप्टो वॉलेट पते को नियंत्रित करता है। EU TFR के तहत, किसी VASP को स्व-होस्टेड (अनहोस्टेड) वॉलेट में या उससे सनराइज़ थ्रेशोल्ड से अधिक राशि के फ़ंड जारी करने से पहले उस वॉलेट के स्वामित्व को सत्यापित करना होता है। यह विजेट वही प्रमाण एकत्र करने का तरीका है, जिससे आपको खुद साइनिंग फ़्लो बनाने की ज़रूरत नहीं पड़ती। सत्यापित प्रमाण मिलने पर संबंधित वॉलेट पता बुक प्रविष्टि को is_ownership_verified: true के रूप में चिह्नित किया जाता है, जिससे जुड़ा हुआ Travel Rule ट्रांसफ़र UNCONFIRMED_OWNERSHIP से आगे बढ़ सकता है।

जब Didit इसे आपके लिए मिंट करता है

आपको शायद ही कभी खुद सत्र मिंट करना पड़ता है। जब आपकी Travel Rule सेटिंग्स में auto_wallet_verification चालू हो (जो डिफ़ॉल्ट है), तो Didit लेन-देन बनाते समय, जब भी किसी ट्रांसफ़र को अंतिम उपयोगकर्ता के वॉलेट नियंत्रण के प्रमाण की ज़रूरत हो, अपने-आप एक विजेट सत्र मिंट कर देता है:
  • ट्रांसफ़र UNCONFIRMED_OWNERSHIP में है - सबमिशन के समय प्रतिपक्ष वॉलेट को स्व-होस्टेड घोषित किया गया था।
  • ट्रांसफ़र आउटबाउंड है और COUNTERPARTY_VASP_NOT_FOUND में है - कोई प्रतिपक्ष VASP पहचाना नहीं जा सका, इसलिए पूरा होने का बचा हुआ तरीका स्वामित्व प्रमाण ही है।
अपने-आप मिंट किया गया सत्र लेन-देन के action_required ब्लॉक में लौटाया जाता है (type: "wallet_ownership", खोलने के लिए url के साथ), और SDK क्लाइंट-साइड सबमिशन पर उसे अपने-आप लॉन्च कर देते हैं। Didit द्वारा आपके लिए बनाए गए इनबाउंड ट्रांसफ़र (सनराइज़ रजिस्ट्रेशन, इनबाउंड TRP पूछताछ, या INTERNAL रेल का इनबाउंड हिस्सा) को कभी भी अपने-आप मिंट किया गया सत्र नहीं मिलता, भले ही वे UNCONFIRMED_OWNERSHIP में आ जाएँ। जब आप किसी वॉलेट को किसी ट्रांसफ़र के मौजूद होने से पहले पूर्व-सत्यापित करना चाहें, जब आपने auto_wallet_verification बंद कर रखा हो, या उन इनबाउंड ट्रांसफ़र में से किसी के लिए, तब POST /v3/travel-rule/widget-session/ के साथ सत्र मैन्युअली मिंट करें।

यह क्या साबित करता है

विजेट अधिकतम चार प्रमाण विधियाँ देता है। कौन-सी दिखेंगी, यह इस पर निर्भर करता है कि आपने सत्र कैसे मिंट किया है और आपकी Travel Rule सेटिंग्स क्या हैं:

संदेश हस्ताक्षर सत्यापन कॉन्ट्रैक्ट

हस्ताक्षर सबमिट करने पर, जब वह वॉलेट का नियंत्रण सिद्ध कर देता है, 200 और status: "VERIFIED" लौटता है। यह 400 लौटाता है और प्रमाण खुला छोड़ देता है, ताकि ग्राहक फिर से हस्ताक्षर कर सके, इन code मानों में से एक के साथ:

Satoshi टेस्ट सत्यापन कॉन्ट्रैक्ट

Satoshi टेस्ट डिपॉज़िट का सत्यापन असिंक्रोनस है, क्योंकि लेन-देन को ऑन-चेन देखा जाना चाहिए और फिर उसकी पुष्टि होनी चाहिए। डिपॉज़िट का txid सबमिट करने पर, जब तक डिपॉज़िट ऑन-चेन पुष्ट नहीं होता, 200 और status: "PENDING" लौटता है। txid सुरक्षित रखा जाता है, त्यागा नहीं जाता। डिपॉज़िट पुष्ट होने पर 200 और status: "VERIFIED" लौटता है। वास्तव में गलत डिपॉज़िट के लिए 400 और status: "REJECTED" लौटता है: किसी दूसरे वॉलेट से भेजा गया, डिपॉज़िट पते पर अपेक्षित राशि से अलग, चुनौती से पुराना, या ऐसा लेन-देन जो पहले ही किसी दूसरे वॉलेट को सिद्ध कर चुका है। प्रमाण बंद हो जाता है, और जब तक सत्र में प्रयास बचे हैं, ग्राहक नया प्रमाण शुरू कर सकता है। जो डिपॉज़िट अभी तक इंडेक्स नहीं हुआ है, वह भी 200 और status: "PENDING" लौटाता है, और Didit की ओर से लुकअप विफल होने पर 400 और code DEPOSIT_LOOKUP_FAILED लौटता है: दोनों स्थितियों में प्रमाण खुला रहता है और Didit जाँच जारी रखता है। यदि मान्य डिपॉज़िट देखे जाने से पहले टेस्ट विंडो समाप्त हो जाती है, तो 410 लौटता है। txid सबमिट होने के बाद, एक बैकग्राउंड जॉब हर पाँच मिनट में लंबित डिपॉज़िट की फिर से जाँच करता है और लेन-देन पुष्ट होने पर प्रमाण पूरा कर देता है, इसलिए ग्राहक को txid फिर से सबमिट करने की जरूरत नहीं होती। जब आप satoshi_deposit_address पास करते हैं, तो विजेट सत्र का अपना expires_at कम से कम 24 घंटे की Satoshi टेस्ट विंडो तक बढ़ा दिया जाता है, ताकि सत्र समाप्त होने से पहले डिपॉज़िट को पुष्ट होने का समय मिले।

प्रवाह

1

विजेट सत्र बनाएँ

POST /v3/travel-rule/widget-session/ को कॉल करें, जिसमें वह वॉलेट दें जिसे आपको सत्यापित करवाना है। चाहें तो इसे किसी ट्रांसफ़र से लिंक करें, ताकि स्वामित्व सिद्ध होते ही वह ट्रांसफ़र अपने-आप आगे बढ़ जाए।
2

लौटाया गया URL खोलें

अपने ग्राहक को रिस्पॉन्स में मिला url भेजें। वे वहाँ एक प्रमाण पूरा करते हैं - इसके लिए Didit खाते या API कुंजी की ज़रूरत नहीं है; URL में मौजूद टोकन ही प्रमाणीकरण है।
3

पूरा होने का पता लगाएँ

जब कोई प्रमाण सत्यापित होता है, तो विजेट एड्रेस-बुक प्रविष्टि को सत्यापित चिह्नित करता है और, अगर सत्र किसी ट्रांसफ़र से लिंक है, तो उसे आगे बढ़ाता है। लिंक किए गए ट्रांसफ़र के लिए travel_rule.status.updated पर नज़र रखें, या विजेट संदर्भ को पोल करें।

विजेट सत्र बनाएँ

यह उदाहरण सत्र को Travel Rule गाइड के घोषित स्व-होस्टेड ट्रांसफ़र से लिंक करता है, इसलिए wallet_address उस ट्रांसफ़र का गंतव्य वॉलेट है। किसी ट्रांसफ़र से लिंक सत्र केवल उस ट्रांसफ़र के प्रतिपक्ष वॉलेट के लिए प्रमाण स्वीकार करता है।
बनाया गया लिंक हमेशा रिस्पॉन्स में लौटाए गए url से ही खोलें - इसे स्वयं न बनाएँ।

लौटाया गया URL खोलें

इस रिलीज़ में विजेट केवल वेब पर उपलब्ध है। url को सिस्टम ब्राउज़र या कस्टम टैब में खोलें - किसी भी हाल में Didit मोबाइल SDK वेबव्यू के अंदर नहीं।मैसेज साइनिंग ग्राहक के ब्राउज़र में इंस्टॉल वॉलेट के साथ काम करती है, जिन्हें विजेट EIP-6963 और Wallet Standard प्रोटोकॉल से खोजता है। QR कोड जैसे तरीके से कोई अलग मोबाइल वॉलेट ऐप जोड़ना आज उपलब्ध नहीं है, इसलिए विजेट किसी दूसरे ऐप पर नहीं भेजता। इन-ऐप वेबव्यू, जैसे Didit Web/Flutter/React Native/iOS/Android SDK वेबव्यू, ग्राहक के ब्राउज़र वॉलेट तक नहीं पहुँच सकता, इसलिए वहाँ खोला गया विजेट ग्राहक के पास साइन करने का कोई तरीका नहीं छोड़ता।मोबाइल पर url को वेबव्यू में दिखाने के बजाय OS ब्राउज़र (SFSafariViewController / Chrome Custom Tabs, या डिफ़ॉल्ट ब्राउज़र) से लॉन्च करें। वेब पर सामान्य टैब या पॉपअप ठीक है।

पूरा होने का पता लगाएँ

विजेट एक सार्वजनिक endpoint देता है, जिसकी पहचान टोकन से होती है - प्रगति देखने के लिए उसे पोल करें, या जब सत्र किसी ट्रांसफ़र से लिंक हो तो webhooks पर भरोसा करें:
  • कोई प्रमाण सत्यापित होते ही completed_at का मान शून्य नहीं रहता।
  • proofs की हर प्रविष्टि में उसकी विधि के लिए ज़रूरी फ़ील्ड होते हैं: SATOSHI_TEST प्रमाण deposit_address, expected_amount और अपना expires_at जोड़ता है; MESSAGE_SIGNING प्रमाण challenge जोड़ता है, वह स्ट्रिंग जिस पर ग्राहक हस्ताक्षर करता है।
  • SATOSHI_TEST प्रमाण status: "PENDING" पर रह सकता है, जब उसका डिपॉज़िट चेन पर दिखे पर अभी पुष्ट न हुआ हो; इसमें आपकी या ग्राहक की ओर से कोई कार्रवाई ज़रूरी नहीं है - ऊपर Satoshi टेस्ट सत्यापन अनुबंध देखें।
  • जब सत्र transaction_id के साथ बनाया गया हो, तो प्रमाण सत्यापित होने पर लिंक किया गया ट्रांसफ़र आगे बढ़ता है, और लाइव एप्लिकेशन पर travel_rule.status.updated webhook फ़ायर होता है। पोल करने के बजाय webhook को प्राथमिकता दें। आने वाली TRP पूछताछ के लिए भेजने वाले को स्वीकृति वापस भेजी जाती है और वह स्वीकृति डिलीवर होने पर COMPLETED हो जाती है। UNCONFIRMED_OWNERSHIP में कोई भी दूसरा ट्रांसफ़र (या ON_HOLD आने वाला ट्रांसफ़र) COMPLETED हो जाता है, या जब लाभार्थी का नाम वॉलेट धारक से मेल नहीं खाता तो COUNTERPARTY_MISMATCHED_DATA हो जाता है, और पूरा हुआ सेटल्ड sunrise डिपॉज़िट FINISHED की ओर बढ़ता रहता है। COUNTERPARTY_VASP_NOT_FOUND में मौजूद आउटबाउंड ट्रांसफ़र COMPLETED हो जाता है।
  • इस संदर्भ में SCREENSHOT प्रमाण स्वामित्व की पुष्टि करने के बाद भी status: "PENDING" रहता है। आप इसे POST .../travel-rule/ownership/ से स्वीकृत करते हैं, जो केवल स्वामित्व पुष्टि की प्रतीक्षा कर रहे ट्रांसफ़र को स्वीकार करता है। इसलिए जिस सत्र से कोई ट्रांसफ़र लिंक न हो, उस पर, या COUNTERPARTY_VASP_NOT_FOUND में मौजूद आउटबाउंड ट्रांसफ़र से लिंक सत्र पर, स्क्रीनशॉट प्रमाण की कोई स्वीकृति का रास्ता नहीं है: यदि ऐसे सत्रों पर यह विकल्प नहीं होना चाहिए, तो allow_screenshot_proof बंद करें।
  • अस्वीकृत प्रमाण के बाद, जब तक प्रयास बचे हों, सत्र को नया प्रयास मिलता है। max_attempts, attempts_used, और attempts_remaining गिनती बताते हैं, अस्वीकृत प्रमाण के साथ rejection_reason आता है, और जब attempts_remaining 0 हो, तो एक और प्रमाण शुरू करने पर 409 मिलता है और आपको नया सत्र बनाना होगा।
  • संदर्भ endpoint अज्ञात टोकन के लिए 404 लौटाता है, और जो सत्र बिना पूरा हुए समाप्त हो गया हो, उसके लिए 410 लौटाता है।
यहाँ कोई एकबारगी निर्भरता नहीं है: विजेट और आपका बैकएंड दोनों एक ही टिकाऊ स्थिति पर पहुँचते हैं (सत्यापित एड्रेस-बुक प्रविष्टि और ट्रांसफ़र की स्थिति), इसलिए छूटा हुआ webhook या बंद टैब हमेशा ट्रांसफ़र या विजेट संदर्भ को दोबारा पढ़कर ठीक किया जा सकता है।

स्थानीयकरण और ब्रांडिंग

विजेट 54 भाषाओं में रेंडर होता है। भाषा लिंक के भाषा पथ से तय होती है, या ब्राउज़र की डिफ़ॉल्ट भाषा से। जब आपके एप्लिकेशन के लिए व्हाइट लेबल सक्षम होता है, तो विजेट आपके सत्यापन-फ़्लो की ब्रांडिंग अपने-आप ले लेता है: लोगो, ब्रांड रंग, बटन और पैनल की स्टाइलिंग, कस्टम फ़ॉन्ट, फ़ेविकॉन, और शीर्षक में आपके एप्लिकेशन का सार्वजनिक नाम। इसके लिए कोई अलग कॉन्फ़िगरेशन नहीं करना होता - KYC सत्रों के लिए आपने जो कस्टमाइज़ेशन सेट किया है, वही यहाँ लागू होता है। जो उपयोगकर्ता पहले से पूरे हो चुके लिंक पर वापस आता है, उसे फिर से पूर्णता स्क्रीन दिखती है; यदि आपने callback_url पास किया है, तो विजेट उसे वहीं वापस भेज देता है। समय-सीमा समाप्त हो चुके लिंक पर एक ब्रांडेड समाप्ति स्क्रीन दिखती है, जो उपयोगकर्ता से नया लिंक माँगने को कहती है। उसके लिए POST /v3/travel-rule/widget-session/ के साथ नया सत्र बनाएँ: action: "resend" के साथ ट्रांसफ़र दोबारा भेजने से कोई सत्र नहीं बनता।

अगले चरण

Travel Rule

पूरा एक्सचेंज जीवनचक्र, रेल्स, सेटिंग्स और प्राप्ति फ़्लो।

वॉलेट की पता पुस्तिका

अपने नियंत्रण वाले वॉलेट रजिस्टर करें, ताकि इनबाउंड ट्रांसफ़र उनसे मिलान हो सकें।

webhook

travel_rule.status.updated की सदस्यता लें, ताकि किसी प्रमाण से ट्रांसफ़र आगे बढ़ने पर आप प्रतिक्रिया दे सकें।

Native SDKs

विजेट URL को सिस्टम ब्राउज़र में खोलें, SDK वेबव्यू में नहीं।
अंतिम संशोधन 7 नवंबर 2026