Verification API के नतीजे सरकारी पोर्टल से अलग क्यों दिखते हैं

मुख्य बातें

• API के नतीजे और पोर्टल के पेज में फ़र्क़ आम तौर पर समय, दायरे, मिलान के नियमों या इनपुट के फ़र्क़ से होता है, किसी का दोष नहीं।
• StampMitra का reference जवाब के फ़ील्ड और हर call का referenceId दर्ज करता है। वह हर नीचे के स्रोत के ताज़ा होने का समय-क्रम या यह नहीं बताता कि जवाब cache से आया या नहीं। मान लेने की जगह अपने प्रोडक्ट के बारे में support से ख़ास जानकारी पूछिए।
• हर API नतीजा किसी एक क्षण का जवाब है। उसे ज़्यादा से ज़्यादा call के क्षण का सच मानिए, और कम से कम स्रोत की आख़िरी ताज़गी का।
• PAN के जवाब में lastUpdatedAt है, जो रिकॉर्ड से जुड़ी तारीख़ है। वह संदर्भ है, आपकी call का समय बताने वाला बयान नहीं।
• पोर्टल और API अलग फ़ील्ड दिखाते हैं। पोर्टल रद्द होने की तारीख़ या रिटर्न की स्थिति दिखा सकता है जो API के जवाब में नहीं है।
• नाम की तुलना के नियम अलग हैं। इंसान दो नाम पढ़कर एक व्यक्ति देखता है। स्कोर वाला function एक संख्या देखता है।
• जाँच शुरू करने से पहले उबाऊ कारण हटाइए: टाइपो, अलग पहचान, पोर्टल का अलग पेज, बड़े बनाम मिले-जुले अक्षर।
• referenceId, एरर हुई हो तो requestId, सटीक इनपुट, call का समय और पूरा जवाब सहेजिए। इनके बिना कोई मदद नहीं कर सकता।
• अपना सिस्टम ऐसे बनाइए कि हर फ़ैसला बताए कि उसका डेटा कितना ताज़ा होना चाहिए, और बड़े असर वाले क़दम से पहले दोबारा जाँचिए।
• Sandbox सैंपल डेटा लौटाता है और आपको इस तरह का फ़र्क़ कभी नहीं दिखाएगा। उसे किसी भी दिशा में सबूत मत बनाइए।

"अलग" दिखता कैसे है

हर फ़र्क़ एक-सा नहीं होता, और वजह उसकी क़िस्म पर निर्भर है। पहले अपना वाला छाँटिए।

कारणों के परिवार थोड़े हैं: समय, स्रोत और ताज़गी, cache, दायरा, मिलान के नियम और सीधी इनपुट की ग़लतियाँ। अगला हिस्सा बारी-बारी से इन्हें लेता है।

नतीजे अलग क्यों होते हैं

1. समय बीत गया

सबसे आम कारण सबसे कम दिलचस्प है। रिकॉर्ड बदलते हैं: रजिस्ट्रेशन निलंबित होता है, कंपनी हटाई जाती है, नाम अपडेट होता है। अगर API call और पोर्टल की नज़र अलग क्षणों की थीं, तो वे वैध रूप से अलग स्थितियाँ दिखा सकती हैं। दो सवाल पूछिए: API call कब हुई, और व्यक्ति ने पोर्टल कब देखा? दिनों का, या किसी जानी-पहचानी घटना के आसपास घंटों का अंतर भी सब समझा सकता है।

इसका हल प्रक्रिया का है। हर verification का समय दर्ज कीजिए, जहाँ नतीजा दिखाएँ वहाँ वह समय दिखाइए, और पुराने नतीजे पर कदम उठाने से पहले दोबारा जाँचिए। "12 अक्टूबर को verify हुआ" और "सक्रिय है" दो अलग बयान हैं।

2. स्रोत एक जैसे नहीं हैं, और हर एक अपनी समय-सारणी पर ताज़ा होता है

verification API आपके सिस्टम और नीचे के डेटा स्रोतों के बीच बैठती है। पोर्टल किसी व्यक्ति और प्राधिकरण के अपने सिस्टम के बीच बैठता है। प्राधिकरण एक होने पर भी API जो डेटा पढ़ती है और पोर्टल का पेज जो दिखाता है, अलग रास्तों से और अलग ताज़ा होने के चक्रों से आ सकते हैं। एक जगह दर्ज बदलाव दूसरी जगह दिखने में समय ले सकता है।

जो दर्ज है: StampMitra का reference हर endpoint का अनुरोध और जवाब बताता है और नोट करता है कि verification आपकी call के समय होता है। जो दर्ज नहीं: हर स्रोत कितनी बार ताज़ा होता है, या प्राधिकरण के रिकॉर्ड तक सटीक रास्ता क्या है। किसी ख़ास प्रोडक्ट के लिए support से पूछिए कि स्रोत क्या है और वह कितना ताज़ा है, और उत्तर अपने जोखिम दस्तावेज़ में लिख लीजिए।

3. रास्ते में कहीं cache है

Caching एक सामान्य, समझदारी भरा इंजीनियरिंग अभ्यास है जो सिस्टम को तेज़ करता है और नीचे की सेवाओं को बचाता है। वह डेटा स्रोत पर, API पर, proxy में, आपके अपने ऐप्लिकेशन में और ब्राउज़र में हो सकता है। असर हमेशा वही: आप हाल की प्रति देखते हैं, जीवित रिकॉर्ड नहीं।

यह ईमानदारी से मानना ज़रूरी है कि आप क्या जान सकते हैं और क्या नहीं। एक जवाब देखकर आप नहीं बता सकते कि वह cache से आया या नहीं। StampMitra का reference verification endpoint के लिए cache के बरताव या ताज़गी के headers को दर्ज नहीं करता। आपके फ़ैसले को ताज़गी की गारंटी चाहिए तो support से पूछिए कि उस प्रोडक्ट के लिए क्या गारंटी है, और अपना caching ऐसे डिज़ाइन कीजिए (नीचे देखिए) कि आप वह परत न बनें जो डेटा को आपकी नीति की इजाज़त से पुराना कर दे।

4. API पोर्टल से कम फ़ील्ड दिखाती है

पोर्टल लोगों के लिए बने हैं और भरा-पूरा पेज दिखाते हैं। API तय, संकरा समूह लौटाती है। GSTIN के लिए StampMitra का जवाब पंजीकरण-रिकॉर्ड देता है (valid, कानूनी और trade नाम, gstinStatus, taxpayerType, dateOfRegistration, अधिकार-क्षेत्र और पते), जबकि पोर्टल का करदाता पेज और दिखा सकता है, जैसे जहाँ हो वहाँ रद्द होने की तारीख़ या रिटर्न की स्थिति। पोर्टल पर ऐसा फ़ील्ड दिखना जो API नहीं लौटाती, दायरे का फ़र्क़ है, विसंगति नहीं।

5. नाम की तुलना के नियम अलग हैं

जो समीक्षक "R Kumar" और "RAHUL KUMAR" देखता है, वह मान लेता है कि वे एक ही व्यक्ति हैं। स्कोर वाला function 100 से कम संख्या लौटाता है। जो समीक्षक "Ram Kumar" और "RAMKUMAR" देखता है, वह स्कोर से सहमत हो भी सकता है और नहीं भी। जब भी असहमति नाम के मिलान पर हो, पूछिए कि हर तरफ़ ने क्या तुलना की और किस नियम से। PAN और bank account endpoint nameMatchScore और nameMatchResult लौटाते हैं, और उनका मिलान-तर्क प्रकाशित नहीं है। अपनी तुलना की परत उनके ऊपर कैसे लगाएँ, इसके लिए PAN को verify करके नाम कैसे मिलाएँ देखिए।

6. इनपुट एक जैसा नहीं था

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

7. पोर्टल का पेज अलग था

प्राधिकरण एक से ज़्यादा lookup चलाते हैं। नंबर वैध है या नहीं जाँचने वाला पेज, करदाता का पूरा ब्योरा देने वाला पेज, और रिटर्न की जानकारी दिखाने वाला पेज, हर एक थोड़े अलग डेटा से पोषित हो सकता है। पक्का कीजिए कि जिसने "पोर्टल देखा" उसने बराबर का function इस्तेमाल किया। URL और समय सहित स्क्रीनशॉट माँगिए।

8. शब्दों के मतलब अलग हैं

API के जवाब में "valid" का मतलब है कि पहचान से मेल खाता रिकॉर्ड मिला। पोर्टल "valid" कह सकता है और साथ में inactive जैसी स्थिति दिखा सकता है। पोर्टल पर status का लेबल API के registrationStatus या panStatus से अलग शब्दों में हो सकता है। सिर्फ़ वर्तनी नहीं, मतलब की तुलना कीजिए, और जब बता न पाएँ कि दो लेबल बराबर हैं या नहीं, मामले को समीक्षा में भेजिए।

9. ग्राहक कुछ और देख रहा है

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

StampMitra क्या दर्ज करता है और क्या नहीं

किनारों के बारे में साफ़ रहना ग्राहकों और ऑडिटरों से बातचीत को ईमानदार रखता है।

जब कोई सवाल दाएँ कॉलम में पड़े, तो support से पूछिए और लिखित उत्तर को दस्तावेज़ मानिए। अपनी नीति में अनुमान से ख़ाली जगह मत भरिए।

तीन परिदृश्य, निदान के साथ

नियम तब ज़्यादा भरोसेमंद लगते हैं जब आप उन्हें लागू होते देख चुके हों। ये मामले गढ़े हुए कारोबारों और ऊपर के जाँच-चरणों पर हैं।

परिदृश्य एक: "Active" बनाम "Cancelled"। एक वेंडर के लिए विश्लेषक GST पोर्टल खोलता है और रद्द रजिस्ट्रेशन देखता है। ऑनबोर्डिंग सिस्टम छह हफ़्ते पहले चली जाँच से registrationStatus: Active दिखाता है। पहला क़दम किसी और चीज़ से पहले जवाब दे देता है: API का नतीजा छह हफ़्ते पुराना है और पोर्टल का दृश्य आज का। कुछ ग़लत नहीं है। नीति की चूक यह है कि सिस्टम ने तारीख़ के बिना "Active" दिखाया और भुगतान चक्र से पहले दोबारा नहीं जाँचा। हल है ताज़गी की चौकसी और दिखती "verified on" तारीख़। आज दोबारा चलाने पर नया referenceId मिलता है; पुराना और नया रिकॉर्ड मिलकर बताते हैं कि status कब बदला।

परिदृश्य दो: ऐसा नाम जो मिलता नहीं दिखता। एक ऋणदाता का समीक्षक PAN के लिए लौटे पंजीकृत नाम की तुलना उधारकर्ता के करार के नाम से करता है। API ने आंशिक मिलान लौटाया। समीक्षक करार पर "Rahul Suresh Kumar" और जवाब में "RAHUL KUMAR" देखकर दोनों को एक व्यक्ति मानता है। यहाँ कोई डेटा की समस्या नहीं। दोनों दृश्यों ने तुलना के अलग नियम लगाए, और सिस्टम की सीमा ने केस को अपने-आप स्वीकार करने की जगह समीक्षा में डाला। यह समीक्षा की कतार का अपना काम है। हल, अगर कोई हो, तो ऐसे ही फ़ैसलों से सीमा अंशांकित करना है, जैसा PAN नाम वाली गाइड में बताया गया है।

परिदृश्य तीन: वह फ़ील्ड जो पोर्टल दिखाता है और API नहीं। एक compliance अधिकारी जानना चाहता है कि वेंडर का रजिस्ट्रेशन किसी ख़ास योजना में है या नहीं, उसे पोर्टल पर दिखता है और वह पूछता है कि API का जवाब यह क्यों नहीं बताता। API का GSTIN जवाब जान-बूझकर संकरा है और वह फ़ील्ड नहीं रखता। यह दायरा है, विसंगति नहीं। अधिकारी के पास दो विकल्प हैं: पोर्टल का अवलोकन स्क्रीनशॉट और समय के साथ हाथ की जाँच की तरह दर्ज करे, या वेंडर से रजिस्ट्रेशन प्रमाणपत्र माँगे। दोनों केस की फ़ाइल में रखने लायक़ हैं। असली ग़लती होती ऐसे फ़ील्ड पर नीति टिकाना जो API नहीं लौटाती, और आवश्यकता दस्तावेज़ में उसका वादा करना।

तीनों में से किसी को सुलझाने के लिए support की ज़रूरत नहीं पड़ी। चौथी क़िस्म, यानी मेल खाते इनपुट, उसी मिनट के अवलोकन और बराबर दायरे के साथ चरण एक से छह के बाद भी बचा दोहराया जा सकने वाला फ़र्क़, वही है जिसे ऊपर भेजना चाहिए।

क़दम-दर-क़दम फ़र्क़ की जाँच

इन्हें क्रम से कीजिए। ज़्यादातर मामले चौथे क़दम तक सुलझ जाते हैं।

1. दोनों अवलोकन समय के साथ लिख लीजिए। API का नतीजा (उसके referenceId और call के समय सहित) और पोर्टल का अवलोकन (स्क्रीनशॉट, URL और समय सहित)।
2. सटीक इनपुट की तुलना कीजिए। जो स्ट्रिंग आपने भेजी उसकी पोर्टल में टाइप की स्ट्रिंग से। दोनों से खाली जगहें हटाइए और अक्षर बड़े कीजिए।
3. पक्का कीजिए कि बराबर की चीज़ें मिला रहे हैं। वही पहचान, उसी तरह का lookup, वही रजिस्ट्रेशन (GSTIN के लिए: वही राज्य)।
4. समय का अंतराल देखिए। अगर वह आपकी नीति की सहनशीलता से ज़्यादा है, या बीच में कोई जाना-पहचाना बदलाव हुआ था, तो API call दोबारा चलाकर फिर देखिए। नई call का नया referenceId होता है, इसलिए दोनों रखिए।
5. दायरा जाँचिए। पोर्टल जो फ़ील्ड दिखाता है, क्या वह API के जवाब का हिस्सा है भी? नहीं, तो फ़र्क़ दायरे का है।
6. मिलान जाँचिए। झगड़ा नाम पर हो तो स्ट्रिंग की तुलना अपने normalised नियमों से कीजिए।
7. अब जाकर डेटा की समस्या पर शक कीजिए। अगर चरण एक से छह के बाद असली, दोहराया जा सकने वाला फ़र्क़ बचे, तो नीचे का सबूत जमा कीजिए और support से पूछिए।

क्या सहेजें

from datetime import datetime, timezone

def dispute_bundle(input_, response=None, error=None, portal_note=""):
    response = response or {}
    error = error or {}
    return {
        "captured_at": datetime.now(timezone.utc).isoformat(),
        "endpoint": "POST /v1/verify/gstin",
        "input": input_,                           # जो भेजा, खाली जगह हटाकर और बड़े अक्षरों में
        "reference_id": response.get("referenceId"),
        "request_id": error.get("requestId"),      # विफलता पर एरर envelope में आता है
        "status": response.get("registrationStatus"),
        "valid": response.get("valid"),
        "last_updated_at": response.get("lastUpdatedAt"),  # सिर्फ़ PAN के जवाब में
        "portal_note": portal_note,                # व्यक्ति ने क्या देखा, कहाँ और कब
    }

ऐसा bundle ही वह सब है जो support को किसी ख़ास call को देखने के लिए चाहिए। API key कभी शामिल मत कीजिए।

जवाब की तारीख़ें कैसे पढ़ें

ताज़गी के सवाल तारीख़ों के आसपास जमा होते हैं, इसलिए सटीक रहिए।

PAN के जवाब में lastUpdatedAt है, जो दर्ज नमूने में 2023-04-01 है। यह रिकॉर्ड से जुड़ी एक तारीख़ है। यह आपकी call का समय या स्रोत की आख़िरी ताज़गी का समय दर्ज नहीं है। इसे संदर्भ की तरह इस्तेमाल कीजिए, जैसे यह देखने के लिए कि जिस status पर आप भरोसा करने वाले हैं उसके साथ बहुत पुरानी तारीख़ है, और इसे ताज़गी की गारंटी मत मानिए।

call का अपना एक समय है, जो आप जानते हैं क्योंकि आपने की थी। आपका "verified at" का अपना रिकॉर्ड वह अकेली तारीख़ है जो पूरी तरह आपके नियंत्रण में है। इसे referenceId के साथ सहेजिए, और जहाँ नतीजा दिखे वहाँ दिखाइए।

GSTIN, CIN और bank account के जवाबों में दर्ज बनावट में अलग से last-updated का फ़ील्ड नहीं है। CIN के जवाब में incorporationDate है, जो कंपनी के बारे में तथ्य है, डेटा के बारे में नहीं। उसे ताज़गी के संकेतक से मत उलझाइए।

ताज़गी के लिए डिज़ाइन

"क्या डेटा ताज़ा है?" पूछने की जगह पूछिए "इस फ़ैसले के लिए कितना ताज़ा होना चाहिए?" अलग फ़ैसलों की ज़रूरतें अलग हैं।

आख़िरी पंक्ति पर ज़ोर चाहिए। जब आपसे पूछा जाए कि आपने कैसे तय किया, तब verification दोबारा चलाने से आपको आज का जवाब मिलता है, वह नहीं जिस पर आपने भरोसा किया था। मूल रिकॉर्ड रखिए।

कोड में ताज़गी की चौकसी

एक छोटा function तालिका को बरताव में बदल देता है। वह ऐसे फ़ैसले के लिए पुराने verification का उपयोग करने से मना करता है जिसे ताज़ा चाहिए।

const MAX_AGE_MS = {
  DISPLAY: 90 * 24 * 3600e3,
  ONBOARD: 1 * 3600e3,
  PAYMENT: 24 * 3600e3,
  INVOICE: 24 * 3600e3,
};

export function usable(verification, purpose, now = Date.now()) {
  return now - Date.parse(verification.checkedAt) <= MAX_AGE_MS[purpose];
}

export async function requireFresh(verification, purpose, reverify) {
  if (verification && usable(verification, purpose)) return verification;
  return reverify(); // नई बिल होने वाली call, नए referenceId के साथ
}

तालिका की अवधियाँ तरीक़ा दिखाने के उदाहरण हैं, सिफ़ारिशें नहीं। अपनी अवधियाँ अपनी जोखिम-सहनशीलता और लागत से तय कीजिए। असली बात यह है कि अंक एक जगह लिखा हो और उस पर बहस हो सके।

अपनी तरफ़ का caching

आपको calls बचाने और स्क्रीन तेज़ करने के लिए verification नतीजे cache करने का मन होगा। सँभलकर किया जाए तो ठीक है। लापरवाही से किया जाए तो वही फ़र्क़ पैदा करता है जिस पर यह गाइड है।

कुछ भी cache न करें तो हर call का भुगतान करते हैं और सरलता पाते हैं। cache करें तो पुरानेपन की ज़िम्मेदारी भी लेते हैं। जान-बूझकर हो तो दोनों बचाव-योग्य हैं।

रिकॉर्ड के लिए एक कच्ची call

जाँच करते समय call को साफ़ इनपुट के साथ हाथ से दोहराना मदद करता है, ताकि आपके ऐप्लिकेशन कोड का कुछ भी तस्वीर को धुँधला न करे।

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

-i flag जवाब की बॉडी के साथ status पंक्ति और headers भी छापता है, जो तब काम का है जब आप support को ठीक वही दिखाना चाहें जो लौटा। जो भी चिपकाएँ उसमें से key हटा दीजिए। याद रखिए कि sandbox key सैंपल डेटा लौटाती है, इसलिए sk_test_ से बनाया पुनरुत्पादन किसी असली रिकॉर्ड के बारे में कुछ साबित नहीं करता; production key और ऐसी पहचान इस्तेमाल कीजिए जिसे जाँचने का आपको हक़ है।

आपके अपने यूज़रों को क्या बताएँ

आप verification कैसे दिखाते हैं, इससे तय होता है कि ये फ़र्क़ कितनी परेशानी बनेंगे। कुछ शब्द और डिज़ाइन के चुनाव उन्हें कम करते हैं।

कब, यह दिखाइए। हर verified बैज के पास तारीख़ दिखाइए, और ब्योरे वाले दृश्य में समय भी। "12 अक्टूबर को verify हुआ" सही सवाल न्योतता है ("क्या तब से बदला?")। अकेला हरा निशान ग़लत विश्वास न्योतता है ("verify हो गया, हमेशा के लिए")।

बताइए कि क्या जाँचा। "12 अक्टूबर को GST रजिस्ट्रेशन सक्रिय" "GST verified" से ज़्यादा ईमानदार लेबल है। पहला किसी समय का तथ्य बताता है। दूसरा स्थायी गुण का इशारा करता है।

दोबारा जाँचने का बटन दीजिए। जहाँ यूज़र का हक़ बनता हो, वहाँ ऐसा बटन दीजिए जो दोबारा verify करे और नया समय दिखाए। उसे दर पर सीमित रखिए, क्योंकि हर दबाव एक बिल होने वाली call है।

यह वादा मत कीजिए कि पोर्टल और API मिलेंगे। अगर आपके सहायता पेज कहते हैं कि आपका नतीजा "सरकारी रिकॉर्ड से मेल खाता है", तो आपने हर ताज़गी-अंतराल की ज़िम्मेदारी ले ली। ज़्यादा सच वाक्य: "हम आपके जमा करते समय आधिकारिक रिकॉर्ड जाँचते हैं, और तारीख़ दिखाते हैं। बाद में रिकॉर्ड बदल सकते हैं।"

सबूत जमा करने का रास्ता रखिए। जिस यूज़र के पास प्रमाणपत्र या स्क्रीनशॉट है, वह उसे केस से जोड़ सके, ताकि कोई इंसान असहमति सुलझा सके। ज़्यादातर असहमतियाँ दस्तावेज़ से सुलझती हैं, बहस से नहीं।

अपनी नीति और जोखिम रजिस्टर में क्या लिखें

ऑडिटर और पार्टनर बैंक पूरे-पूरे डेटा की उम्मीद नहीं करते। वे उम्मीद करते हैं कि आप डेटा की सीमाएँ जानते हैं और उन्हें सँभाल चुके हैं। आपकी नीति में तीन अनुच्छेद ज़्यादातर को कवर करते हैं।

पहला, उन डेटा स्रोतों का बयान जिन पर आप भरोसा करते हैं, ऐसे शब्दों में जिनका आप समर्थन कर सकें: "हम पहचानें StampMitra की verification API से verify करते हैं, जो call के समय नीचे के स्रोत में दर्ज रिकॉर्ड लौटाती है। हम जवाब पर भरोसा करते हैं, उसका संदर्भ सहेजते हैं, और नीचे की समय-सारणी से दोबारा verify करते हैं।" अगर StampMitra support ने किसी स्रोत की ताज़गी के बारे में ख़ास बातें दी हैं, तो उन्हें मिलने की तारीख़ के साथ उद्धृत कीजिए।

दूसरा, इस गाइड की ताज़गी की तालिका अपने अंकों और उन्हें मंज़ूर करने वाले मालिक के साथ।

तीसरा, विवाद की प्रक्रिया: असहमति किसे मिलती है, कौन-सा सबूत जमा होता है, फ़र्क़ support तक कैसे पहुँचता है और कैसे दर्ज होता है। कोई इंसान नतीजा पलटे तो दर्ज कीजिए कि किसने और क्यों। मूल जवाब को जस का तस रखिए।

जोखिम रजिस्टर की एक प्रविष्टि ऐसी पढ़ी जा सकती है: "Verification के नतीजे आधिकारिक रिकॉर्ड से पीछे रह सकते हैं। निवारण: फ़ैसले के प्रकार के हिसाब से ताज़गी की सीमाएँ; भुगतान से पहले दोबारा जाँच; तारीख़ के साथ दिखाना; विवादित मामलों के लिए समीक्षक की कतार; नीति के अनुसार सबूत का रिटेंशन।" यह ऐसा जोखिम है जिसे आपने नाम दिया और सीमित किया, और समीक्षक यही देखना चाहता है।

किसी ग्राहक से बात, जो कहे कि पोर्टल अलग दिखाता है

आपकी support टीम को यह बातचीत हर हफ़्ते मिलेगी। एक स्क्रिप्ट उसे शांत और काम की रखती है।

• उन्हें धन्यवाद दीजिए और वह पहचान तथा स्क्रीनशॉट माँगिए जो पेज और समय दिखाए।
• उसी पहचान से verification खुद चलाइए और समय नोट कीजिए।
• अगर आपका नतीजा और उनका स्क्रीनशॉट अलग हों, तो समझाइए कि दोनों दृश्य कुछ घंटों या दिनों के फ़र्क़ पर हो सकते हैं, और आप दोबारा जाँच रहे हैं।
• फ़र्क़ बना रहे तो ऐसा दस्तावेज़ माँगिए जो मामला निपटाए: रजिस्ट्रेशन प्रमाणपत्र, कंपनी का master record, PAN कार्ड की तस्वीर, जैसा आपकी नीति इजाज़त दे।
• उन्हें यह मत बताइए कि कौन-सा स्रोत "सही" है जब तक पक्का न हों। बताइए कि हर एक क्या दिखाता है और आपको क्या चाहिए।
• हर चीज़ केस से जुड़ी रखिए: स्क्रीनशॉट, referenceId, समय।

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

support को भेजना

जब आपकी अपनी जाँच दोहराए जा सकने वाले फ़र्क़ पर ख़त्म हो, तब support को ऐसा संदेश भेजिए जिस पर वे सवालों के दूसरे दौर के बिना काम कर सकें।

1. Endpoint और सटीक इनपुट (जहाँ उचित हो वहाँ छिपाकर)।
2. call का referenceId और उसका समय।
3. call विफल हुई हो तो requestId।
4. जवाब ने क्या कहा, आपके सहेजे रिकॉर्ड से उतारकर।
5. पोर्टल ने क्या दिखाया, स्क्रीनशॉट, URL और समय के साथ।
6. आपने क्या ख़ारिज किया (टाइपो, अलग पेज, दायरे का फ़र्क़)।
7. आपको क्या चाहिए: व्याख्या, उनकी तरफ़ से दोबारा जाँच, या उस प्रोडक्ट के लिए स्रोत की ताज़गी पर बयान।

[email protected] पर या support पेज से भेजिए। इन सात बातों वाला संदेश "डेटा ग़लत है" जैसे सामान्य संदेश से कहीं जल्दी ख़ास जवाब पाता है।

पोर्टल कब सही औज़ार है और कब नहीं

पोर्टल प्राधिकरण का अपना इंटरफ़ेस हैं और किसी एक रिकॉर्ड की पुष्टि करने वाले व्यक्ति, ग्राहक से विवाद निपटाने, या ऐसा फ़ील्ड देखने के लिए सही औज़ार हैं जो API नहीं लौटाती। सिस्टम के पुर्ज़े की तरह उनकी सीमाएँ हैं। वे इंसानी इस्तेमाल के लिए बने हैं, आम तौर पर captcha और सत्र-प्रबंधन के साथ, वे आपको स्थिर मशीन-पठनीय अनुबंध नहीं देते, उनमें आपके अपने लेन-देन से जुड़ा ऑडिट निशान नहीं होता, और उन्हें स्वचालित करना उनकी शर्तें तोड़ सकता है। API आपको प्रोग्राम वाला इंटरफ़ेस, हर call का referenceId और ऐसा रिकॉर्ड देती है जिसे आप सहेज सकें।

व्यावहारिक तरीक़ा दोनों को उसी काम के लिए इस्तेमाल करना है जिसमें वे अच्छे हैं: बड़े पैमाने पर स्वचालित, ऑडिट-योग्य फ़ैसलों के लिए API, और विवादित मामले में इंसानी पुष्टि के लिए पोर्टल। जब वे असहमत हों, तो प्राधिकरण के अपने रिकॉर्ड को वह चीज़ मानिए जिसे आप अंततः प्रतिबिंबित करना चाहते हैं, और दोनों दृश्यों को तस्वीरें।

sandbox आपको यह क्यों नहीं दिखा सकता

Sandbox हर इनपुट के लिए सैंपल डेटा लौटाता है: स्थिर, बनावटी, गढ़े नामों के साथ, और जादुई वैल्यू के अलावा इनपुट पर तीन में से लगभग दो बार "valid"। वह किसी असली रिकॉर्ड को नहीं छूता। इस विषय के लिए इसके दो मतलब हैं। sandbox का नतीजा कभी पोर्टल से अलग नहीं होगा क्योंकि उसका कोई असली जोड़ीदार नहीं, इसलिए साफ़ sandbox तुलना बेमानी है। और sandbox में असली पोर्टल पेज से दिखा फ़र्क़ अपेक्षित है, bug नहीं। sandbox बनाम production: क्या टेस्ट हो सकता है गाइड बताती है कि sandbox क्या साबित करता है, इस बात समेत कि जवाब में अनपेक्षित status हो तो आपका कोड कैसे बरतता है।

आम ग़लतियाँ

• इनपुट की सटीक स्ट्रिंग की तुलना किए बिना यह निष्कर्ष निकालना कि API ग़लत है।
• यह निष्कर्ष निकालना कि पोर्टल ही अकेला सच है और API के referenceId रिकॉर्ड को अनदेखा करना।
• "आपने कैसे तय किया" का जवाब देने के लिए verification दोबारा चलाना, जो सबूत की जगह आज का जवाब रख देता है।
• नतीजे सिर्फ़ पहचान से cache करना, ताकि दिखाने लायक़ नतीजा भुगतान में इस्तेमाल हो जाए।
• lastUpdatedAt को call का समय मान लेना।
• यह मान लेना कि API के जवाब में किसी फ़ील्ड का न होना डेटा का न होना है, जबकि वह जवाब के दायरे से बाहर है।
• नामों की तुलना ठीक-ठीक बराबरी से करके "बेमेल" के लिए API को दोष देना।
• किसी असली रिकॉर्ड के बारे में कुछ साबित या ग़लत साबित करने के लिए sandbox इस्तेमाल करना।
• support को पहचान, समय या referenceId के बिना स्क्रीनशॉट भेजना।

आगे क्या करें

शुरुआत अपनी स्क्रीन पर हर verification का समय दिखाने से कीजिए, फिर इस गाइड की ताज़गी की तालिका अपनी नीति में उन अंकों के साथ जोड़िए जिन्हें आपके जोखिम मालिक ने मंज़ूर किया हो। जिन पहचानों के रजिस्ट्रेशन बदलते हैं उनकी बनावट के लिए PAN, GSTIN और CIN में फ़र्क और GSTIN को प्रोग्राम से कैसे verify करें पढ़िए। हर call से क्या सहेजें ताकि बाद का सवाल रिकॉर्ड से सुलझ सके, यह verification कॉल से क्या लॉग करें में है। PAN प्रोडक्ट पेज और GSTIN प्रोडक्ट पेज ताज़गी की देरी से सबसे ज़्यादा प्रभावित दो lookups बताते हैं, API reference हर endpoint के फ़ील्ड बताता है, और pricing पेज दिखाता है कि दोबारा जाँच की क्या क़ीमत है।

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

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