Marketplace के लिए Seller Verification API: विश्वास की सीढ़ी

मुख्य बातें

• विश्वास की सीढ़ी बनाइए: लगभग बिना जाँच के देखना और ड्राफ़्ट listing, PAN जाँच के बाद products प्रकाशित करना, बैंक खाता जाँच के बाद payout पाना, और जिन sellers को ज़रूरत है उनके लिए पंजीकरण जाँचों (GSTIN, CIN या Udyam) के बाद ऊँची सीमाएँ।
• verification को signup से नहीं, पैसे की आवाजाही से जोड़िए। नुक़सान असल में payout वाले कदम पर होता है, इसलिए payout को seller के नाम के सत्यापित खाते से बाँधिए।
• एक PAN के पीछे अलग-अलग राज्यों के कई GSTIN हो सकते हैं। pan-to-gstin उनकी सूची देता है, ताकि seller का चुना पंजीकरण असली और चालू है, यह screenshot माँगे बिना पक्का हो।
• जुड़े खातों को पकड़ने के लिए PAN और खाता संख्या का keyed hash रखिए, ताकि एक ही व्यक्ति के पाँच स्टोर बिना कच्चे पहचान-नंबर सहेजे दिख जाएँ।
• ब्रांड, स्टोर और कानूनी नाम का अंतर सामान्य है। तय कीजिए कि हर जाँच किस नाम से तुलना करती है, और sellers को ऐसे संदेश दीजिए जो ठीक-ठीक बताएँ कि क्या सुधारना है।
• valid: false और found: false पूरी, billable calls हैं। retry सिर्फ़ 429 और 502 पर।
• एक बुरे payout के नुक़सान के सामने प्रति seller लागत छोटी है। तीन मात्राओं का हिसाब प्रकाशित rate card से नीचे दिया है।

marketplace sellers को क्यों जाँचते हैं, सीधे शब्दों में

ज़रूरत चार बार-बार आने वाली समस्याओं में दिखती है।

नक़ली या दोहराए गए sellers। कोई व्यक्ति एक ही ब्योरे के हेर-फेर से बहुत-से खाते खोलता है, ताकि प्रतिबंध से बचे, ratings में हेरा-फेरी करे या सीमाओं से निकल जाए।

payout में धोखा। seller प्रोफ़ाइल के खाते का ब्योरा किसी बड़े payout से ठीक पहले बदल दिया जाता है, या वह खाता कभी seller का था ही नहीं।

कर और invoice के सवाल। marketplace seller के कर-ब्योरे को invoices के लिए सँभालता है, और जिस seller को कर लगाना है उसका अवैध या रद्द पंजीकरण आपकी सपोर्ट और compliance की समस्या बन जाता है। e-commerce operator के सटीक दायित्व, जैसे sellers का पंजीकरण और स्रोत पर कर-संग्रह, आपके कर सलाहकार के विषय हैं। इंजीनियरिंग की बात इतनी है कि फ़ाइल में सही पंजीकरण-डेटा रहना चाहिए।

झूठे दावे। कोई seller ख़ुद को पंजीकृत कंपनी, MSME या अधिकृत डीलर बताता है। कुछ दावे रजिस्ट्री से मिलाए जा सकते हैं और कुछ नहीं। इनका फ़र्क़ पता हो तो आपके badges ईमानदार रहते हैं।

विश्वास की सीढ़ी

तालिका बताती है कि हर पायदान पर seller क्या कर सकता है और बदले में आप क्या माँगते हैं। दाएँ कॉलम की सीमाएँ वे जगह-भराई हैं जिन्हें आपकी risk टीम ट्यून करे।

सीढ़ी दो गुणों से चलती है। स्तर तभी मिलता है जब उसका सबूत पूरा हो, और नया सबूत उलटा पड़े (जैसे GST पंजीकरण बाद में रद्द हो जाए) तो स्तर वापस भी लिया जा सकता है। और लागत सफलता के साथ बढ़ती है: जो sellers स्तर 2 तक नहीं पहुँचते, वे bank-account call कभी चलाते ही नहीं।

अलग-अलग तरह के seller क्या लेकर आते हैं

हर seller के पास एक जैसे पहचानकर्ता नहीं होते, और आपका फ़ॉर्म उसी हिसाब से ढलना चाहिए।

• अपने नाम से बेचने वाला व्यक्ति। व्यक्ति-प्रकार का PAN, निजी खाता। स्तर 3 शायद लागू ही न हो।
• दुकान के नाम वाला एकल प्रोप्राइटर। व्यक्ति का PAN, प्रोप्राइटर के नाम का खाता, और शायद एक GSTIN जिसमें कानूनी नाम प्रोप्राइटर का और व्यापारिक नाम दुकान का हो।
• साझेदारी फ़र्म या LLP। फ़र्म का PAN, फ़र्म के नाम का खाता, पंजीकृत हो तो GSTIN। इस प्लेटफ़ॉर्म पर LLP के लिए CIN lookup नहीं है, इसलिए PAN, GSTIN और बैंक जाँच के साथ दस्तावेज़ों पर टिकिए।
• कंपनी। कंपनी का PAN, CIN, GSTIN, चालू खाता।
• सूक्ष्म या लघु उद्यम। ऊपर में से कोई, और MSME दर्जे का दावा हो तो Udyam संख्या।
• gig या डिलीवरी पार्टनर। driving licence वाला व्यक्ति और, गाड़ी उसकी हो तो, वाहन पंजीकरण। इनके लिए verify/driving-license और verify/rc हैं, जिनकी चर्चा आगे है।

एक स्थिति अक्सर उलझाती है। मान लीजिए कोई seller पहले अपने निजी नाम से बेचता था और अब उसने कंपनी बना ली है। उसका निजी PAN और कंपनी का PAN दो अलग पहचानकर्ता हैं, और बैंक खाता तथा GSTIN भी नए होंगे। इसे पुराने खाते का "अपडेट" मानने के बजाय नई seller-पहचान की तरह onboard कीजिए। पुरानी बिक्री का इतिहास और बकाया payout अलग से तय कीजिए, और समीक्षक को दोनों पहचानें संपर्क (मोबाइल, ईमेल) के आधार पर जुड़ी हुई दिखाइए। इस तरह हर स्तर उसी पहचान को मिलता है जिसका सबूत हमारे पास है, और पुराने स्तर की सीमाएँ नई संस्था पर चुपचाप नहीं चढ़तीं।

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

सीढ़ियों की प्रक्रिया, कदम-दर-कदम

1. संपर्क सत्यापित कीजिए। अपने प्रदाता से मोबाइल नंबर पर OTP भेजिए और ईमेल पक्का कीजिए। फ़ैसला: सत्यापित संपर्क नहीं तो खाता नहीं। यह StampMitra की call नहीं है।
2. कानूनी नाम और PAN एक ही स्क्रीन पर लीजिए। साफ़ लिखिए कि नाम PAN से मेल खाना चाहिए। ढाँचा अपनी तरफ़ जाँचिए: दस अक्षर, अक्षरों की सही जगहें। फ़ैसला: field सुधरवाइए या आगे बढ़िए।
3. PAN जाँचिए (स्तर 1)। POST /v1/verify/pan में pan और name। valid, type, registeredName, nameMatchResult और nameMatchScore पढ़िए। फ़ैसला: मज़बूत मिलान पर आगे बढ़िए, कमज़ोर पर एक बार सही नाम माँगिए, एक बार दोबारा भरवाने के बाद valid: false पर अस्वीकार कीजिए, और seller के बताए प्रकार से उलटे type को समीक्षा में भेजिए।
4. duplicate देखिए। PAN का keyed hash निकालकर अपनी seller तालिका में खोजिए। फ़ैसला: वही hash किसी दूसरे खाते पर मिले तो आगे कुछ भी ख़र्च करने से पहले अपनी duplicate नीति (मिलाना, रोकना या समीक्षा) लगाइए।
5. payout का ब्योरा पहले payout पर लीजिए, signup पर नहीं। खाता संख्या और IFSC तब माँगिए जब seller का पैसा इंतज़ार कर रहा हो, यानी ऐसे क्षण में जब उसे सबसे ज़्यादा प्रेरणा होती है।
6. बैंक खाता जाँचिए (स्तर 2)। POST /v1/verify/bank-account में accountNumber, ifsc और कानूनी नाम। फ़ैसला: वैध खाते और मज़बूत नाम-score पर ही payout खोलिए, बीच के score को समीक्षा में भेजिए, और खाता वैध न हो तो दूसरा खाता माँगिए।
7. जहाँ लागू हो वहाँ GSTIN लीजिए। ढाँचा देखिए और यह भी कि उसके भीतर का PAN सत्यापित PAN के बराबर है। यह मुफ़्त है।
8. पंजीकरण जाँचिए (स्तर 3)। POST /v1/verify/gstin और, कई राज्यों में पंजीकरण वाले sellers के लिए, POST /v1/verify/pan-to-gstin। फ़ैसला: चालू पंजीकरण जिसका PAN मेल खाए तो स्तर 3 दीजिए, वरना स्तर 2 पर रोककर seller को बताइए कि क्या सुधारना है।
9. seller कंपनी या MSME होने की बात कहे तो संस्था जाँचिए। verify/cin, verify/udyam। फ़ैसला: badge सिर्फ़ उसी का जो रजिस्ट्री ने पक्का किया।
10. सबूत और स्तर दर्ज कीजिए। हर जाँच का referenceId, समय, मुख्य response fields, फ़ैसला और नियम का संस्करण seller से जोड़कर रखिए।
11. दोबारा जाँच तय कीजिए। स्तर 3 के sellers का पंजीकरण-स्थिति समय-सारणी पर और घटनाओं के ट्रिगर पर फिर जाँचिए।

नमूना request और response: एक PAN, कई GSTIN

जो sellers एक से ज़्यादा राज्यों में काम करते हैं उनके पास एक ही PAN के नीचे एक से ज़्यादा GSTIN होते हैं। टाइप किए GSTIN पर भरोसा करने की जगह सत्यापित PAN से सूची निकालिए:

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

{
  "referenceId": "SMV-20260927-1L67Z5",
  "found": true,
  "gstins": [
    { "gstin": "07AAAAA1111A1Z1", "state": "Delhi", "status": "Active" }
  ]
}

Node का एक function सूची को फ़ैसले में बदल देता है। seller ने GSTIN चुना हो तो पक्का कीजिए कि वह सूची में है और चालू है, न चुना हो तो सूची दिखाइए।

const BASE = "https://api-b2b.stampmitra.in";

export async function resolveSellerGstin(verifiedPan, chosenGstin) {
  const res = await fetch(`${BASE}/v1/verify/pan-to-gstin`, {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.STAMPMITRA_API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ pan: verifiedPan }),
  });
  if (res.status === 429 || res.status === 502) return { outcome: "retry_later" };
  if (res.status === 402) return { outcome: "ops_alert" };
  const body = await res.json();
  if (!res.ok) return { outcome: "fix_input", requestId: body.error?.requestId };
  if (!body.found || !body.gstins?.length) return { outcome: "no_registration", ref: body.referenceId };

  const active = body.gstins.filter((g) => String(g.status).toLowerCase() === "active");
  if (chosenGstin) {
    const hit = body.gstins.find((g) => g.gstin === chosenGstin);
    if (!hit) return { outcome: "not_linked_to_pan", ref: body.referenceId };
    if (String(hit.status).toLowerCase() !== "active") return { outcome: "inactive", state: hit.state, ref: body.referenceId };
    return { outcome: "confirmed", state: hit.state, ref: body.referenceId };
  }
  return { outcome: "choose", options: active.map((g) => ({ gstin: g.gstin, state: g.state })), ref: body.referenceId };
}

फ़ैसले की तालिका: valid, मेल नहीं, निष्क्रिय, नहीं मिला

जुड़े खाते और duplicate sellers

बुरे seller पर प्रतिबंध तभी चलता है जब वह नए ईमेल से लौट न सके। सत्यापन-डेटा से निकलने वाले सबसे मज़बूत संकेत PAN और बैंक खाता हैं। इन्हें अपनी seller तालिका में सीधे मत रखिए। दोनों का keyed hash (आपके key management में रखे secret के साथ HMAC) रखिए और hash मिलाइए। इससे आप बिना कच्चे पहचानकर्ताओं का कॉलम रखे पूछ सकते हैं: "क्या कोई और seller यह PAN इस्तेमाल करता है?" और "क्या यह खाता किसी और seller पर दिखता है?"

import hmac, hashlib, os

SECRET = os.environ["SELLER_HASH_KEY"].encode()

def keyed_hash(value: str) -> str:
    normalised = "".join(value.split()).upper()
    return hmac.new(SECRET, normalised.encode(), hashlib.sha256).hexdigest()

def duplicate_policy(pan_hash: str, account_hash: str, seller_id: str, repo) -> str:
    same_pan = repo.sellers_with_pan_hash(pan_hash, exclude=seller_id)
    same_account = repo.sellers_with_account_hash(account_hash, exclude=seller_id)
    if same_account:
        return "review_shared_account"
    if same_pan:
        return "review_second_store"
    return "ok"

साझा PAN हमेशा धोखा नहीं होता। असली seller दूसरी श्रेणी के लिए दूसरा स्टोर खोल सकता है, और पारिवारिक कारोबार एक खाता साझा कर सकता है। hash का मक़सद पैटर्न को समीक्षक के सामने लाना है, अपने-आप प्रतिबंध लगाना नहीं।

payout पर रोक

payout वह जगह है जहाँ verification अपनी क़ीमत वसूलता है, इसलिए रोक payout सेवा में बनाइए, seller UI में नहीं जहाँ client की कोई ख़ामी उसे लाँघ सकती है। रोक के लिए चाहिए: seller का सत्यापित खाता, आपकी सीमा से ऊपर का नाम-score या समीक्षक की मंज़ूरी, ऐसा खाता जो ठंडक-अवधि में बदला न हो, और ऐसा seller-स्तर जो उस रकम की अनुमति दे। payout-खाते का हर बदलाव verification और ठंडक-अवधि को फिर शुरू करता है और seller को उसके सत्यापित मोबाइल और ईमेल पर सूचना देता है, ताकि खाता-हड़पने की कोशिश उसे दिख जाए।

आपकी risk टीम chargeback का बफ़र चाहे तो पहली बिक्री के बाद पहला payout कुछ तय समय रोकिए। यह व्यावसायिक नियम है, verification का नतीजा नहीं, पर उसे उसी रोक में रखना ठीक रहता है।

डिलीवरी पार्टनर और ड्राइवर: licence और वाहन की जाँच

जो प्लेटफ़ॉर्म ड्राइवर या डिलीवरी राइडर जोड़ते हैं उन्हें अलग दस्तावेज़ चाहिए। driving-licence endpoint POST /v1/verify/driving-license में dlNumber और dob जाते हैं और धारक का नाम, वैधता की तारीख़ और licence की स्थिति लौटती है। वाहन endpoint POST /v1/verify/rc में vehicleNumber जाता है और मालिक का नाम, पंजीकरण की स्थिति, rcStatus, समाप्ति, बीमा की तारीख़ और गाड़ी व्यावसायिक है या नहीं, लौटता है। दोनों संवेदनशील scopes हैं: IP allowlist वाली production key की उम्मीद रखिए, और ध्यान रहे कि RC endpoint premium दर वर्ग में है।

फ़ैसले उसी ढर्रे के हैं। जिस licence की स्थिति चालू नहीं या वैधता बीत चुकी है, वह रुकने की वजह है। जिस गाड़ी का मालिक राइडर नहीं है, उसके लिए रिश्ता समझाने वाला दस्तावेज़ चाहिए, जैसे मालिक की अनुमति, और वह समीक्षा का मामला है। सेवा से न बैठने वाला व्यावसायिक या निजी वर्गीकरण नीति का सवाल है। हमेशा की तरह, ये जाँचें रिकॉर्ड पक्का करती हैं, गाड़ी चलाने का हुनर या सुरक्षा नहीं, और किसे जोड़ना है यह फ़ैसला आपका रहता है।

seller को ऐसे संदेश जो मदद करें, जानकारी न खोलें

जाँच विफल होने पर seller को जो शब्द दिखते हैं वे मायने रखते हैं। बताइए क्या सुधारना है, यह नहीं कि रजिस्ट्री ने क्या कहा। "कानूनी नाम PAN पर छपे नाम से ठीक वैसा ही होना चाहिए" ज़्यादा काम का और ज़्यादा सुरक्षित है, बनिस्बत पंजीकृत नाम लौटाकर दिखाने के, जिससे PAN का अंदाज़ा लगाकर दूसरों के नाम टटोले जा सकते हैं। यह मत बताइए कि कोई PAN किसी दूसरे खाते पर है या नहीं। payout के लिए कहिए "हम इस खाते को आपके नाम से नहीं मिला सके" और दूसरा खाता या दस्तावेज़ माँगिए, बैंक का नाम दिखाने की जगह। ऐसा संदर्भ दिखाइए जो आप खोज सकें, जैसे आपका अपना case id, कच्चा upstream response कभी नहीं।

अपील और seller के विवाद

जो verification प्रणाली "नहीं" कह सकती है, उसके पास "आप ग़लत हैं" सुनने का रास्ता भी होना चाहिए। स्रोत रिकॉर्ड कभी-कभी पुराने होते हैं, रजिस्ट्रियों में नाम की वर्तनी अलग हो सकती है, और seller आपके ही फ़ॉर्म की टाइपिंग-चूक से रुक सकता है। पहला अस्वीकार जाने से पहले अपील का रास्ता बना लीजिए।

हर अस्वीकार को एक case id दीजिए जिसे seller बता सके और जिसे आपके विश्लेषक खोज सकें। seller को बताइए कि कौन-सा कदम विफल हुआ (PAN, खाता, पंजीकरण) और क्या उसे हल करेगा, स्रोत का डेटा दोहराए बिना। seller को एक बार केस खोले बिना field दोबारा भरने दीजिए, क्योंकि ज़्यादातर विफलताएँ टाइपो होती हैं। इससे आगे दस्तावेज़ अपलोड लीजिए और इंसान से घोषित मानों से मिलवाइए। दस्तावेज़ दिखाए कि स्रोत रिकॉर्ड पुराना है, तो यह नतीजा और समीक्षक का नाम seller की फ़ाइल पर दर्ज कीजिए और दूसरे मंज़ूरीकर्ता के साथ हाथ से override करके स्तर दीजिए। जवाब बदलने की उम्मीद में API कभी लूप में न चलाइए: दोहराया गया नकारात्मक जवाब फिर बिल होता है और वही नतीजा लौटाता है।

अपीलों का नतीजा देखते रहिए। किसी एक नियम पर बहुत-सी अपीलें सफल हों तो नियम ज़्यादा सख़्त है। लगभग कोई सफल न हो तो या नियम ठीक है या sellers ने अपील करना छोड़ दिया है। अस्वीकार-स्क्रीन पर छोड़कर जाने की दर देखकर फ़र्क़ पता चलता है।

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

• PAN पर valid: false। पहले देखिए कि आपका फ़ॉर्म खाली जगह, छोटे अक्षर या ग़लती से चिपकी कोई अतिरिक्त पंक्ति तो नहीं भेज रहा। भेजने से पहले PAN को साफ़ करके बड़े अक्षरों में रखना आपके हाथ में है। इसके बाद भी विफल हो, तो seller से PAN कार्ड की प्रति या आयकर पोर्टल की पुष्टि वाला दस्तावेज़ माँगिए, और मामला हाथ की समीक्षा में डालिए।
• GSTIN वैध, पर PAN-से-GSTIN सूची में नहीं। GSTIN के बीच के दस अक्षर उसी PAN के होते हैं जिस पर वह पंजीकृत है। इन्हें सत्यापित PAN से मिलाइए। अगर अलग निकलें, तो seller ने किसी और का GSTIN भरा है, चाहे ग़लती से या जान-बूझकर, और यही बात seller को सुधारने के लिए बताने लायक़ है।
• खाता वैध, पर नाम-score बीच का। अक्सर यह नाम के संक्षिप्त रूप या क्रम का फ़र्क़ होता है। एक बार seller से पूछिए कि खाता किस नाम पर खुला है, और ज़रूरत हो तो खाते की पासबुक या चेक का पहला पन्ना माँगिए। नाम बिलकुल अलग हो तो खाता किसी और का है और payout रुकना चाहिए।
• जाँच बार-बार 429 या 502 पर अटके। यह seller की ग़लती नहीं है। जाँच को बाक़ी स्थिति में रखिए, seller को "जाँच चल रही है" बताइए, और कुछ देर बाद सीमित backoff से दोबारा चलाइए।
• seller का दावा कि दूसरा खाता उसका अपना ही है। जुड़े खातों की सूची देखिए, पर कारण बताए बिना किसी को प्रतिबंधित मत कीजिए। पारिवारिक या एक ही संचालक के कई स्टोर वैध हो सकते हैं, और फ़ैसला समीक्षक का रहे।

marketplace के प्रकार के हिसाब से अलग-अलग ज़ोर

सीढ़ी सामान्य है, पर संवेदनशील जगहें इस पर खिसकती हैं कि आप क्या बेचते हैं।

माल के marketplace में पंजीकरण की स्थिति और duplicate स्टोर सबसे ज़्यादा मायने रखते हैं। नक़ली माल और छोड़ी हुई listings की समस्याएँ अक्सर थोक में बनाए खातों से आती हैं, इसलिए duplicate hash और PAN-to-GSTIN जाँच यहाँ ज़्यादा वज़न रखती हैं।

सेवा और freelancer marketplace में अक्सर ऐसे व्यक्ति होते हैं जिनका GST पंजीकरण नहीं होता। उनके लिए स्तर 3 कभी लागू न हो और PAN व बैंक खाते की जोड़ी ही पूरी कहानी हो। ऊँचे जोखिम वाली श्रेणियों और तेज़ी से बढ़ते payout वाले sellers के लिए स्तर 4 की हाथ की समीक्षा रखिए।

quick-commerce और डिलीवरी प्लेटफ़ॉर्म भारी मात्रा में राइडर और स्टोर पार्टनर जोड़ते हैं। राइडरों के लिए licence और वाहन की जाँच मायने रखती है, और स्टोर पार्टनर एक व्यवसाय है जिसके लिए पंजीकरण की जाँचें हैं। यहाँ throughput और turnaround सबसे ज़रूरी हैं, इसलिए समीक्षा queue छोटी रखिए और रोज़ नापिए।

B2B marketplace व्यवसायों को बेचते हैं जो tax invoice और उधार की शर्तें चाहते हैं। ख़रीदार पूछेंगे कि सप्लायर का पंजीकरण असली है या नहीं, इसलिए पंजीकरण की जाँचें और स्थिति की दोबारा जाँचें भरोसा ढोती हैं। इस मामले में संस्था की जाँच पर B2B प्लेटफ़ॉर्म के लिए KYB पेज और गहराई में जाता है।

सीमा-पार या निर्यात करने वाले sellers के भारतीय पंजीकरण हो ही न सकते हैं। उन्हें अलग प्रवाह से भेजिए और जिनके पास भारतीय पहचानकर्ता नहीं हैं उन पर थोपिए मत।

मार्केटप्लेस के लिए अपनाने लायक़ समीक्षा-नियम

ये सुझाव हैं जिन्हें आपकी risk और नीति टीमें अपने हिसाब से ढालें।

• स्तर 1 के लिए seller के घोषित प्रकार से मेल खाते प्रकार का वैध PAN चाहिए, और आपकी ऊँची सीमा से ऊपर का नाम-score या समीक्षक की मंज़ूरी।
• स्तर 2 के लिए seller के नाम का वैध खाता चाहिए। बीच के score समीक्षा में जाएँ और कम score रोके जाएँ।
• स्तर 3 के लिए ऐसा चालू पंजीकरण चाहिए जिसका PAN सत्यापित PAN के बराबर हो। पंजीकरण का ज़िक्र करने वाला badge सिर्फ़ उसी पर लगे जिसे रजिस्ट्री ने पक्का किया।
• वृद्धि कीजिए जब कोई PAN hash या खाता hash एक से ज़्यादा sellers पर दिखे, किसी बड़े settlement के पास खाता बदले, या seller के पंजीकरण की स्थिति निष्क्रिय हो जाए।
• दो मंज़ूरीकर्ता निलंबित seller को बहाल करने और किसी भी हाथ के स्तर-उन्नयन के लिए।
• ठंडक-अवधि payout-खाता बदलने के बाद, और सत्यापित मोबाइल व ईमेल पर सूचना।
• एक संकेत पर अपने-आप प्रतिबंध नहीं। संकेतों से मामले समीक्षा में भेजिए, और जो फ़ैसला seller का कारोबार ख़त्म करे उसे इंसान के पास रखिए।

टीम का ढाँचा

तीन queue चलाइए। onboarding queue नाम-बेमेल और अनसुलझे पंजीकरण सँभालती है, शुरुआती सुझाव के तौर पर एक कार्य-दिवस की समय-सीमा के साथ। payout-रोक queue खाता-बेमेल और बदलाव सँभालती है, कम समय-सीमा के साथ क्योंकि sellers पैसे का इंतज़ार कर रहे हैं। जोखिम queue duplicate और जुड़े खातों के मामले और वृद्धि सँभालती है, जिस पर वरिष्ठ trust-and-safety विश्लेषक रहें। हर queue के सबसे पुराने मामले की उम्र नापिए और दिखाते रहिए।

विश्लेषकों को हर seller के लिए एक ही स्क्रीन दीजिए जिसमें घोषित और सत्यापित मान आमने-सामने हों, हर जाँच का referenceId, स्तर का इतिहास और टिप्पणियाँ हों। उन्हें सिस्टमों के बीच मान कॉपी न करने पड़ें।

क्या रखें और कितने समय तक

हर जाँच के लिए: product, referenceId, समय, key का environment, पहचानकर्ता का ढका या hash किया रूप, फ़ैसले में काम आए response fields, फ़ैसला, नियम का संस्करण और समीक्षक। कच्चे PAN, खाता संख्या और licence नंबर application logs से बाहर रखिए। संचालन के डेटा और सबूत के संग्रह को अलग कीजिए और दोनों पर पहुँच-नियंत्रण व audit लगाइए।

seller रिकॉर्ड कितने समय रखे जाएँ, यह कर और लेखा नियमों, e-commerce और उपभोक्ता नियमों, आपके अनुबंधों और व्यक्तिगत sellers के निजी डेटा पर डेटा-सुरक्षा कानून पर निर्भर है। अवधियाँ हम नहीं बता सकते। सवाल अपने सलाहकार के पास ले जाइए, जवाब को retention schedule में लिखिए और उसे स्वचालित कीजिए। StampMitra का अपना तरीक़ा उसके retention और deletion schedule और data processing addendum में है।

लागत: तीन seller-मात्राएँ

pay-as-you-go पर PAN, GSTIN, CIN, Udyam और cross-lookups की दर ₹5 प्रति call है और bank-account जाँच की ₹4। licence और RC जैसे premium वर्ग की दर pay as you go पर ₹9 है। Growth और Scale standard और premium दरें घटाते हैं और महीने की plan फ़ीस जोड़ते हैं, और bank-account की दर सब plans पर एक-सी है। सभी राशियाँ 18 प्रतिशत GST से पहले की हैं।

स्तर 2 के एक seller (PAN और बैंक खाता) और स्तर 3 के एक seller (GSTIN जोड़कर) की लागत:

मासिक मॉडलों के लिए funnel की मान्यता चाहिए। हम मानते हैं कि हर नए seller पर PAN जाँच होती है, इस मॉडल में सब आख़िर में बैंक जाँच तक पहुँचते हैं, और 40 प्रतिशत sellers पर GSTIN जाँच भी होती है। प्रतिशत अपने आँकड़ों से बदलिए। महीने में 1,000 नए sellers पर यह 1,000 PAN और 400 GSTIN calls (कुल 1,400 standard calls) और 1,000 बैंक जाँचें हैं।

महीने में 10,000 नए sellers पर: 14,000 standard calls और 10,000 बैंक जाँचें।

महीने में 1,00,000 नए sellers पर, जैसा कोई बहुत बड़ा प्लेटफ़ॉर्म देख सकता है: 1,40,000 standard calls और 1,00,000 बैंक जाँचें।

तीन बातें। छोटी मात्रा पर plan फ़ीस कम दरों से भारी पड़ती है, इसलिए pay as you go या Growth किफ़ायती है। seller आधार बढ़ने पर Scale, Growth से आगे निकल जाता है। सबसे बड़े स्तर पर मासिक ख़र्च उस सीमा से कहीं ऊपर है जहाँ StampMitra enterprise व्यवस्था का सुझाव देता है, और वह contact पेज के ज़रिये व्यावसायिक बातचीत का विषय है। तालिकाएँ मानती हैं कि GST plan फ़ीस पर भी लगता है, जिसे invoice से पक्का कीजिए। उपयोग सफल response के बाद दर्ज होता है, इसलिए error लौटाने वाली calls का शुल्क नहीं लगता, पर valid: false सफल call है। सीढ़ी को चरणों में चलाने से बैंक और रजिस्ट्री की जाँचें सिर्फ़ उन sellers के लिए बचती हैं जो सचमुच उन पायदानों तक पहुँचते हैं, इसलिए असली मासिक लागत अक्सर ऊपर के "सब कुछ तक पहुँचते हैं" वाले मॉडल से कम निकलती है।

रोलआउट: sandbox, pilot, production

Sandbox। सीढ़ी sandbox keys पर बनाइए, जहाँ response नमूना डेटा है और wallet नहीं कटता। sandbox PAN SNDBX0000A पर वैध और SNDBX9999F पर अवैध नतीजा देता है, और GSTIN के लिए जोड़ी 09SNDBX0000A1Z5 व 09SNDBX9999F1Z5 है। बाक़ी इनपुट पर स्थिर पर मनमाना नतीजा आता है, इसलिए उन पर assertion मत लगाइए। dashboard में ताज़ा test values देखिए। हर स्तर-परिवर्तन, स्तर हटना, duplicate नीति, payout रोक और 402, 429, 502 के रास्तों का test कीजिए।

Pilot। production access के लिए आवेदन कीजिए, जिसके लिए आपके संगठन की KYC मंज़ूरी और product-वार आवेदन चाहिए। किसी एक श्रेणी या शहर के नए sellers पर सीढ़ी चालू कीजिए, अपनी मौजूदा समीक्षा साथ-साथ चलाइए, और फ़ैसले मिलाइए।

Production। सीढ़ी श्रेणी-दर-श्रेणी बढ़ाइए, फिर मौजूदा sellers को स्तर के क्रम में दोबारा जाँचने पर विचार कीजिए, सबसे ज़्यादा payout वाले पहले। wallet balance पर अलर्ट रखिए, और keys के scopes और IP allowlist के लिए sandbox बनाम production keys गाइड देखिए।

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

किन मापदंडों पर नज़र रखें

• signup से स्तर 1, स्तर 1 से स्तर 2 और स्तर 2 से स्तर 3 तक का रूपांतरण। किसी कदम पर अचानक गिरावट बताती है कि कौन-सी माँग बहुत भारी है।
• समीक्षा-दायरे में sellers का हिस्सा और सबसे पुराने मामले की उम्र।
• कारण के हिसाब से payout-रोकें, और कितनी समीक्षा के बाद छोड़ी गईं।
• duplicate-hash के मिलान, और उनमें से कितने समीक्षकों ने एक ही संचालक के पाए।
• प्रति हज़ार sellers payout-खाता बदलाव, और उनमें रोके गए का हिस्सा।
• जिन sellers का पंजीकरण निष्क्रिय हुआ, और उसके बाद क्या हुआ।
• verification की लागत प्रति उस seller के हिसाब से जो स्तर 2 तक पहुँचा, प्रति signup नहीं।

जो ग़लतियाँ seller verification को कमज़ोर करती हैं

• signup पर सब कुछ जाँचना। ईमानदार sellers छूटते हैं और ऐसे लोगों पर पैसा लगता है जो कभी बेचते ही नहीं।
• रोक सिर्फ़ UI में लगाना। client की ख़ामी या सीधी API call उसे लाँघ देती है। रोक payout सेवा में लगाइए।
• duplicate पकड़ने के लिए कच्चे पहचानकर्ता रखना। keyed hash इस्तेमाल कीजिए।
• ब्रांड के नाम को कानूनी नाम समझना। तय कीजिए कि हर जाँच किस नाम से तुलना करती है।
• registry का डेटा sellers को लौटाकर दिखाना। अंदाज़े से नंबर आज़माने वालों को दूसरों की जानकारी मिल जाती है।
• स्थिति के बदलाव अनदेखे करना। स्तर बढ़ते समय चालू रहा पंजीकरण या licence बाद में चालू न रहे, यह हो सकता है।
• एक संकेत पर अपने-आप प्रतिबंध। संकेतों से मामले लोगों तक भेजिए।
• sandbox का व्यवहार production में ले जाना। sandbox का डेटा कृत्रिम है। छोटे production समूह पर दोबारा परखिए।

संबंधित API और गाइड

इस पेज के endpoints verification API reference में हैं: PAN, bank account, GSTIN, PAN to GSTIN, driving licence और vehicle RC। और पढ़ने के लिए vendor onboarding verification पेज, जो सप्लायर-पक्ष की जाँचें बताता है, payout से पहले bank account verification, B2B प्लेटफ़ॉर्म के लिए KYB गाइड, business verification गाइड और errors गाइड देखिए। सारे उद्योग-वार पेज solutions पेज पर हैं, और मौजूदा दरें 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-1L67Z5",
  "found": true,
  "gstins": [
    {
      "gstin": "07AAAAA1111A1Z1",
      "state": "Delhi",
      "status": "Active"
    }
  ]
}

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

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