मुख्य कंटेंट पर जाएं
Didit ने पहचान और धोखाधड़ी के लिए इंफ्रास्ट्रक्चर बनाने हेतु $7.5M जुटाए
Didit
ब्लॉग पर वापस जाएँ
ब्लॉग · 21 मई 2026

केवाईबी सत्र जीवनचक्र: स्थितियाँ और वेबहुक

केवाईबी सत्यापन को शुरू से अंत तक ट्रैक करें — सत्र की स्थिति, प्रति-सुविधा की स्थिति, व्यावसायिक-इकाई की स्थिति, और वेबहुक जो आपके रिकॉर्ड को सिंक में रखते हैं — प्रत्येक कंपनी के लिए $2.00 में।.

द्वारा Diditअपडेट किया गया
kyb-session-lifecycle-webhooks.png

एक KYB सत्यापन केवल हाँ/नहीं का एक उत्तर नहीं है — यह चलते हुए हिस्सों वाली एक प्रक्रिया है। रजिस्ट्री लुकअप तुरंत स्वीकृत हो सकता है जबकि दस्तावेज़ सत्यापन पुनः सबमिशन का इंतजार करता है और इकाई AML एक विश्लेषक के लंबित समीक्षा में बैठा रहता है। KYB को साफ-सुथरा एकीकृत करने के लिए, आपको यह जानना होगा कि सत्यापन का हर हिस्सा किस स्थिति में है, और आपको अपनी प्रणालियों को यह जानना होगा कि जैसे ही कोई स्थिति बदलती है, वे तुरंत अपडेट हो जाएं। यही सत्र जीवनचक्र और वेबहुक का उद्देश्य है।

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

मुख्य निष्कर्ष

  • तीन स्तर की स्थिति। एक KYB सत्यापन में एक सत्र स्थिति, प्रति-सुविधा स्थिति, और — एक बार प्रबंधित होने पर — एक व्यावसायिक-इकाई स्थिति होती है।
  • आठ सत्र स्थितियाँ। NOT_STARTED, IN_PROGRESS, APPROVED, DECLINED, IN_REVIEW, RESUBMITTED, ABANDONED, EXPIRED।
  • छह सुविधा स्थितियाँ चार KYB सुविधाओं में से प्रत्येक पर: NOT_FINISHED, APPROVED, DECLINED, IN_REVIEW, RESUB_REQUESTED, AWAITING_USER।
  • प्रबंधन के तहत तीन इकाई स्थितियाँ: ACTIVE, FLAGGED, BLOCKED।
  • हर चीज़ पर वेबहुक। सत्रों के लिए status.updated और data.updated (session_kind: business के साथ); प्रबंधित संस्थाओं के लिए business.status.updated और business.data.updated।
  • एक पूर्ण प्रबंधन एपीआई — POST /v3/businesses/create/, GET /v3/businesses/, GET /v3/businesses/{vendor_data}/, PATCH .../update-status/।

KYB जीवनचक्र क्या कवर करता है

एक KYB सत्यापन तीन स्तरों पर स्थिति उत्पन्न करता है, और प्रत्येक एक अलग प्रश्न का उत्तर देता है:

  • सत्र उत्तर देता है कि "सत्यापन कुल मिलाकर कैसा चल रहा है?"
  • प्रत्येक सुविधा उत्तर देती है कि "रजिस्ट्री / कंपनी AML / दस्तावेज़ / प्रमुख व्यक्ति जाँच कहाँ खड़ी है?"
  • व्यावसायिक इकाई उत्तर देती है कि "हमारी प्रणाली में इस कंपनी की परिचालन स्थिति अभी क्या है?"

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

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

सटीक स्थिति के बिना, KYB एकीकरण अनुमान में बदल जाता है: एक ही "लंबित" झंडा आपको यह नहीं बताता है कि कौन सी जाँच चीजों को रोक रही है या इसे अनब्लॉक करने के लिए क्या कार्रवाई करनी होगी। प्रति-सुविधा स्थिति के साथ, आप सटीक रूप से रूट कर सकते हैं — आवेदक से एक दस्तावेज़ को फिर से सबमिट करने के लिए कहें, विश्लेषक समीक्षा के लिए एक इकाई-AML मैच को कतारबद्ध करें, एक UBO को अपने KYC को पूरा करने के लिए प्रेरित करें — बजाय इसके कि पूरे सत्यापन को विफल कर दें।

वेब हुक मायने रखते हैं क्योंकि KYB अतुल्यकालिक है। रजिस्ट्री डेटा, दस्तावेज़ OCR, और स्क्रीनिंग परिणाम अलग-अलग समय पर आते हैं, और मानवीय समीक्षा में और भी अधिक समय लगता है। परिवर्तनों के लिए पोलिंग करना wasteful और धीमा है; वेबहुक परिवर्तन को जैसे ही होता है धकेल देते हैं, ताकि आपके रिकॉर्ड एक क्रोन जॉब के बिना API को हथौड़ा मारे बिना वास्तविकता को दर्शाएं।

तकनीकी विवरण

एक KYB सत्र एकीकृत /v3/ API के विरुद्ध बनाया जाता है और अपनी जीवनचक्र स्थिति को वापस रिपोर्ट करता है।

curl -X POST https://verification.didit.me/v3/session/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "workflow_id": "your_kyb_workflow_id",
    "vendor_data": "merchant_6601",
    "callback": "https://yourapp.com/kyb/callback"
  }'

एक status.updated वेबहुक सत्र की स्थिति और प्रति-सुविधा की स्थिति को वहन करता है:

{
  "event": "status.updated",
  "session_kind": "business",
  "session_id": "kyb_3a90f1c2",
  "vendor_data": "merchant_6601",
  "status": "IN_REVIEW",
  "features": {
    "kyb_registry": "APPROVED",
    "kyb_company_aml": "IN_REVIEW",
    "kyb_documents": "RESUB_REQUESTED",
    "kyb_key_people": "APPROVED"
  }
}

सत्र स्थितियाँ। NOT_STARTED, IN_PROGRESS, APPROVED, DECLINED, IN_REVIEW, RESUBMITTED, ABANDONED, EXPIRED।

सुविधा स्थितियाँ। kyb_registry, kyb_company_aml, kyb_documents, और kyb_key_people में से प्रत्येक एक रिपोर्ट करता है: NOT_FINISHED, APPROVED, DECLINED, IN_REVIEW, RESUB_REQUESTED, या AWAITING_USER।

वेबहुक। सत्रों के लिए: status.updated (जीवनचक्र परिवर्तन) और data.updated (संवर्धित डेटा), दोनों session_kind: "business" के साथ। प्रबंधित संस्थाओं के लिए: business.status.updated और business.data.updated।

मूल्य। प्रति कंपनी सत्यापन $2.00।

व्यावसायिक इकाई का प्रबंधन

एक बार जब कोई कंपनी सत्यापित हो जाती है, तो वह एक इकाई बन जाती है जिसे आप व्यवसायों API के माध्यम से प्रबंधित करते हैं:

  • POST /v3/businesses/create/ — एक व्यावसायिक इकाई पंजीकृत करें।
  • GET /v3/businesses/ — प्रबंधित व्यवसायों की सूची बनाएं।
  • GET /v3/businesses/{vendor_data}/ — अपने vendor_data संदर्भ द्वारा एक व्यवसाय प्राप्त करें।
  • PATCH .../update-status/ — इकाई की स्थिति बदलें।

इकाई अपनी स्थिति रखती है, सत्यापन सत्र से स्वतंत्र: ACTIVE (अच्छी स्थिति में), FLAGGED (जोखिम संकेत के लिए समीक्षाधीन), या BLOCKED (निलंबित)। यह परिचालन परत है — एक कंपनी एक APPROVED सत्र पूरा कर सकती है और बाद में FLAGGED हो सकती है क्योंकि निगरानी ने कुछ उजागर किया। इकाई में परिवर्तन business.status.updated और business.data.updated उत्सर्जित करते हैं ताकि डाउनस्ट्रीम सिस्टम अद्यतित रहें।

जीवनचक्र, शुरू से अंत तक

एक विशिष्ट सत्यापन परतों को क्रम से चलता है। सत्र NOT_STARTED पर खुलता है, सुविधाओं के चलने पर IN_PROGRESS में चला जाता है, और प्रत्येक सुविधा हल हो जाती है — रजिस्ट्री APPROVED, दस्तावेज़ शायद RESUB_REQUESTED जब तक एक साफ अपलोड नहीं आता, कंपनी AML IN_REVIEW जब तक एक विश्लेषक एक मैच को मंजूरी नहीं देता, प्रमुख लोग APPROVED। जब हर सुविधा स्थिर हो जाती है, तो सत्र APPROVED, DECLINED, या IN_REVIEW पर आता है। वहां से कंपनी एक ACTIVE इकाई के रूप में प्रबंधन में प्रवेश करती है, और इसकी स्थिति बाद में FLAGGED या BLOCKED में जा सकती है जैसा कि चल रही निगरानी निर्देशित करती है — प्रत्येक संक्रमण आपको वेबहुक द्वारा धकेल दिया जाता है।

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

  • बाज़ार विक्रेताओं को सटीक रूप से रूट करते हैं: एक दस्तावेज़ को फिर से सबमिट करें, एक UBO के KYC को पूरा करें, या एक इकाई-AML मैच को रोकें — पूरे ऑनबोर्डिंग को विफल किए बिना।
  • फिनटेक और बैंकिंग प्लेटफॉर्म पोलिंग के बजाय वेबहुक के साथ कॉर्पोरेट-खाता रिकॉर्ड को सिंक में रखते हैं, और जोखिम बदलने पर संस्थाओं को फ़्लैग या ब्लॉक करते हैं।
  • उधार प्रदाता प्रत्येक अंडरराइटिंग चेक की स्थिति को ट्रैक करते हैं और प्रबंधन एपीआई के माध्यम से उधारकर्ता की स्थिति को अपडेट करते हैं।
  • क्रिप्टो B2B प्लेटफॉर्म सत्यापन से लेकर चल रही स्थिति तक प्रत्येक प्रतिपक्ष इकाई के एक ऑडिट करने योग्य जीवनचक्र को बनाए रखते हैं।

डिडिट के साथ कैसे एकीकृत करें

  1. कार्यप्रवाह बनाएं। बिजनेस कंसोल में, अपनी आवश्यक सुविधाओं के साथ एक KYB कार्यप्रवाह बनाएं।
  2. सत्र बनाएं। अपने KYB workflow_id और एक vendor_data संदर्भ के साथ POST /v3/session/।
  3. वेबहुक की सदस्यता लें। सत्रों के लिए status.updated और data.updated (session_kind: business) को संभालें, और प्रबंधित व्यावसायिक संस्थाओं के लिए business.status.updated / business.data.updated।
  4. संस्थाओं का प्रबंधन करें। प्रत्येक कंपनी को ACTIVE, FLAGGED, या BLOCKED रखने के लिए POST /v3/businesses/create/, GET /v3/businesses/, GET /v3/businesses/{vendor_data}/, और PATCH .../update-status/ का उपयोग करें।

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

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

KYB सत्र की स्थितियाँ क्या हैं?

NOT_STARTED, IN_PROGRESS, APPROVED, DECLINED, IN_REVIEW, RESUBMITTED, ABANDONED, और EXPIRED।

व्यक्तिगत सुविधाएँ कौन सी स्थितियाँ रिपोर्ट करती हैं?

kyb_registry, kyb_company_aml, kyb_documents, और kyb_key_people में से प्रत्येक NOT_FINISHED, APPROVED, DECLINED, IN_REVIEW, RESUB_REQUESTED, या AWAITING_USER रिपोर्ट करता है।

मुझे किन वेबहुक की सदस्यता लेनी चाहिए?

सत्रों के लिए, status.updated और data.updated (session_kind: business के साथ)। प्रबंधित व्यावसायिक संस्थाओं के लिए, business.status.updated और business.data.updated।

सत्यापन के बाद मैं किसी कंपनी की स्थिति कैसे बदलूँ?

इकाई को ACTIVE, FLAGGED, या BLOCKED पर सेट करने के लिए प्रबंधन API — PATCH .../update-status/ — का उपयोग करें।

KYB सत्यापन की लागत क्या है?

पूर्ण सत्यापन — रजिस्ट्री, UBO, अधिकारी, और इकाई AML — के लिए प्रति कंपनी $2.00।

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

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

पहचान और धोखाधड़ी के लिए इंफ्रास्ट्रक्चर।

KYC, KYB, ट्रांज़ैक्शन मॉनिटरिंग और वॉलेट स्क्रीनिंग के लिए एक API। 5 मिनट में इंटीग्रेट करें।

इस पेज को समराइज़ करने के लिए AI से पूछें