ब्लॉग · 21 मई 2026

AWAITING_USER: फ़्लैग किए गए लेन-देन के लिए ऑटो-सुधार (HI)

एक हार्ड डिक्लाइन के बजाय, एक फ़्लैग किया गया लेन-देन रुक सकता है, उपयोगकर्ता से एक कदम-दर-कदम कार्रवाई के लिए कह सकता है — जैसे री-केवाईसी या धन का प्रमाण — और एक बार जब वे इसे साफ़ कर देते हैं तो स्वचालित रूप से फिर से शुरू हो.

द्वारा Didit21 मई 2026अपडेट किया गया 21 मई 2026

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

Didit के लेन-देन निगरानी API में इस अंतर के लिए एक चौथी स्थिति बनाई गई है: AWAITING_USER। बाइनरी अनुमोदन-या-अस्वीकृति के बजाय, एक फ़्लैग किया गया लेन-देन रुक सकता है, उपयोगकर्ता से एक विशिष्ट कार्रवाई का अनुरोध कर सकता है - पहचान को फिर से सत्यापित करें, धन का प्रमाण प्रदान करें - और जैसे ही वे इसे साफ़ करते हैं, स्वचालित रूप से फिर से शुरू हो जाता है। घर्षण केवल वहीं होता है जहाँ जोखिम होता है, और इसकी लागत बाकी सब की तरह प्रति लेन-देन $0.02 ही होती है।

यह मार्गदर्शिका बताती है कि AWAITING_USER पथ कैसे काम करता है और इसे अपने प्रवाह में कैसे जोड़ा जाए।

मुख्य बातें

AWAITING_USER चार लेन-देन स्थितियों में से एक है — APPROVED, IN_REVIEW, और DECLINED के साथ — ताकि सुधार एक प्रथम-श्रेणी का परिणाम हो, न कि एक वर्कअराउंड।
एक फ़्लैग किया गया लेन-देन विफल होने के बजाय रुक जाता है, उपयोगकर्ता से एक स्टेप-अप कार्रवाई का अनुरोध करता है, और एक बार जब कार्रवाई साफ़ हो जाती है तो स्वचालित रूप से फिर से शुरू हो जाता है।
स्टेप-अप री-केवाईसी, धन का प्रमाण अपलोड, या कोई भी सत्यापन चरण हो सकता है जो एकीकृत /v3/ API पर उत्पन्न होता है।
वेबहुक लूप को चलाते हैं — transaction.status.updated तब सक्रिय होता है जब लेन-देन AWAITING_USER में प्रवेश करता है और छोड़ता है।
वही स्थिति केस प्रबंधन में भी मौजूद है, ताकि एक विश्लेषक एक अलर्ट को AWAITING_USER में ले जा सके और उपयोगकर्ता को इसे साफ़ करने दे सके।
प्रति लेन-देन $0.02, कोई न्यूनतम नहीं। सुधार के दौरान उत्पन्न एक री-केवाईसी या एएमएल जांच को उसकी अपनी प्रकाशित दर पर बिल किया जाता है।

AWAITING_USER क्या करता है

जब कोई नियम सक्रिय होता है, तो इंजन एक स्थिति असाइन करता है। चार में से तीन परिचित हैं: APPROVED लेन-देन को आगे बढ़ने देता है, IN_REVIEW एक विश्लेषक के लिए एक अलर्ट खोलता है, और DECLINED इसे ब्लॉक करता है। चौथा, AWAITING_USER, कुछ अलग करता है - यह लेन-देन को निलंबित कर देता है और संकेत देता है कि उपयोगकर्ता को इसे हल करने से पहले कुछ करना होगा।

संक्षेप में: एक हस्तांतरण एक उच्च-मूल्य या उच्च-वेग नियम को ट्रिप करता है, इंजन AWAITING_USER लौटाता है, आपका एप्लिकेशन उपयोगकर्ता को अनुरोधित चरण (एक नया जीवंतता जांच, एक दस्तावेज़ अपलोड, धन के स्रोत की घोषणा) को पूरा करने के लिए प्रेरित करता है, और सत्यापन सत्र प्लेटफ़ॉर्म पर वापस फ़ीड करता है। एक बार जब चरण साफ़ हो जाता है, तो लेन-देन का पुनर्मूल्यांकन होता है और APPROVED पर चला जाता है (या यदि नए सबूत चीजों को बदतर बनाते हैं तो बढ़ जाता है)। किसी विश्लेषक को इसकी देखभाल करने की आवश्यकता नहीं है।

यह क्यों मायने रखता है

कठिन अस्वीकृति महंगी होती है। प्रत्येक झूठी-सकारात्मक ब्लॉक एक निराश वैध ग्राहक, एक समर्थन टिकट, और अक्सर एक छूटा हुआ खाता होता है। लेकिन फ़्लैग किए गए भुगतानों को पास होने देना ही कंपनियों को प्रवर्तन कार्रवाइयों में डालता है। पारंपरिक समाधान - एक मैनुअल सुधार कतार - एक लागत को दूसरी के लिए बदल देता है: विश्लेषक का समय, धीमी टर्नअराउंड, और दिनों तक रुका हुआ लेन-देन।

AWAITING_USER उस ट्रेड-ऑफ को समाप्त कर देता है। उपयोगकर्ता काम करता है, उसी क्षण, घर्षण के बिंदु पर - ठीक उसी समय जब वे इसे साफ़ करने के लिए प्रेरित होते हैं क्योंकि उनका अपना लेन-देन प्रतीक्षारत है। आप जोखिम को पकड़ते हैं, आप ग्राहक को बनाए रखते हैं, और आप एक दस्तावेज़ का पीछा करने के लिए एक विश्लेषक को भुगतान नहीं करते हैं। यह एक अनुपालन नियंत्रण के बीच का अंतर है जिसकी कीमत आपको ग्राहकों को चुकानी पड़ती है और एक जो चुपचाप अपना काम करता है।

तकनीकी विवरण

एक लेन-देन जिसे इंजन सुधार के लिए रूट करता है, AWAITING_USER स्थिति और उन नियमों के साथ वापस आता है जिन्होंने इसे ट्रिगर किया था:

{
  "transaction_id": "txn_77c9e2",
  "status": "AWAITING_USER",
  "risk_score": 71,
  "triggered_rules": [
    { "name": "उच्च-मूल्य हस्तांतरण - पहले 30 दिन", "bundle": "AML/CTF", "action": "CHANGE_STATUS" }
  ],
  "required_action": "PROOF_OF_FUNDS",
  "alert_id": "alrt_5e3f10"
}

आप उपयोगकर्ता को संकेत देकर और एकीकृत /v3/ API पर सत्यापन चरण उत्पन्न करके प्रतिक्रिया करते हैं। जब चरण पूरा हो जाता है, तो एक वेबहुक आपको बताता है कि लेन-देन आगे बढ़ गया है:

# वेबहुक पेलोड: transaction.status.updated
{
  "event": "transaction.status.updated",
  "transaction_id": "txn_77c9e2",
  "previous_status": "AWAITING_USER",
  "status": "APPROVED"
}

वेबहुक। transaction.created और transaction.status.updated की सदस्यता लें। स्थिति-अपडेटेड इवेंट तब सक्रिय होता है जब लेन-देन AWAITING_USER में प्रवेश करता है और जब यह छोड़ता है - ताकि आपका लेजर और आपका यूआई बिना पोलिंग के सिंक में रहें।

मूल्य। प्रति लेन-देन $0.02। सुधार चरण को उसकी अपनी प्रकाशित दर पर बिल किया जाता है: उपयोगकर्ता सत्यापन दरों पर एक री-केवाईसी, $0.20 पर एक फ़्लैग किए गए पक्ष पर एक एएमएल जांच।

सुधार लूप, चरण-दर-चरण

एक नियम ट्रिप करें। एक लेन-देन एक सीमा को पार करता है जिसे आपकी नीति कहती है कि उसे अस्वीकार करने के बजाय सुधारा जाना चाहिए - मान लीजिए, एक नए खाते से पहला उच्च-मूल्य हस्तांतरण।
रुको, विफल मत हो। इंजन DECLINED के बजाय AWAITING_USER लौटाता है, जिसमें आवश्यक कार्रवाई संलग्न होती है।
उपयोगकर्ता को संकेत दें। आपका एप्लिकेशन स्टेप-अप को सतह पर लाता है - एक जीवंतता पुनः जांच, एक दस्तावेज़ अपलोड, धन के स्रोत की घोषणा - और सत्यापन सत्र उत्पन्न करता है।
उपयोगकर्ता इसे साफ़ करता है। उपयोगकर्ता उसी प्रवाह के भीतर चरण को पूरा करता है जिसमें वे पहले से थे।
स्वचालित रूप से फिर से शुरू करें। लेन-देन नए सबूतों के साथ फिर से मूल्यांकन करता है और APPROVED पर चला जाता है - या यदि सबूत जोखिम बढ़ाते हैं तो IN_REVIEW/DECLINED पर बढ़ जाता है। एक transaction.status.updated वेबहुक आपके बैकएंड को दोनों तरह से बताता है।

क्योंकि केस प्रबंधन में वही AWAITING_USER स्थिति मौजूद है, एक विश्लेषक जो IN_REVIEW अलर्ट पर काम कर रहा है, उसे खुद हल करने के बजाय उपयोगकर्ता को वापस भेज सकता है - अलर्ट OPEN → INVESTIGATING → AWAITING_USER के माध्यम से चलता है और उपयोगकर्ता के जवाब देने के बाद हल हो जाता है।

उपयोग के मामले

फिनटेक — हाल ही में ऑनबोर्ड किए गए खाते से पहला उच्च-मूल्य हस्तांतरण ग्राहक को ब्लॉक करने के बजाय धन के प्रमाण के लिए रुक जाता है।
क्रिप्टो — उच्च जोखिम वाले वॉलेट में एक आउटबाउंड हस्तांतरण निपटान से पहले धन के स्रोत की घोषणा के लिए रुक जाता है।
ऋण — एक संवितरण जो एक सिंथेटिक-पहचान संकेत को ट्रिप करता है, री-केवाईसी जीवंतता जांच के लिए रुक जाता है।
मार्केटप्लेस — एक विक्रेता भुगतान जो एक वेग नियम को ट्रिप करता है, धन जारी होने से पहले पुनः सत्यापन के लिए रुक जाता है।
आईगेमिंग — एक जमा-वेग स्पाइक एक स्टेप-अप जांच के लिए रुक जाता है, जो एक जिम्मेदार-गेमिंग टचपॉइंट के रूप में भी काम करता है।

Didit के साथ कैसे एकीकृत करें

अपनी सुधार नीति तय करें। बिजनेस कंसोल में, सेट करें कि कौन से नियम DECLINED के बजाय AWAITING_USER पर रूट करते हैं, और प्रत्येक कौन सी स्टेप-अप कार्रवाई का अनुरोध करता है।
लेन-देन भेजें। पैसे चलने पर POST /v3/transactions/, एक स्थिर transaction_id और vendor_data के साथ प्रत्येक को उसके उपयोगकर्ता से लिंक करें।
विराम को संभालें। जब कोई लेन-देन AWAITING_USER लौटाता है, तो उपयोगकर्ता को संकेत दें और /v3/ API पर सत्यापन चरण उत्पन्न करें।
पुनः शुरू होने की प्रतीक्षा करें। एक बार जब उपयोगकर्ता चरण साफ़ कर देता है तो लेन-देन को जारी करने या रोकने के लिए transaction.status.updated पर प्रतिक्रिया करें।

क्योंकि यह सब एकीकृत /v3/ API पर है, एक फ़्लैग किए गए लेन-देन द्वारा उत्पन्न सुधार केवाईसी वही केवाईसी है जिसके साथ आप उपयोगकर्ताओं को ऑनबोर्ड करते हैं - एक पहचान-और-धोखाधड़ी प्लेटफ़ॉर्म, एंड टू एंड।

अक्सर पूछे जाने वाले प्रश्न

AWAITING_USER क्या है?

यह चार लेन-देन स्थितियों में से एक है। एक हार्ड डिक्लाइन के बजाय, एक फ़्लैग किया गया लेन-देन रुक जाता है और एक उपयोगकर्ता कार्रवाई का अनुरोध करता है - पुनः सत्यापन या धन का प्रमाण - फिर एक बार जब उपयोगकर्ता इसे साफ़ कर देता है तो स्वचालित रूप से फिर से शुरू हो जाता है।

क्या लेन-देन अपने आप फिर से शुरू होता है?

हाँ। एक बार जब अनुरोधित चरण साफ़ हो जाता है, तो लेन-देन का पुनर्मूल्यांकन होता है और स्वचालित रूप से APPROVED पर चला जाता है - या यदि नए सबूत जोखिम बढ़ाते हैं तो बढ़ जाता है। परिवर्तन पर एक transaction.status.updated वेबहुक सक्रिय होता है।

स्टेप-अप क्या हो सकता है?

एकीकृत /v3/ API पर कोई भी सत्यापन चरण - एक री-केवाईसी जीवंतता जांच, एक दस्तावेज़ पुनः सत्यापन, एक एएमएल जांच, या धन का प्रमाण अपलोड।

क्या किसी विश्लेषक को शामिल होना पड़ता है?

नहीं। ऑटो-सुधार लूप बिना किसी विश्लेषक के चलता है। लेकिन वही AWAITING_USER स्थिति केस प्रबंधन में भी मौजूद है, ताकि एक विश्लेषक जब चाहें तो एक अलर्ट को उपयोगकर्ता को वापस भेज सके।

इसकी लागत कितनी है?

प्रति लेन-देन $0.02। सुधार चरण को उसकी अपनी दर पर बिल किया जाता है - उपयोगकर्ता सत्यापन दरों पर एक री-केवाईसी, $0.20 पर एक एएमएल जांच।

शुरू करने के लिए तैयार हैं?

दस्तावेज़ों में लेन-देन निगरानी अवलोकन पढ़ें, लेन-देन निगरानी उत्पाद पृष्ठ पर देखें कि यह प्लेटफ़ॉर्म के बाकी हिस्सों में कैसे फिट बैठता है, और मूल्य निर्धारण पृष्ठ पर प्रति-कॉल पारदर्शी मूल्य निर्धारण जांचें। जब आप तैयार हों, तो मुफ्त में शुरू करें — हर महीने 500 मुफ्त केवाईसी जांच, और प्रति कॉल $0.02 पर लेन-देन निगरानी।