> ## 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.

# KYT समस्या निवारण: सामान्य समस्याएँ और समाधान

> Didit के KYT की सामान्य समस्याएँ: txn_id टकराव, नियम न चलना, AML टाइमआउट, webhook हस्ताक्षर बेमेल और मुद्रा त्रुटियाँ, कारण व समाधान सहित।

सामान्य लेन-देन निगरानी समस्याओं का संदर्भ, जिसमें लक्षण, कारण और समाधान दिए गए हैं।

## `txn_id` की डुप्लीकेट त्रुटि

**लक्षण.** लेन-देन सबमिट करने पर `400` मिलता है, जिसमें `transaction_id` फ़ील्ड पर `A transaction with this transaction_id already exists.` लिखा होता है। या, जब दो समान अनुरोध एक साथ आते हैं, तो `409` मिलता है।

**कारण.** `txn_id` (जो `transaction_id` आप भेजते हैं) हर एप्लिकेशन के लिए अद्वितीय होता है।
Didit दूसरे लेन-देन को उसी `transaction_id` के साथ अस्वीकार करता है और मौजूदा रिकॉर्ड वापस नहीं करता।

**समाधान.**

* `txn_id` अपनी ओर से निर्धारित तरीके से बनाएँ (उदाहरण के लिए, अपनी लेन-देन DB की ID का उपयोग करें)।
* पुनः प्रयास के दौरान डुप्लीकेट `transaction_id` के लिए `400` या `409` मिलने पर, दोबारा सबमिट करने के बजाय मौजूदा लेन-देन खोजें: पहले रिस्पॉन्स के `uuid` का उपयोग करके [`GET /v3/transactions/{uuid}/`](https://docs.didit.me/hi/management-api/transactions/get) से उसे पढ़ें, या `transaction.created` webhook में आपके `txn_id` के साथ आने वाला `transaction_id` (Didit uuid) इस्तेमाल करें।
* यदि अनुरोध पुनः प्रयास नहीं था, तो नए लेन-देन को उसका अपना `transaction_id` दें।

## नियम लागू नहीं हो रहा

**लक्षण.** आपने ऐसा नियम बनाया है जो मेल खाना चाहिए, लेकिन `rule_runs[]` में कोई भी लेन-देन `matched: true` के साथ नहीं दिख रहा।

**कारण और समाधान.**

* **एप्लिकेशन सैंडबॉक्स मोड में है** - सैंडबॉक्स एप्लिकेशन नियम मूल्यांकन, AML स्क्रीनिंग, बिलिंग, और `transaction.created` व `transaction.status.updated` webhooks को छोड़ देता है। सक्षम होने पर Travel Rule एक्सचेंज फिर भी चलते हैं, [Didit Test VASP](https://docs.didit.me/hi/transaction-monitoring/travel-rule-sandbox.md) के विरुद्ध, और `environment: sandbox` चिह्नित `travel_rule.status.updated` webhooks भेजते हैं। आपके नियमों का मोड चाहे जो हो, `rule_runs` खाली आता है और स्कोर `0` रहता है, और लेन-देन `APPROVED` ही रहता है, जब तक कोई समाप्त होने वाला Travel Rule ट्रांसफ़र आपका `timeout_outcome` लागू न करे। लेन-देन रिस्पॉन्स पर `environment` जाँचें: `"sandbox"` का अर्थ है कि उसका कभी मूल्यांकन नहीं हुआ। नियम को लाइव करने से पहले उसे कैसे जाँचें, यह जानने के लिए [सैंडबॉक्स में लेन-देन निगरानी](https://docs.didit.me/hi/integration/sandbox-testing.md#सैंडबॉक्स-में-लेन-देन-निगरानी) देखें।
* **नियम का मोड `DISABLED` या `TEST` है** - *Rules → \[rule] → Mode* जाँचें। केवल `ACTIVE` नियम स्कोरिंग में योगदान देते हैं; `TEST` नियमों का मूल्यांकन होता है, लेकिन वे स्टेटस को प्रभावित नहीं करते।
* **Scope फ़िल्टर लेन-देन को बाहर रखता है** - उदाहरण के लिए, यदि scope `transaction_type = finance` पर सेट है, तो वह `travelRule` लेन-देन से मेल नहीं खाएगा।
* **एग्रीगेशन विंडो ज़रूरत से छोटी है** - "30 दिनों में 20 लेन-देन" वाला नियम केवल 15 लेन-देन के बाद मेल नहीं खाएगा।
* **शर्त का फ़ील्ड null है** - उदाहरण के लिए, नियम `counterparty.country_code` जाँचता है, लेकिन आपने प्रतिपक्ष भेजा ही नहीं।
* **मुद्रा रूपांतरण** - नियम `amount_in_default_currency` पर थ्रेशोल्ड लगाता है; यदि आपके एप्लिकेशन की डिफ़ॉल्ट मुद्रा लेन-देन की मुद्रा से अलग है, तो परिवर्तित राशि थ्रेशोल्ड से नीचे हो सकती है।

किसी पिछले लेन-देन को दोबारा चलाकर देखने के लिए कि नियम क्यों लागू हुआ या नहीं हुआ, *Rules → \[rule] → Backtest* सुविधा का उपयोग करें।

## नियम हर चीज़ पर लागू हो रहा है

**लक्षण.** कोई नियम 90% से अधिक लेन-देन पर लागू हो रहा है - आपकी समीक्षा कतार भर गई है।

**कारण.** शर्तें बहुत व्यापक हैं, या थ्रेशोल्ड बहुत कम हैं।

**समाधान.**

* लागू होने का दायरा सीमित करने के लिए `scope` फ़िल्टर जोड़ें (उदाहरण के लिए, केवल आउटबाउंड, या केवल कुछ लेन-देन प्रकार)।
* थ्रेशोल्ड बढ़ाएँ (राशि, लेन-देन की गति की गिनतियाँ)।
* नियम को एक सप्ताह के लिए `TEST` मोड में रखें - `rule_runs` का विश्लेषण करें ताकि मिलान दर देखी जा सके, और उसे फिर से सक्षम करने से पहले शर्तें कड़ी करें।

## क्रिप्टो स्क्रीनिंग का समय समाप्त हो गया

**लक्षण.** लेन-देन `status: APPROVED` के साथ पूरा हो गया, लेकिन किसी वॉलेट, लेन-देन हैश, या क्रिप्टो स्क्रीनिंग प्रदाता के लिए `provider_results[]` एरे में `status: FAILED` दिखता है।

**कारण.**

* प्रदाता का API कुछ समय के लिए उपलब्ध नहीं था।
* क्वेरी का समय समाप्त हो गया (आमतौर पर \~10 सेकंड)।

**समाधान.**

* प्रदाता की समस्याओं से लेन-देन कभी विफल नहीं होते - एनरिचमेंट सर्वोत्तम प्रयास के आधार पर होता है।
* यदि कोई विशेष प्रदाता बार-बार विफल हो, तो उसकी उसकी स्थिति का पेज देखें या सहायता टिकट खोलें।
* वैकल्पिक प्रदाताओं पर भेजने के लिए *Settings → Transaction Monitoring → Providers* में प्रदाता प्राथमिकताएँ कॉन्फ़िगर करने पर विचार करें।

## IP एनरिचमेंट गायब है

**लक्षण.** किसी लेन-देन का `applicant.ip_enrichment` या तो मौजूद नहीं है या अधूरा है।

**कारण.**

* सबमिशन में `applicant.device.ip` नहीं है।
* IP निजी / आरक्षित (रूटेबल नहीं है) है।
* सभी एनरिचमेंट प्रदाता अस्थायी रूप से उपलब्ध नहीं थे।

**समाधान.**

* अपने क्लाइंट या सर्वर में सबमिट करने वाले उपयोगकर्ता का IP कैप्चर करें और हर लेन-देन के साथ भेजें।
* केवल रूटेबल IP का उपयोग करें - Didit निजी रेंज को चुपचाप छोड़ देता है।
* प्रदाता की स्थिति जाँचने के लिए कंसोल में *Settings → Status* देखें।

## Webhook हस्ताक्षर मेल नहीं खा रहा

**लक्षण.** आपका endpoint इवेंट अस्वीकार कर रहा है, क्योंकि हस्ताक्षर मेल नहीं खाता।

**कारण.**

* raw body बदल दी गई है (JSON को अलग whitespace के साथ दोबारा स्ट्रिंगीफ़ाई किया गया है)।
* गलत सीक्रेट।
* एक ही URL के कई webhook गंतव्य - हस्ताक्षर हर webhook गंतव्य के लिए अलग होते हैं।

**समाधान.**

* **रॉ अनुरोध बॉडी पर हस्ताक्षर करें**, न कि पार्स किए गए JSON पर। कई फ़्रेमवर्क रॉ-बॉडी मिडलवेयर देते हैं।
* यदि सीक्रेट से छेड़छाड़ हुई हो, तो उसे रोटेट करें: *Webhook destinations → \[destination] → Rotate secret*।
* सीक्रेट में भ्रम से बचने के लिए हर URL के लिए केवल एक webhook गंतव्य रखें।

## Webhook नहीं पहुँच रहा

**लक्षण.** लेन-देन बन रहे हैं, लेकिन webhooks कभी नहीं पहुँचते।

**कारण.**

* webhook गंतव्य का `enabled` `false` है।
* URL सार्वजनिक रूप से पहुँच योग्य नहीं है।
* बार-बार विफलताओं के बाद webhook गंतव्य अपने आप बंद हो गया।
* इवेंट `subscribed_events` में नहीं है।

**समाधान.**

* टेस्ट इवेंट भेजें: *Webhook destinations → \[destination] → Send test*।
* हाल की डिलीवरी जाँचें: *Webhooks → \[destination] → Deliveries*। बॉडी और हेडर के साथ 4xx/5xx रिस्पॉन्स देखें।
* बंद किए गए webhook गंतव्यों को फिर से सक्षम करें।

## मुद्रा रूपांतरण सही नहीं लग रहा

**लक्षण.** `amount_in_default_currency` आपकी अपेक्षित दर से मेल नहीं खाता।

**कारण.**

* FX दर `txn_date` पर मिड-मार्केट दर है।
* पिछली तारीख़ वाले लेन-देन उस तारीख़ की ऐतिहासिक दर का उपयोग करते हैं।
* कुछ मुद्राओं (दुर्लभ FX) के अपडेट अंतराल अधिक लंबे होते हैं।

**समाधान.**

* प्रदर्शन के लिए `amount` और `currency` (मूल) का उपयोग करें।
* `amount_in_default_currency` का उपयोग केवल आंतरिक नियम थ्रेशोल्ड के लिए करें।
* ऑडिट के लिए, लेन-देन रिकॉर्ड मूल्यांकन के समय इस्तेमाल हुई रूपांतरण दर को सुरक्षित रखता है।

## vendor\_data पर ब्लॉकलिस्ट मिलान नहीं हो रहा

**लक्षण।** आपने `vendor_data` से एक व्यवसाय को ब्लॉकलिस्ट किया था, फिर भी उस प्रतिपक्ष वाला लेन-देन पास हो गया।

**कारण।**

* payload में मौजूद प्रतिपक्ष के पास `vendor_data` नहीं है। यह बाहरी स्नैपशॉट के रूप में संग्रहीत है।
* `vendor_data` के अक्षरों की स्थिति अलग है।

**समाधान।**

* जब प्रतिपक्ष आपके प्लेटफ़ॉर्म पर मौजूद कोई इकाई हो, तो हमेशा `counterparty.vendor_data` भेजें।
* हर जगह एक ही अक्षर-स्थिति का उपयोग करें। `vendor_data` केस-संवेदी है।

## AWAITING\_USER में अटके लेन-देन

**लक्षण।** लेन-देन `AWAITING_USER` में अटके हैं, क्योंकि उपयोगकर्ता कभी रेमेडिएशन सत्र पूरा नहीं करता।

**कारण।**

* उपयोगकर्ता ने रेमेडिएशन सत्र का URL नहीं खोला।
* रेमेडिएशन सत्र की समय-सीमा समाप्त हो गई।
* लेन-देन एक Travel Rule ट्रांसफ़र है, जिसे `travel-rule-pending-action` जैसे लाइब्रेरी नियम ने `AWAITING_USER` में भेजा है। Didit Travel Rule लेन-देन के लिए अपना डिफ़ॉल्ट रेमेडिएशन सत्र नहीं बनाता, इसलिए जब तक नियम अपना रेमेडिएशन वर्कफ़्लो नाम न दे, भेजने के लिए कोई लिंक नहीं होता।

**समाधान।**

* लेन-देन के रिस्पॉन्स में `remediation_session_url` वह लिंक है जो आपको भेजना है। यह लिंक उपयोगकर्ता को दोबारा भेजें।
* Travel Rule लेन-देन के लिए, ट्रांसफ़र को उसके **Travel Rule** टैब से हल करें, फिर लेन-देन की स्थिति खुद बदलें, क्योंकि ट्रांसफ़र हल करने से लेन-देन अपने-आप `AWAITING_USER` से बाहर नहीं आता।
* रेमेडिएशन सत्र [KYC क्विकस्टार्ट](https://docs.didit.me/hi/getting-started/quick-start.md) वाले पैटर्न का ही पालन करते हैं। पूरा होने की सूचना देने वाले webhook की सदस्यता लें।
* यदि रेमेडिएशन कभी पूरा न हो, तो अटके लेन-देन समाप्त करने के लिए अपने सिस्टम में समय-सीमा सेट करें।

## बनाने के अनुरोध पर रेट लिमिट

**लक्षण।** उच्च-वॉल्यूम बर्स्ट के दौरान `429 Too Many Requests` मिलता है।

**समाधान।**

* `Retry-After` हेडर का सम्मान करें।
* बर्स्ट ट्रैफ़िक के लिए क्लाइंट-साइड थ्रॉटलिंग करें।
* सिद्ध प्रोडक्शन वॉल्यूम के लिए उच्च सीमा चाहिए तो सहायता से संपर्क करें।

[रेट लिमिटिंग](https://docs.didit.me/hi/integration/rate-limiting.md) भी देखें।

## अगले कदम

> [card] [इंटीग्रेशन गाइड](https://docs.didit.me/hi/transaction-monitoring/integration-guide.md)
>
> पूर्ण इंटीग्रेशन पैटर्न।

> [card] [नियम](https://docs.didit.me/hi/transaction-monitoring/rules.md)
>
> नियमों का मूल्यांकन कैसे होता है।

> [card] [webhook](https://docs.didit.me/hi/transaction-monitoring/webhooks.md)
>
> webhook की कार्यप्रणाली।


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