PAN को verify करके नाम कैसे मिलाएँ

मुख्य बातें

• एक endpoint: POST /v1/verify/pan, scope verification.pan.read। pan ज़रूरी, name वैकल्पिक (256 अक्षर तक)। name के बिना भी वैधता और रिकॉर्ड का नाम मिलता है, पर मिलान का सार्थक नतीजा नहीं।
• नाम वैसे भेजिए जैसे व्यक्ति अपने PAN कार्ड से लिखेगा, किसी भारी-भरकम साफ़ किए रूप में नहीं। तुलना के लिए अपनी तरफ़ normalise कीजिए, भेजने से पहले नहीं।
• docs के नमूने में nameMatchResult और nameMatchScore strings में आते हैं (MATCH और "100")। reference हर एक का एक ही उदाहरण दिखाता है, इसलिए संभव मानों का समूह खुला मानिए और स्कोर को तुलना से पहले संख्या में बदलिए।
• फ़ैसले की परतें रखिए: API का मिलान, फिर आपकी अपनी normalised तुलना, फिर इंसानी समीक्षा की कतार। किसी एक परत को पूरा जवाब मत मानिए।
• सीमाएँ अपने डेटा को नापकर तय कीजिए। किसी गाइड का दिया कोई भी अंक अंदाज़ा है, "काफ़ी अच्छा" कितना है इस बारे में भी।
• नाम मिलने से बस यह साबित होता है कि नाम रिकॉर्ड से मिलता-जुलता है। यह नहीं कि व्यक्ति PAN का मालिक है।
• sandbox सैंपल डेटा लौटाता है, इसलिए वह असली नामों पर मिलान के बर्ताव के बारे में कुछ नहीं बताता। मिलान की नीति fixtures पर परखिए और असली डेटा पर production में, सहमति के साथ, सावधानी से कसिए।
• referenceId, स्कोर और अपना फ़ैसला सहेजिए। logs में PAN मास्क कीजिए।

एक ही व्यक्ति के नाम मेल क्यों नहीं खाते

अगर आपने कुछ सौ असली नाम-जोड़ियाँ नहीं देखी हैं, तो बिगड़ने के तरीक़े चौंकाते हैं। ये ज़्यादातर टाइपो नहीं हैं, ये प्रचलन हैं।

सूची को फिर देखिए। सिर्फ़ आख़िरी दो पंक्तियाँ ऐसे बेमेल हैं जिन्हें कोई एल्गोरिदम भरोसे से सुलझा देता है। बाक़ी संदर्भ पर निर्भर हैं, और सँभला डिज़ाइन उन्हें उस परत पर भेजता है जो संदर्भ का उपयोग कर सके: पहले आपका normalisation, फिर कोई इंसान।

फ़ॉर्म ऐसा बनाइए कि पहले ही कम नाम फ़ेल हों

जो नाम-बेमेल आप देखेंगे उनमें से आधे फ़ॉर्म ने खुद बनाए होते हैं। कुछ चुनाव किसी भी API call से पहले उन्हें घटा देते हैं।

नाम वैसे माँगिए जैसा PAN कार्ड पर छपा है। संकेत फ़ील्ड के पास रखिए, किसी सहायता पेज में नहीं: "आपके PAN कार्ड पर छपा पूरा नाम"। नाम को चिह्नित करके दिखाया नमूना कार्ड का छोटा चित्र बहुत सस्ता पड़ता है और यह उलझन मिटा देता है कि कौन-सी पंक्ति उतारनी है।

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

कम से कम दो शब्दों की शर्त मत लगाइए। कुछ लोगों का एक ही नाम होता है। इसे ठुकराने वाला नियम ठीक वही ग्राहक पैदा करता है जो कोई सरनेम गढ़ेंगे और मिलान में फ़ेल होंगे।

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

रिकॉर्ड का नाम वापस दिखाएँ तो सावधानी से। यूज़र को दिखाना ("हमें यह नाम मिला: RAHUL KUMAR। क्या यह आप हैं?") पुष्टि करके बेमेल सुलझा सकता है, पर वह टाइप करने वाले किसी भी व्यक्ति को निजी डेटा भी दिखा देता है। इसे सिर्फ़ ऐसे कदम के बाद इस्तेमाल कीजिए जो व्यक्ति के धारक होने की संभावना बढ़ाए, और किसी सार्वजनिक पेज पर कभी नहीं।

जहाँ भरोसेमंद स्रोत हो वहाँ पहले से भर दीजिए। अगर ग्राहक आपके पास पहले से है और नाम पिछली verify की गई जाँच से आया था, तो उसे दोबारा पूछने की जगह दोबारा इस्तेमाल करके मिलाइए।

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

फ़ोन के कीबोर्ड की आदतें भी बेमेल बनाती हैं। अपने-आप बड़ा होने वाला पहला अक्षर कोई दिक़्क़त नहीं (केस वैसे भी हटता है), पर शब्द सुधारने वाली सुविधा "Aslam" को "Aslan" या "Sharma" को "Charm" में बदल सकती है, और आवाज़ से लिखने की सुविधा नामों को आम शब्दों में तोड़ देती है। अगर आपके मोबाइल ट्रैफ़िक में कई ऐसे बेमेल आते हैं, तो name फ़ील्ड पर शब्द-सुधार बंद रखिए और भेजने से पहले यूज़र को टाइप किया नाम एक बार साफ़ दिखाइए।

name फ़ील्ड में क्या भेजें

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

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

name फ़ील्ड में 256 अक्षर तक आ सकते हैं। placeholder भेजने से बेहतर है कुछ न भेजना। name के बिना भी आपको वैधता, status और registeredName मिलते हैं, जिन्हें आप खुद मिला सकते हैं।

नाम भेजने पर 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":"Rahul Kumar"}'

docs की बनावट में जवाब:

{
  "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"
}

डीबगिंग का समय बचाने वाली दो चेतावनियाँ। पहली, reference nameMatchResult, panStatusCode और aadhaarSeedingStatus का एक-एक उदाहरण मान ही दर्ज करता है। जो मान आपने देखे नहीं, उन पर पूरा switch मत लिखिए। एक default शाखा रखिए जो अनजाने मानों को समीक्षा में भेजे और पूरा जवाब लॉग करे। दूसरी, इस जवाब में nameMatchScore एक string है, इसलिए कई भाषाओं में शब्दकोश-क्रम की तुलना में "100" > "95" ग़लत और "95" > "100" सही निकलता है। तुलना से पहले Number() या float() से बदलिए।

nameMatchResult और nameMatchScore पढ़ना

दर्ज नमूना MATCH के साथ "100" स्कोर लौटाता है। और कौन-से नतीजे और स्कोर होते हैं, और कौन-सी सीमाएँ उन्हें अलग करती हैं, यह reference में दर्ज नहीं, और मिलान का एल्गोरिदम प्रकाशित नहीं है। इसी से तय होता है कि उन्हें कैसे इस्तेमाल करना चाहिए।

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

लेबल को खुला समूह मानिए। MATCH दिखाया गया है। उसके अलावा कुछ भी "नमूने वाले नतीजे से अलग कुछ" है और आपकी अगली परत में जाना चाहिए। अच्छा पैटर्न यह है: API का MATCH आपके चुने स्कोर पर या उससे ऊपर हो तो स्वीकार कीजिए, सिर्फ़ लेबल के आधार पर कुछ अपने-आप ख़ारिज मत कीजिए, और बाक़ी हर नतीजे को फ़ैसले से पहले अपनी तुलना से गुज़ारिए।

स्कोर कभी ग्राहक को मत दिखाइए। "आपका नाम 82% मिला" जैसा संदेश बहस न्योतता है और नीति खोल देता है। कार्रवाई दिखाइए: नाम की पुष्टि करें, दस्तावेज़ अपलोड करें, या समीक्षा की प्रतीक्षा करें।

मिलान की परतदार योजना

तीन परतें, हर एक अगली की तुलना में सस्ती।

परत 1: API की तुलना। name भेजिए। नतीजा आपकी स्कोर-सीमा पर या उससे ऊपर का मिलान हो, तो आम तौर पर काम पूरा। यह परत तेज़ है, प्लेटफ़ॉर्म का अपना तर्क इस्तेमाल करती है और कोई अतिरिक्त ख़र्च नहीं लेती, क्योंकि तुलना उसी call का हिस्सा है।

परत 2: आपकी normalised तुलना। जो साफ़ मिलान नहीं है, उसके लिए जवाब के registeredName को ग्राहक के इनपुट से ऐसे नियमों से मिलाइए जो आपके हाथ में हैं: अक्षर बड़े करना, विराम चिह्न और उपाधियाँ हटाना, इनिशियल फैलाना या समेटना, शब्द क्रमबद्ध करना, आम संक्षेप सँभालना। यह परत कहे कि दोनों समतुल्य हैं तो flag के साथ स्वीकार कीजिए। कहे कि साफ़ अलग हैं तो जोखिम-स्तर के हिसाब से समीक्षा में भेजिए या ख़ारिज कीजिए। अनिश्चित हो तो परत 3।

परत 3: कोई इंसान। समीक्षक टाइप किया नाम, पंजीकृत नाम, दोनों स्कोर और, अगर आपने लिया हो, दस्तावेज़ की फ़ोटो देखता है और फ़ैसला करता है। फ़ैसलों की सूची छोटी रखिए (मंज़ूर, अस्वीकार, दूसरा दस्तावेज़ माँगें) और दर्ज कीजिए कि किसने और क्यों तय किया। समीक्षा की कतार स्वचालन की हार नहीं है। यह वह कतार है जो नियम को अच्छे ग्राहकों को ठुकराने से रोकती है।

परतों का मक़सद हर ग़लती को सस्ता बनाना है। परत 1 की झूठी अस्वीकृति को परत 2 में दूसरा मौक़ा मिलता है। परत 2 की झूठी स्वीकृति जोखिम-स्तर और उन अगली जाँचों (bank account मिलान, दस्तावेज़ समीक्षा) से सीमित होती है जो आप ज़्यादा जोखिम वाले मामलों के लिए चलाते हैं।

normalise करने वाली तुलना, कोड में

परत 2 का छोटा Python संस्करण। यह सबसे अच्छा होने का दावा नहीं करता। यह ढाँचा दिखाता है, ताकि आप अपने ग्राहकों के लिए ज़रूरी हिस्से कस सकें।

import re

HONORIFICS = {"MR", "MRS", "MS", "MISS", "SHRI", "SMT", "KUM", "DR", "PROF", "LATE", "SRI", "SHREE"}
ABBREV = {"MOHD": "MOHAMMED", "MD": "MOHAMMED", "MOHAMMAD": "MOHAMMED", "MOHAMED": "MOHAMMED"}

def tokens(name):
    s = re.sub(r"[.'`-]", " ", (name or "").upper())
    s = re.sub(r"[^A-Z0-9 ]", " ", s)
    return [ABBREV.get(t, t) for t in s.split() if t not in HONORIFICS]

def compatible(a, b):
    short, long_ = (a, b) if len(a) <= len(b) else (b, a)
    pool = list(long_)
    for t in short:
        idx = pool.index(t) if t in pool else -1
        if idx == -1 and len(t) == 1:
            idx = next((i for i, p in enumerate(pool) if p.startswith(t)), -1)
        if idx == -1 and len(t) > 1:
            idx = next((i for i, p in enumerate(pool) if len(p) == 1 and t.startswith(p)), -1)
        if idx == -1:
            return False
        pool.pop(idx)
    return True

def compare_names(typed, on_record):
    a, b = tokens(typed), tokens(on_record)
    if not a or not b:
        return "UNKNOWN"
    if a == b:
        return "EXACT"
    if sorted(a) == sorted(b):
        return "REORDERED"
    if compatible(a, b):
        return "COMPATIBLE"
    if "".join(a) == "".join(b):
        return "SPACING"
    return "DIFFERENT"

def decide_pan(res, typed_name, accept_score=90.0):
    ref = res.get("referenceId")
    if not res.get("valid"):
        return {"decision": "FAIL", "reasons": ["NOT_VALID"], "ref": ref}
    reasons = []
    if res.get("panStatus") != "VALID":
        reasons.append("STATUS_" + str(res.get("panStatus") or "EMPTY").upper())
    try:
        score = float(re.sub(r"[^0-9.]", "", str(res.get("nameMatchScore") or "")) or 0)
    except ValueError:
        score = 0.0
    if not (res.get("nameMatchResult") == "MATCH" and score >= accept_score):
        own = compare_names(typed_name, res.get("registeredName"))
        if own in ("EXACT", "REORDERED", "SPACING"):
            reasons.append("NAME_EQUIVALENT_OWN_CHECK")
        elif own == "COMPATIBLE":
            reasons.append("NAME_COMPATIBLE_INITIALS_OR_MIDDLE")
        else:
            reasons.append("NAME_DIFFERENT")
    needs_look = any(r.startswith("STATUS_") or r in ("NAME_DIFFERENT", "NAME_COMPATIBLE_INITIALS_OR_MIDDLE") for r in reasons)
    return {"decision": "REVIEW" if needs_look else "PASS", "reasons": reasons, "ref": ref}

तुलना जान-बूझकर स्कोर की जगह श्रेणी लौटाती है। श्रेणियाँ समीक्षक को समझाई जा सकती हैं: "वही शब्द, अलग क्रम में" वह वाक्य है जो इंसान समझता है, जबकि "0.83" नहीं। और फ़ैसले के function में चुनाव देखिए। इसमें कोई भी चीज़ नाम के फ़र्क़ पर किसी व्यक्ति को अपने-आप ख़ारिज नहीं करती। अलग नाम समीक्षा में जाता है, बंद गली में नहीं। VALID से अलग status समीक्षा में जाता है, क्योंकि reference एक status दर्ज करता है और स्रोत पर बाक़ियों का समूह बड़ा है। सिर्फ़ valid: false सीधे विफल होता है। ज़्यादा जोखिम वाले प्रोडक्ट के लिए इनमें से कुछ भी कस सकते हैं।

वही JavaScript में चाहिए तो ऊपर की तुलना का तर्क लगभग शब्दशः उतरता है, और Node सेवा तथा Python batch job को एक ही जोड़ी पर एक जवाब देना चाहिए। इसके लिए नाम-जोड़ियों की एक साझा परीक्षण फ़ाइल रखिए जिसे दोनों कार्यान्वयन पास करें।

सीमा चुनना और उसे अंशांकित करना

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

1. अपने ट्रैफ़िक से असली PAN verification के नतीजों का नमूना इकट्ठा कीजिए: टाइप किया नाम, registeredName, nameMatchResult, nameMatchScore और आपका अंतिम इंसानी फ़ैसला। जहाँ अभी इंसानी फ़ैसले नहीं हैं, वहाँ एक छोटी समीक्षा-अवधि चलाइए जिसमें हर अपूर्ण मिलान की समीक्षा हो।
2. फ़ैसलों को स्कोर की पट्टी के हिसाब से तालिका में रखिए। आप वह पट्टी खोज रहे हैं जहाँ समीक्षक ज़्यादातर मामले मंज़ूर करने लगते हैं और वह जहाँ ज़्यादातर अस्वीकार करते हैं।
3. दो ग़लतियाँ अलग गिनिए: किसी सीमा पर जिन अच्छे ग्राहकों को आप ठुकरा देते (झूठी अस्वीकृति) और जिन बेमेल या बुरे को स्वीकार कर लेते (झूठी स्वीकृति)।
4. सीमा वहाँ रखिए जहाँ आपके प्रोडक्ट के लिए दोनों ग़लतियों की लागत संतुलित हो, और एक दूसरी, नीची सीमा रखिए जिसके नीचे आप मामले समीक्षा में भेजना बंद करके सीधे विफल कर दें।
5. हर तिमाही इसे दोबारा देखिए, और जब भी कोई नया ग्राहक-वर्ग जोड़ें, क्योंकि नई भौगोलिक जगह या लिपि के नाम अलग व्यवहार करते हैं।

किसी दूसरी टीम की सीमा मत उठाइए। उनके ग्राहक, जोखिम सहने की क्षमता और समीक्षा की क्षमता आपकी नहीं हैं। और जिस नमूने पर नतीजे बताएँ उसी पर सीमा मत कसिए; एक होल्डआउट रखिए।

उदाहरण

यहाँ सारे नाम गढ़े हुए हैं। "आपकी परत 2 क्या कहती है" वाला स्तंभ ऊपर की तुलना से निकला है। API का असली नतीजा इन जोड़ियों पर अलग हो सकता है, क्योंकि reference सिर्फ़ MATCH और "100" का नमूना दिखाता है, और इसीलिए आप अपने डेटा पर अंशांकित करते हैं।

आख़िरी दो पंक्तियाँ परतदार समीक्षा का मक़सद दिखाती हैं। "Suresh Patil" और "Suresh Patel" में एक ही अक्षर का फ़र्क़ है, और वह टाइपो हो सकता है या दो अलग लोग। कोई एल्गोरिदम इसे तय नहीं कर सकता, और उसे कोशिश भी नहीं करनी चाहिए। कार्ड की तस्वीर के साथ कोई इंसान कर सकता है।

कंपनी, फ़र्म और ट्रस्ट: जो नाम इंसानों के नहीं हैं

वही call कंपनी, फ़र्म या ट्रस्ट के PAN को भी verify करती है, और वहाँ नाम की तुलना प्रचलनों के अलग समूह से टकराती है।

संस्थाओं के लिए मिलान के स्कोर से ज़्यादा अहम संस्था का प्रकार है। कंपनी के PAN का चौथा अक्षर C, फ़र्म का F और ट्रस्ट का T होता है। जो नाम मिलता है पर व्यक्ति के PAN का है, उसका मतलब है कि किसी ने कंपनी के लिए प्रोपराइटर का नंबर दे दिया है। संस्था-प्रकार की जाँच पहले चलाइए। कारोबारों का बड़ा प्रवाह KYC बनाम KYB और PAN, GSTIN और CIN में फ़र्क में बताया गया है।

समीक्षा की कतार में केस आए तो ग्राहक से क्या पूछें

समीक्षा की कतार तब सबसे अच्छी चलती है जब ग्राहक को पहला संदेश ख़ास, छोटा और तटस्थ हो। ऐसे शब्द मत लिखिए जो आरोप जैसे सुनाई दें। जो उदाहरण काम करते हैं:

• "आपका भरा नाम इस PAN के नाम से थोड़ा अलग है। कृपया अपना नाम ठीक वैसे लिखिए जैसे PAN कार्ड पर छपा है।"
• "हमारी जाँच में उपनाम आपके लिखे उपनाम से अलग निकला। अगर शादी के बाद या किसी और वजह से नाम बदला है, तो कृपया बदलाव दिखाने वाला दस्तावेज़ अपलोड कीजिए।"
• "आपने सिर्फ़ पहला नाम लिखा है। कृपया PAN कार्ड पर छपा अपना पूरा नाम बताइए।"

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

ग्राहक को टाइपो सुधारने का तरीक़ा दीजिए, बिना नए सिरे से शुरू किए। समीक्षा की कतार के ज़्यादातर बेमेल पहले जवाब में सुलझ जाते हैं, और जो प्रवाह नया आवेदन थमा दे वह लोगों को खो देता है।

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

नाम मिलान क्या साबित नहीं करता

नाम मिलना दिखाता है कि नंबर मौजूद है और ग्राहक के टाइप किए नाम से मिलता है। यह नहीं दिखाता कि टाइप करने वाला धारक है। PAN गुप्त नहीं होते, और कोई भी तस्वीर से नाम पढ़कर टाइप कर सकता है। अगर आपका जोखिम मॉडल स्वामित्व माँगता है, तो ऐसा कदम जोड़िए जो साबित करे कि व्यक्ति के पास दस्तावेज़ या खाता है: इंसान से समीक्षित दस्तावेज़ की तस्वीरें, ऐसी bank account verification जहाँ खाताधारक का नाम भी मिलना चाहिए (penny drop बनाम name match देखिए), या कोई और कारक जिसे आपकी नीति मानती है। StampMitra Aadhaar आधारित verification नहीं देता, इसलिए ऐसा प्रवाह मत बनाइए जो उस पर निर्भर हो।

इसी तरह नाम मिलना व्यक्ति के पते, साख, निवास, या किसी और संदर्भ में वह वही है जो दावा करता है, इस बारे में कुछ नहीं कहता। PAN एक टैक्स पहचान है। उसके दायरे के लिए PAN, GSTIN और CIN में फ़र्क देखिए।

धारक के प्रकार से दूसरी जाँच

जवाब में type है (नमूने में Individual)। PAN का चौथा अक्षर धारक की श्रेणी बताता है, इसलिए आप दोनों को ग्राहक के दावा किए संस्था-प्रकार से मिला सकते हैं। जो व्यक्ति खुद को प्राइवेट कंपनी बताकर ऐसा PAN देता है जिसका चौथा अक्षर P है या जिसका type Individual कहता है, उसने या तो ग़लत PAN दिया है या वह कंपनी नहीं है। इसे स्पष्टीकरण के सवाल में भेजिए। यह मुफ़्त जाँच ऐसी ग़लतियों की एक श्रेणी पकड़ती है जो अकेला नाम-मिलान चूक जाता है: व्यक्ति का PAN, जिसके साथ कंपनी का नाम टाइप किया गया।

पहले status, फिर नाम

नाम की फ़िक्र से पहले PAN की स्थिति पर फ़ैसला कीजिए। valid: false प्रक्रिया ख़त्म कर देता है। valid: true हो तो panStatus, panStatusCode और panStatusDescription देखिए। नमूना VALID, E और Existing and valid PAN दिखाता है। स्रोत के रिकॉर्ड में दूसरी स्थितियाँ हो सकती हैं, और reference उन्हें नहीं गिनाता, इसलिए लिखिए "VALID पास, बाक़ी सब समीक्षा में", कच्चे मान लॉग कीजिए और अपने ट्रैफ़िक में जो दिखे उसके हिसाब से तालिका बढ़ाइए।

lastUpdatedAt रिकॉर्ड से जुड़ी तारीख़ है, जो संदर्भ देती है पर आपकी call का समय नहीं है। ताज़गी कैसे काम करती है, और API का नतीजा पोर्टल पर देखे नतीजे से अलग क्यों हो सकता है, यह API और सरकारी पोर्टल के नतीजों में फ़र्क में पढ़िए।

सहमति, उद्देश्य और भंडारण

PAN और उससे जुड़ा नाम निजी डेटा हैं। इन्हें बताए गए उद्देश्य के लिए इकट्ठा कीजिए, ग्राहक को बताइए कि आप क्या जाँचेंगे और क्यों, सिर्फ़ वही माँगिए जो जाँच को चाहिए, और नतीजे उतने समय रखिए जितना आपकी नीति या कानून माँगे, उससे ज़्यादा नहीं। Digital Personal Data Protection Act, 2023 सामान्य ढाँचा है, और क्षेत्रीय नियम KYC रिकॉर्ड का लंबा रिटेंशन माँग सकते हैं, इसलिए अवधि अपने compliance मालिक से तय कीजिए।

referenceId, फ़ैसला, कारण, स्कोर और समय सहेजिए। registeredName और fatherName सहेजने से पहले दो बार सोचिए: अगर आपका फ़ैसला दर्ज है और referenceId से आप request logs में वह call निकाल सकते हैं, तो शायद आपको अपने डेटाबेस में नाम चाहिए ही नहीं। logs में PAN को पहले दो और आख़िरी दो अक्षरों तक मास्क कीजिए। इन चुनावों पर verification कॉल से क्या लॉग करें में बात है।

मिलान की नीति को परखना

sandbox plumbing में मदद करता है, मिलान में नहीं। SNDBX0000A बनावटी नाम TEST USER के साथ वैध PAN लौटाता है, और SNDBX9999F not valid। बाक़ी हर इनपुट का नतीजा स्थिर पर मनमाना है। sandbox की call आपके नाम को किसी असली रिकॉर्ड से कभी नहीं मिलाती, इसलिए वहाँ दिखा स्कोर इस बारे में कुछ नहीं बताता कि तुलना "R Kumar" को "RAHUL KUMAR" से कैसे बरतती है।

परीक्षण को उसी हिसाब से बाँटिए।

• नीति के लिए fixtures। अलग-अलग nameMatchResult और nameMatchScore वाले जवाब रिकॉर्ड कीजिए या हाथ से लिखिए और decide_pan को दीजिए। परखिए कि अनजाने लेबल समीक्षा में जाते हैं, कि string स्कोर parse होता है, और कि valid: false विफल होता है।
• compare_names के unit tests। जोड़ियों और अपेक्षित श्रेणियों की तालिका, जो आपके Node और Python कोड में साझा हो।
• HTTP रास्ते के लिए sandbox। जादुई वैल्यू, ग़लत PAN (400), ग़लत key (401), scope की कमी (403)।
• production smoke test। अपने PAN और नाम से कुछ calls, और अपने नाम के कुछ रूप जिन्हें परखने का आपको हक़ है, ताकि असली स्कोर दिखें। नतीजों को निजी डेटा की तरह सँभालिए।

go-live के बाक़ी रास्ते के लिए sandbox बनाम production: क्या टेस्ट हो सकता है देखिए।

समय के साथ मिलान की गुणवत्ता पर नज़र

मिलान की नीति launch पर ख़त्म नहीं होती। ग्राहकों का मिश्रण बदलता है, नए क्षेत्र आते हैं, फ़ॉर्म में बदलाव से आपको मिलने वाली स्ट्रिंग बदल जाती हैं, और प्लेटफ़ॉर्म की अपनी तुलना भी बदल सकती है। मुट्ठी भर संख्याएँ बताती हैं कि नीति पर कब ध्यान चाहिए।

कारणों को कोड में दर्ज कीजिए (ऊपर का फ़ैसले का function यही करता है) ताकि ये संख्याएँ एक query हों, कोई शोध-परियोजना नहीं। शुरू में हर महीने देखिए और स्थिर होने पर हर तिमाही।

एरर, retry और लागत

ग़लत बनावट वाला PAN तुरंत 400 (pan must match the format ABCDE1234F) के साथ विफल होता है और उसका कोई ख़र्च नहीं। ग़लत key 401 है, scope की कमी 403, ख़ाली wallet 402, rate limit 429 और पहुँच से बाहर upstream 502। सिर्फ़ 429 और 502 पर, बेतरतीब backoff और सीमा के साथ, retry कीजिए। valid: false पूरी हुई lookup है जो production में बिल होती है। pay-as-you-go पर PAN की एक call ₹5 है और प्लान में कम; pricing पेज देखिए। चूँकि नाम की तुलना उसी call का हिस्सा है, name शामिल करने का कोई अतिरिक्त शुल्क नहीं, इसीलिए जब भी आपके पास नाम हो उसे भेजिए। हर status सँभालने का ब्योरा एरर, retry और idempotency में है।

आम ग़लतियाँ

• भेजने से पहले नाम की सफ़ाई कर देना, जिससे अच्छा मिलान ख़राब हो जाता है।
• nameMatchScore की string की तरह तुलना करना।
• एक नमूने से nameMatchResult के मानों की सूची कोड में बैठा देना।
• नाम के फ़र्क़ पर बिना समीक्षा की कतार के अपने-आप ख़ारिज कर देना।
• किसी ब्लॉग या दूसरी टीम से सीमा उठा लेना।
• ग्राहक को कच्चा स्कोर दिखाना।
• नाम मिलान को इस बात का सबूत मान लेना कि व्यक्ति PAN का मालिक है।
• type को दावा किए संस्था-प्रकार से मिलाना भूल जाना।
• यह मान लेना कि sandbox का स्कोर असली नामों के बारे में कुछ बताता है।
• पूरा PAN और नाम एक साथ लॉग कर देना।

आगे क्या करें

key नहीं है तो quickstart में पाँच मिनट लगते हैं। PAN endpoint reference और PAN प्रोडक्ट पेज पढ़िए, फिर ऊपर का परतदार फ़ैसला बनाइए। वेंडर या कर्ज़दार पर जाँचों के क्रम के लिए वेंडर ऑनबोर्डिंग फ़्लो पढ़िए। प्राप्तकर्ता के बैंक खाते के लिए penny drop बनाम name match पढ़िए। सवाल 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"
}

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