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

​
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}/ से उसे पढ़ें, या 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 के विरुद्ध, और environment: sandbox चिह्नित travel_rule.status.updated webhooks भेजते हैं। आपके नियमों का मोड चाहे जो हो, rule_runs खाली आता है और स्कोर 0 रहता है, और लेन-देन APPROVED ही रहता है, जब तक कोई समाप्त होने वाला Travel Rule ट्रांसफ़र आपका timeout_outcome लागू न करे। लेन-देन रिस्पॉन्स पर environment जाँचें: "sandbox" का अर्थ है कि उसका कभी मूल्यांकन नहीं हुआ। नियम को लाइव करने से पहले उसे कैसे जाँचें, यह जानने के लिए सैंडबॉक्स में लेन-देन निगरानी देखें।
  • नियम का मोड 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 क्विकस्टार्ट वाले पैटर्न का ही पालन करते हैं। पूरा होने की सूचना देने वाले webhook की सदस्यता लें।
  • यदि रेमेडिएशन कभी पूरा न हो, तो अटके लेन-देन समाप्त करने के लिए अपने सिस्टम में समय-सीमा सेट करें।

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

लक्षण। उच्च-वॉल्यूम बर्स्ट के दौरान 429 Too Many Requests मिलता है। समाधान।
  • Retry-After हेडर का सम्मान करें।
  • बर्स्ट ट्रैफ़िक के लिए क्लाइंट-साइड थ्रॉटलिंग करें।
  • सिद्ध प्रोडक्शन वॉल्यूम के लिए उच्च सीमा चाहिए तो सहायता से संपर्क करें।
रेट लिमिटिंग भी देखें।

​
अगले कदम

इंटीग्रेशन गाइड

पूर्ण इंटीग्रेशन पैटर्न।

नियम

नियमों का मूल्यांकन कैसे होता है।

webhook

webhook की कार्यप्रणाली।
अंतिम संशोधन 7 नवंबर 2026