PAN, GSTIN और CIN में फ़र्क: हर पहचान से क्या verify होता है

मुख्य बातें

• PAN करदाता की पहचान है। इसमें दस अक्षर होते हैं और चौथा अक्षर बताता है कि धारक व्यक्ति है, कंपनी है, फ़र्म है या ट्रस्ट।
• GSTIN एक GST रजिस्ट्रेशन की पहचान है। पंद्रह अक्षरों में राज्य का कोड, धारक का PAN, एंटिटी नंबर, एक स्थायी Z और आख़िर में चेक कैरेक्टर होता है। इसलिए एक PAN के पीछे कई GSTIN हो सकते हैं।
• CIN कंपनी की पहचान है। इक्कीस अक्षरों में लिस्टिंग, उद्योग, राज्य, साल और कंपनी का प्रकार छिपा होता है। इसमें PAN नहीं होता।
• लुकअप सिर्फ़ इतना पक्का करता है कि रिकॉर्ड मौजूद है और स्रोत ने जो आख़िरी बार अपडेट किया, वही दिख रहा है। इससे यह साबित नहीं होता कि आपके सामने बैठा आदमी उस नंबर का मालिक है।
• एंटिटी के प्रकार के हिसाब से नंबर माँगिए: व्यक्ति से PAN, प्रोपराइटर और फ़र्म से PAN और GSTIN, कंपनी से PAN, GSTIN और CIN।
• लंबाई, अक्षरों की बनावट, राज्य कोड और GSTIN का चेक कैरेक्टर जैसे ऑफ़लाइन चेक फ़ालतू कॉल बचाते हैं। पर docs का सैंपल GSTIN और sandbox के GSTIN चेक कैरेक्टर पर पास नहीं होते, इसलिए यह चेक sandbox में बंद रखिए।
• हर लुकअप अलग call है, अलग endpoint और scope के साथ, और हर एक का अपना referenceId है। दो नतीजों को आपस में मिलाना आपके कोड का काम है।

तीन नंबर, तीन सवाल: एक नज़र में तुलना

नीचे की तालिका में तीनों पहचानें साथ-साथ रखी हैं। पहले आख़िरी दो पंक्तियाँ पढ़िए, क्योंकि ऑनबोर्डिंग की ग़लतियाँ वहीं होती हैं।

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

PAN को अक्षर-दर-अक्षर पढ़ना

PAN का ढाँचा AAAAA9999A है: पाँच अक्षर, चार अंक, एक अक्षर। यह ढाँचा सार्वजनिक है और बदलता नहीं। StampMitra का PAN endpoint सबसे पहले यही जाँचता है। ग़लत बनावट पर तुरंत 400 आता है और संदेश होता है pan must match the format ABCDE1234F।

कारोबार के लिहाज़ से सबसे काम का चौथा अक्षर है। इससे आप बिना नेटवर्क कॉल किए एक साफ़ ग़लत नंबर पकड़ लेते हैं।

इसे संगति की जाँच की तरह इस्तेमाल कीजिए। कोई कहे कि वह प्राइवेट लिमिटेड कंपनी है और PAN का चौथा अक्षर P निकले, तो या तो उसने अपना निजी PAN दे दिया है या वह कंपनी है ही नहीं। यह सवाल पूछने की वजह है, सीधे reject करने की नहीं, क्योंकि ग़लतियाँ आम हैं। StampMitra का अपना ऑनबोर्डिंग फ़ॉर्म भी यही तर्क लगाता है: व्यक्ति और प्रोपराइटर के लिए P, पार्टनरशिप और LLP के लिए F, कंपनी के लिए C, और ट्रस्ट या सोसाइटी के लिए T या A की उम्मीद।

PAN के जवाब में type भी आता है, जैसे Individual। यानी आप लौटे हुए प्रकार को चौथे अक्षर से और आवेदक के दावे से मिला सकते हैं।

GSTIN की बनावट

GSTIN पंद्रह अक्षर का होता है और हर हिस्से का एक काम है। नीचे docs के सैंपल 07AAAAA1111A1Z1 पर हिस्से तोड़कर दिखाए हैं।

राज्य कोड डाक पिन कोड नहीं हैं

शुरू के दो अंक GST की अपनी सूची के राज्य कोड हैं। दिल्ली 07, उत्तर प्रदेश 09, महाराष्ट्र 27, कर्नाटक 29, तमिलनाडु 33, तेलंगाना 36। केंद्र शासित प्रदेशों और कुछ विशेष मामलों के अपने कोड हैं। आपके validation कोड में पूरी सूची होनी चाहिए, क्योंकि अनजाना कोड मुफ़्त और तुरंत reject का मौक़ा है।

एक PAN, कई GSTIN क्यों

GST रजिस्ट्रेशन राज्य के हिसाब से होता है। जिस कंपनी के तीन राज्यों में दफ़्तर या गोदाम हैं, उसके पास तीन GSTIN होंगे और तीनों में एक ही PAN होगा। एक राज्य में दो अलग कारोबारी रजिस्ट्रेशन भी हो सकते हैं, और तेरहवाँ अक्षर यही गिनता है। इसलिए "इस PAN का GSTIN क्या है?" ग़लत सवाल है। सही सवाल हैं: "इनवॉइस पर जो GSTIN छपा है, वह मेरे verify किए PAN का है या नहीं?" और "supply की जगह किस राज्य से मेल खाती है?" उलटी दिशा के लिए PAN to GSTIN लुकअप है, जो किसी PAN से जुड़े GSTIN की सूची राज्य और स्थिति के साथ लौटाता है।

चेक कैरेक्टर

पंद्रहवाँ अक्षर पहले चौदह का checksum है। इसमें 0 से 9 और A से Z को base 36 के अंक माना जाता है, बारी-बारी से एक और दो से गुणा किया जाता है, हर गुणनफल को वापस base 36 में तोड़कर जोड़ा जाता है और अंत में 36 के modulo का पूरक लिया जाता है। इससे ज़्यादातर एक-अक्षर की टाइपिंग ग़लतियाँ और कई अक्षर-अदला-बदली पकड़ में आ जाती हैं। चलता हुआ कोड आगे "ऑफ़लाइन चेक" वाले हिस्से में है। एक चेतावनी यहीं ज़रूरी है: StampMitra docs का सैंपल GSTIN और sandbox के जो GSTIN लिखे हैं, उनका चेक कैरेक्टर सही नहीं बैठता। वे टेस्ट वैल्यू हैं। फ़ॉर्म में चेक कैरेक्टर की जाँच जोड़ें तो उसे सिर्फ़ production में चलाइए, वरना sandbox के टेस्ट API तक पहुँचने से पहले ही गिर जाएँगे।

CIN की बनावट

CIN इक्कीस अक्षर का होता है। docs का सैंपल U74999DL2015PTC284009 लेकर देखिए।

दो बातें लोगों को चौंकाती हैं। पहली, CIN जीवन भर एक जैसा नहीं रहता: लिस्टिंग का अक्षर, राज्य कोड और उद्योग कोड कंपनी की किसी समय की हालत बताते हैं, और जब रजिस्टर में ये बदलते हैं, जैसे कंपनी लिस्ट हो या पंजीकृत कार्यालय दूसरे राज्य में जाए, तब आम तौर पर नया CIN जारी होता है। इसलिए जिस CIN को verify किया उसे verify करने की तारीख़ के साथ रखिए। दूसरी, CIN में PAN नहीं होता। कंपनी का अपना PAN होता है, पर वह कंपनी से माँगकर PAN लुकअप से जाँचना पड़ता है। निकाला नहीं जा सकता।

LLP और बाक़ी संस्थाएँ

LLP को कंपनी जैसा CIN नहीं मिलता। उसकी पहचान LLPIN है, जो तीन अक्षर, एक हाइफ़न और चार अंक जैसा दिखता है। प्रोपराइटरशिप का कंपनी रजिस्ट्री में कोई अपना पंजीकरण होता ही नहीं: उसकी पहचान मालिक का PAN है, और उसके साथ अगर कारोबार के पास GST या Udyam है तो वह। पंजीकृत पार्टनरशिप फ़र्म का फ़र्म PAN (चौथा अक्षर F) होता है, पर वह कंपनी रजिस्ट्री में नहीं, राज्य के फ़र्म रजिस्ट्रार के पास दर्ज होती है। अगर आपके ऑनबोर्डिंग में LLP आते हैं, तो LLPIN को उसी फ़ील्ड में भेजने से पहले CIN verification reference में देख लीजिए कि आपके खाते पर कौन-से इनपुट चलते हैं।

Udyam चौथी पहचान है, जो सूक्ष्म, लघु और मध्यम उद्योगों के पास मिलती है। उसका अलग लुकअप है और अलग गाइड भी: GSTIN, CIN और Udyam से बिज़नेस वेरिफ़िकेशन।

PAN लुकअप से क्या साबित होता है और क्या खुला रहता है

POST /v1/verify/pan के जवाब में valid, type, registeredName, panStatus और panStatusDescription जैसे फ़ील्ड आते हैं, और अगर आपने name भी भेजा हो तो nameMatchResult और nameMatchScore भी। फ़ील्ड की पूरी तालिका इसी गाइड में आगे है।

इससे यह साबित होता है कि नंबर रिकॉर्ड में है, उसकी पढ़ने लायक स्थिति है, और आपके दिए नाम से रिकॉर्ड का नाम कितना मिलता है, यह नापा जा सकता है।

जो साबित नहीं होता, वह इससे ज़्यादा अहम है। यह साबित नहीं होता कि फ़ॉर्म में नंबर डालने वाला आदमी ही PAN का मालिक है। PAN कोई गुप्त चीज़ नहीं है, लोग उसकी फ़ोटो आम तौर पर भेज देते हैं, और लुकअप सिर्फ़ यह देखता है कि नंबर मौजूद है। अगर आपके जोखिम मॉडल को "यह आदमी इस PAN का मालिक है" चाहिए, तो उसके लिए अलग स्वामित्व वाला कदम चाहिए, और StampMitra Aadhaar आधारित verification नहीं देता। पता भी साबित नहीं होता, क्योंकि PAN पते का दस्तावेज़ नहीं है। कारोबार असल में चल रहा है या सॉल्वेंट है, यह भी नहीं। और जवाब स्रोत की आख़िरी ताज़गी को दिखाता है, जिसे API और सरकारी पोर्टल के नतीजों में फ़र्क वाली गाइड विस्तार से समझाती है।

PAN endpoint की गहरी जानकारी के लिए PAN verification API गाइड पढ़िए।

GSTIN लुकअप से क्या साबित होता है और क्या खुला रहता है

POST /v1/verify/gstin में gstin और वैकल्पिक businessName जाता है, और जवाब में valid, legalName, tradeName, registrationStatus, principalPlaceOfBusiness और message लौटते हैं। जाँचे गए नंबर की गूँज GSTIN फ़ील्ड में आती है।

इससे यह साबित होता है कि उस नंबर का रजिस्ट्रेशन मौजूद है, वह एक legal name और trade name पर दर्ज है और उसकी एक स्थिति है। वेंडर ऑनबोर्डिंग में सबसे अहम फ़ील्ड registrationStatus है। docs के सैंपल में Active दिखता है। स्रोत पर दूसरी स्थितियाँ भी होती हैं, जैसे रद्द या निलंबित रजिस्ट्रेशन, और reference उनकी पूरी सूची नहीं देता। इसलिए अपना नियम ऐसा रखिए: "Active हो तो पास, बाक़ी सब समीक्षा में", और कच्चा मान लॉग कर लीजिए।

जो साबित नहीं होता: रिटर्न भरे जा रहे हैं या नहीं, टैक्स चुकाया जा रहा है या नहीं, और जिस संस्था के नाम रजिस्ट्रेशन है वही आपकी कॉन्ट्रैक्ट वाली पार्टी है या नहीं। कोई वेंडर आपको असली और चालू GSTIN थमा सकता है जो असल में किसी और का है। बचाव है नाम की तुलना, इसीलिए endpoint businessName लेता है, और PAN की तुलना, यानी GSTIN के अक्षर 3 से 12 को वेंडर के verify किए PAN से मिलाइए। principal place of business संदर्भ के लिए काम की है, इस बात का सबूत नहीं कि माल कहाँ से जाता है।

स्थितियों और इनपुट नियमों की विस्तृत चर्चा GSTIN को प्रोग्राम से कैसे verify करें में है।

CIN लुकअप से क्या साबित होता है और क्या खुला रहता है

POST /v1/verify/cin में cin जाता है और जवाब में valid, companyName, incorporationDate, cinStatus, companyStatus, directors की सूची (हर एक में din, name, designation), directorDetails की सूची जो हर director में dob और address जोड़ती है, email, registrationNumber और incorporationCountry आते हैं।

इससे साबित होता है कि कंपनी रजिस्टर में है, रजिस्टर के आख़िरी अपडेट तक की स्थिति और निदेशकों के साथ। "इस कंपनी के लिए दस्तख़त कौन कर सकता है" वाले सवाल के लिए यही सबसे काम की पहचान है, क्योंकि नाम और DIN मिलते हैं जिन्हें आप आवेदन करने वाले व्यक्ति से मिला सकते हैं।

जो साबित नहीं होता: आवेदक इन निदेशकों में से है या उनका अधिकृत प्रतिनिधि है (इसके लिए बोर्ड प्रस्ताव या authorisation letter चाहिए, और StampMitra का production access फ़ॉर्म ठीक इन्हीं दस्तावेज़ों को माँगता है), कंपनी का कारोबार चल रहा है, और उसके टैक्स रजिस्ट्रेशन ठीक हैं। कंपनी रजिस्टर में हो सकती है और उसके पास वैध GST रजिस्ट्रेशन न हो, और नाम बदलने के बाद GSTIN पुराने नाम से भी दिख सकता है।

तीनों आपस में कहाँ जुड़ते हैं और कहाँ कभी नहीं

रिश्ते सिर्फ़ एक दिशा में चलते हैं।

• GSTIN के अंदर PAN है। अक्षर 3 से 12 निकालकर किसी भी verify किए PAN से मिलाइए।
• PAN के अंदर GSTIN नहीं है। इसके लिए PAN to GSTIN लुकअप चाहिए, या वेंडर खुद बताए।
• CIN के अंदर दोनों में से कुछ नहीं। कंपनी का CIN उसके PAN से जोड़ने के लिए कंपनी से PAN माँगिए, उसे verify कीजिए और PAN से लौटे नाम को CIN से लौटे कंपनी नाम से मिलाइए।
• PAN का चौथा अक्षर एंटिटी के प्रकार से मेल खाना चाहिए: कंपनी के लिए C, फ़र्म या LLP के लिए F, व्यक्ति या प्रोपराइटर के लिए P।

इससे पाँच सस्ती संगति-जाँचें बनती हैं, जिनमें उन calls के अलावा कुछ अतिरिक्त ख़र्च नहीं जो आप वैसे भी कर रहे थे।

1. PAN का चौथा अक्षर दावा किए गए प्रकार से मेल खाता है।
2. GSTIN के अक्षर 3 से 12 verify किए PAN के बराबर हैं।
3. GSTIN का राज्य कोड वेंडर के बताए पते के हिसाब से समझ में आता है। पुणे के वेंडर का कर्नाटक रजिस्ट्रेशन हो सकता है, पर आपको कारण पता होना चाहिए।
4. GSTIN, PAN और CIN से आए नाम सामान्य रूप में एक जैसे हैं, यानी अक्षरों का केस, विराम चिह्न और "Private Limited" बनाम "Pvt Ltd" को एक करने के बाद।
5. कंपनी के मामले में आवेदन करने वाला व्यक्ति CIN के directors में है या उसके पास authorisation दस्तावेज़ है।

किस तरह की पार्टी से कौन-सा नंबर माँगें

सबसे सब कुछ माँगने से यूज़र बीच में छोड़ जाते हैं और पैसा बेवजह लगता है। वही माँगिए जो वह एंटिटी रख सकती है।

वेंडर पर किस क्रम में कौन-से चेक चलाएँ, इसका पूरा ढाँचा वेंडर ऑनबोर्डिंग फ़्लो में है। व्यक्तिगत और कारोबारी कर्ज़दारों के लिए KYC बनाम KYB देखिए।

कॉल करने से पहले ऑफ़लाइन चेक

फ़ॉर्मेट की जाँच मुफ़्त है, तुरंत होती है और सबसे आम इनपुट ग़लतियाँ पकड़ लेती है। इससे 400 वाला रास्ता उन मामलों के लिए बचा रहता है जिनकी आपने कल्पना नहीं की थी। तीनों के लिए नीचे छोटा JavaScript संस्करण है।

// identifiers.mjs
const PAN_RE = /^[A-Z]{5}[0-9]{4}[A-Z]$/;
const GSTIN_RE = /^[0-9]{2}[A-Z]{5}[0-9]{4}[A-Z][1-9A-Z]Z[0-9A-Z]$/;
const CIN_RE = /^[LU][0-9]{5}[A-Z]{2}[0-9]{4}[A-Z]{3}[0-9]{6}$/;

const PAN_TYPES = { P: "Individual", C: "Company", H: "HUF", F: "Firm or LLP", A: "AOP", B: "BOI", T: "Trust", L: "Local authority", J: "Artificial juridical person", G: "Government" };

export function checkPan(raw) {
  const pan = String(raw ?? "").trim().toUpperCase();
  if (!PAN_RE.test(pan)) return { ok: false, reason: "FORMAT" };
  const holder = PAN_TYPES[pan[3]];
  if (!holder) return { ok: false, reason: "HOLDER_TYPE" };
  return { ok: true, pan, holder };
}

const CHARSET = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";
function gstinCheckChar(first14) {
  let sum = 0;
  for (let i = 0; i < 14; i++) {
    const product = CHARSET.indexOf(first14[i]) * (i % 2 === 0 ? 1 : 2);
    sum += Math.floor(product / 36) + (product % 36);
  }
  return CHARSET[(36 - (sum % 36)) % 36];
}

export function checkGstin(raw, { checkDigit = true } = {}) {
  const gstin = String(raw ?? "").trim().toUpperCase();
  if (!GSTIN_RE.test(gstin)) return { ok: false, reason: "FORMAT" };
  if (checkDigit && gstinCheckChar(gstin.slice(0, 14)) !== gstin[14]) return { ok: false, reason: "CHECKSUM" };
  return { ok: true, gstin, stateCode: gstin.slice(0, 2), embeddedPan: gstin.slice(2, 12) };
}

जिस key का prefix sk_test_ हो, वहाँ checkDigit को false कर दीजिए। docs का सैंपल 07AAAAA1111A1Z1 और sandbox के GSTIN चेक कैरेक्टर पर फ़ेल होते हैं, और placeholder के लिए यही अपेक्षित है। CIN का पैटर्न यहाँ जान-बूझकर छोड़ा है: असली CIN में, ख़ासकर पुराने रिकॉर्ड में, कंपनी-प्रकार वाले हिस्से में बदलाव दिखे हैं, इसलिए क्लाइंट पर ढीला रहिए और अंतिम फ़ैसला API पर छोड़िए। झूठा reject आपका ग्राहक खोता है, झूठा accept सिर्फ़ एक call ख़र्च कराता है।

वही जाँच Python में

import re

PAN_RE = re.compile(r"^[A-Z]{5}[0-9]{4}[A-Z]$")
GSTIN_RE = re.compile(r"^[0-9]{2}[A-Z]{5}[0-9]{4}[A-Z][1-9A-Z]Z[0-9A-Z]$")
CHARSET = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ"

def gstin_check_char(first14: str) -> str:
    total = 0
    for i, ch in enumerate(first14):
        product = CHARSET.index(ch) * (1 if i % 2 == 0 else 2)
        total += product // 36 + product % 36
    return CHARSET[(36 - total % 36) % 36]

def split_gstin(raw: str, check_digit: bool = True) -> dict:
    gstin = (raw or "").strip().upper()
    if not GSTIN_RE.match(gstin):
        return {"ok": False, "reason": "FORMAT"}
    if check_digit and gstin_check_char(gstin[:14]) != gstin[14]:
        return {"ok": False, "reason": "CHECKSUM"}
    return {"ok": True, "gstin": gstin, "state_code": gstin[:2], "embedded_pan": gstin[2:12]}

तीनों endpoint को कॉल करना

तीनों /v1/verify/ के नीचे POST endpoint हैं। प्रमाणीकरण Authorization: Bearer <key> से होता है (x-api-key header भी चलता है) और हर एक के लिए key पर अपना scope चाहिए: verification.pan.read, verification.gstin.read और verification.cin.read। scope न हो तो 403 आता है, code FORBIDDEN के साथ। नीचे docs की सैंपल वैल्यू से तीनों calls हैं।

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":"Rahul Kumar"}'

curl -X POST "https://api-b2b.stampmitra.in/v1/verify/gstin" \
  -H "Authorization: Bearer $STAMPMITRA_API_KEY" -H "Content-Type: application/json" \
  -d '{"gstin":"07AAAAA1111A1Z1","businessName":"Jane Doe Enterprises"}'

curl -X POST "https://api-b2b.stampmitra.in/v1/verify/cin" \
  -H "Authorization: Bearer $STAMPMITRA_API_KEY" -H "Content-Type: application/json" \
  -d '{"cin":"U74999DL2015PTC284009"}'

Python में तीनों नतीजे एक छोटे helper से:

import os, requests

BASE = "https://api-b2b.stampmitra.in/v1/verify"
HEADERS = {"Authorization": f"Bearer {os.environ['STAMPMITRA_API_KEY']}", "Content-Type": "application/json"}

def call(path: str, body: dict) -> dict:
    r = requests.post(f"{BASE}/{path}", json=body, headers=HEADERS, timeout=10)
    data = r.json()
    if not r.ok:
        raise RuntimeError(f"{r.status_code} {data['error']['code']} request={data['error']['requestId']}")
    return data

pan = call("pan", {"pan": "ABCDE1234F", "name": "Jane Doe Enterprises Private Limited"})
gstin = call("gstin", {"gstin": "07AAAAA1111A1Z1", "businessName": "Jane Doe Enterprises"})
cin = call("cin", {"cin": "U74999DL2015PTC284009"})
print(pan["referenceId"], gstin["registrationStatus"], [d["din"] for d in cin["directors"]])

हर लुकअप में किन फ़ील्ड पर ध्यान दें

हर सफल जवाब में referenceId आता है, जिसका रूप SMV-YYYYMMDD-XXXXXXX है। नकारात्मक नतीजे में भी वह आता है, क्योंकि नकारात्मक फ़ैसला भी पूरा हुआ लुकअप है और उसका बिल बनता है। वह call की पहचान है, दोबारा भेजी गई कॉल की डुप्लीकेट पहचान नहीं।

तीनों को एक साथ कैसे सहेजें

ज़्यादातर टीमें वेंडर की पंक्ति में तीन टेक्स्ट कॉलम से शुरू करती हैं और बाद में पछताती हैं। तीनों पहचानों की उम्र और रिश्ते अलग हैं, इसलिए डेटा भी वैसे ही रखिए: एक एंटिटी का रिकॉर्ड, हर टैक्स रजिस्ट्रेशन की एक पंक्ति, और हर verification घटना की एक पंक्ति।

{
  "entity": { "id": "ent_1042", "claimedType": "PRIVATE_LTD", "pan": "ABCDE1234F", "cin": "U74999DL2015PTC284009" },
  "registrations": [
    { "gstin": "07AAAAA1111A1Z1", "stateCode": "07", "lastStatus": "Active", "lastCheckedAt": "2026-10-29" }
  ],
  "verifications": [
    { "referenceId": "SMV-20260927-8F42K7", "kind": "pan", "checkedAt": "2026-10-29", "outcome": "valid" }
  ]
}

PAN एंटिटी का होता है और कम बदलता है, जबकि GSTIN कारोबार के राज्य-रजिस्ट्रेशन खुलने-बंद होने के साथ आते-जाते हैं, इसलिए उनकी अलग पंक्तियाँ बनती हैं। स्थिति एक पल का तथ्य है, इसलिए उसके साथ lastCheckedAt रखिए और उसे समय-समय पर ताज़ा कीजिए। और referenceId से जुड़ी verification पंक्ति आपको पूरा जवाब अपने मुख्य डेटाबेस में रखे बिना ऑडिट की कड़ी दे देती है। रिटेंशन और मास्किंग पर verification कॉल से क्या लॉग करें में बात है।

एक पूरा उदाहरण: प्राइवेट लिमिटेड वेंडर जोड़ना

एक काल्पनिक ट्रेडिंग कंपनी, Jane Doe Enterprises Private Limited, वेंडर बनने के लिए आवेदन करती है। आवेदक आपको तीन नंबर और एक व्यक्ति का नाम देता है।

1. ऑफ़लाइन: PAN का चौथा अक्षर C है, जो "प्राइवेट लिमिटेड कंपनी" से मेल खाता है। GSTIN में वही PAN बैठा है। CIN में PTC कोड है। एक भी call ख़र्च नहीं हुई और तीन संगति-जाँचें पास हो गईं।
2. PAN call: valid सही है, type कंपनी दिखाता है और registeredName है JANE DOE ENTERPRISES PRIVATE LIMITED।
3. GSTIN call: registrationStatus Active है, legalName PAN के नाम से मिलता है, principalPlaceOfBusiness बेंगलुरु की है और राज्य कोड 29 यानी कर्नाटक है। वेंडर के इनवॉइस का पता भी बेंगलुरु का है, इसलिए समझाने को कुछ नहीं।
4. CIN call: cinStatus और companyStatus चालू हैं, incorporationDate 2015-03-12 है और directors में Rahul Kumar नाम का एक निदेशक है।
5. आवेदन करने वाला व्यक्ति Rahul Kumar है। उसका अधिकार संभावित है पर लुकअप से साबित नहीं, इसलिए आप बोर्ड प्रस्ताव या authorisation letter माँगते हैं, जैसा StampMitra खुद कंपनियों से माँगता है।

कुल ख़र्च तीन calls। अगर GSTIN की स्थिति Active के अलावा कुछ होती, या उसका legal name PAN के नाम से विराम चिह्नों से ज़्यादा अलग होता, या कोई निदेशक आवेदक से न मिलता, तो फ़ैसला अलग होता। हर ऐसे मामले में सही कदम स्वचालित reject नहीं, तीनों referenceId के साथ हाथ से समीक्षा है।

ऐसे किनारे के मामले जो सीधी जाँच को तोड़ देते हैं

लुकअप सीधे हैं। जिन संस्थाओं का वे वर्णन करते हैं, वे हमेशा सीधी नहीं होतीं। पहला अजीब वेंडर आने से पहले इनकी तैयारी कर लीजिए।

प्रोपराइटर के दो नाम होते हैं। PAN में व्यक्ति का नाम होता है, जबकि GST रजिस्ट्रेशन में वही व्यक्ति legal name है और दुकान का ब्रांड trade name। PAN के नाम की tradeName से तुलना फ़ेल होगी और legalName से पास। सही फ़ील्ड से तुलना कीजिए।

व्यक्ति के नाम बदलते हैं। रिकॉर्ड का नाम मौजूदा बैंक खाते या इनवॉइस के नाम से अलग हो सकता है, शादी के बाद नाम बदलने से लेकर वर्तनी की आदतों तक कई वजहों से। इनिशियल, नामों का क्रम और छूटा हुआ बीच का नाम बिना किसी धोखाधड़ी के स्कोर गिरा देते हैं। यहाँ बराबरी की जाँच से बेहतर है स्कोर और एक सीमा, और सख़्त reject से सस्ता है समीक्षा की एक अलग पंक्ति।

कंपनियाँ बदलती और नाम बदलती हैं। प्राइवेट से पब्लिक बनी कंपनी, या पंजीकृत कार्यालय दूसरे राज्य ले जाने वाली कंपनी, अपनी पुरानी लेटरहेड वाले CIN से अलग CIN पर पहुँच सकती है। नाम बदली कंपनी के पास ऐसा GSTIN भी हो सकता है जिसका legal name अभी पुराना है। जब वेंडर की कसम खाई हुई CIN पर लुकअप "नहीं मिला" कहे, तो धोखे का अनुमान लगाने से पहले ताज़ा incorporation प्रमाणपत्र माँगिए।

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

हर किसी के पास GSTIN नहीं होता। रजिस्ट्रेशन की सीमा से नीचे के छोटे कारोबार, कुछ छूट वाले आपूर्तिकर्ता और कई सेवा देने वाले वैध रूप से बिना GSTIN के होते हैं। बिना रजिस्ट्रेशन वाले आपूर्तिकर्ता से ख़रीदना ठीक है या नहीं, यह टैक्स और नीति का सवाल है जो आपकी फ़ाइनेंस टीम तय करेगी। verification API इसका जवाब नहीं दे सकती।

विदेशी पार्टियाँ। विदेशी वेंडर के पास तीनों में से कोई नहीं होता। PAN फ़ील्ड में नक़ली placeholder भरवाने की कोशिश मत कीजिए। अनिवासी पार्टियों को दूसरी प्रक्रिया में भेजिए।

सरकारी और सार्वजनिक संस्थाएँ। उनके PAN का चौथा अक्षर G या L होता है और हो सकता है उनके पास CIN हो ही नहीं। "हर गैर-व्यक्ति को CIN देना ज़रूरी" वाला नियम उन्हें रोक देगा।

LLP के पास CIN नहीं, LLPIN होता है। सीमित दायित्व साझेदारी का PAN चौथे अक्षर F के साथ फ़र्म जैसा दिखता है, पर कंपनी-रजिस्ट्री वाला CIN उसके पास नहीं होता। अगर आपके नियम में "फ़र्म हो तो GSTIN, कंपनी हो तो CIN" लिखा है, तो LLP को किस खाने में रखना है, यह पहले से लिख लीजिए। इस गाइड के endpoint CIN तक सीमित हैं, इसलिए LLP के लिए PAN, GSTIN और दस्तावेज़ों पर टिकिए।

ट्रस्ट, सोसाइटी और संयुक्त हिंदू परिवार। इनके PAN के चौथे अक्षर अलग होते हैं (जैसे ट्रस्ट के लिए T, परिवार के लिए H), और इनका GSTIN हो भी सकता है और नहीं भी। जो फ़ॉर्म हर गैर-व्यक्ति से CIN माँगता है, वह इन्हें वहीं रोक देगा। फ़ॉर्म में "संस्था का प्रकार" पहले पूछिए और उसी के हिसाब से अगले खाने दिखाइए।

कॉपी-पेस्ट से बिगड़े नंबर। वेंडर अक्सर नंबर किसी PDF या ईमेल से चिपकाते हैं और साथ में खाली जगह, लाइन टूटने का निशान या छोटे अक्षर आ जाते हैं। इन्हें अपनी तरफ़ साफ़ कर दीजिए (खाली जगह हटाइए, बड़े अक्षर कीजिए) और फिर ऑफ़लाइन जाँच चलाइए। इससे वह विफलता call तक पहुँचती ही नहीं जो असल में सिर्फ़ चिपकाने की ग़लती थी।

GSTIN का राज्य और पता मेल न खाएँ। राज्य कोड रजिस्ट्रेशन के राज्य को बताता है, वेंडर के इनवॉइस पते को नहीं। जो वेंडर एक राज्य में रजिस्टर्ड है और दूसरे राज्य के पते से इनवॉइस भेजता है, उसकी ग़लती नहीं भी हो सकती। इसे समीक्षा का सवाल बनाइए, अस्वीकार का कारण नहीं, और अपने कर सलाहकार से पूछ लीजिए कि ऐसे वेंडर से किस राज्य का GSTIN माँगना है।

रनबुक में चिपकाने लायक फ़ैसले का क्रम

सीधे-सादे चरणों में, ताकि compliance समीक्षक और इंजीनियर दोनों पढ़ सकें।

1. एंटिटी का प्रकार जो पहचानें रख सकता है, वही माँगिए (ऊपर की तालिका)। जो पहचान प्रकार के पास होनी चाहिए वह आवेदक न दे सके तो रुककर कारण पूछिए।
2. ऑफ़लाइन फ़ॉर्मेट जाँच चलाइए। यहाँ विफलता टाइपिंग की ग़लती है, verification का नतीजा नहीं। यूज़र को सुधार का संदेश दिखाइए, call ख़र्च मत कीजिए।
3. PAN का चौथा अक्षर दावा किए गए प्रकार से मिलाइए। बेमेल पर स्पष्टीकरण का सवाल पूछिए, reject मत कीजिए।
4. PAN verify कीजिए। valid ग़लत हो तो रुकिए। स्थिति सामान्य वैध स्थिति से अलग हो तो समीक्षा में भेजिए।
5. GSTIN दिया हो तो उसे verify कीजिए। registrationStatus Active और GSTIN में बैठा PAN verify किए PAN के बराबर होना चाहिए।
6. एंटिटी कंपनी हो तो CIN verify कीजिए। कंपनी का नाम मिलाइए और निदेशकों में आवेदक को खोजिए।
7. तीनों नाम सामान्य रूप में आने के बाद मिलाइए। सीमा से नीचे वाला हर मामला सभी referenceId के साथ समीक्षा में जाए।
8. नतीजा, तारीख़ और पहचानें दर्ज कीजिए। रजिस्ट्रेशन की दोबारा जाँच की समय-सारणी बनाइए, क्योंकि ऑनबोर्डिंग के समय चालू GSTIN बाद में रद्द हो सकता है।

बेमेल के आम पैटर्न और उनका मतलब

Sandbox की वैल्यू और sandbox कॉल से क्या पता चलता है

Sandbox में API सैंपल डेटा लौटाती है और किसी असली रिकॉर्ड को कभी verify नहीं करती। दर्ज टेस्ट इनपुट का नतीजा पहले से तय है: PAN SNDBX0000A वैध है और SNDBX9999F अवैध। GSTIN 09SNDBX0000A1Z5 वैध और सक्रिय है, और 09SNDBX9999F1Z5 अवैध है तथा रद्द दिखता है। CIN के लिए U00000SB0000SANDBOX000001 वैध है और U00000SB0000SANDBOX999999 अवैध। इनके अलावा किसी भी इनपुट का नतीजा स्थिर पर मनमाना होता है: एक ही इनपुट पर हमेशा एक ही जवाब आता है, और मोटे तौर पर तीन में से दो बार वैध निकलता है। लौटे सारे नाम बनावटी हैं।

दो सावधानियाँ। CIN की टेस्ट वैल्यू इक्कीस अक्षर की नहीं हैं, इसलिए आपके फ़ॉर्म का CIN पैटर्न उन्हें ठुकराए तो sandbox में ढीले पैटर्न से API को आज़माइए। और sandbox के "valid" को किसी असली कंपनी का सबूत कभी मत मानिए। डेमो में sandbox नतीजों पर भरोसा करने से पहले sandbox में क्या टेस्ट हो सकता है और क्या नहीं पढ़ लीजिए।

कॉल का हिसाब और ख़र्च

production में हर लुकअप अलग बिल होने वाली call है, इसलिए calls का क्रम ख़र्च का फ़ैसला भी है। standard pay-as-you-go दर पर PAN की call ₹5, GSTIN की ₹5 और CIN की ₹5 है। प्लान में ये दरें घटती हैं, और मौजूदा तालिका pricing पेज पर है। sandbox की calls आपके wallet से कभी नहीं कटतीं। व्यावहारिक क्रम: पहले मुफ़्त ऑफ़लाइन चेक, फिर PAN, फिर GSTIN सिर्फ़ तब जब PAN पास हो, और CIN सिर्फ़ कंपनियों के लिए। जिस व्यक्ति के पास रजिस्ट्रेशन नहीं, उसके लिए GSTIN की call मत कीजिए, और प्रोपराइटर के लिए CIN की call मत कीजिए।

आम ग़लतियाँ

• GSTIN को निगमन का सबूत मान लेना। प्रोपराइटर के पास GSTIN हो सकता है और कोई कंपनी बिल्कुल नहीं।
• नामों को बिल्कुल बराबर वाली स्ट्रिंग तुलना से मिलाना। पहले केस, विराम चिह्न और आम प्रत्यय एक कीजिए, फिर जहाँ API स्कोर देती है वह स्कोर इस्तेमाल कीजिए।
• सिर्फ़ valid: true सहेजना। referenceId, तारीख़ और जिन फ़ील्ड पर फ़ैसला लिया उन्हें सहेजिए, वरना बाद में फ़ैसले की सफ़ाई नहीं दे पाएँगे।
• sandbox में GSTIN का चेक कैरेक्टर चलाना। वह हर दर्ज सैंपल को ठुकरा देता है।
• यह भूल जाना कि एक PAN के कई GSTIN होते हैं, और वेंडर के पहले बताए GSTIN को ही verify करके रुक जाना।
• पुराने दस्तावेज़ से लिया CIN बिना यह देखे इस्तेमाल करना कि उसके अंदर का राज्य या लिस्टिंग की स्थिति बदल चुकी हो सकती है।
• endpoint को ब्राउज़र से कॉल करना। key आपके सर्वर पर रहनी चाहिए, देखिए authentication।

शब्दावली

आगे क्या करें

चेक बना रहे हैं तो quickstart से sandbox key लीजिए और फिर PAN, GSTIN और CIN के endpoint reference पढ़िए। विफलताओं को सँभालने के लिए एरर, 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"
    }
  ]
}

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