Penny drop बनाम name match: बैंक खाता verification को समझिए

मुख्य बातें

• penny drop पुष्टि करता है कि खाता मौजूद और पहुँच में है और बैंक के रिकॉर्ड का धारक-नाम लौटाता है। name match उस नाम को अपेक्षित नाम से मिलाता है। आपको दोनों चाहिए।
• एक endpoint, POST /v1/verify/bank-account, scope verification.bank-account.read। accountNumber (9 से 18 अंक) और ifsc (11 अक्षर) ज़रूरी। name और phone वैकल्पिक।
• जवाब में valid, nameAtBank, bankName, utr, city, branch, micr, nameMatchScore, nameMatchResult, accountStatus, accountStatusCode, ifscDetails और referenceId आते हैं।
• docs के नमूने में nameMatchScore एक string है ("100"), nameMatchResult GOOD_MATCH है और accountStatus ACCOUNT_IS_VALID। reference हर एक का एक ही उदाहरण दिखाता है, इसलिए मानों का समूह खुला मानिए।
• बैंक में दर्ज नाम अक्सर व्यक्ति के औपचारिक नाम से छोटा, संक्षिप्त या अलग क्रम में होता है। इसके लिए बनाइए: normalise कीजिए, स्कोर लीजिए, फिर समीक्षा।
• बैंक का नाम उस payee के नाम से मिलाइए जिसे आपने कहीं और verify किया है (जैसे PAN का नाम), सिर्फ़ उससे नहीं जो उसने टाइप किया।
• reference नहीं कहता कि verification calls idempotent हैं। penny drop की timeout वाली call को आँख मूँदकर retry करना सुरक्षित नहीं: पहले देखिए कि पहली call पूरी हुई या नहीं।
• StampMitra के production access फ़ॉर्म में bank account verification ऊँचे जोखिम का चिह्नित है और अतिरिक्त जाँच के बाद खुलता है, इसलिए जल्दी आवेदन कीजिए।
• वैध खाता और मिलता नाम यह साबित करते हैं कि खाता असली और संभवतः उनका है। इससे उनकी नीयत, या खाते के सिर्फ़ ज़रिया होने की बात साबित नहीं होती।

तीन payee, तीन नीतियाँ

एक ही जवाब के साथ अलग बरताव चाहिए, इस पर निर्भर करते हुए कि आप किसे क्या भुगतान करने जा रहे हैं और ग़लती की क़ीमत क्या है। तीन काल्पनिक स्थितियाँ जो एक ही फ़ैसले की बनावट अलग सीमाओं के साथ इस्तेमाल करती हैं।

गिग वर्कर को हफ़्ते का भुगतान। रक़में छोटी और बार-बार, payee हज़ारों, और ग़लती से ठुकराया गया वर्कर एक support टिकट और हाथ से निकला पार्टनर है। नीति: पहले PAN verify कीजिए, बैंक के nameAtBank को PAN के पंजीकृत नाम से उदार सीमा पर मिलाइए, और अगर पहला नाम और उपनाम का पहला अक्षर मिलें तो आंशिक मिलान को flag के साथ पास होने दीजिए। बाक़ी को समीक्षा की कतार में भेजिए जो रद्द चेक की फ़ोटो माँगे। जाँच सुलझने तक पहला भुगतान रोकिए और फिर रुकी रक़म छोड़ दीजिए। ग़लती की क़ीमत एक हफ़्ते की कमाई तक सीमित है।

ट्रेडिंग कंपनी के लिए वेंडर ऑनबोर्डिंग। रक़में बड़ी, वेंडर कम और हर एक पर असली मेहनत लायक़। नीति: वेंडर का PAN, GSTIN और, कंपनी हो तो, CIN verify कीजिए; फिर बैंक खाता verify कीजिए और लुकअप से मिले legal name से तुलना कीजिए, trade name सिर्फ़ प्रोपराइटरशिप के लिए मानिए। आंशिक मिलान हमेशा किसी इंसान के पास जाए, जो रद्द चेक या बैंक पत्र माँगे। बाद में खाता बदला जाए तो वही प्रवाह चले और पहले भुगतान से पहले दूसरा अनुमोदक हो। यहाँ ग़लती की क़ीमत ग़लत जगह गया इनवॉइस भुगतान है, इसीलिए समीक्षा की कतार वैकल्पिक नहीं है।

कर्ज़ का वितरण। रक़म बड़ी है, उधार लेने वाले की पूरी KYC हो चुकी है, और जो पैसा खाते में जाएगा उसे वापस बुलाना मुश्किल है। नीति सख़्त है: बैंक का नाम verify किए उधारकर्ता के नाम से ऊँची सीमा पर मिलना चाहिए, साझा खातों की समीक्षा हो, और हर आंशिक मिलान ऐसे इंसान के पास जाए जिसके सामने उधारकर्ता के दस्तावेज़ हों। ऋणदाता ifscDetails को उधारकर्ता के बताए बैंक और शहर से भी मिलाता है। नाम का बेमेल वितरण को तब तक रोकता है जब तक सुलझ न जाए, देरी चाहे कितनी शर्मनाक लगे। नियंत्रित ऋणदाताओं को अपने नियामक या पार्टनर बैंक से भी पूछ लेना चाहिए कि वितरण पर कौन-से नियंत्रण ज़रूरी हैं, क्योंकि वे नियम इस API के बाहर हैं।

तीनों नीतियाँ वही decide_bank function अलग accept_score और reject_score मानों के साथ इस्तेमाल करती हैं, और फ़र्क़ मुख्यतः इसमें है कि समीक्षा की कतार क्या माँगती है और पैसा क्या रोकता है। कोड वही रहता है। नीति configuration है।

दो विचार जिन्हें लोग मिला देते हैं

कोई कहे "हम penny drop verification करते हैं", तो वह आम तौर पर एक साथ चार अलग बातें कह रहा होता है।

पहले दो जवाब बैंक से transfer की पटरी के ज़रिए आते हैं। तीसरा तुलना है, जो API (nameMatchScore) कर सकती है और आप दोबारा। चौथे का जवाब penny drop बिल्कुल नहीं देता, और उसके लिए दूसरा कारक चाहिए, जैसे दस्तावेज़, reverse penny drop या ग्राहक के अपने खाते से भुगतान।

इन चारों सवालों को अलग रखने से डिज़ाइन साफ़ हो जाता है। पहले तीन में से किसी पर आप अपने-आप विफल कर सकते हैं, और सिर्फ़ तीसरे को, जब स्कोर बीच का हो, इंसान के पास भेजते हैं।

penny drop कैसे काम करता है और क्या पता चलता है

penny drop जाँचे जाने वाले खाते में बहुत छोटा क्रेडिट भेजता है और नतीजा पढ़ता है। बैंक transfer की भाषा में यह लाभार्थी को सामान्य क्रेडिट है, जो आपके दिए खाता संख्या और IFSC से जाता है। क्रेडिट सफल हो तो खाता मौजूद है, क्रेडिट के लिए खुला है और सही पते पर है। बैंक लाभार्थी का नाम भी वैसे लौटाता है जैसे उसके रिकॉर्ड में है, और transfer के साथ एक संदर्भ चलता है, जो StampMitra के जवाब में utr फ़ील्ड है।

चार सावधानियाँ तय करती हैं कि आप इसे कैसे इस्तेमाल करें।

पहली, रक़म और उसका ख़र्च कौन उठाता है, यह StampMitra के reference में नहीं लिखा। प्रोडक्ट के वर्णन में endpoint को खाते और धारक के नाम की penny-drop पुष्टि कहा गया है, और जवाब में utr है। अपने ग्राहकों को कोई रक़म तब तक मत बताइए जब तक support से पक्का न कर लें। खाताधारकों को यह ज़रूर बताइए कि उनके स्टेटमेंट में बहुत छोटा क्रेडिट दिख सकता है, ताकि कोई चौंके नहीं।

दूसरी, खाते वैध होकर भी क्रेडिट ठुकरा सकते हैं, ऐसी वजहों से जिनका धोखाधड़ी से कोई लेना-देना नहीं: फ़्रीज़ या निष्क्रिय खाता, खाते के प्रकार पर रोक, या बैंक की तरफ़ की अस्थायी विफलता। इसलिए विफल क्रेडिट खाते के बारे में सबूत है, बेईमानी का सबूत नहीं। इसे "कृपया ब्योरा जाँचिए या दूसरा खाता आज़माइए" से सँभालिए, इल्ज़ाम से नहीं।

तीसरी, बैंक जो नाम लौटाता है वह बैंक की अपनी बही का है। वह लंबाई, संक्षेप और क्रम के बैंक के अपने नियमों पर चलता है। वह PAN के नाम से और चेक बुक पर लिखे नाम से अलग हो सकता है।

चौथी, जाँच बैंक की व्यवस्था तक पहुँचने पर निर्भर है। इससे विफलता के ऐसे तरीक़े आते हैं (timeout, upstream उपलब्ध नहीं) जो सिर्फ़ format पर टिकी जाँच में नहीं होते, और इसीलिए retry के बरताव का अपना हिस्सा नीचे है।

StampMitra का bank account endpoint

curl -X POST "https://api-b2b.stampmitra.in/v1/verify/bank-account" \
  -H "Authorization: Bearer $STAMPMITRA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"accountNumber":"000123456789","ifsc":"ICIC0001234","name":"Ravi Kumar"}'

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

PAN endpoint से तुलना कीजिए, जो nameMatchScore string और nameMatchResult भी लौटाता है, पर लेबल के मान अलग हैं। दोनों को सँभालने वाले साझा helper को लेबलों को खुला समूह मानना होगा और हर एक के लिए स्कोर parse करना होगा।

accountStatus, nameMatchResult और nameMatchScore पढ़ना

reference इनमें से हर फ़ील्ड का एक उदाहरण दर्ज करता है। वह दूसरे status या लेबल नहीं गिनाता, और तुलना का तर्क या स्कोर की सीमाएँ प्रकाशित नहीं करता। इसी हिसाब से डिज़ाइन कीजिए।

status के लिए लिखिए "ACCOUNT_IS_VALID पास; बाक़ी सब पास नहीं"। अनजानी स्थिति समीक्षा में जाए या "कृपया दूसरा खाता आज़माइए" में, आपके प्रोडक्ट के हिसाब से, और आप कच्चा मान और referenceId लॉग करें। नाम के लिए nameMatchResult को संकेत और nameMatchScore को संकेतक मानिए, और अपनी सीमा लगाइए, अपने डेटा पर अंशांकित, उस तरीक़े से जो PAN को verify करके नाम कैसे मिलाएँ में है। वहाँ सीमाओं, normalisation, परतों और समीक्षा के बारे में जो कहा गया है वह यहाँ भी लागू है।

एक अंतर ध्यान देने लायक़ है: निशाना। PAN के लिए निशाना व्यक्ति का पंजीकृत नाम है। बैंक खाते के लिए निशाना बैंक की अपनी स्ट्रिंग है, जो औपचारिक नाम से आम तौर पर छोटी और ज़्यादा संक्षिप्त होती है। PAN के नामों पर अंशांकित सीमा बैंक के नामों के लिए अक्सर बहुत सख़्त निकलेगी।

बैंक का नाम आपकी अपेक्षा से अलग क्यों होता है

भुगतान प्रवाहों में झूठी अस्वीकृतियों का सबसे बड़ा स्रोत बैंक के नाम हैं। वे ग़लत नहीं हैं। उन्हें उस व्यवस्था ने आकार दिया है जो उन्हें रखती है।

इससे दो बचाव निकलते हैं। पहला, दोनों स्ट्रिंग normalise कीजिए (केस, विराम चिह्न, उपाधियाँ, "MOHD" और "MOHAMMED" जैसे संक्षेप) और टोकन की तुलना कीजिए, जैसे PAN गाइड में है। दूसरा, पहले से तय कीजिए कि आपका प्रोडक्ट हर तरह के payee के लिए कितना फ़र्क़ सहेगा। हफ़्ते में छोटी रक़म पाने वाला गिग वर्कर ऋण बाँटते ऋणदाता से ज़्यादा फ़र्क़ सह सकता है।

किस नाम से तुलना करें

"payee के नाम से तुलना कीजिए" काफ़ी ख़ास नहीं है। आपके पास आम तौर पर तीन उम्मीदवार नाम होते हैं, और आप कौन-सा चुनते हैं इससे नतीजा बदलता है।

व्यक्तियों के लिए बेहतर डिज़ाइन यह है कि पहले PAN verify कीजिए, फिर बैंक के nameAtBank की PAN के registeredName से तुलना कीजिए, और टाइप किया नाम केवल आख़िरी विकल्प रखिए। तब बेमेल का मतलब है कि खाता शायद उस व्यक्ति के नाम पर नहीं जिसका PAN आपने verify किया, और यही संकेत आपको चाहिए। कारोबारों के लिए पंजीकृत legal name से तुलना कीजिए और प्रोपराइटरशिप के लिए trade name मानने को तैयार रहिए, जहाँ खाता दोनों में से किसी के नाम हो सकता है। पहले कौन-सी पहचान verify करें, इसका बड़ा चित्र PAN, GSTIN और CIN में फ़र्क में है।

अपने request में फिर भी name भेजिए। प्लेटफ़ॉर्म की तुलना उसी call का हिस्सा है और कोई अतिरिक्त ख़र्च नहीं लेती। वही नाम भेजिए जिसे आप निशाना बनाएँगे, ताकि जो स्कोर मिले वही स्कोर आप पर काम करे।

एक उदाहरण जिसमें दो उम्मीदवार नाम टकराते हैं। एक फ़्रीलांसर के पास अपने नाम का बचत खाता है और अपनी छोटी कंपनी के नाम का चालू खाता। भुगतान वह चालू खाते में लेना चाहता है। अगर आप बैंक के nameAtBank की तुलना सिर्फ़ उसके टाइप किए नाम से करेंगे, तो दोनों खाते "मिलते" दिख सकते हैं, क्योंकि उसने वही लिखा जो उसके मन में था। जब तुलना उसके PAN के registeredName से होती है, तो बचत खाता मिलता है और चालू खाता नहीं, और तब सही सवाल बनता है: क्या यह भुगतान व्यक्ति को जा रहा है या कंपनी को? अगर कंपनी को, तो तुलना कंपनी के GSTIN या CIN के legal name से होनी चाहिए, और वही पैसा लेने वाली पार्टी का सही रिकॉर्ड बनता है। यानी पहले तय कीजिए कि payee कौन है, फिर उसी का नाम तुलना का निशाना बनाइए।

इसी तरह, जब जाँच valid: false लौटाए, तो पहले यह मत मान लीजिए कि खाता फ़र्ज़ी है। खाता संख्या का एक अंक या IFSC का एक अक्षर ग़लत होना सबसे आम कारण है। यूज़र को वही दो field दोबारा जाँचने का मौक़ा दीजिए, और बार-बार विफल होने पर ही हाथ की समीक्षा या दूसरे खाते की माँग पर जाइए।

जवाब को फ़ैसले में बदलना

फ़ैसला एक ही शुद्ध function में रखिए। नीचे का संस्करण साफ़ मिलान को स्वीकार करता है, आंशिक मिलान और अनजानी स्थितियों को समीक्षा में भेजता है, और सिर्फ़ तब विफल करता है जब lookup कहे कि खाता वैध नहीं।

import re

def decide_bank(res: dict, accept_score: float = 85.0, reject_score: float = 40.0) -> dict:
    ref = res.get("referenceId")
    if not res.get("valid"):
        return {"decision": "FAIL", "reasons": ["ACCOUNT_NOT_VALID"], "ref": ref}
    reasons = []
    if res.get("accountStatus") != "ACCOUNT_IS_VALID":
        reasons.append("STATUS_" + str(res.get("accountStatus") or "EMPTY").upper())
    try:
        score = float(re.sub(r"[^0-9.]", "", str(res.get("nameMatchScore") or "")))
    except ValueError:
        score = None
    if score is None:
        reasons.append("NO_SCORE")
    elif score < reject_score:
        reasons.append("NAME_FAR")
    elif score < accept_score:
        reasons.append("NAME_PARTIAL")
    if "NAME_FAR" in reasons:
        return {"decision": "FAIL", "reasons": reasons, "ref": ref}
    return {"decision": "REVIEW" if reasons else "PASS", "reasons": reasons, "ref": ref}

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

अगर आपका बैकएंड Node है तो वही तर्क JavaScript में लगभग शब्दशः उतरता है। मुख्य बात यह है कि फ़ैसला एक ही जगह रहे और कारणों को कोड में लौटाए।

call पर पैसा ख़र्च करने से पहले इनपुट जाँचिए

ग़लत बनावट वाला मान बैंक तक कुछ भेजे जाने से पहले ही 400 से विफल होता है। दर्ज संदेश है accountNumber must be a 9-18 digit numeric bank account number। उसे पहले ही पकड़ लीजिए।

import re

def check_bank_input(account_number, ifsc):
    acct = re.sub(r"\s+", "", str(account_number or ""))
    code = re.sub(r"\s+", "", str(ifsc or "")).upper()
    if not re.fullmatch(r"[0-9]{9,18}", acct):
        return {"ok": False, "field": "accountNumber", "reason": "खाता संख्या 9 से 18 अंक की होनी चाहिए।"}
    if not re.fullmatch(r"[A-Z]{4}0[A-Z0-9]{6}", code):
        return {"ok": False, "field": "ifsc", "reason": "IFSC में 11 अक्षर होते हैं: चार अक्षर, एक शून्य, फिर छह अक्षर या अंक।"}
    return {"ok": True, "accountNumber": acct, "ifsc": code}

IFSC की बनावट (चार अक्षर, एक शून्य, छह अक्षर-अंक) मानक format है। पैटर्न की जाँच यह नहीं बता सकती कि शाखा मौजूद है या नहीं, पर वह टाइपिंग की ग़लतियाँ मुफ़्त में हटा देती है। अगर आपका प्रवाह यह झंझट सह सके तो यूज़र से खाता संख्या दो बार टाइप करवाइए, क्योंकि नौ से अठारह अंक की संख्या में एक अंक की ग़लती लंबाई की जाँच पास कर सकती है और वैध IFSC के साथ किसी दूसरे असली खाते की ओर इशारा कर सकती है।

खाता भरने की स्क्रीन कैसी हो

ज़्यादातर विफल verification फ़ॉर्म में ही पैदा होते हैं। कुछ बारीकियाँ उन्हें घटाती हैं।

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

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

बताइए कि क्या होगा। बटन के नीचे एक पंक्ति: "खाते की पुष्टि के लिए हम इसमें बहुत छोटी रक़म भेजेंगे। आपको कुछ करना नहीं है।" यह वाक्य उन यूज़रों के support संदेशों की बाढ़ रोकता है जो अनपेक्षित क्रेडिट देख लेते हैं। यह पंक्ति छापने से पहले असली बरताव support से पक्का कर लीजिए।

विफलता के संदेश में अगला कदम दीजिए। तुलना कीजिए।

आख़िरी पंक्ति ऊपर के retry नियमों से जुड़ती है: संदेश अस्पष्टता के बारे में सच बताता है और यूज़र को दोबारा भेजने को नहीं कहता।

बैंक का लौटाया नाम किसी ऐसे को कभी मत दिखाइए जिसने payee प्रोफ़ाइल का मालिक होना साबित न किया हो। किसी अजनबी के अंदाज़े के जवाब में "हमें मिला: RAVI KUMAR SHARMA" दिखाना आपके फ़ॉर्म को नाम खोजने की सेवा बना देता है।

retry और दोहराई गई calls: वह एक जगह जहाँ सावधानी चाहिए

PAN, GSTIN और CIN के लिए timeout हुई call दोबारा भेजना आम तौर पर लागत के सिवा बेअसर है। penny drop में call का मतलब बैंक के ज़रिए असली transfer है। आपकी तरफ़ का timeout यह नहीं बताता कि transfer गया या नहीं। आँख मूँदकर retry का मतलब उसी खाते में दो क्रेडिट और आप पर दो शुल्क हो सकता है।

reference कहता है कि verification endpoint idempotent नहीं हैं: referenceId एक call की पहचान है और साफ़ तौर पर idempotency key नहीं है, और उनके लिए कोई idempotency header दर्ज नहीं है। इसलिए खुद को बचाइए।

1. अपने job को idempotent बनाइए। call से पहले payee और खाते के सामने "verification माँगी गई" दर्ज कीजिए, और बाद में नतीजा। job फिर शुरू हो तो दूसरी call करने से पहले उसे रिकॉर्ड देखना चाहिए।
2. timeout पर अपने-आप retry मत कीजिए। 429 पर backoff के साथ retry कीजिए (request दर के कारण ठुकराया गया, कुछ भेजा नहीं गया)। अनुरोध भेजे जाने के बाद timeout या 502 पर, पहले सबूत ढूँढिए कि पहली call पूरी हुई या नहीं।
3. logs देखिए। GET /v1/logs में service=bank-account.verify, आपकी call से ठीक पहले का from समय और status छन्नी दिखाती है कि प्लेटफ़ॉर्म ने कोई call दर्ज की या नहीं। की हो, तो दोबारा call करने की जगह वही नतीजा इस्तेमाल कीजिए।
4. अस्पष्टता सामने रखिए। पक्का न कर पाएँ तो यूज़र से कहिए "हम अभी इस खाते की जाँच कर रहे हैं", और तंग लूप में फिर कोशिश करने की जगह उसे asynchronously सुलझाइए।

हर status code के व्यापक नियम एरर, retry और idempotency में हैं। वहाँ से यही बात साथ ले जाइए कि bank account verification वह endpoint है जहाँ "बस retry कर दो" सबसे कम सुरक्षित है।

विकल्प, और हर एक कहाँ जमता है

penny drop खाता असली और संभवतः payee का होने की पुष्टि के कई तरीक़ों में से एक है। वे इसमें अलग हैं कि क्या साबित करते हैं, यूज़र को कितनी रगड़ देते हैं, कितने में पड़ते हैं और क्या माँगते हैं।

ज़्यादातर भुगतान और वेंडर प्रवाहों के लिए name match के साथ penny drop संतुलित डिफ़ॉल्ट है। जब जोखिम क़ब्ज़े या नक़ल का हो तो और मज़बूत तरीक़ा लीजिए, और जब आपकी नीति या पार्टनर बैंक माँगे तो दस्तावेज़। ये तरीक़े एक-दूसरे के पूरक हैं। रद्द चेक की तस्वीर और मिलता penny drop दोनों अकेले से ज़्यादा बताते हैं।

भुगतान प्रवाह में verification कहाँ बैठे

उस क्षण रखिए जब कोई खाता भुगतान का ठिकाना बनता है, और जब भी वह बदले।

1. ऑनबोर्डिंग पर। पहले payee की पहचान verify कीजिए (व्यक्तियों के लिए PAN, कारोबारों के लिए GSTIN और CIN), फिर बैंक खाता verify कीजिए और बैंक का नाम verify किए नाम से मिलाइए।
2. खाता बदलने पर। बदला हुआ बैंक खाता वेंडर और भुगतान प्रणालियों में धोखाधड़ी की क्लासिक घटनाओं में से है। इसे नए payee की तरह सँभालिए: दोबारा verify कीजिए, और नए खाते में पहले भुगतान से पहले रोक या दूसरे अनुमोदन पर विचार कीजिए।
3. तय समय पर, अगर नीति माँगे। खाते बंद और फ़्रीज़ होते हैं। निष्क्रिय payee की बड़े भुगतान से पहले समय-समय पर दोबारा जाँच ऐसे खातों को पकड़ती है जो अब वैध नहीं।
4. बड़े एकबारगी भुगतान से पहले। call की क़ीमत ग़लत जगह गए बड़े भुगतान के सामने छोटी है।

referenceId, utr, फ़ैसला, कारण, स्कोर और समय payee के सामने सहेजिए। क्या रखें और क्या छिपाएँ, यह verification कॉल से क्या लॉग करें में है। बैंक खाता संख्या संवेदनशील है: अपने इंटरफ़ेस में सिर्फ़ आख़िरी चार अंक दिखाइए।

सबूत और विवाद

देर-सबेर कोई payee कहेगा कि आपने ग़लत खाते में भुगतान किया, या कोई पार्टनर बैंक पूछेगा कि आपने उस खाते में भुगतान का फ़ैसला कैसे लिया। verification का रिकॉर्ड आपका जवाब है, और वह तभी काम आता है जब आपने सही टुकड़े रखे हों।

हर verification के लिए रखिए: payee की पहचान, referenceId, utr, call का समय, आख़िरी चार अंकों तक छिपाई खाता संख्या और पूरा IFSC, nameAtBank या उसका hash, स्कोर, status, आपका फ़ैसला और उसके कारण, और हर उस समीक्षक की पहचान जिसने डिफ़ॉल्ट को बदला। referenceId और utr से StampMitra support और बैंक उस ख़ास call का पता लगा सकते हैं। कारणों से आप दिखा सकते हैं कि आंशिक मिलान क्यों मंज़ूर हुआ, और किसने किया।

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

यह जाँच किससे बचाती है और किससे नहीं

अपनी जोखिम टीम से यह साफ़-साफ़ कहिए। verification एक श्रेणी की ग़लतियों और कुछ धोखाधड़ियों को संकरा करता है। वह payee को भरोसेमंद नहीं बनाता।

परखना और live जाना

sandbox में दर्ज टेस्ट वैल्यू हैं: वैध खाते के लिए SANDBOX0000000001 और not valid के लिए SANDBOX9999999999। बाक़ी हर इनपुट का नतीजा स्थिर पर मनमाना होता है, मोटे तौर पर तीन में से दो valid, और हर नाम बनावटी है। ध्यान दीजिए कि ये टेस्ट वैल्यू नौ से अठारह अंक के production format का पालन नहीं करतीं। इनके साथ का request आपके खाते पर validation में ठुकरा दिया जाए, तो इसे दर्ज टेस्ट वैल्यू और format जाँच की बेमेल मानिए और उसके आसपास कोड बनाने की जगह support से पूछिए। sandbox कभी किसी बैंक से संपर्क नहीं करता, इसलिए वह दिखा नहीं सकता कि असली बैंक के नाम असली PAN के नामों से कैसे अलग होते हैं। अपने फ़ैसले के function को ऊपर की तालिका के पैटर्न से बने fixtures पर परखिए, और go-live के बाद असली डेटा से सीमाएँ अंशांकित कीजिए।

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

लागत और क्रम

Bank account verification की अपनी दर है: pay-as-you-go पर ₹4 प्रति call, और प्लान की कीमतें pricing तालिका में। क्योंकि हर call में बैंक transfer शामिल है, विफल या दोहराई गई call वह ख़र्च है जिससे आप बचना चाहते हैं, इसलिए क्रम मायने रखता है। पहले ऑफ़लाइन इनपुट जाँच चलाइए। फिर payee की पहचान verify कीजिए। बैंक endpoint सबसे आख़िर में बुलाइए, और सिर्फ़ उन payee के लिए जो पहले के चरण पास कर चुके हों। पूरे वेंडर प्रवाह में जाँचों का क्रम वेंडर ऑनबोर्डिंग फ़्लो में है।

आम ग़लतियाँ

• penny drop और name match को एक ही जाँच के दो हिस्सों की जगह विकल्प समझ लेना।
• बैंक के नाम की तुलना सिर्फ़ यूज़र के टाइप किए नाम से करना, स्वतंत्र रूप से verify किए नाम से नहीं।
• बैंक के नामों के लिए PAN पर अंशांकित सीमा इस्तेमाल करना, जबकि बैंक के नाम छोटे और ज़्यादा संक्षिप्त होते हैं।
• timeout हुई call को आँख मूँदकर retry करके दो क्रेडिट भेज देना।
• साझा खाते या trade name वाले मामलों को समीक्षा में भेजने की जगह सीधे ठुकरा देना।
• एक नमूने से accountStatus या nameMatchResult के मानों का समूह कोड में बैठा देना।
• payee का बैंक खाता बदलने पर दोबारा verification छोड़ देना।
• logs और स्क्रीन में पूरी खाता संख्या दिखाना।
• पक्का किए बिना ग्राहकों को कोई रक़म बता देना।
• यह मान लेना कि वैध खाता और मिलता नाम भरोसेमंद payee का मतलब है।

आगे क्या करें

quickstart से sandbox key लीजिए, sandbox वैल्यू के साथ endpoint call कीजिए, और bank account reference तथा प्रोडक्ट पेज पढ़िए। फिर मिलान का वह तरीक़ा पढ़िए जिस पर यह गाइड टिकी है: PAN को verify करके नाम कैसे मिलाएँ। पूरे payee प्रवाह के लिए KYC बनाम KYB और वेंडर प्रवाह की गाइड देखिए। सवाल support को भेजिए।

API reference एक नज़र में

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

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