> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# वॉलेट स्वामित्व विजेट - Travel Rule नियंत्रण प्रमाण

> Didit का होस्टेड विजेट मैसेज साइनिंग, Satoshi test, स्क्रीनशॉट या स्व-घोषणा से साबित करता है कि ग्राहक वॉलेट का नियंत्रक है। Travel Rule के लिए।

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

सत्यापित प्रमाण मिलने पर संबंधित [वॉलेट पता बुक प्रविष्टि](https://docs.didit.me/hi/transaction-monitoring/travel-rule.md#वॉलेट-पता-पुस्तिका) को `is_ownership_verified: true` के रूप में चिह्नित किया जाता है, जिससे जुड़ा हुआ [Travel Rule ट्रांसफ़र](https://docs.didit.me/hi/transaction-monitoring/travel-rule.md) `UNCONFIRMED_OWNERSHIP` से आगे बढ़ सकता है।

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

आपको शायद ही कभी खुद सत्र मिंट करना पड़ता है।
जब आपकी [Travel Rule सेटिंग्स](https://docs.didit.me/hi/transaction-monitoring/travel-rule.md#सेटअप) में `auto_wallet_verification` चालू हो (जो डिफ़ॉल्ट है), तो Didit लेन-देन बनाते समय, जब भी किसी ट्रांसफ़र को अंतिम उपयोगकर्ता के वॉलेट नियंत्रण के प्रमाण की ज़रूरत हो, अपने-आप एक विजेट सत्र मिंट कर देता है:

* ट्रांसफ़र `UNCONFIRMED_OWNERSHIP` में है - सबमिशन के समय प्रतिपक्ष वॉलेट को [स्व-होस्टेड घोषित](https://docs.didit.me/hi/transaction-monitoring/travel-rule.md#घोषित-स्व-होस्टेड-वॉलेट) किया गया था।
* ट्रांसफ़र आउटबाउंड है और `COUNTERPARTY_VASP_NOT_FOUND` में है - कोई प्रतिपक्ष VASP पहचाना नहीं जा सका, इसलिए पूरा होने का बचा हुआ तरीका स्वामित्व प्रमाण ही है।

अपने-आप मिंट किया गया सत्र लेन-देन के `action_required` ब्लॉक में लौटाया जाता है (`type: "wallet_ownership"`, खोलने के लिए `url` के साथ), और SDK [क्लाइंट-साइड सबमिशन](https://docs.didit.me/hi/transaction-monitoring/sdk-transaction-submission.md#आवश्यक-उपयोगकर्ता-क्रियाएँ) पर उसे अपने-आप लॉन्च कर देते हैं।
Didit द्वारा आपके लिए बनाए गए इनबाउंड ट्रांसफ़र (सनराइज़ रजिस्ट्रेशन, इनबाउंड `TRP` पूछताछ, या `INTERNAL` रेल का इनबाउंड हिस्सा) को कभी भी अपने-आप मिंट किया गया सत्र नहीं मिलता, भले ही वे `UNCONFIRMED_OWNERSHIP` में आ जाएँ।
जब आप किसी वॉलेट को किसी ट्रांसफ़र के मौजूद होने से पहले पूर्व-सत्यापित करना चाहें, जब आपने `auto_wallet_verification` बंद कर रखा हो, या उन इनबाउंड ट्रांसफ़र में से किसी के लिए, तब `POST /v3/travel-rule/widget-session/` के साथ सत्र मैन्युअली मिंट करें।

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

विजेट अधिकतम चार प्रमाण विधियाँ देता है। कौन-सी दिखेंगी, यह इस पर निर्भर करता है कि आपने सत्र कैसे मिंट किया है और आपकी [Travel Rule सेटिंग्स](https://docs.didit.me/hi/transaction-monitoring/travel-rule.md#सेटअप) क्या हैं:

| विधि | यह कैसे काम करती है | कब दी जाती है |
| - | - | - |
| `MESSAGE_SIGNING` | ग्राहक अपने वॉलेट से Didit द्वारा जारी की गई चुनौती स्ट्रिंग पर हस्ताक्षर करता है। यह EVM, Solana, Bitcoin और Tron वॉलेट का समर्थन करता है (Bitcoin के लिए लीगेसी, नेस्टेड SegWit, नेटिव SegWit और Taproot पते)। Didit हस्ताक्षर को पते के आधार पर सत्यापित करता है, और जिस खाते का सत्यापन हो रहा है उससे अलग खाते से हस्ताक्षर करने पर स्पष्ट खाता बदलने के संकेत के साथ उसे अस्वीकार कर दिया जाता है। EVM स्मार्ट-कॉन्ट्रैक्ट अकाउंट (ERC-4337 स्मार्ट वॉलेट) भी हस्ताक्षर कर सकते हैं: Didit उस चेन पर, जिस पर वॉलेट घोषित है, अकाउंट के अपने कॉन्ट्रैक्ट से पूछता है कि हस्ताक्षर मान्य है या नहीं (ERC-1271)। जो अकाउंट अभी तक deploy नहीं हुआ है, उसके लिए यह वॉलेट द्वारा लौटाए गए ERC-6492 हस्ताक्षर की जाँच करता है, बिना अकाउंट deploy किए या कोई लेन-देन भेजे। स्मार्ट-कॉन्ट्रैक्ट अकाउंट की जाँच हर समर्थित EVM चेन पर होती है। नीचे [संदेश हस्ताक्षर सत्यापन कॉन्ट्रैक्ट](#संदेश-हस्ताक्षर-सत्यापन-कॉन्ट्रैक्ट) देखें। ग्राहक के ब्राउज़र में इंस्टॉल वॉलेट EIP-6963 और Wallet Standard प्रोटोकॉल से खोजे जाते हैं, इसलिए हर एक्सटेंशन अपना अलग हस्ताक्षर विकल्प बनकर दिखता है। QR कोड जैसे माध्यम से अलग मोबाइल वॉलेट ऐप को जोड़ने की सुविधा अभी उपलब्ध नहीं है। | हमेशा, समर्थित चेन परिवारों के लिए। |
| `SATOSHI_TEST` | ग्राहक वॉलेट से आपके नियंत्रित डिपॉज़िट पते पर एक छोटी ऑन-चेन राशि भेजता है। Didit का वॉचर भेजने वाले की जाँच करता है (EVM स्मार्ट-कॉन्ट्रैक्ट अकाउंट के लिए अकाउंट स्वयं, भले ही लेन-देन ERC-4337 बंडलर सबमिट करे), राशि की जाँच करता है, और यह भी कि डिपॉज़िट ऑन-चेन पर पुष्ट हुआ है। पुष्टि होते ही यह प्रमाण अपने आप पूरा कर देता है। देखें [Satoshi टेस्ट सत्यापन कॉन्ट्रैक्ट](#satoshi-टेस्ट-सत्यापन-कॉन्ट्रैक्ट) नीचे। | केवल तब जब मिंट के समय आप `satoshi_deposit_address` पास करें और चेन EVM, Bitcoin या Solana चेन हो, इसलिए यह कभी भी स्वतः मिंट किए गए सत्र पर नहीं होता। |
| `SCREENSHOT` | ग्राहक वॉलेट का स्क्रीनशॉट अपलोड करता है जिसमें पता दिखता हो (JPEG/PNG/WebP, अधिकतम 10 MB)। अन्य विधियों से अलग, यह कभी अपने आप सत्यापित नहीं होता: आपकी अनुपालन टीम इसे स्क्रीनशॉट समीक्षा कतार ([`GET /v3/travel-rule/wallet-proofs/`](https://docs.didit.me/hi/management-api/travel-rule/list-wallet-proofs)) से समीक्षा करती है और स्वीकृत या अस्वीकृत करती है ([`POST .../decision/`](https://docs.didit.me/hi/management-api/travel-rule/decide-wallet-proof)), या लेन-देन के **Travel Rule** टैब में कंसोल से, या [`POST .../travel-rule/ownership/`](https://docs.didit.me/hi/management-api/travel-rule/confirm-ownership) के जरिए स्थानांतरण की पुष्टि करती है (उस स्थानांतरण के लिए जो `UNCONFIRMED_OWNERSHIP` में है, या होल्ड पर रखे इनबाउंड स्थानांतरण के लिए)। | केवल तब जब आपकी सेटिंग्स में `allow_screenshot_proof` `true` हो। |
| `SELF_DECLARATION` | ग्राहक बिना क्रिप्टोग्राफ़िक प्रमाण के स्वामित्व की पुष्टि करता है। यह अंतिम विकल्प है, जहाँ अधिकार-क्षेत्र इसे स्वीकार करता है। | केवल तब जब `allow_self_declaration` `true` हो और आपका [`ownership_validation_mode`](https://docs.didit.me/hi/transaction-monitoring/travel-rule#स्वामित्व-सत्यापन-मोड) जुड़े स्थानांतरण के लिए घोषणा स्वीकार करता हो: `FULL` में कभी नहीं, और `SIMPLIFIED` में केवल `simplified_validation_threshold` से नीचे। जो मोड स्वीकार नहीं करता, उसके लिए ऐसी घोषणा शुरू करने पर `403` मिलता है। |

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

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

| `code` | अर्थ |
| - | - |
| `SIGNATURE_INVALID` | हस्ताक्षर वॉलेट को सिद्ध नहीं करता: किसी दूसरे खाते या कुंजी ने हस्ताक्षर किया है, या संदेश अलग है। स्मार्ट-कॉन्ट्रैक्ट अकाउंट के मामले में, उसके कॉन्ट्रैक्ट ने बताया है कि हस्ताक्षर उसका अपना नहीं है। |
| `SIGNATURE_UNSUPPORTED_SCHEME` | वॉलेट ने ऐसे फ़ॉर्मेट में हस्ताक्षर किया है जिसे Didit सत्यापित नहीं करता, उदाहरण के लिए Bitcoin multisig या BIP-322 पूर्ण हस्ताक्षर। |
| `SIGNATURE_LOOKUP_FAILED` | वॉलेट एक स्मार्ट-कॉन्ट्रैक्ट अकाउंट हो सकता है, और उसकी चेन अभी जाँची नहीं जा सकी। इस उत्तर पर प्रमाण कभी सत्यापित नहीं होता; फिर से हस्ताक्षर करने पर उसकी फिर से जाँच होती है। |

### 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 गाइड के [घोषित स्व-होस्टेड ट्रांसफ़र](https://docs.didit.me/hi/transaction-monitoring/travel-rule.md#घोषित-स्व-होस्टेड-वॉलेट) से लिंक करता है, इसलिए `wallet_address` उस ट्रांसफ़र का गंतव्य वॉलेट है।
किसी ट्रांसफ़र से लिंक सत्र केवल उस ट्रांसफ़र के प्रतिपक्ष वॉलेट के लिए प्रमाण स्वीकार करता है।

```bash theme={null}
curl -X POST https://verification.didit.me/v3/travel-rule/widget-session/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "wallet_address": "0xd3b62acb76fb27a7f8961ec40fa11746b113aca9",
    "chain": "ETH",
    "holder_name": "Jane Doe",
    "vendor_data": "user-042",
    "transaction_id": "99999999-aaaa-bbbb-cccc-dddddddddddd",
    "satoshi_deposit_address": "0x71C7656EC7ab88b098defB751B7401B5f6d8976F",
    "callback_url": "https://yourapp.example/wallet-verified",
    "expires_in_minutes": 60
  }'
```

| फ़ील्ड | प्रकार | विवरण |
| - | - | - |
| `wallet_address` | string | सत्यापित किया जाने वाला वॉलेट पता। |
| `chain` | string | पते के लिए चेन पहचानकर्ता (जैसे `ETH`, `BTC`, `SOL`)। वही टोकन इस्तेमाल करें जो आपके ट्रांसफ़र में होता है (`ETH`, `ethereum` नहीं): विजेट एड्रेस-बुक प्रविष्टि को इसी `chain` के साथ सहेजता है, और किसी दूसरी चेन वाला ट्रांसफ़र उससे मेल नहीं खाएगा। मैसेज साइनिंग के लिए ऐसी चेन चाहिए जिसे Didit पहचानता हो। |
| `holder_name` | string | वॉलेट धारक का नाम, जिसका उपयोग लाभार्थी के नाम के मिलान के लिए होता है। |
| `vendor_data` | string | धारक के लिए आपका आंतरिक पहचानकर्ता, जो बनाई गई एड्रेस-बुक प्रविष्टि में रखा जाता है। |
| `transaction_id` | string (uuid) | वैकल्पिक। Travel Rule ट्रांसफ़र का Didit लेन-देन UUID, जिसे प्रमाण सत्यापित होने पर आगे बढ़ाया जाता है; अज्ञात UUID पर `404` लौटता है, और ट्रांसफ़र के प्रतिपक्ष वॉलेट के अलावा किसी भी वॉलेट का प्रमाण `400` के साथ अस्वीकार होता है। वॉलेट को स्वतंत्र रूप से सत्यापित करने के लिए इसे छोड़ दें। |
| `satoshi_deposit_address` | string | वैकल्पिक। आपके नियंत्रण वाला डिपॉज़िट पता; इसे देने पर `SATOSHI_TEST` विधि सक्षम हो जाती है। |
| `callback_url` | string | वैकल्पिक। वह स्थान जहाँ पूरा होने के बाद विजेट ग्राहक को वापस भेजता है। |
| `expires_in_minutes` | integer | वैकल्पिक। बनाए गए लिंक का जीवनकाल मिनटों में, `5` से `10080` तक (डिफ़ॉल्ट `60`); जब आप `satoshi_deposit_address` पास करते हैं, तो यह अपने-आप Satoshi टेस्ट की 24 घंटे की विंडो जितना कम से कम बढ़ा दिया जाता है। |

```json theme={null}
{
  "widget_session_id": "77777777-8888-9999-aaaa-bbbbbbbbbbbb",
  "token": "3s9x...urlsafe",
  "url": "https://verify.didit.me/wallet-ownership/3s9x...urlsafe",
  "expires_at": "2026-07-07T13:00:00Z"
}
```

बनाया गया लिंक हमेशा रिस्पॉन्स में लौटाए गए `url` से ही खोलें - इसे स्वयं न बनाएँ।

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

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

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

विजेट एक सार्वजनिक endpoint देता है, जिसकी पहचान टोकन से होती है - प्रगति देखने के लिए उसे पोल करें, या जब सत्र किसी ट्रांसफ़र से लिंक हो तो webhooks पर भरोसा करें:

```bash theme={null}
curl https://verification.didit.me/v3/travel-rule/widget/{token}/
```

```json theme={null}
{
  "vasp_name": "Origin CASP SL",
  "wallet_address": "0xd3b62acb76fb27a7f8961ec40fa11746b113aca9",
  "chain": "ETH",
  "holder_name": "Jane Doe",
  "allowed_methods": ["MESSAGE_SIGNING", "SCREENSHOT", "SATOSHI_TEST", "SELF_DECLARATION"],
  "transfer_status": "UNCONFIRMED_OWNERSHIP",
  "callback_url": "https://yourapp.example/wallet-verified",
  "expires_at": "2026-07-07T13:00:00Z",
  "completed_at": null,
  "proofs": [
    {
      "proof_id": "88888888-9999-aaaa-bbbb-cccccccccccc",
      "method": "SATOSHI_TEST",
      "status": "PENDING",
      "wallet_address": "0xd3b62acb76fb27a7f8961ec40fa11746b113aca9",
      "chain": "ETH",
      "deposit_address": "0x71C7656EC7ab88b098defB751B7401B5f6d8976F",
      "expected_amount": "0.000042817305521963",
      "expires_at": "2026-07-07T13:05:00.412731+00:00",
      "created_at": "2026-07-06T13:05:00.412731Z"
    }
  ],
  "customization": null
}
```

* कोई प्रमाण सत्यापित होते ही `completed_at` का मान शून्य नहीं रहता।
* `proofs` की हर प्रविष्टि में उसकी विधि के लिए ज़रूरी फ़ील्ड होते हैं: `SATOSHI_TEST` प्रमाण `deposit_address`, `expected_amount` और अपना `expires_at` जोड़ता है; `MESSAGE_SIGNING` प्रमाण `challenge` जोड़ता है, वह स्ट्रिंग जिस पर ग्राहक हस्ताक्षर करता है।
* `SATOSHI_TEST` प्रमाण `status: "PENDING"` पर रह सकता है, जब उसका डिपॉज़िट चेन पर दिखे पर अभी पुष्ट न हुआ हो; इसमें आपकी या ग्राहक की ओर से कोई कार्रवाई ज़रूरी नहीं है - ऊपर [Satoshi टेस्ट सत्यापन अनुबंध](#satoshi-टेस्ट-सत्यापन-कॉन्ट्रैक्ट) देखें।
* जब सत्र `transaction_id` के साथ बनाया गया हो, तो प्रमाण सत्यापित होने पर लिंक किया गया ट्रांसफ़र आगे बढ़ता है, और लाइव एप्लिकेशन पर [`travel_rule.status.updated`](https://docs.didit.me/hi/integration/webhooks#इवेंट-प्रकार) 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/`](https://docs.didit.me/hi/transaction-monitoring/travel-rule#स्वामित्व-की-पुष्टि-करना) से स्वीकृत करते हैं, जो केवल स्वामित्व पुष्टि की प्रतीक्षा कर रहे ट्रांसफ़र को स्वीकार करता है।
  इसलिए जिस सत्र से कोई ट्रांसफ़र लिंक न हो, उस पर, या `COUNTERPARTY_VASP_NOT_FOUND` में मौजूद आउटबाउंड ट्रांसफ़र से लिंक सत्र पर, स्क्रीनशॉट प्रमाण की कोई स्वीकृति का रास्ता नहीं है: यदि ऐसे सत्रों पर यह विकल्प नहीं होना चाहिए, तो `allow_screenshot_proof` बंद करें।
* अस्वीकृत प्रमाण के बाद, जब तक प्रयास बचे हों, सत्र को नया प्रयास मिलता है।
  `max_attempts`, `attempts_used`, और `attempts_remaining` गिनती बताते हैं, अस्वीकृत प्रमाण के साथ `rejection_reason` आता है, और जब `attempts_remaining` `0` हो, तो एक और प्रमाण शुरू करने पर `409` मिलता है और आपको नया सत्र बनाना होगा।
* संदर्भ endpoint अज्ञात टोकन के लिए `404` लौटाता है, और जो सत्र बिना पूरा हुए समाप्त हो गया हो, उसके लिए `410` लौटाता है।

> [!NOTE]
>
> यहाँ कोई एकबारगी निर्भरता नहीं है: विजेट और आपका बैकएंड दोनों एक ही टिकाऊ स्थिति पर पहुँचते हैं (सत्यापित एड्रेस-बुक प्रविष्टि और ट्रांसफ़र की स्थिति), इसलिए छूटा हुआ webhook या बंद टैब हमेशा ट्रांसफ़र या विजेट संदर्भ को दोबारा पढ़कर ठीक किया जा सकता है।

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

विजेट **54 भाषाओं में** रेंडर होता है। भाषा लिंक के भाषा पथ से तय होती है, या ब्राउज़र की डिफ़ॉल्ट भाषा से।

जब आपके एप्लिकेशन के लिए व्हाइट लेबल सक्षम होता है, तो विजेट आपके सत्यापन-फ़्लो की ब्रांडिंग अपने-आप ले लेता है: लोगो, ब्रांड रंग, बटन और पैनल की स्टाइलिंग, कस्टम फ़ॉन्ट, फ़ेविकॉन, और शीर्षक में आपके एप्लिकेशन का सार्वजनिक नाम। इसके लिए कोई अलग कॉन्फ़िगरेशन नहीं करना होता - KYC सत्रों के लिए आपने जो कस्टमाइज़ेशन सेट किया है, वही यहाँ लागू होता है।

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

## अगले चरण

> [card] [Travel Rule](https://docs.didit.me/hi/transaction-monitoring/travel-rule.md)
>
> पूरा एक्सचेंज जीवनचक्र, रेल्स, सेटिंग्स और प्राप्ति फ़्लो।

> [card] [वॉलेट की पता पुस्तिका](https://docs.didit.me/hi/transaction-monitoring/travel-rule.md#वॉलेट-पता-पुस्तिका)
>
> अपने नियंत्रण वाले वॉलेट रजिस्टर करें, ताकि इनबाउंड ट्रांसफ़र उनसे मिलान हो सकें।

> [card] [webhook](https://docs.didit.me/hi/integration/webhooks.md)
>
> travel\_rule.status.updated की सदस्यता लें, ताकि किसी प्रमाण से ट्रांसफ़र आगे बढ़ने पर आप प्रतिक्रिया दे सकें।

> [card] [Native SDKs](https://docs.didit.me/hi/integration/native-sdks/overview.md)
>
> विजेट URL को सिस्टम ब्राउज़र में खोलें, SDK वेबव्यू में नहीं।


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.