वेंडर ऑनबोर्डिंग का प्रवाह: कौन-सी जाँचें, किस क्रम में

मुख्य बातें

• जाँचें लागत और निर्णायकता के क्रम में लगाइए: ऑफ़लाइन validation, भीतर का डुप्लिकेट, PAN, PAN से मिलाकर GSTIN, कंपनियों के लिए CIN, नाम मिलान के साथ बैंक खाता, फिर दस्तावेज़ और समीक्षा।
• पहली पक्की विफलता पर रुकिए। जो वेंडर पहले की किसी जाँच में फ़ेल हो चुका है, उसके लिए बाद का महँगा endpoint मत बुलाइए।
• कोई भी API call करने से पहले अपने डेटा में डुप्लिकेट देखिए। डुप्लिकेट PAN, GSTIN या बैंक खाता अक्सर सबसे क़ीमती संकेत है और उसका कोई ख़र्च नहीं।
• PAN को आधार मानिए। GSTIN में वही बैठा होना चाहिए, बैंक खाते का नाम verify किए कानूनी नाम से मिलना चाहिए, और CIN का कंपनी नाम सहमत होना चाहिए।
• प्रवाह को state machine की तरह बनाइए, नतीजे सहेजकर, ताकि crash या retry कभी दोहरा बिल न बनाए और न प्रगति खोए।
• bank account verification को कभी आँख मूँदकर retry मत कीजिए। उसमें बैंक transfer शामिल है और reference verification endpoint के लिए idempotency दर्ज नहीं करता।
• मौजूदा वेंडर का बदला हुआ बैंक खाता क्लासिक धोखाधड़ी की घटना है। खाते की जाँच दोबारा चलाइए और रोक या दूसरा अनुमोदन जोड़िए।
• रजिस्ट्रेशन की दोबारा जाँच तय अंतराल पर और बड़े भुगतान से पहले कीजिए। मंज़ूरी के बाद status बदलते हैं।
• verification जोखिम को संकरा करता है। वह वेंडर को भरोसेमंद नहीं बनाता, और अनुबंधों, रिश्ते की अपनी परख या आपकी नीति की जगह नहीं लेता।

तीन वेंडर, एक सुबह

क्रम कैसे काम करता है, यह एक ही सुबह जमा हुए तीन काल्पनिक वेंडरों पर देखिए।

वेंडर क, एक फ़्रीलांस डिज़ाइनर। PAN और बैंक खाता देता है। ऑफ़लाइन जाँचें पास। कोई डुप्लिकेट नहीं। PAN lookup valid: true और ऐसा नाम लौटाता है जो सामान्य रूप में आने पर टाइप किए नाम से मिलता है। बैंक जाँच वैध खाता और समीक्षा की पट्टी से काफ़ी ऊपर का स्कोर लौटाती है। दो paid calls, कोई इंसान नहीं, state VERIFIED, फिर पहले भुगतान की रोक के साथ ACTIVE।

वेंडर ख, एक ट्रेडिंग कंपनी। कंपनी का PAN, GSTIN, CIN और बैंक खाता देती है। ऑफ़लाइन जाँचें पास और कोई डुप्लिकेट नहीं। PAN वैध है और चौथा अक्षर C है। GSTIN lookup Active लौटाता है, उसमें बैठा PAN verify किए PAN के बराबर है, पर legalName PAN के पंजीकृत नाम से अलग है: "Pvt Ltd" बनाम "Private Limited" सामान्य रूप में आने पर सुलझ जाता है, और जो बचता है वह एक शब्द का फ़र्क़ है जो हाल का नाम-बदलाव लगता है। फ़ैसला NAME_DIFFERS के साथ REVIEW। प्रवाह रुकता नहीं। CIN की जाँच चलती है और ऐसी सक्रिय कंपनी दिखाती है जिसका नाम PAN से नहीं, GSTIN से मिलता है, जो नाम-बदलाव के अनुमान का समर्थन करता है। बैंक जाँच पास होती है। समीक्षक को चार नतीजे और एक कारण दिखता है, वह वेंडर से नाम-बदलाव दिखाने वाला निगमन प्रमाणपत्र माँगता है, एक दिन के भीतर पाता है और मंज़ूर कर देता है। चार paid calls, एक इंसानी फ़ैसला।

वेंडर ग, ऐसे GSTIN वाला आपूर्तिकर्ता जो उसका नहीं है। कंपनी का PAN, GSTIN और बैंक खाता देता है। ऑफ़लाइन जाँचें पास। डुप्लिकेट जाँच में कुछ नहीं मिलता। PAN वैध है। GSTIN lookup Active लौटाता है, पर अक्षर 3 से 12 उस PAN से अलग PAN हैं जो अभी verify हुआ। फ़ैसला: PAN_MISMATCH के साथ FAIL। प्रवाह ख़त्म। न CIN की call, न बैंक की call, और इसलिए किसी अजनबी के खाते में कोई bank transfer नहीं। वेंडर को तटस्थ संदेश जाता है जिसमें पूछा गया है कि रजिस्ट्रेशन किस PAN पर हुआ। चार की जगह दो paid calls, और ऐसा बेमेल पकड़ा गया जिसे अकेली नाम की जाँच चूक सकती थी।

तीनों रास्ते एक ही कोड इस्तेमाल करते हैं। प्रवाह इसलिए अलग है कि डेटा अलग है, और जाँचों का क्रम तय करता है कि हर रास्ता कितने में पड़ता है।

वेंडर का प्रवाह आपको किससे बचाता है

उन विफलताओं के बारे में ख़ास रहिए जिन्हें रोकना चाहते हैं। हर एक किसी जाँच से जुड़ती है, और जिस जाँच को आप किसी जोखिम से न जोड़ सकें वह हटाने का उम्मीदवार है।

आख़िरी पंक्ति जान-बूझकर है। Verification API रिकॉर्ड जाँचती हैं। वे नीयत या रिश्ते नहीं पढ़तीं। जो वेंडर प्रवाह इन्हें पूरा जवाब मान लेता है, वह झूठा सुकून पैदा करता है।

जाँचों का क्रम, एक तालिका में

लागत वाला स्तंभ क्रम समझाता है। क़दम एक और दो मुफ़्त हैं, इसलिए पहले चलते हैं। क़दम तीन से पाँच अलग लागत और अलग निर्णायकता वाले एकल lookup हैं। क़दम छह में बैंक शामिल है, जो उसे सबसे महँगा और वह बनाता है जिसे आप सबसे कम दोहराना चाहते हैं, इसलिए वह स्वचालित जाँचों में सबसे आख़िर में आता है।

सब कुछ एक साथ क्यों नहीं चलाते

समानांतर calls तेज़ हैं, और इंटरैक्टिव प्रवाह के लिए यह लुभावना लगता है। सौदा लागत और सफ़ाई का है। अगर PAN फ़ेल हो जाए, तो समानांतर चलाने पर आप GSTIN lookup और ऐसे bank transfer का पैसा दे चुके होंगे जिसकी ज़रूरत नहीं थी। उससे बुरा, ऐसे वेंडर पर समानांतर बैंक जाँच जिसका PAN अभी verify नहीं हुआ, उसके पास तुलना के लिए verify किया नाम नहीं होता, तो आपको टाइप किया नाम इस्तेमाल करना पड़ता है, जो सबसे कमज़ोर उम्मीदवार है।

क्रमवार प्रवाह शायद ही इतना धीमा होता है कि फ़र्क़ पड़े। हर StampMitra verification एक synchronous call है, इसलिए कंपनी का पूरा चार-call वाला रास्ता क्रम से चार round trip है, लंबा इंतज़ार नहीं। समानांतर की ज़रूरत तय करने से पहले अपने नेटवर्क पर नापिए। जहाँ देरी लागत से ज़्यादा मायने रखती है, वहाँ PAN, GSTIN और CIN के lookup समानांतर चला सकते हैं, क्योंकि वे स्वतंत्र और सस्ते हैं, और बैंक जाँच को सख़्ती से उनके बाद रखिए। बैंक जाँच के आर-पार समानांतर मत कीजिए।

क़दम 0: हर वेंडर-प्रकार के लिए सही इनपुट माँगिए

पहला फ़ैसला यह है कि क्या माँगना है। हर वेंडर से हर पहचान माँगने से लोग छोड़ जाते हैं और ऐसे lookup का पैसा लगता है जो सफल हो ही नहीं सकते। वही माँगिए जो वेंडर का प्रकार रख सकता है।

पहचानों के साथ इकट्ठा कीजिए: PAN पर जैसा है वैसा कानूनी नाम, अलग हो तो trade name, पंजीकृत पता, संपर्क व्यक्ति और ईमेल, आपके कर्मचारियों से किसी संबंध की वेंडर की अपनी घोषणा, और बैंक खाते के लिए खाताधारक का नाम जैसा बैंक में है। अगर आपकी नीति दस्तावेज़ों को सहारे के रूप में इस्तेमाल करती है, तो दस्तावेज़ के रूप में रद्द चेक या बैंक पत्र माँगिए।

एक डिज़ाइन बिंदु: पहले वेंडर का प्रकार लीजिए और उसी से तय होने दीजिए कि कौन-से फ़ील्ड दिखें। "कंपनी" चुनने वाले को CIN दिखता है। "फ़्रीलांसर" चुनने वाले को नहीं। StampMitra का अपना ऑनबोर्डिंग फ़ॉर्म ऐसे ही बना है।

क़दम 1: ऑफ़लाइन validation

इन्हें किसी भी चीज़ से पहले अपने सर्वर पर चलाइए। ये मुफ़्त हैं और टाइपो पकड़ती हैं।

• PAN की बनावट: पाँच अक्षर, चार अंक, एक अक्षर; चौथा अक्षर दावा किए प्रकार से मेल खाना चाहिए।
• GSTIN की बनावट और राज्य कोड; चेक कैरेक्टर सिर्फ़ production key पर।
• CIN की बनावट (ढीली, क्योंकि असली CIN में भिन्नताएँ हैं)।
• खाता संख्या: नौ से अठारह अंक। IFSC: चार अक्षर, एक शून्य, छह अक्षर या अंक।

हर एक का कोड PAN, GSTIN और CIN में फ़र्क और GSTIN को प्रोग्राम से कैसे verify करें में है। यहाँ की विफलता टाइपो है, इसलिए वेंडर को सुधार का संदेश दिखाइए और आवेदन आगे मत बढ़ाइए।

क़दम 2: कुछ भी ख़र्च करने से पहले डुप्लिकेट की पहचान

किसी भी paid call से पहले अपने ही डेटा में देखिए। जो वेंडर उसी PAN, GSTIN या बैंक खाते के साथ पहले से मौजूद है, वह पूरे प्रवाह का सबसे सस्ता और सबसे क़ीमती संकेत है।

-- आवेदक की किसी भी पक्की पहचान से कौन-से मौजूदा वेंडर मेल खाते हैं?
SELECT id, legal_name, status, 'pan' AS matched_on FROM vendors WHERE pan = :pan
UNION
SELECT id, legal_name, status, 'gstin' FROM vendors WHERE gstin = :gstin
UNION
SELECT v.id, v.legal_name, v.status, 'bank_account'
FROM vendors v JOIN vendor_accounts a ON a.vendor_id = v.id
WHERE a.account_number_hash = :account_hash AND a.ifsc = :ifsc;

मेल का मतलब पहचान के हिसाब से अलग है।

बैंक खाते को मिलान के लिए salted hash की तरह रखिए और दिखाने के लिए सिर्फ़ आख़िरी चार अंक, ताकि डुप्लिकेट पहचान को ज़रूरत से ज़्यादा जगहों पर असली खाता संख्या न रखनी पड़े। नाम अकेले कमज़ोर डुप्लिकेट-सबूत हैं, क्योंकि "Sharma Traders" आम नाम है। उन्हें सिर्फ़ सुझाव के लिए इस्तेमाल कीजिए, फ़ैसले के लिए नहीं।

क़दम 3: PAN verify कीजिए

PAN बाक़ी प्रवाह का आधार है। PAN और वेंडर के भरे कानूनी नाम के साथ POST /v1/verify/pan call कीजिए।

curl -X POST "https://api-b2b.stampmitra.in/v1/verify/pan" \
  -H "Authorization: Bearer $STAMPMITRA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"pan":"ABCDE1234F","name":"Jane Doe Enterprises Private Limited"}'

पहले valid, फिर panStatus, फिर नाम का नतीजा और स्कोर, फिर type को दावा किए वेंडर-प्रकार से मिलाकर शाखा कीजिए। valid: false प्रवाह रोक देता है। VALID से अलग status या कमज़ोर नाम-मिलान समीक्षा में जाता है। फ़ैसले का function, नाम को सामान्य करने वाला कोड, और अलग नामों को ठुकराने की जगह इंसान के पास भेजने के कारण PAN को verify करके नाम कैसे मिलाएँ में हैं। PAN की call क्या साबित करती है और क्या नहीं, यह PAN verification गाइड में है।

इस क़दम का registeredName बाक़ी प्रवाह के लिए याद रखिए। वही संदर्भ-नाम बनता है जिससे बैंक खाते की तुलना होती है।

क़दम 4: GSTIN verify कीजिए और उसे PAN से मिलाइए

GSTIN वाले वेंडर के लिए POST /v1/verify/gstin call कीजिए, फिर कोड में तीन तुलनाएँ चलाइए।

1. registrationStatus Active होना चाहिए। बाक़ी कुछ भी समीक्षा में जाता है, और रद्द या निलंबित रजिस्ट्रेशन को आम तौर पर वेंडर को GST इनवॉइसिंग के लिए सेट अप होने से रोकना चाहिए।
2. GSTIN के अक्षर 3 से 12 verify किए PAN के बराबर होने चाहिए। बेमेल पक्की विफलता है।
3. legalName PAN के पंजीकृत नाम से सामान्य रूप में आने के बाद सहमत होना चाहिए। फ़र्क़ समीक्षा में जाता है।

अगर वेंडर के पास सिर्फ़ PAN है और वह कहता है कि वह GST में पंजीकृत है, तो उसके रजिस्ट्रेशन सूचीबद्ध करने के लिए PAN to GSTIN lookup इस्तेमाल कीजिए और पूछिए कि इनवॉइस पर कौन-सा आएगा। सूची के पहले GSTIN को बिना पुष्टि के कभी सही मत मानिए। status के मान, उनका मतलब और जवाब में क्या नहीं है, यह GSTIN को प्रोग्राम से कैसे verify करें में है।

जिस वेंडर के पास GSTIN नहीं, उसका कारण दर्ज कीजिए (सीमा से नीचे, छूट वाला आपूर्तिकर्ता, सेवा देने वाला जो पंजीकृत नहीं)। बिना रजिस्ट्रेशन वाले आपूर्तिकर्ता से ख़रीदना ठीक है या नहीं, और उन ख़रीदों के टैक्स का क्या हो, यह आपकी फ़ाइनेंस और टैक्स टीम का सवाल है। API इसका जवाब नहीं दे सकती।

क़दम 5: कंपनियों के लिए CIN verify कीजिए

कंपनी वेंडर के लिए POST /v1/verify/cin call कीजिए। जाँचिए कि कंपनी cinStatus और companyStatus दोनों में चालू है, companyName की तुलना PAN और GSTIN के नामों से कीजिए, और directors की सूची पढ़िए। फिर आवेदन करने वाले व्यक्ति को निदेशकों से मिलाइए।

अगर आवेदक सूचीबद्ध निदेशक है, तो आपकी नीति भारी अधिकार-दस्तावेज़ की शर्त छोड़ सकती है, जैसा StampMitra का अपना production access फ़ॉर्म बोर्ड प्रस्ताव के साथ करता है। अगर आवेदक निदेशक नहीं है, तो कंपनी की तरफ़ से हस्ताक्षरित authorisation letter या बोर्ड प्रस्ताव माँगिए। lookup दिखाता है कि निदेशक कौन हैं। वह यह नहीं दिखाता कि कंपनी ने किसे अधिकृत किया है।

Udyam पंजीकरण, अगर आपकी नीति उसे छोटे वेंडरों के लिए प्रासंगिक मानती है, का अपना lookup है; GSTIN, CIN और Udyam से बिज़नेस वेरिफ़िकेशन गाइड उसे कवर करती है। व्यक्ति की तुलना में कारोबार के लिए आपको क्या जाँचना है, इस बड़े सवाल के लिए KYC बनाम KYB देखिए।

क़दम 6: बैंक खाता सबसे आख़िर में verify कीजिए

इस क़दम तक सिर्फ़ वही वेंडर पहुँचते हैं जो ऊपर की हर जाँच पास कर चुके हैं। खाता संख्या, IFSC और name के रूप में PAN lookup से मिला verify किया कानूनी नाम (या प्रोपराइटर का नाम, प्रोपराइटरशिप पर आपकी नीति के हिसाब से) देकर POST /v1/verify/bank-account call कीजिए। पहले valid, फिर accountStatus, फिर स्कोर पर शाखा कीजिए।

तीन नियम, जो सब penny drop बनाम name match में समझाए गए हैं:

1. बैंक के नाम की तुलना verify किए नाम से कीजिए, वेंडर के टाइप किए से नहीं।
2. आंशिक मिलान समीक्षा में भेजिए। बैंक के नाम कटे, संक्षिप्त और उलटे-पलटे होते हैं।
3. timeout हुई call को आँख मूँदकर retry मत कीजिए। call में बैंक transfer शामिल है और retry दूसरा क्रेडिट भेज सकता है। पहले logs में पूरी हुई call देखिए।

StampMitra के production access फ़ॉर्म में bank account verification ऊँचे जोखिम का चिह्नित है, यानी आपका आवेदन मंज़ूर होने के बाद वह एक छोटी अतिरिक्त जाँच के बाद खुलता है। आवेदन करते समय उसकी योजना बनाइए।

क़दम 7: दस्तावेज़ और इंसानी समीक्षा

कुछ वेंडर इस क़दम तक सब हरा लेकर पहुँचेंगे। बाक़ी कारणों के साथ आएँगे। समीक्षक की स्क्रीन पर दिखना चाहिए: वेंडर और उसका प्रकार; हर verification का नतीजा referenceId और समय के साथ; वे कारण जिन्होंने केस को कतार में डाला; अपलोड किए दस्तावेज़; और lookups (निदेशक) तथा दस्तावेज़ों (अधिकार) से निकले रिश्ते।

जो दस्तावेज़ आम तौर पर काम आते हैं: बैंक-नाम के फ़र्क़ के लिए रद्द चेक या बैंक पत्र; status के सवाल के लिए रजिस्ट्रेशन प्रमाणपत्र; कंपनी-नाम के फ़र्क़ के लिए निगमन प्रमाणपत्र; निदेशक न होने वाले हस्ताक्षरकर्ता के लिए authorisation letter। आप कौन-से दस्तावेज़ मानते हैं, यह आपके compliance मालिक का नीतिगत फ़ैसला है।

समीक्षक को कार्रवाइयों की बंद सूची दीजिए (मंज़ूर, अस्वीकार, दस्तावेज़ माँगें, सुधरा नंबर माँगें, ऊपर भेजें) और हर फ़ैसले के लिए तर्क की एक पंक्ति ज़रूरी कीजिए। बंद सूची से आप बाद में नतीजों पर रिपोर्ट बना सकते हैं, और तर्क वही है जो आप ऑडिटर को दिखाते हैं।

क़दम 8: सक्रियण और पहले भुगतान के नियंत्रण

मंज़ूरी का मतलब "तुरंत भुगतान" नहीं होना चाहिए। कुछ सस्ते नियंत्रण तब नुक़सान घटाते हैं जब कुछ फिसल गया हो।

• पहले भुगतान की रोक। नए वेंडर को पहला भुगतान आपकी नीति की तय अवधि तक रोकिए, और किसी सीमा से ऊपर दूसरा अनुमोदक माँगिए।
• सीमाएँ। नया वेंडर एकल भुगतान और महीने के कुल पर सीमा के साथ शुरू होता है, जो इतिहास बनने पर बढ़ाई जाती है।
• खाता-बदलाव का नियम। वेंडर के बैंक खाते का हर बदलाव नई bank account verification, रोक, और किसी जाने-पहचाने संपर्क को ऐसे माध्यम से callback ट्रिगर करता है जो वेंडर ने बदलाव के अनुरोध में नहीं दिया।
• नामित मालिक। हर वेंडर का एक भीतरी मालिक है जो रिश्ते के लिए ज़िम्मेदार है, ताकि flag को कहीं जाना हो।

इनमें से कोई API की सुविधा नहीं है। ये वह नीति हैं जो verification के नतीजों को सुरक्षित भुगतानों में बदलती हैं।

प्रवाह की state machine

प्रवाह को साफ़ states के रूप में सहेजिए, ताकि restart, retry और समीक्षाएँ भलीभाँति परिभाषित रहें।

हर paid जाँच को अपनी पंक्ति में सहेजिए: प्रकार, इनपुट का hash, referenceId, नतीजा, कारण और समय। orchestrator पंक्तियाँ पढ़कर जानता है कि क्या हो चुका है, इसलिए restart दोहराता नहीं, आगे बढ़ता है।

Python में orchestrator

def run_checks(vendor, store):
    done = store.checks_for(vendor["id"])      # प्रकार -> सहेजा नतीजा

    def step(kind, fn):
        if kind in done:
            return done[kind]                  # आगे बढ़िए, paid call कभी दोहराइए मत
        result = fn()
        store.save_check(vendor["id"], kind, result)
        done[kind] = result
        return result

    def pan_step():
        res = verify_pan(vendor["pan"], vendor["legal_name"])
        return {**decide_pan(res, vendor["legal_name"]), "res": res}

    pan = step("pan", pan_step)
    if pan["decision"] == "FAIL":
        return finish(vendor, store, "REJECTED", pan)
    verified_name = pan["res"]["registeredName"]

    if vendor.get("gstin"):
        def gstin_step():
            res = verify_gstin(vendor["gstin"])
            return {**decide_gstin(res, expected_pan=vendor["pan"], expected_name=verified_name), "res": res}
        g = step("gstin", gstin_step)
        if g["decision"] == "FAIL":
            return finish(vendor, store, "REJECTED", g)

    if vendor["type"] == "COMPANY":
        def cin_step():
            res = verify_cin(vendor["cin"])
            active = bool(res.get("valid")) and str(res.get("cinStatus", "")).lower() == "active" \
                and str(res.get("companyStatus", "")).lower() == "active"
            applicant = (vendor.get("applicant_name") or "").upper()
            is_director = any((d.get("name") or "").upper() == applicant for d in res.get("directors", []))
            return {"decision": "PASS" if active else "FAIL",
                    "reasons": [] if active else ["COMPANY_NOT_FOUND_OR_INACTIVE"],
                    "applicant_is_director": is_director, "res": res}
        c = step("cin", cin_step)
        if c["decision"] == "FAIL":
            return finish(vendor, store, "REJECTED", c)

    def bank_step():
        res = verify_bank(vendor["account"], verified_name)
        return {**decide_bank(res), "res": res}
    bank = step("bank", bank_step)
    if bank["decision"] == "FAIL":
        return finish(vendor, store, "REJECTED", bank)

    needs_review = any(c.get("decision") == "REVIEW" for c in done.values())
    return finish(vendor, store, "IN_REVIEW" if needs_review else "VERIFIED", None)


def finish(vendor, store, state, because):
    reasons = (because or {}).get("reasons", [])
    store.set_state(vendor["id"], state, reasons)
    return {"state": state, "reasons": reasons}

तीन डिज़ाइन चुनाव। step हर paid call को आगे बढ़ने-योग्य बनाता है: सहेजा नतीजा दोबारा call करने की जगह लौटा दिया जाता है। लूप पहली FAIL पर रुकता है, इसलिए PAN में फ़ेल वेंडर पर कभी बैंक call नहीं लगती। और PAN के क़दम का verify किया नाम, वेंडर के टाइप किए की जगह, वह नाम है जिससे बैंक का नतीजा परखा जाता है।

वही प्रवाह Node.js में चाहिए तो step का ढाँचा जस का तस उतरता है: हर क़दम पहले सहेजे नतीजे देखे, फिर call करे, फिर सहेजे। ऊपर बताए verify_* और decide_* function हर endpoint की गाइड में बने हैं। Node और Python सेवाओं के बरताव को एक जैसा रखने के लिए उन्हें एक ही मॉड्यूल में रखिए।

हर चरण पर वेंडर क्या देखे

वेंडर का अनुभव तय करता है कि कितने पूरा करेंगे। हर state का एक संदेश होना चाहिए जो बताए कि क्या हो रहा है और, अगर कुछ है, तो उन्हें क्या करना है।

दो और आदतें। हर state-बदलाव पर ईमेल भेजिए, विषय में वेंडर का कोड रखकर, ताकि वेंडर उसे उद्धृत कर सके। और procurement कर्मचारियों को एक status पेज दीजिए जो दिखाए कि हर वेंडर कहाँ है और कितने समय से वहाँ है, क्योंकि हफ़्ते भर से समीक्षा में अटका वेंडर वह वेंडर है जो प्रतिस्पर्धी के पास चला जाता है।

मंज़ूरी के बाद वेंडर-आधार को साफ़ रखना

मंज़ूरी जीवनचक्र की शुरुआत है।

• रजिस्ट्रेशन की तय दोबारा जाँच। GST रजिस्ट्रेशन के status बदलते हैं। जोखिम के हिसाब से दोबारा जाँचिए: ज़्यादा ख़र्च वाले वेंडर सीमा से ऊपर के भुगतान चक्र से पहले और हर महीने, नियमित वेंडर तिमाही, कभी-कभार वाले एक साल बाद अगले इस्तेमाल पर। हर दोबारा जाँच बिल होने वाली call है, जिसका अपना referenceId है।
• घटना-आधारित जाँचें। बैंक खाते का बदलाव, अधिकृत हस्ताक्षरकर्ता का बदलाव, नाम बदलने का अनुरोध, बहुत बड़ा इनवॉइस, वेंडर की शिकायत। हर एक ख़ास दोबारा जाँच ट्रिगर कर सकता है।
• flag और मालिक। status का बदलाव वेंडर के भीतरी मालिक के नाम एक flag उठाता है, समय-सीमा के साथ।
• निष्क्रिय वेंडर। जिन वेंडरों की लंबे समय से कोई गतिविधि नहीं, उन्हें निष्क्रिय चिह्नित कीजिए और अगले भुगतान से पहले दोबारा verify करवाइए।
• निकास। वेंडर बंद हो तो उसका verification रिकॉर्ड उतने समय रखिए जितना आपकी नीति तय करे, और आगे के भुगतान रोक दीजिए।

जो वेंडर पहले से हैं उन्हें backfill करना

इस प्रवाह को लाने वाली ज़्यादातर टीमों के पास पहले से सैकड़ों-हज़ारों वेंडर हैं जिनका कोई verification रिकॉर्ड नहीं। सबको एक साथ मत चलाइए।

1. जोखिम के हिसाब से बाँटिए। वेंडरों को सालाना ख़र्च, भुगतान की आवृत्ति और इस आधार पर क्रम दीजिए कि उन्हें ऐसे बैंक खाते में भुगतान होता है जिसे आपने कभी verify नहीं किया। सूची के ऊपर से शुरू कीजिए।
2. पहले मुफ़्त जाँचें चलाइए। पूरे आधार पर ऑफ़लाइन validation और डुप्लिकेट पहचान का कोई ख़र्च नहीं और आम तौर पर ये हैरान करने वाली चीज़ें दिखाती हैं: बिगड़े नंबर और कई वेंडरों का एक ही खाता।
3. paid जाँचें batch में चलाइए। PAN और GSTIN को ऐसे batch में चलाइए जो आपकी rate limit के भीतर रहें, गति और सीमित retry के साथ, जैसे GSTIN की बड़ी मात्रा वाली सलाह में। bank account की जाँच सिर्फ़ उन वेंडरों के लिए चलाइए जिन्हें आप सचमुच भुगतान करते हैं, और हर एक के लिए एक बार।
4. नतीजों को अस्वीकार नहीं, समीक्षा मानिए। थोड़े अलग नाम वाला वैध पुराना वेंडर कतार में पहुँचे, अनुबंध के बीच में ब्लॉक न हो।
5. सब कुछ referenceId के साथ दर्ज कीजिए। backfill इन वेंडरों का पहला ऑडिट निशान है।
6. बजट। वेंडरों को प्रकार के हिसाब से गिनिए, हर प्रकार को चाहिए calls से गुणा कीजिए, और pricing पेज की दरें लगाइए। pay-as-you-go पर PAN जैसी standard verification ₹5 प्रति call है और bank account verification ₹4 प्रति call, प्लान में कम दरों के साथ। sandbox की calls मुफ़्त हैं पर सैंपल डेटा लौटाती हैं, इसलिए असली backfill में काम नहीं आतीं।

बिना चौंकाने वाली लागत का मॉडल

एक वेंडर को ऑनबोर्ड करने की लागत paid calls की संख्या गुणा उनकी दरें है। जाँचों का क्रम वह संख्या कम रखता है।

दोबारा जाँचें वेंडर के जीवन में calls जोड़ती हैं। तिमाही अनुसूची पर दोबारा जाँची गई कंपनी वेंडर हर तिमाही एक GSTIN call और शायद एक CIN call जोड़ता है। ये छोटी हैं, पर हज़ारों वेंडरों में इन्हें बजट में होना चाहिए। मौजूदा दरों और प्लान की छूट के लिए pricing पेज देखिए, और याद रखिए कि production में हर पूरी हुई call बिल होती है, नकारात्मक नतीजे समेत।

पहले से तय कर लेने लायक़ किनारे के मामले

• विदेशी वेंडर। इनमें से कोई पहचान लागू नहीं। उन्हें अलग जाँचों वाली अलग प्रक्रिया में भेजिए।
• सरकारी और सार्वजनिक संस्थाएँ। PAN का चौथा अक्षर G या L होता है, और CIN हो ही नहीं सकता। हर ग़ैर-व्यक्ति के लिए CIN अनिवार्य मत कीजिए।
• कई GSTIN वाले वेंडर। इनवॉइस पर आने वाले हर एक को verify कीजिए और पक्का कीजिए कि सब में एक ही PAN बैठा है।
• नाम बदलने या रूप बदलने वाले वेंडर। पार्टनरशिप से कंपनी बनना या नाम बदलना, नाम और नंबर बदल सकता है। जब lookup ऐसे नंबर पर "नहीं मिला" कहे जिसे वेंडर अपना बताता है, तो ताज़ा प्रमाणपत्र माँगिए।
• बैंक खाता साझा करने वाली समूह कंपनियाँ। वैध और आम। समीक्षा में भेजिए, रिश्ता दर्ज कीजिए और टिप्पणी के साथ मंज़ूर कीजिए।
• एजेंसी के ज़रिए भुगतान पाने वाले व्यक्ति। तय कीजिए कि आपका वेंडर एजेंसी है या व्यक्ति, और उसी को verify कीजिए।
• अधूरा छोड़ा आवेदन। वेंडर PAN के बाद रुक जाए और हफ़्तों बाद लौटे, तो नए सिरे से सब कुछ चलाने की जगह देखिए कि कौन-सा चरण पूरा हो चुका है। जो चरण पहले पास हुआ और जिसका इनपुट नहीं बदला, उसे दोबारा चलाने की ज़रूरत नहीं। पर इतने समय बाद GSTIN की स्थिति दोबारा देख लेना ठीक रहता है, क्योंकि पुराना Active नतीजा तब तक बदल चुका हो सकता है। अधूरे आवेदनों के लिए एक समय-सीमा तय कीजिए जिसके बाद वह state ख़ुद बंद हो जाए, वरना कतार में पुराने मामले जमा होते जाते हैं।
• सुधार के बाद दोबारा जमा करना। वेंडर नाम या खाता संख्या सुधारकर लौटे, तो सिर्फ़ उस चरण और उसके बाद के चरण दोबारा चलाइए जो बदले इनपुट पर निर्भर हैं। PAN वही हो और सिर्फ़ बैंक खाता बदला हो, तो PAN की call दोबारा ख़र्च करने का कोई कारण नहीं। हर दोबारा जमा करने को पिछले प्रयास से जोड़कर रखिए, ताकि समीक्षक देख सके कि वेंडर ने क्या-क्या बदला।
• एक ही वेंडर, दो टीमों के ज़रिए। बड़े संगठनों में अलग-अलग विभाग एक ही सप्लायर को अलग-अलग नामों से जोड़ लेते हैं। डुप्लिकेट की पहचान वाला चरण इसे पकड़ने की सबसे सस्ती जगह है, और ऐसे मिलान पर नया वेंडर बनाने की जगह मौजूदा रिकॉर्ड में दूसरा संपर्क या दूसरा खाता जोड़ना ठीक है।

देखने लायक़ मीट्रिक

आम ग़लतियाँ

• बैंक खाते की जाँच पहले चलाना, या PAN पास होने से पहले।
• बैंक के नाम की तुलना verify किए नाम की जगह टाइप किए नाम से करना।
• डुप्लिकेट पहचान छोड़ देना, जिससे एक संस्था दो वेंडर बन जाती है।
• हर ग़ैर-व्यक्ति वेंडर के लिए CIN अनिवार्य करना।
• timeout हुई bank verification को आँख मूँदकर retry करना।
• GSTIN में बैठे PAN की verify किए PAN से तुलना किए बिना GSTIN पर मंज़ूरी देना।
• मंज़ूरी को बिना रोक और बिना सीमा के तुरंत भुगतान की इजाज़त मान लेना।
• बदला हुआ बैंक खाता बिना दोबारा verification और callback के जाने देना।
• नाम के फ़र्क़ पर समीक्षा में भेजने की जगह अपने-आप अस्वीकार कर देना।
• पूरे वेंडर-आधार को बिना गति-नियंत्रण के एक ही बार में backfill करना।
• असली वेंडरों को मंज़ूर करने के लिए sandbox के नतीजे इस्तेमाल करना। sandbox सैंपल डेटा लौटाता है।

आगे क्या करें

quickstart से sandbox key लीजिए और दर्ज टेस्ट वैल्यू के सामने प्रवाह बनाइए। फिर production के लिए आवेदन से पहले sandbox बनाम production टेस्टिंग गाइड और भेजने से पहले एरर, retry और idempotency पढ़िए। हर call से क्या रखना है, यह verification कॉल से क्या लॉग करें में है। सवाल support को भेजिए।

API reference एक नज़र में

{
  "referenceId": "SMV-20260927-8F42K7",
  "pan": "ABCDE1234F",
  "type": "Individual",
  "valid": true,
  "registeredName": "RAHUL KUMAR",
  "fatherName": "SURESH KUMAR",
  "panStatus": "VALID",
  "panStatusCode": "E",
  "panStatusDescription": "Existing and valid PAN",
  "nameMatchResult": "MATCH",
  "nameMatchScore": "100",
  "aadhaarSeedingStatus": "y",
  "aadhaarSeedingStatusDescription": "Aadhaar linked",
  "lastUpdatedAt": "2023-04-01",
  "message": "PAN is Valid"
}

{
  "referenceId": "SMV-20260927-9K21P4",
  "verificationId": "VRF-4M8Q2T7XB9KD",
  "gstin": "29AAICP2912R1ZR",
  "GSTIN": "29AAICP2912R1ZR",
  "valid": true,
  "legalNameOfBusiness": "UJJIVAN SMALL FINANCE BANK LIMITED",
  "tradeNameOfBusiness": "UJJIVAN SMALL FINANCE BANK",
  "centerJurisdiction": "I-A RANGE",
  "stateJurisdiction": "GUWAHATI - A - 1",
  "dateOfRegistration": "2017-09-30",
  "constitutionOfBusiness": "Public Limited Company",
  "taxpayerType": "Regular",
  "gstinStatus": "Active",
  "lastUpdateDate": "2022-03-01",
  "natureOfBusinessActivities": [
    "Retail Business",
    "Supplier of Services",
    "Recipient of Goods or Services",
    "Office / Sale Office",
    "Others"
  ],
  "principalPlaceAddress": "First Floor 3512-DISPUR Prithivi Mansion opp. KFC building G.S. Road, Lachit Nagar Assam 781007",
  "principalPlaceSplitAddress": {
    "buildingName": "Prithivi Mansion",
    "street": "G.S. Road",
    "location": "Lachit Nagar",
    "buildingNumber": "3512-DISPUR",
    "district": "Guwahati",
    "state": "Assam",
    "city": "Dispur",
    "flatNumber": "First Floor",
    "latitude": "26.1445",
    "longitude": "91.7362",
    "pincode": "781007"
  },
  "additionalAddresses": [
    {
      "address": "Mirza Santipur NH-37 Dist-Kamrup Rural PS-Palashbari, PO  Mirza Kamrup Assam 781125",
      "splitAddress": {
        "buildingName": "",
        "street": "NH-37",
        "location": "Santipur, Mirza",
        "buildingNumber": "",
        "district": "Kamrup Rural",
        "state": "Assam",
        "city": "Palashbari",
        "flatNumber": "",
        "latitude": "26.0926",
        "longitude": "91.5069",
        "pincode": "781125"
      }
    },
    {
      "address": "N.A.C.C.I. Foundation 3559-Tezpur CHAMBER BHAWAN Binjraj Road, P. o. and P.S. - Tezpur, Dist. Binjraj Road, P. o. and P.S. - Tezpur, Dist. Sonitpur Assam 784154",
      "splitAddress": {
        "buildingName": "CHAMBER BHAWAN",
        "street": "Binjraj Road",
        "location": "Tezpur",
        "buildingNumber": "3559-Tezpur",
        "district": "Sonitpur",
        "state": "Assam",
        "city": "Tezpur",
        "flatNumber": "",
        "latitude": "26.6338",
        "longitude": "92.8006",
        "pincode": "784154"
      }
    }
  ],
  "message": "GSTIN Exists",
  "legalName": "UJJIVAN SMALL FINANCE BANK LIMITED",
  "tradeName": "UJJIVAN SMALL FINANCE BANK",
  "registrationStatus": "Active",
  "principalPlaceOfBusiness": "First Floor 3512-DISPUR Prithivi Mansion opp. KFC building G.S. Road, Lachit Nagar Assam 781007"
}

{
  "referenceId": "SMV-20260927-6R38Y3",
  "verificationId": "VRF-6C2N9V4HQ7ZE",
  "valid": true,
  "status": "VALID",
  "cin": "U72900KA2015PTC082988",
  "companyName": "COMPANY NAME",
  "registrationNumber": 82987,
  "incorporationDate": "2015-09-23",
  "cinStatus": "ACTIVE",
  "email": "[email protected]",
  "incorporationCountry": "INDIA",
  "directorDetails": [
    {
      "din": "07168822",
      "name": "Frank Kelvin",
      "dob": "1997-07-21",
      "designation": "DIRECTOR",
      "address": "ST BED KORAMANGALA, BANGALORE, KARNATAKA, INDIA, 566634"
    },
    {
      "din": "07168826",
      "name": "John Doe",
      "dob": "1997-02-07",
      "designation": "DIRECTOR",
      "address": "GAUTAM NAGAR, NOIDA, UTTAR PRADESH, INDIA, 211361"
    }
  ],
  "companyStatus": "ACTIVE",
  "directors": [
    {
      "din": "07168822",
      "name": "Frank Kelvin",
      "designation": "DIRECTOR"
    },
    {
      "din": "07168826",
      "name": "John Doe",
      "designation": "DIRECTOR"
    }
  ]
}

{
  "referenceId": "SMV-20260927-3B71A0",
  "valid": true,
  "nameAtBank": "RAVI KUMAR",
  "bankName": "ICICI Bank",
  "utr": "017952100012345",
  "city": "Mumbai",
  "branch": "Andheri West",
  "micr": "400229002",
  "nameMatchScore": "100",
  "nameMatchResult": "GOOD_MATCH",
  "accountStatus": "ACCOUNT_IS_VALID",
  "accountStatusCode": "1",
  "ifscDetails": {
    "bank": "ICICI Bank",
    "ifsc": "ICIC0001234",
    "micr": "400229002",
    "address": "Andheri West, Mumbai",
    "city": "Mumbai",
    "state": "Maharashtra",
    "branch": "Andheri West"
  }
}

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