> ## 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 VASP से जुड़ें

> VASP Didit ग्राहक के साथ Travel Rule डेटा कैसे साझा करते हैं: Travel Address, सार्वजनिक TRP endpoints, callbacks, ईमेल पिकअप और sunrise पंजीकरण।

यह पेज **दूसरे पक्ष** के लिए है, यानी प्रतिपक्ष VASP (या उसकी इंजीनियरिंग टीम), जिसे [Didit Travel Rule](https://docs.didit.me/hi/transaction-monitoring/travel-rule.md) एक्सचेंज के तहत Didit पर चलने वाले VASP को Travel Rule डेटा भेजना होता है या उससे प्राप्त करना होता है।

यहाँ दस्तावेज़ की गई हर चीज़ Didit द्वारा संचालित सार्वजनिक इन्फ़्रास्ट्रक्चर है।
इंटरऑपरेट करने के लिए आपको Didit खाता, API कुंजी या Didit के साथ किसी भी व्यावसायिक संबंध की ज़रूरत नहीं है। सबसे गहरे इंटीग्रेशन के लिए भी केवल HTTPS और JSON चाहिए।

## Didit एक्सचेंज को कैसे रूट करता है

जब कोई Didit ग्राहक ट्रांसफ़र भेजता है, तो Didit इन रेल्स को सख़्त प्राथमिकता क्रम में आज़माता है और जो पहली रेल आप तक पहुँच सकती है, उसका उपयोग करता है:

| प्राथमिकता | रेल | इसका आपके लिए क्या अर्थ है |
| - | - | - |
| 1 | `INTERNAL` | दोनों VASP Didit पर चलते हैं - एक्सचेंज प्लेटफ़ॉर्म के भीतर ही सेटल होता है और कोई बाहरी कॉल नहीं की जाती। |
| 2 | `TRP` | आप एक Travel Rule Protocol (TRP) endpoint उपलब्ध कराते हैं, या Didit ग्राहक आपका [Travel Address](#travel-address) जानता है। Didit `BTC`, `ETH` और `USDC` ट्रांसफ़र के लिए आपके TRP पूछताछ endpoint को मशीन-से-मशीन कॉल करता है (`USDC` तब जब ट्रांसफ़र उस नेटवर्क का नाम दे जिस पर वह चलता है)। |
| 3 | `GTR` | प्रेषक के लिए Global Travel Rule (GTR) सदस्यता सक्रिय है और आप GTR VASP कोड से पहचाने जा सकते हैं। Didit आपका उत्तर GTR की प्रतिक्रिया से पढ़ता है, या अनुरोध की स्थिति की पोलिंग करके। |
| 4 | `TRUST` | प्रेषक के लिए TRUST सदस्यता सक्रिय है और आप TRUST सदस्यता आईडी से पहचाने जा सकते हैं। केवल भेजने के लिए: नीचे दी गई चेतावनी देखें। |
| 5 | `VERIFYVASP` | प्रेषक के लिए VerifyVASP सदस्यता सक्रिय है और आप VerifyVASP आईडी से पहचाने जा सकते हैं। Didit सत्यापन की स्थिति की पोलिंग करके आपका उत्तर पढ़ता है। |
| 6 | `SYGNA` | प्रेषक के लिए Sygna Bridge सदस्यता सक्रिय है और आप Sygna VASP कोड से पहचाने जा सकते हैं। Didit Sygna प्रोटोकॉल में मूल रूप से संवाद करता है (ECIES-एन्क्रिप्टेड IVMS101, हस्ताक्षरित अनुमति अनुरोध), और ट्रांसफ़र की स्थिति की पोलिंग करके आपका अनुमति उत्तर पढ़ता है: उसका Sygna callback अभी लाइव नहीं है। |
| 7 | `EMAIL` | कोई प्रोटोकॉल चैनल उपलब्ध नहीं है - इसके बजाय आपके अनुपालन संपर्क को एक बार-उपयोग वाला [ईमेल पिकअप लिंक](#ईमेल-से-पिकअप) मिलता है। |

> [!WARNING]
>
> **Didit `TRUST` का उत्तर प्राप्त नहीं कर सकता, और नेटवर्क के ज़रिए उसे भेजे गए ट्रांसफ़र अभी स्वीकार नहीं करता।**
> `TRUST` पर, Didit ग्राहक का ट्रांसफ़र आप तक पहुँचता है, लेकिन आपका उत्तर वापस नहीं आ सकता, और ट्रांसफ़र भेजने वाले की पुष्टि की समय-सीमा पर समाप्त हो जाता है, पूरा होने के बजाय।
> `GTR`, `VERIFYVASP` और `SYGNA` पर, Didit आपका उत्तर नेटवर्क से ही पढ़ता है, उसकी प्रतिक्रिया से या ट्रांसफ़र की स्थिति की पोलिंग करके।

ऊपर की तालिका उन ट्रांसफ़र पर लागू होती है जो Didit ग्राहक भेजता है।
जब आप किसी Didit ग्राहक को ट्रांसफ़र भेजते हैं, तो Didit उसे केवल एक `TRP` [ट्रांसफ़र पूछताछ](#post-/trp/inquiries//) के रूप में ले सकता है, जब Didit का सार्वजनिक TRP होस्ट लाइव हो (अभी उत्तर नहीं देता, देखें [TRP endpoints](#trp-endpoints)), या, सेटलमेंट के बाद, [sunrise पंजीकरण](#सनराइज़-ऐसे-ट्रांसफ़र-जो-विनिमय-से-पहले-सेटल-हो-गए) के रूप में: आज कोई नेटवर्क रेल और कोई ईमेल चैनल किसी Didit ग्राहक तक आने वाला ट्रांसफ़र नहीं पहुँचाता।

नेटवर्क रेल्स (`GTR`, `TRUST`, `VERIFYVASP`, `SYGNA`) प्रेषक की ओर की सदस्यता के माध्यम से चलती हैं।
आज इसके लिए Didit ग्राहक की अपनी जुड़ी हुई सदस्यता होनी चाहिए: Didit के पास इनमें से किसी भी नेटवर्क पर अभी प्लेटफ़ॉर्म सदस्यता नहीं है और वह एक प्रदाता के रूप में ऑनबोर्ड हो रहा है।
GTR डिफ़ॉल्ट रूप से शामिल नहीं है, और यही सदस्यता आवश्यकता चारों नेटवर्कों पर लागू होती है।
प्रेषक को [Get Travel Rule Settings](https://docs.didit.me/hi/management-api/travel-rule/get-settings.md) में `networks` ऑब्जेक्ट की जाँच करनी चाहिए: `didit` का अर्थ है कि Didit की सदस्यता उस एप्लिकेशन के लिए नेटवर्क पर स्वयं प्रतिभागी होती है, `own` का अर्थ है जुड़ी हुई ग्राहक सदस्यता, `off` का अर्थ है कि प्लेटफ़ॉर्म रूटिंग अक्षम है, और `unavailable` का अर्थ है कि उस एप्लिकेशन के लिए उस नेटवर्क पर अभी कोई भी नहीं भेज सकता।
जब तक Didit के पास प्लेटफ़ॉर्म सदस्यता नहीं होती, कोई भी नेटवर्क `didit` नहीं दिखाता।
Travel Rule सक्षम करने से नेटवर्क सदस्यता सक्रिय नहीं होती।
हर नेटवर्क आज कहाँ तक पहुँचता है, इसके लिए [Travel Rule networks](https://docs.didit.me/hi/transaction-monitoring/travel-rule-networks.md) देखें।

यदि आप इनमें से किसी नेटवर्क पर हैं और Didit ग्राहक की वहाँ अपनी सदस्यता है, तो उसके साथ अपनी नेटवर्क पहचान साझा करें, और ट्रांसफ़र उस नेटवर्क के ज़रिए आप तक पहुँचेगा जिसका आप पहले से संचालन करते हैं।
`SYGNA` पर, आपका अनुमति उत्तर ट्रांसफ़र को पूरा या अस्वीकार करता है: Didit हर 5 मिनट में ट्रांसफ़र की स्थिति पोल करता है, और हर अनुमति अनुरोध के callback के रूप में `https://trp.didit.me/sygna/callbacks/permission/{token}/` भी पंजीकृत करता है, जिसका token उस ट्रांसफ़र के लिए बनाया जाता है।
यह callback Didit के सार्वजनिक TRP होस्ट पर है, जो अभी अनुरोधों का उत्तर नहीं देता।
`ACCEPTED` का `permission_status` भेजने वाले के ट्रांसफ़र को `COMPLETED` पर ले जाता है, और `REJECTED` उसे `COUNTERPARTY_VASP_GENERAL_DECLINE` पर ले जाता है, या जब `reject_code` `BVRC007` हो (लाभार्थी का नाम मेल नहीं खाता) तो `COUNTERPARTY_MISMATCHED_DATA` पर।
Callback को आपके हस्ताक्षर की आवश्यकता है: वैध हस्ताक्षर के बिना यह `401` के साथ `{"status": "INVALID_SIGNATURE"}` लौटाता है, अज्ञात token के लिए `404`, और ऐसे निर्णय के लिए फिर `200` लौटाता है जिसे वह पहले ही लागू कर चुका है।

बिना किसी साझा सदस्यता के, `TRP` वह रास्ता है जिसकी योजना बनानी चाहिए: Didit ग्राहक के साथ अपना Travel Address साझा करें, और उनके ट्रांसफ़र आपके TRP endpoint तक पहुँचेंगे। आप अपनी पूछताछ के उत्तर में जो उत्तर देते हैं, वह ट्रांसफ़र को तुरंत पूरा या अस्वीकार करता है; बाद में Didit के callback पर आप जो उत्तर भेजते हैं, उसके लिए Didit के सार्वजनिक TRP होस्ट की ज़रूरत होती है, जो अभी लाइव नहीं है।

जब कोई भी रेल आपकी पहचान नहीं कर पाती, तो Didit एक और समाधान चरण चलाता है: **ब्लॉकचेन विश्लेषण के आधार पर पहचान**।
गंतव्य वॉलेट की पहचान ब्लॉकचेन विश्लेषण डेटा के आधार पर की जाती है, और जब उसे आपके एक्सचेंज या कस्टडी सेवा से जोड़ा जाता है, तो Didit आपका नाम अपनी VASP डायरेक्टरी में दर्ज करता है और उसके साथ रेल्स को फिर से आज़माता है।
इसका अर्थ है कि यदि प्रेषक ने केवल वॉलेट पता दिया हो, तब भी आपकी पहचान हो सकती है।
ब्लॉकचेन विश्लेषण के आधार पर जोड़े गए ट्रांसफ़र आप तक स्वचालित रूप से तभी रूट होते हैं जब आपकी डायरेक्टरी प्रविष्टि में कोई रूट हो: सत्यापित `TRP` endpoint, नेटवर्क सूची, या अनुपालन संपर्क (देखें [Didit VASP डायरेक्टरी में प्रवेश](#didit-vasp-डायरेक्टरी-में-शामिल-होना))।
इसलिए पूरी समाधान श्रृंखला यह है: वह Didit ग्राहक जिसने वॉलेट पर नियंत्रण सिद्ध किया है (`INTERNAL`) और वह Travel Address जो प्रेषक ने उसके लिए संग्रहीत किया, फिर प्रोटोकॉल और नेटवर्क रेल्स, और अंत में ब्लॉकचेन विश्लेषण।

## Travel Address

हर ऐसा Didit VASP जिसमें Travel Rule सक्षम है, उसका एक **Travel Address** होता है। यह `ta` से शुरू होने वाली एक संक्षिप्त स्ट्रिंग है, जो उसके व्यक्तिगत TRP ट्रांसफ़र-पूछताछ endpoint का URL एन्कोड करती है। Didit ग्राहक अपना Travel Address अपनी Travel Rule सेटिंग्स से पढ़ते हैं और उसे प्रतिपक्षों के साथ साझा करते हैं। जब कोई Didit ग्राहक आपको अपना Travel Address देता है, तो TRP के ज़रिए उस तक पहुँचने के लिए आपके पास ज़रूरी सब कुछ होता है।

एन्कोडिंग TRP Travel Address परिपाटी का पालन करती है:

* `ta` उपसर्ग हटाएँ।
* बाकी हिस्से को Base58Check डिकोड करें (Bitcoin वर्णमाला, डबल-SHA256 चेकसम)।
* डिकोड किए गए बाइट्स स्कीम के बिना पूछताछ URL हैं; उसके आगे `https://` जोड़ें।
* URL में हमेशा क्वेरी जोड़ी `t=i` (प्रकार: पूछताछ) होती है।

एक डिकोड किया गया Didit Travel Address इन दो रूपों में से एक का होता है:

```
https://trp.didit.me/trp/inquiries/{profile_uuid}/?t=i
https://trp.didit.me/trp/inquiries/{profile_uuid}/wallets/{entry_uuid}/?t=i
```

पहला रूप होस्टेड VASP प्रोफ़ाइल की पहचान करता है। `{profile_uuid}` उसी प्रोफ़ाइल का UUID है। अपने ट्रांसफ़र की पूछताछ इसी URL पर POST करें, और सबसे पहले यह सत्यापित करने के लिए कि आप किससे बात कर रहे हैं, मिलते-जुलते [पहचान endpoint](#get-/trp/identity//) को क्वेरी करें।

दूसरा रूप **प्रति-वॉलेट** Travel Address है। यह Didit ग्राहक के एक वॉलेट का नाम बताता है (उसकी पता पुस्तिका में `receiving_travel_address`), इसलिए आपकी पूछताछ ग्राहक के खाता संख्या या धारक के नाम से मिलान किए बिना उस वॉलेट तक पहुँचती है। वॉलेट हटा दिए जाने के बाद, या उसके किसी अन्य VASP के नाम दर्ज होने पर, यह `404` लौटाता है।

## TRP endpoints

Didit, TRP API संस्करण `3.2.1` का उपयोग करता है, और इसका बेस URL `https://trp.didit.me` है।
सभी endpoint HTTPS पर JSON का आदान-प्रदान करते हैं।

> [!WARNING]
>
> Didit का सार्वजनिक TRP होस्ट अभी ये endpoint नहीं देता। जब तक यह ऐसा नहीं करता, Didit के किसी ग्राहक को भेजी गई TRP पूछताछ या पहचान अनुरोध डिलीवर नहीं किया जा सकता; यह सेक्शन वह अनुबंध है जिसका उत्तर होस्ट लाइव होने के बाद देगा।

| विधि | पाथ | उद्देश्य |
| - | - | - |
| `GET` | `/identity` | प्लेटफ़ॉर्म ऑपरेटर की पहचान (`/trp/identity` पर भी उपलब्ध)। |
| `GET` | `/trp/identity/{profile_uuid}/` | एक होस्टेड VASP प्रोफ़ाइल की पहचान। |
| `POST` | `/trp/inquiries/{profile_uuid}/` | एक होस्टेड VASP को ट्रांसफ़र पूछताछ सबमिट करें। |
| `POST` | `/trp/inquiries/{profile_uuid}/wallets/{entry_uuid}/` | होस्टेड VASP के एक वॉलेट के लिए ट्रांसफ़र पूछताछ सबमिट करें (प्रति-वॉलेट Travel Address)। |
| `POST` | `/trp/callbacks/resolution/{token}/` | वह पूछताछ हल करें जो **Didit** ने आपको भेजी (स्वीकृत या अस्वीकृत)। |
| `POST` | `/trp/callbacks/confirmation/{token}/` | Didit द्वारा आपके लिए स्वीकृत ट्रांसफ़र की पुष्टि करें या उसे रद्द करें। |

दो TRP हेडर महत्वपूर्ण हैं:

* `api-version` - आप जिस TRP प्रोटोकॉल संस्करण का उपयोग करते हैं, उदाहरण के लिए `3.2.1`।
  पूछताछ और दोनों callback पर आवश्यक।
* `request-identifier` - अनुरोध के लिए आपका अद्वितीय ID, जो रिस्पॉन्स हेडर में वापस भेजा जाता है।
  पूछताछ और दोनों callback पर आवश्यक।

पूछताछ या callback endpoint पर बिना दोनों हेडर के किया गया अनुरोध `400` लौटाता है।

Didit का हर रिस्पॉन्स `api-version: 3.2.1` के साथ आता है और आपका `request-identifier` वापस भेजता है।

### GET /identity

प्लेटफ़ॉर्म ऑपरेटर की पहचान लौटाता है।
इसके लिए कोई हेडर आवश्यक नहीं है।

```bash theme={null}
curl https://trp.didit.me/identity
```

```json theme={null}
{
  "name": "Didit",
  "lei": "",
  "x509": ""
}
```

### GET /trp/identity/{profile_uuid}/

उस विशिष्ट VASP की पहचान लौटाता है जिसके साथ आप आदान-प्रदान करने वाले हैं। PII भेजने से पहले नाम और LEI सत्यापित करने के लिए इसका उपयोग करें।
जब Didit शुरुआत करता है, तो वह उलटी दिशा में भी यही जाँच करता है: यदि आपके endpoint द्वारा रिपोर्ट की गई पहचान अपेक्षित LEI या नाम से मेल नहीं खाती, तो एक्सचेंज निरस्त कर दिया जाता है।

```bash theme={null}
curl https://trp.didit.me/trp/identity/11111111-2222-3333-4444-555555555555/
```

```json theme={null}
{
  "name": "Bene CASP GmbH",
  "lei": "5493001KJTIIGC8Y1R12",
  "x509": ""
}
```

प्रोफ़ाइल मौजूद न होने या उसका Travel Rule सेटअप अक्षम होने पर `404` लौटाता है।

### POST /trp/inquiries/{profile_uuid}/

ट्रांसफ़र पूछताछ सबमिट करें। आप प्रेषक VASP हैं, और Didit का ग्राहक लाभार्थी VASP है।

```bash theme={null}
curl -X POST https://trp.didit.me/trp/inquiries/11111111-2222-3333-4444-555555555555/ \
  -H "Content-Type: application/json" \
  -H "api-version: 3.2.1" \
  -H "request-identifier: 7f6a1c1e-0a63-4b1f-9f6e-7dcd7c3f1a01" \
  -d '{
    "asset": { "dti": "X9J9K872S" },
    "amount": 250000000000000000,
    "callback": "https://trp.yourvasp.example/callbacks/inquiry/abc123",
    "IVMS101": {
      "originator": {
        "originatorPersons": [
          { "naturalPerson": { "name": { "nameIdentifier": [{ "primaryIdentifier": "Ruiz", "secondaryIdentifier": "Carlos", "nameIdentifierType": "LEGL" }] } } }
        ],
        "accountNumber": ["0x77ccff0cc624a53cd8b8d8703ced826710211ec7"]
      },
      "beneficiary": {
        "beneficiaryPersons": [
          { "naturalPerson": { "name": { "nameIdentifier": [{ "primaryIdentifier": "Diaz", "secondaryIdentifier": "Ana", "nameIdentifierType": "LEGL" }] } } }
        ],
        "accountNumber": ["0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb"]
      }
    }
  }'
```

| फ़ील्ड | प्रकार | विवरण |
| - | - | - |
| `asset.dti` | string | आवश्यक। ट्रांसफ़र की जा रही संपत्ति का Digital Token Identifier (ISO 24165)। इसके बिना पूछताछ `400` देती है; pre-3.2.0 `asset.slip0044` नहीं पढ़ा जाता। |
| `amount` | number | आवश्यक। संपत्ति की सबसे छोटी इकाई में पूरी राशि (DTI के दशमलव के अनुसार base units)। पूर्ण संख्या का कोई भी JSON संकेतन स्वीकार होता है, घातांक रूप भी, और अंकों की स्ट्रिंग भी। भिन्न, या दर्ज न हो सकने वाली बहुत बड़ी राशि `400` देती है। |
| `callback` | string | आवश्यक। आपकी ओर का पूर्ण सार्वजनिक `http(s)` URL, जहाँ Didit पूछताछ का निपटारा पोस्ट करता है (`https` अनुशंसित)। वही `callback` दोहराने वाला पुनः प्रयास उसी पूछताछ से मिलाया जाता है जिसे वह दोहराता है। |
| `IVMS101` | object | आवश्यक। IVMS 101 पेलोड: `originator.originatorPersons` और `beneficiary.beneficiaryPersons` (Didit हर एक का पहला `naturalPerson` पढ़ता है; कानूनी-व्यक्ति डेटा नहीं पढ़ा जाता), साथ में `accountNumber` वॉलेट सरणियाँ। |

इस चैनल पर संपत्तियाँ DTI से पहचानी जाती हैं, और एक DTI एक ही ब्लॉकचेन पर एक token की पहचान करता है।
Didit आज नौ नेटवर्क पर `BTC` (`4H95J0R2X`), `ETH` (`X9J9K872S`) और `USDC` को मैप करता है, और समय के साथ और संपत्तियाँ जोड़ी जाएँगी।
पूरी सूची के लिए [TRP परिसंपत्ति पहचानकर्ता](https://docs.didit.me/hi/transaction-monitoring/travel-rule.md#trp-एसेट-पहचानकर्ता) देखें।
जिस पूछताछ का DTI Didit नहीं पहचानता, उसे फिर भी स्वीकार किया जाता है, और DTI को asset code के रूप में लाभार्थी VASP तक पहुँचाया जाता है।

`200` रिस्पॉन्स का अर्थ है कि पूछताछ प्रोसेसिंग के लिए स्वीकार हो गई। `400` का अर्थ है TRP हेडर गायब हैं या body अमान्य है। `404` का अर्थ है कि प्रोफ़ाइल (या प्रति-वॉलेट पते का वॉलेट) अज्ञात या अक्षम है। `422` का अर्थ है कि अनुरोध किसी TRP एक्सटेंशन का उपयोग करता है: Didit कोई एक्सटेंशन समर्थित नहीं करता, इसलिए `api-extensions` हेडर या body में `extensions` कुंजी अस्वीकार की जाती है।
उसी `request-identifier` को दोबारा भेजना आइडेम्पोटेंट है: मूल पूछताछ दोहराई नहीं जाती, बल्कि फिर से उपयोग की जाती है।

इसके बाद Didit ग्राहक के एप्लिकेशन में इनबाउंड ट्रांसफ़र बनाता है और उसे ग्राहक की वॉलेट पता पुस्तिका और नीति के विरुद्ध हल करता है।
वह लाभार्थी का मिलान इस क्रम में करता है: पहले, प्रति-वॉलेट Travel Address द्वारा नामित वॉलेट से; अन्यथा `IVMS101.beneficiary.accountNumber` के पहले वॉलेट पते से; या, इनमें से कुछ न होने पर, ग्राहक की सत्यापित वॉलेट प्रविष्टियों के विरुद्ध `beneficiaryPersons[0].naturalPerson` नाम से।

जब Didit तुरंत उत्तर दे सकता है, तो `200` रिस्पॉन्स में उत्तर होता है:

* `{"approved": {"address": "...", "callback": "..."}}` जब पूछताछ अपने आप स्वीकृत हो गई हो। Didit यह स्वीकृति आपके `callback` पर अलग से पोस्ट नहीं करता।
* `{"rejected": "NOT_ENOUGH_COUNTERPARTY_DATA: inquiry carries no beneficiary identification"}` जब पूछताछ में न तो लाभार्थी की पहचान होती है और न ही वॉलेट पता, इसलिए हमेशा दोनों शामिल करें।
* `{"version": "3.2.1"}` जब निर्णय Didit ग्राहक की प्रतीक्षा करता है। **निपटारा** बाद में आपके `callback` URL पर POST के रूप में आता है, नीचे दिए दो body में से एक के साथ।

```json theme={null}
{
  "approved": {
    "address": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
    "callback": "https://trp.didit.me/trp/callbacks/confirmation/{token}/"
  }
}
```

```json theme={null}
{
  "rejected": "Wallet ownership denied by beneficiary VASP"
}
```

स्वीकृति स्वचालित हो सकती है, जब लाभार्थी VASP auto-accept सक्षम करता है और लाभार्थी संपत्ति की ब्लॉकचेन पर किसी सत्यापित वॉलेट प्रविष्टि से मेल खाता है। या लाभार्थी पक्ष पर मैन्युअल समीक्षा या वॉलेट-स्वामित्व प्रमाण के बाद आ सकती है। इसलिए पूछताछ और निपटारे के बीच देरी के लिए तैयार रहें।
पूछताछ कभी ऐसे वॉलेट से मेल नहीं खाती जिसे Didit ग्राहक ने किसी दूसरे VASP का दर्ज किया हो, और `originatingVASP` में दिया गया आपका VASP नाम ही Didit ग्राहक को ट्रांसफ़र के प्रेषक VASP के रूप में दिखाई देता है।
आपकी भेजी गई पूछताछ पर Didit कोई समय-सीमा नहीं लगाता, और यदि Didit ग्राहक उसे रद्द करता है, तो वह आपको कोई अस्वीकृति नहीं भेजता। इसलिए अपना खुद का टाइमआउट लागू करें।

स्वीकृति प्राप्त करने और ट्रांसफ़र को ऑन-चेन प्रसारित करने के बाद, वह `approved.callback` URL, जो आपको दिया गया था, उस पर POST करके एक्सचेंज बंद करें:

```bash theme={null}
curl -X POST "https://trp.didit.me/trp/callbacks/confirmation/{token}/" \
  -H "Content-Type: application/json" \
  -H "api-version: 3.2.1" \
  -H "request-identifier: 0b8e2f4a-6c1d-4e9a-8f3b-2d7c5a1e9f60" \
  -d '{ "txid": "0x5c504ed432cb51138bcf09aa5e8a410dd4a1e204ef84bfed1be16dfba1b22060" }'
```

यदि आप ट्रांसफ़र निरस्त करते हैं, तो इसके बजाय उसी URL पर `{ "canceled": "reason" }` भेजें।
`txid` लाभार्थी-पक्ष के ट्रांसफ़र को `FINISHED` पर ले जाता है; `canceled` उसे `CANCELLED` पर ले जाता है।
दोनों callback संभाले जाने पर `204` लौटाते हैं। अज्ञात token या ऐसे ट्रांसफ़र के लिए, जो अब उस callback की प्रतीक्षा नहीं कर रहा, `404` लौटता है। ऐसी body के लिए, जिसमें callback के दोनों फ़ील्ड में से कोई भी न हो, `400` लौटता है।

### Didit द्वारा आपको भेजी गई इंक्वायरी का समाधान

जब कोई Didit ग्राहक TRP के ज़रिए आपको ट्रांसफ़र भेजता है, तो Didit:

1. आपके इंक्वायरी URL के होस्ट की रूट पर मौजूद `/identity` लाता है (`https://{your-host}/identity`) और उसमें बताए गए नाम और LEI को ग्राहक की अपेक्षित जानकारी से मिलाता है। जब रूट Didit की डायरेक्टरी से आया हो, तो आपके `/identity` को उस डायरेक्टरी एंट्री का LEI बताना होगा।
2. आपके इंक्वायरी URL पर एक ट्रांसफ़र इंक्वायरी POST करता है, जिसकी बॉडी की संरचना ऊपर जैसी ही होती है: `asset.dti`, बेस-यूनिट में `amount` JSON नंबर के रूप में, एक `callback`, और `IVMS101` payload।

केवल `2xx` उत्तर को डिलीवर हुआ माना जाता है। `3xx` को अस्वीकार किया जाता है, क्योंकि रीडायरेक्ट फ़ॉलो नहीं किए जाते। किसी भी अन्य उत्तर को ग्राहक की ट्रांसफ़र टाइमलाइन पर आपके स्टेटस कोड के साथ दर्ज किया जाता है, जैसे `refused by counterparty (HTTP 403): ...`।

दोनों कॉल में दोनों TRP हेडर होते हैं, और Didit इन पर HTTP रीडायरेक्ट फ़ॉलो नहीं करता, इसलिए `/identity` और इंक्वायरी URL को सीधे सर्व करें।
अगर `/identity` पहुँच में नहीं है, कोई LEI नहीं बताता, या ग्राहक द्वारा दिए गए LEI से अलग LEI बताता है, या ऐसा नाम बताता है जो मेल नहीं खाता, तो Didit इंक्वायरी भेजने से पहले रुक जाता है और ग्राहक का ट्रांसफ़र `COUNTERPARTY_VASP_NOT_REACHABLE` पर चला जाता है।
अगर इसके बाद इंक्वायरी POST विफल होता है, या आपका endpoint उसका `4xx` या `5xx` स्टेटस देता है, तो भी ट्रांसफ़र `COUNTERPARTY_VASP_NOT_REACHABLE` पर चला जाता है।

उस इंक्वायरी में दिया गया `callback` Didit के रिज़ॉल्यूशन endpoint की ओर इशारा करता है (`/trp/callbacks/resolution/{token}/`)।
जवाब देने के लिए वही रिज़ॉल्यूशन बॉडी POST करें जिन्हें Didit खुद इस्तेमाल करता है: मंज़ूरी के लिए `{ "approved": { "address": "...", "callback": "..." } }` (आपका `callback` वह जगह है जहाँ Didit ऑन-चेन पुष्टि POST करेगा), या अस्वीकार के लिए `{ "rejected": "reason" }`।
इसके साथ दोनों TRP हेडर भेजें।
हैंडल होने के बाद Didit `204` देता है, `404` तब देता है जब ट्रांसफ़र अब रिज़ॉल्यूशन का इंतज़ार नहीं कर रहा, और `400` तब देता है जब मंज़ूरी में `address` न हो या `callback` एक सार्वजनिक `http(s)` URL न हो जिसे Didit कॉल कर सके।

मंज़ूरी के बाद Didit की ओर से ट्रांसफ़र `COMPLETED` पर चला जाता है। जब ग्राहक ऑन-चेन हैश बताता है, तो Didit पुष्टि के लिए आपके दिए गए callback पर `{ "txid": "..." }` POST करता है (या अगर ट्रांसफ़र पहले रद्द हो जाए, तो `{ "canceled": "reason" }`)।

> [!NOTE]
>
> कॉलबैक टोकन एक ही उद्देश्य के लिए होते हैं, उनका अनुमान नहीं लगाया जा सकता, और हर ट्रांसफ़र के लिए अलग से बनाए जाते हैं। पूरे कॉलबैक URL को गोपनीय मानें, और ध्यान रखें कि रिज़ॉल्यूशन केवल तब स्वीकार होता है जब ट्रांसफ़र अब भी उसका इंतज़ार कर रहा हो।

## ईमेल से पिकअप

अगर कोई प्रोटोकॉल चैनल आप तक नहीं पहुँचता और Didit ग्राहक ने आपका अनुपालन ईमेल दिया है, तो Didit ईमेल का सहारा लेता है: आपके अनुपालन संपर्क को एक संदेश मिलता है जिसमें प्रेषक VASP का नाम होता है और एक बार उपयोग होने वाला सुरक्षित पिकअप लिंक होता है।
इसके लिए कोई अकाउंट, API कुंजी या इंटीग्रेशन ज़रूरी नहीं है। लिंक का टोकन ही प्रमाणीकरण है।

लिंक खोलने पर लंबित विनिमय दिखता है। इसके नीचे का अंतर्निहित API, जिसे होस्टेड पेज आपकी ओर से चलाता है, सार्वजनिक है:

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

```json theme={null}
{
  "originator_vasp_name": "Origin CASP SL",
  "amount": "0.250000000000000000",
  "currency": "ETH",
  "beneficiary_wallet": "0xede2d7e4f5b097e6391ab6bbcf2f47a53f4778cb",
  "status": "AWAITING_COUNTERPARTY"
}
```

`amount` वही संग्रहित दशमलव मान है, जिसमें पूरे 18 दशमलव स्थान शामिल हैं।

```bash theme={null}
curl -X POST https://verification.didit.me/v3/travel-rule/pickup/{token}/respond/ \
  -H "Content-Type: application/json" \
  -d '{ "decision": "accept", "beneficiary_name": "Ana Diaz" }'
```

`decision` या तो `accept` होता है या `decline`। accept के मामले में, लाभार्थी का नाम वैसा ही दें जैसा आपके रिकॉर्ड में है, ताकि प्रेषक पक्ष नाम मिलान चला सके। या फिर अपना पूरा IVMS 101 रिस्पॉन्स `ivms_response` के रूप में भेजें, और उसमें दिया गया लाभार्थी नाम प्राथमिकता पाएगा।
decline के मामले में आप `decline_reason` दे सकते हैं (`data_mismatch`, `not_our_customer`, `wallet_not_hosted`, `sanctions`, `risk_appetite`, `jurisdiction`, `insufficient_data` या `other`) और `decline_detail` में 512 अक्षरों तक का विवरण दे सकते हैं, जो `other` के लिए अनिवार्य है।
अगर accept के साथ `beneficiary_name` नहीं है, तो उसे मिलान में गड़बड़ी माना जाता है, जब प्रेषक ने लाभार्थी का नाम दिया हो, जब तक प्रेषक ने नाम मिलान बंद न किया हो।
उत्तर के रूप में परिणामी `{"status": "..."}` मिलता है: नाम मेल खाने पर `COMPLETED`, मेल न खाने पर `COUNTERPARTY_MISMATCHED_DATA`, या decline के बाद `COUNTERPARTY_VASP_GENERAL_DECLINE`।
आप एक ही बार जवाब दे सकते हैं, जब तक ट्रांसफ़र आपके जवाब का इंतज़ार कर रहा हो। जवाब देने के बाद, ट्रांसफ़र रद्द होने के बाद, या उसकी पुष्टि की समय-सीमा निकल जाने के बाद, दोनों endpoint `410` लौटाते हैं, और अज्ञात टोकन पर `404` लौटता है।
इस अनुरोध में प्रेषक द्वारा साझा किए गए प्रेषक फ़ील्ड और IVMS 101 `ivms_request` दिखते हैं, जो आपके क्षेत्राधिकार की भाषा में होता है। जब तक आप जवाब नहीं देते, समय-सीमा से 72, 24 और 6 घंटे पहले आपको याद दिलाया जाता है।

## सनराइज़: ऐसे ट्रांसफ़र जो विनिमय से पहले सेटल हो गए

जब कोई ट्रांसफ़र Travel Rule विनिमय होने से पहले Didit ग्राहक के वॉलेट तक पहुँच जाता है (क्योंकि उस समय कोई साझा रेल मौजूद नहीं था), तब भी सेटलमेंट के बाद डेटा डिलीवर किया जा सकता है।

Didit ग्राहक को (जो आपका लाभार्थी प्रतिपक्ष है) अपने सामान्य चैनल से Travel Rule payload भेजें और उन्हें उसे रजिस्टर करने को कहें। वे [`POST /v3/travel-rule/inbound/`](https://docs.didit.me/hi/transaction-monitoring/travel-rule#डिपॉज़िट-के-बाद-सनराइज़-पंजीकरण) को डिपॉज़िट की चेन, `txid`, वॉलेट पता, राशि, मुद्रा और आपका प्रेषक डेटा के साथ कॉल करेंगे।
अपनी VASP पहचान (नाम, LEI और Travel Address) उस payload में `originating_vasp` के रूप में शामिल करें, ताकि Didit ग्राहक के ट्रांसफ़र रिकॉर्ड में दर्ज हो कि डिपॉज़िट किसने भेजा।
यह जानकारी केवल उसी ट्रांसफ़र पर रहती है और आपकी [डायरेक्टरी एंट्री](#didit-vasp-डायरेक्टरी-में-शामिल-होना) को कभी न बनाती है और न बदलती है।
LEI 20 अक्षरों का वैध LEI होना चाहिए और Travel Address भी वैध होना चाहिए, नहीं तो रजिस्ट्रेशन अस्वीकार हो जाएगा।

## Didit VASP डायरेक्टरी में शामिल होना

Didit एक VASP डायरेक्टरी रखता है, जिसे उसके ग्राहकों की आउटबाउंड रूटिंग संदर्भित करती है।
प्रविष्टियाँ इन स्रोतों से आती हैं:

* ESMA का अंतरिम MiCA रजिस्टर, जिसमें क्रिप्टो-एसेट सेवा प्रदाता सूचीबद्ध हैं, जिसे हर सप्ताह पढ़ा जाता है: यदि आप वहाँ सूचीबद्ध हैं, तो आपका नाम, LEI और गृह सदस्य राज्य।
* सार्वजनिक TRISA डायरेक्टरी, जिसे हर सप्ताह पढ़ा जाता है: आप कौन हैं, आपका देश, और TRISA में आपकी प्रविष्टि।
* वैश्विक LEI रजिस्टर, जो आपका LEI, अन्य कानूनी नाम और देश भरता है।
* ब्लॉकचेन एनालिटिक्स एट्रिब्यूशन, जब कोई गंतव्य वॉलेट आपके एक्सचेंज या कस्टडी सेवा से पहचाना जाता है: Didit आपकी प्रविष्टि जोड़ता है या उससे मिलाता है, और पहचाने गए नाम को एक उपनाम के रूप में रखता है।
* Didit स्टाफ़, जो प्रविष्टियों का क्यूरेशन करता है: सत्यापित रूटिंग पहचानकर्ता और नेटवर्क सूचियाँ, अनुपालन संपर्क, उपनाम, और ब्रांड उनकी इकाइयों के साथ।

Didit के किसी ग्राहक द्वारा आपके बारे में दी गई जानकारी, जैसे सनराइज़ पंजीकरण पर `originating_vasp` या किसी ट्रांसफ़र पर Travel Address, केवल उस ग्राहक के ट्रांसफ़र पर रहती है और आपकी प्रविष्टि को कभी नहीं बदलती।
आप जो ट्रांसफ़र पूछताछ किसी Didit ग्राहक को भेजते हैं, वह भी आपकी प्रविष्टि नहीं बनाती और न ही उसे अपडेट करती है।

आपकी प्रविष्टि आपको ट्रांसफ़र तब भेजती है जब उसमें सत्यापित `TRP` endpoint, भेजने वाले के लिए उपलब्ध कोई नेटवर्क सूची, या ईमेल फ़ॉलबैक के लिए कोई अनुपालन संपर्क हो।
आपके अपने किसी डोमेन का अनुपालन पता, जो अपने प्रतिक्रिया लिंक के माध्यम से अनुरोध का उत्तर देता है, एक ऐसा संपर्क बन जाता है जिसका हर Didit ग्राहक उपयोग कर सकता है।
जब तक आपकी प्रविष्टि में कोई रूट नहीं है, कोई Didit ग्राहक आप तक केवल उन फ़ील्ड्स के माध्यम से पहुँचता है जो वह हर ट्रांसफ़र के साथ भेजता है: आपका Travel Address, आपका नेटवर्क पहचानकर्ता (`counterparty_gtr_vasp_code`, `counterparty_trust_membership_id`, `counterparty_verifyvasp_id`, या `counterparty_sygna_vasp_code`), या आपका अनुपालन ईमेल (`counterparty_vasp_email`)।
आज पहुँच योग्य होने के लिए, अपना Travel Address, नेटवर्क पहचानकर्ता, या अनुपालन ईमेल उन Didit ग्राहकों के साथ साझा करें जिनके साथ आप काम करते हैं।

## प्रतिपक्ष VASP के लिए चेकलिस्ट

* **आप पहले से TRP चलाते हैं**: Didit ग्राहक के साथ अपना Travel Address और LEI साझा करें - उसके `BTC`, `ETH` और `USDC` ट्रांसफ़र आपके endpoint पर मानक TRP पूछताछ के रूप में पहुँचेंगे। अपनी पूछताछ प्रतिक्रिया में उत्तर दें: बाद का उत्तर Didit के सार्वजनिक TRP होस्ट की माँग करता है, जो अभी लाइव नहीं है।
* **आप GTR, TRUST, या VerifyVASP पर हैं**: अपना नेटवर्क पहचानकर्ता साझा करें; जब Didit ग्राहक वहाँ अपनी स्वयं की सदस्यता रखता है, तब ट्रांसफ़र उस नेटवर्क के माध्यम से पहुँचते हैं। Didit आपका GTR या VerifyVASP उत्तर नेटवर्क से पढ़ता है, लेकिन TRUST उत्तर नहीं पढ़ता, इसलिए जब TRUST पर कोई एक्सचेंज पूरा करना हो तो एक TRP endpoint भी प्रकाशित करें। [Travel Rule नेटवर्क](https://docs.didit.me/hi/transaction-monitoring/travel-rule-networks.md) बताता है कि यह कब बदलता है।
* **आप Sygna Bridge पर हैं**: अपना Sygna VASP कोड साझा करें; जब Didit ग्राहक की अपनी Sygna सदस्यता हो, तब आपका अनुमति-संबंधी उत्तर ट्रांसफ़र को पूरा करता है या अस्वीकार करता है, जब Didit उसे पोलिंग से पढ़ लेता है।
* **आपके पास अभी कोई प्रोटोकॉल चैनल नहीं है**: Didit ग्राहक को निगरानी में रखा गया अनुपालन ईमेल पता दें - आपको पिकअप लिंक मिलेंगे और आप बिना किसी इंटीग्रेशन के होस्टेड पेज से उत्तर दे सकेंगे।
* **कोई ट्रांसफ़र पहले ही सेटल हो चुका है**: Didit ग्राहक के माध्यम से डेटा [सनराइज़ पंजीकरण](#सनराइज़-ऐसे-ट्रांसफ़र-जो-विनिमय-से-पहले-सेटल-हो-गए) से भेजें।
* **आप Didit VASPs को आउटबाउंड ट्रांसफ़र भी करना चाहते हैं**: अपने प्रतिपक्ष से उनकी Didit Travel Rule सेटिंग्स से उनका Travel Address माँगें, और Didit का सार्वजनिक TRP होस्ट लाइव होने के बाद [POST /trp/inquiries](#post-/trp/inquiries//) को कॉल करें।

## अगले चरण

> [card] [Travel Rule](https://docs.didit.me/hi/transaction-monitoring/travel-rule.md)
>
> ग्राहक-उन्मुख उत्पाद: लाइफ़साइकल, सेटिंग्स, रेल्स, और /v3/ API।

> [card] [वॉलेट स्वामित्व विजेट](https://docs.didit.me/hi/transaction-monitoring/wallet-ownership-widget.md)
>
> जब कोई वॉलेट स्व-होस्टेड होता है, तब लाभार्थी-पक्ष के स्वामित्व प्रमाण कैसे एकत्र किए जाते हैं।

> [card] [सनराइज़ पंजीकरण](https://docs.didit.me/hi/transaction-monitoring/travel-rule.md#डिपॉज़िट-के-बाद-सनराइज़-पंजीकरण)
>
> उन डिपॉज़िट के लिए Travel Rule डेटा पंजीकृत करना जो ऑन-चेन पहले ही सेटल हो चुके हैं।

> [card] [webhook](https://docs.didit.me/hi/integration/webhooks.md)
>
> Didit ग्राहक अपनी ओर से हर एक्सचेंज स्थिति परिवर्तन कैसे देखते हैं।


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