Payout से पहले Bank Account Verification: नियंत्रण और लागत

मुख्य बातें

• तीन मौक़ों पर जाँचिए: किसी खाते में पहले payout से पहले, जब भी खाता बदले, और जब उस पर गया payout लौट आए। जिन जगहों पर अनजाँचे खाते नुक़सान करते हैं, ये तीनों उन्हें ढक लेते हैं।
• call है POST /v1/verify/bank-account, जिसमें accountNumber, ifsc, और बेहतर होगा कि name, साथ में वैकल्पिक phone जाता है। valid, accountStatus, nameAtBank, nameMatchScore और nameMatchResult पढ़िए, और referenceId रखिए।
• अलग-अलग payout-प्रकारों के लिए नाम-मिलान की नीति अलग होनी चाहिए। वेतन का खाता संयुक्त refund-खाते से कम बेमेल सहता है, इसलिए नीति payout-प्रकार के हिसाब से रखिए, सब पर एक-सी नहीं।
• ढाँचे पहले अपनी तरफ़ जाँचिए: IFSC में ग्यारह अक्षर होते हैं जिनके पाँचवें स्थान पर शून्य होता है, और इस endpoint के लिए खाता संख्या नौ से अठारह अंकों की होती है।
• valid: false पूरा, billable जवाब है, त्रुटि नहीं। retry सिर्फ़ 429 और 502 पर।
• bank-account की दर हर plan पर एक-सी है, इसलिए plan फ़ीस इस जाँच को सस्ता नहीं बनाती। plan अपने बाक़ी उपयोग के हिसाब से चुनिए, इस endpoint के हिसाब से नहीं।
• रोको-फिर-छोड़ो वाला डिज़ाइन प्रवेश पर रोकने से सुरक्षित है: payees को ब्योरा सहेजने दीजिए, पर payout सेवा से कहिए कि अनजाँचे खाते को न माने।

अनजाँचे खाते में भुगतान करने पर क्या बिगड़ता है

payout की ज़्यादातर हानि और सपोर्ट का बोझ पाँच तरह की गड़बड़ियों से आता है।

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

ग़लत IFSC। खाता संख्या सही है पर शाखा का कोड नहीं, इसलिए भुगतान विफल होता है या अनपेक्षित जगह पहुँचता है।

बंद या फ़्रीज़ खाते। payee के साइन-अप के समय खाता वैध था और अब नहीं है। payouts लौटते हैं और payee आपको दोष देता है।

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

खाते की अदला-बदली। किसी असली payee के खाते का ब्योरा हड़पे गए login या धोखे के अनुरोध से किसी बड़े settlement से ठीक पहले बदल दिया जाता है।

बैंक-खाते की जाँच इन पाँचों को प्रविष्टि के क्षण पर सँभालती है, और नीचे के खाता-बदलाव वाले नियम आख़िरी को ख़ास तौर पर।

endpoint क्या लौटाता है, field-दर-field

bank-account verification का दस्तावेज़ में दर्ज response नमूना मानों के साथ ऐसा दिखता है:

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

तीन व्यावहारिक बातें। पहली, नकारात्मक नतीजों का response दस्तावेज़ में सिर्फ़ उसी valid flag और referenceId के रूप में दर्ज है, इसलिए रक्षात्मक कोड लिखिए जो यह न माने कि हर field मौजूद है। दूसरी, इनपुट name वैकल्पिक है, पर उसके बिना आपके पास नाम-मिलान का नतीजा नहीं रहता, जो payouts के लिए जाँच का सबसे क़ीमती हिस्सा है। हमेशा payee का कानूनी नाम भेजिए। तीसरी, खाताधारक के दस अंकों के भारतीय मोबाइल नंबर के लिए वैकल्पिक phone field है, जो दस्तावेज़ के अनुसार उपलब्ध होने पर मिलान का भरोसा बढ़ाता है।

payout की कड़ी में जाँच कहाँ रखें

कड़ी में नियंत्रण के उतने बिंदु होते हैं जितने ज़्यादातर टीमें इस्तेमाल नहीं करतीं। तालिका उन पाँच को गिनाती है जो बनाने लायक़ हैं, उस क्रम में कि कितनी हानि रोकते हैं।

सिर्फ़ एक बना सकें तो पहला बनाइए। दो बना सकें तो दूसरा जोड़िए, क्योंकि धोखेबाज़ों का पसंदीदा रास्ता खाते का बदलाव है।

प्रक्रिया, कदम-दर-कदम

1. ज़रूरत के क्षण पर खाता लीजिए। खाता संख्या, IFSC और खाताधारक का नाम तब माँगिए जब payee का पैसा इंतज़ार में हो या होने वाला हो। साफ़ लिखिए कि खाता payee के अपने नाम का होना चाहिए। फ़ैसला: अभी कुछ चुकाया नहीं गया, खाता "असत्यापित" सहेजा जाता है।
2. normalise करके अपनी तरफ़ पहले जाँचिए। खाली जगहें हटाइए, IFSC को upper-case कीजिए, देखिए कि IFSC ग्यारह अक्षर का है और पाँचवें स्थान पर शून्य है, और खाता संख्या नौ से अठारह अंकों की है। फ़ैसला: payee से सुधरवाइए, या आगे बढ़िए।
3. अपने डेटा में duplicate देखिए। अपनी payee तालिका में खाता संख्या और IFSC का keyed hash खोजिए। फ़ैसला: खाता पहले से किसी और payee का हो तो भुगतान से पहले समीक्षा में भेजिए।
4. endpoint बुलाइए। accountNumber, ifsc, name और चाहें तो phone के साथ POST /v1/verify/bank-account। नीचे फ़ैसले का ढाँचा।
5. response पढ़िए। valid: false: रोकिए और दूसरा खाता माँगिए। valid: true और मज़बूत score: सत्यापित चिह्नित कीजिए। बीच का score: समीक्षा। कमज़ोर score: रोकिए।
6. payee को दिखाइए कि आपको क्या मिला। बैंक के नाम की जगह IFSC ब्योरे से बैंक और शाखा दिखाइए, और payee को पुष्टि करने दीजिए। फ़ैसला: payee पुष्टि करे या सुधारे।
7. छोड़िए या रोकिए। payout सेवा सत्यापित स्थिति और ठंडक-अवधि देखकर छोड़ती या रोकती है। फ़ैसला: यह जाँच payout सेवा में रहे, ऐप में नहीं।
8. भुगतान कीजिए और वापसी पर नज़र रखिए। payout लौटे तो खाते को "विफल" चिह्नित कीजिए, payee से ब्योरा दोबारा पक्का करवाइए और फिर भुगतान करने से पहले दोबारा जाँचिए।
9. सबूत दर्ज कीजिए। referenceId, समय, मुख्य fields, आपका फ़ैसला और नियम का संस्करण।

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","phone":"9876543210"}'

कोड में payout का द्वार

नीचे का Node function response को payout-प्रकार के हिसाब से सीमाओं के साथ payout के फ़ैसले में बदलता है। संख्याएँ जगह-भराई हैं जिन्हें आप ट्यून करें।

const POLICY = {
  salary: { release: 90, review: 70 },
  vendor: { release: 90, review: 65 },
  refund: { release: 80, review: 55 },
  claim: { release: 92, review: 75 },
  creator: { release: 85, review: 60 },
};

export async function decidePayoutAccount({ payoutType, accountNumber, ifsc, legalName, phone }) {
  const res = await fetch("https://api-b2b.stampmitra.in/v1/verify/bank-account", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.STAMPMITRA_API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ accountNumber, ifsc, name: legalName, ...(phone ? { phone } : {}) }),
  });
  if (res.status === 429 || res.status === 502) return { action: "retry_later", status: res.status };
  if (res.status === 402) return { action: "ops_alert", reason: "wallet" };
  const body = await res.json();
  if (!res.ok) return { action: "fix_input", requestId: body.error?.requestId };
  if (!body.valid) return { action: "hold", reason: "account_not_valid", ref: body.referenceId };

  const p = POLICY[payoutType] ?? POLICY.salary;
  const score = Number(body.nameMatchScore);
  if (Number.isNaN(score)) return { action: "review", reason: "no_score", ref: body.referenceId };
  if (score >= p.release) return { action: "release", ref: body.referenceId };
  if (score >= p.review) return { action: "review", reason: "name_partial", ref: body.referenceId };
  return { action: "hold", reason: "name_mismatch", ref: body.referenceId };
}

payout-प्रकार के हिसाब से नाम-मिलान की नीति

सब पर एक सीमा सबसे आम ग़लती है। सही सहनशीलता इस पर निर्भर है कि किसे भुगतान हो रहा है, कितना, और खाता ग़लत हुआ तो क्या होगा।

ये शुरुआती बिंदु हैं। पहले महीने के बाद अपना बेमेल-डेटा देखिए और सुधारिए, और हर payout के समय लागू सीमाओं का रिकॉर्ड रखिए।

जो नाम अलग दिखते हैं पर अलग नहीं हैं

बैंक खाते नाम को कई रूपों में दिखाते हैं: आद्याक्षर के साथ, अलग क्रम में, उपाधि के साथ, संक्षिप्त, या बैंक की प्रणाली के काटे हुए। कारोबारी खाते पर पंजीकृत नाम, व्यापारिक नाम या दोनों हो सकते हैं। संयुक्त खाते में कई धारक होते हैं। नाबालिग के खाते में अभिभावक होता है। किसी महिला के खाते में शादी से पहले या बाद का नाम हो सकता है।

endpoint का score आम भिन्नता सँभालता है, और आपका समीक्षा-दायरा बाक़ी। समीक्षकों को आपका दिया नाम, बैंक का नाम और score साथ-साथ दिखाइए, स्वीकार्य कारणों की छोटी सूची दीजिए ("आद्याक्षर", "क्रम", "विवाह के बाद का नाम", "पंजीकृत फ़र्म का व्यापारिक नाम", "संयुक्त खाता जिसमें payee पहला धारक है"), और एक खुला text field। कारण दर्ज कीजिए। कोई कारण बार-बार दिखे तो वह नियम बनाने का उम्मीदवार है।

payee से कभी यह मत कहिए कि वह अपने सिस्टम का नाम बैंक के नाम के हिसाब से बदलकर "मिला" दे, बिना समीक्षा किए कि फ़र्क़ क्यों है। इससे नियंत्रण औपचारिकता बन जाता है।

payee सूची की थोक में पहले से जाँच

कई टीमें इस endpoint से एक spreadsheet के रास्ते मिलती हैं: payout-रन के लिए दस हज़ार payees अपलोड। इसे ऐसा batch job मानिए जिसमें rate limits, लागत और दोबारा शुरू हो सकना ध्यान में हों।

पहले ढाँचे जाँचिए और ग़लत पंक्तियों को बिना call के लौटाइए। पंक्तियों को normalise किए खाते और IFSC से deduplicate कीजिए ताकि एक ही खाता एक बार जाँचा जाए। batch का क्रम ऐसा रखिए कि सबसे ऊँचे मूल्य के payouts पहले जाँचे जाएँ। अपने plan की rate limit के भीतर छोटा worker pool चलाइए (दस्तावेज़ में दर्ज error का उदाहरण 60 सेकंड में 60 requests है, अपनी सीमा dashboard और pricing पेज से पढ़िए)। हर नतीजा payee और खाते की कुंजी पर तालिका में लिखिए ताकि restart में जो हो चुका वह छूट जाए, और 402 wallet error पर retry करने की जगह batch रोक दीजिए।

import os
import time
import requests

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

def verify_row(row: dict) -> dict:
    for attempt in range(4):
        r = requests.post(
            f"{BASE}/v1/verify/bank-account",
            headers=HEADERS,
            json={"accountNumber": row["account"], "ifsc": row["ifsc"], "name": row["name"]},
            timeout=20,
        )
        if r.status_code in (429, 502):
            time.sleep(2 ** attempt + 0.3)
            continue
        if r.status_code == 402:
            raise RuntimeError("wallet empty: stop the batch")
        return {"status": r.status_code, "body": r.json()}
    return {"status": 0, "body": {}}

def run_batch(rows, done: set, save):
    for row in rows:
        key = f"{row['account']}|{row['ifsc']}"
        if key in done:
            continue
        save(key, verify_row(row))
        done.add(key)
        time.sleep(1.1)  # प्रति-मिनट की सीमा के भीतर रहने के लिए

खाता-बदलाव और सुप्त payees

payout के जीवन-चक्र में सबसे जोखिम वाली घटना खाते का बदलाव है, क्योंकि धोखेबाज़ को ठीक वही चाहिए। हर बदलाव को पहले payout की तरह मानिए, कुछ अतिरिक्त नियमों के साथ। payee के कानूनी नाम से नया खाता जाँचिए। ताज़ा login माँगिए और, जहाँ हो, payee के सत्यापित मोबाइल पर दूसरा कारक। सूचना पुराने संपर्क-ब्योरे पर भी भेजिए, नए पर भी, ताकि असली payee को वह बदलाव दिखे जो उसने किया ही नहीं। नए खाते में पहले payout से पहले ठंडक-अवधि रखिए, और बड़े payees के लिए उसे लंबा कीजिए। पुराना खाता निष्क्रिय चिह्नित करके रिकॉर्ड में रखिए ताकि जाँच में क्रम दिखे।

सुप्त payees उसी जोखिम का शांत रूप हैं। जिस payee को लंबे समय से भुगतान नहीं हुआ और जो अचानक ब्योरा बदले या payout माँगे, उसकी दोबारा जाँच बनती है, क्योंकि रखा हुआ खाता बंद हो चुका हो सकता है, और क्योंकि सुप्त प्रोफ़ाइलें क़ब्ज़े का निशाना होती हैं।

जब payout लौट आए

लौटे हुए payouts जानकारी हैं। आम कारण हैं ग़लत खाता संख्या, बंद खाता, प्राप्त करने वाले बैंक की नाम-पाबंदी, या IFSC का मेल न खाना। payout लौटे तो खाते को विफल चिह्नित कीजिए, उस पर आगे के payouts रोकिए, payee को बताइए कि क्या करना है, और फिर भुगतान से पहले सुधरे या बदले खाते को दोबारा जाँचिए। आँख मूँदकर दोबारा मत भेजिए: बार-बार की विफल कोशिशें पैसा और भरोसा खाती हैं, और खाते पर क़ब्ज़े का संकेत भी हो सकती हैं। वापसी का कारण सत्यापन के सबूत के साथ दर्ज कीजिए ताकि पैटर्न दिखें, जैसे कोई एक बैंक या चैनल आपकी ज़्यादातर वापसियाँ पैदा कर रहा हो।

कारोबारी, संयुक्त और तीसरे पक्ष के खाते

हर payee निजी बचत खाते वाला व्यक्ति नहीं होता, और नीति में लिखा होना चाहिए कि बाक़ियों का क्या करते हैं।

कारोबारी payees के खाते का नाम आम तौर पर फ़र्म या कंपनी का पंजीकृत नाम होता है, और कभी व्यापारिक नाम। बैंक जाँच को संस्था की registry जाँच के साथ जोड़िए, ताकि बैंक का नाम उस कानूनी नाम से मिले जिसे आप पहले ही सत्यापित कर चुके हैं। यह जोड़ी vendor onboarding पेज में बताई है। कंपनी-payee का निजी खाता चेतावनी है, जब तक दर्ज कारण न हो, जैसे ऐसा एकल प्रोप्राइटर जिसका खाता उसके अपने नाम में है।

संयुक्त खातों में बैंक का नाम एक से ज़्यादा धारक गिनाता है, और किसी एक नाम से score मध्यम आ सकता है। नीति में तय कीजिए कि payee धारक हो तो संयुक्त खाता स्वीकार करेंगे या नहीं, और समीक्षक को कौन-सा सबूत चाहिए। जो भी तय करें, उसे एक-सा लागू कीजिए और कारण payee के रिकॉर्ड पर लिखिए।

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

नाबालिग और अभिभावक के मामले में खाता अभिभावक या संयुक्त नाम में हो सकता है। आपकी नीति बताए कि कौन-से दस्तावेज़ चाहिए और कानूनी payee कौन है।

payment प्रदाता, payee के संदेश और audit के सवाल

आपके payment प्रदाता का काम और यह जाँच क्या जोड़ती है

आपके payment प्रदाता या बैंक के अपने नियंत्रण हैं, और उनमें से कुछ भुगतान के समय खाते का ब्योरा जाँचते हैं। यह verification उन नियंत्रणों की जगह नहीं लेती और उनकी नक़ल भी नहीं है। यह तीन चीज़ें जोड़ती है जो अकेली payment-रेल से मिलनी कठिन हैं।

पहली समय है। आपको खाता ग़लत होने की ख़बर तब मिलती है जब payee उसे डालता है, दिनों बाद payout लौटने पर नहीं। दूसरी नाम का मिलान है। भुगतान ऐसे खाते में सफल हो सकता है जिसका धारक वह नहीं जिसे आप देना चाहते थे, और मिलान पैसा हिलने से पहले आपको संकेत देता है। तीसरी सबूत है। आपके पास हर खाते का transaction id और फ़ैसले का रिकॉर्ड है, जो आप ऑडिटर को या रोक पर आपत्ति करने वाले payee को दिखा सकते हैं।

यह आपकी लागत की तस्वीर भी बदलता है। विफल और लौटे payouts में सँभालने का समय, संवाद और कभी-कभी शुल्क लगता है। ग़लत खाते को प्रविष्टि पर पकड़ना वापसी पर पकड़ने से सस्ता है, हालाँकि हमारे पास बताने लायक़ उद्योग-आँकड़ा नहीं है और gate से पहले और बाद अपनी वापसी-दर आपको ख़ुद नापनी चाहिए।

payees से ऐसे बात कीजिए कि रोक शिकायत न बने

रोक में फँसे ज़्यादातर payees ईमानदार होते हैं, और आप उन्हें कैसे बताते हैं यह तय करता है कि वह सपोर्ट टिकट बनेगा या नहीं। सीधे शब्दों में बताइए कि आपको क्या चाहिए और क्यों, और अगला कदम साफ़ दीजिए।

अच्छा रोक-संदेश समस्या को मोटे तौर पर बताता है ("हम इस खाते को आपके नाम से नहीं मिला सके"), बताता है कि payee क्या कर सकता है ("खाता संख्या और IFSC जाँचिए, या अपने नाम का खाता जोड़िए"), और बताता है कि आगे क्या होगा ("खाता पक्का होते ही आपका payout छोड़ दिया जाएगा")। उसमें ऐसा संदर्भ होता है जो payee बता सके। उसमें बैंक का नाम, खाते का अस्तित्व या किसी और payee के उसे इस्तेमाल करने की बात नहीं होती।

इंसान के पास जाने से पहले एक self-service दोबारा प्रयास दीजिए, क्योंकि ज़्यादातर बेमेल टाइपिंग की ग़लतियाँ होती हैं। उसके बाद दस्तावेज़ अपलोड का सरल तरीक़ा दीजिए, जैसे रद्द चेक की तस्वीर या बैंक स्टेटमेंट का पन्ना, जिसे समीक्षक मिला सके। payee को बताइए कि समीक्षा में आम तौर पर कितना समय लगता है और वादा निभाइए। payee आपकी कही अवधि से ज़्यादा इंतज़ार करे तो उसे कारण बताइए।

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

audit और finance के सवाल जिनका आपके पास जवाब होना चाहिए

payout-नियंत्रणों की जाँच ऑडिटर, finance प्रमुख और कभी-कभी नियामक करते हैं। साफ़ सबूत-रिकॉर्ड आपको आम सवालों के जवाब जल्दी देने देता है।

आपको कैसे पता कि payout के समय payee का खाता उसी का था? verification का रिकॉर्ड, उसका transaction id, नाम का score और फ़ैसला दिखाइए। कमज़ोर मिलान वाले खाते में payout किसने मंज़ूर किया? समीक्षक, कारण और समय दिखाइए। बदले हुए खाते को तुरंत बड़ा भुगतान जाने से कैसे रोकते हैं? ठंडक-अवधि का नियम और उसका log दिखाइए। पिछली तिमाही में कितने payouts लौटे और क्यों? कारण के हिसाब से वापसियाँ दिखाइए, और उनमें वे कितने थे जिनका उस समय कोई सत्यापन नहीं था। verification सेवा के ठप होने पर क्या होता है? fail-closed का नियम और रुकी हुई queue दिखाइए।

सबूत को पहले दिन से export होने वाली रिपोर्ट की तरह बनाइए। पहला ऑडिटर पूछे तब रिपोर्ट तय करना, logs से उसे दोबारा बनाने से कहीं आसान है।

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

payout डेस्क की पाँच स्थितियाँ

ये काल्पनिक मामले हैं।

पहला payout

एक seller अपने पहले order की डिलीवरी वाले दिन खाता जोड़ता है। ढाँचे की जाँचें पास होती हैं, endpoint नाम के मज़बूत मिलान के साथ वैध खाता लौटाता है, और प्लेटफ़ॉर्म की सामान्य रोक-अवधि के बाद payout छूट जाता है।

रिश्तेदार का खाता

एक डिलीवरी पार्टनर अपने जीवनसाथी का खाता डालता है। नाम का score कम है। gig पार्टनरों के लिए प्लेटफ़ॉर्म की नीति दर्ज संयुक्त-खाता अपवाद की इजाज़त देती है। समीक्षक दोनों धारकों वाला बैंक स्टेटमेंट पन्ना माँगता है, कारण दर्ज करता है और मंज़ूर कर देता है। फ़ैसला और दस्तावेज़ payee के रिकॉर्ड से जुड़ते हैं।

बदला हुआ खाता

लंबे इतिहास वाला seller किसी बड़े settlement की पिछली शाम payout-खाता बदल देता है। नया खाता वैध पाया जाता है पर बैंक पर नाम किसी और व्यक्ति का है। बदलाव रुक जाता है, settlement पुराने सत्यापित खाते में जाता है, seller को उसके सत्यापित मोबाइल पर सूचना मिलती है, और मामला जोखिम queue में जाता है।

लौटा हुआ वेतन

वेतन का एक credit "खाता बंद" कारण से लौटता है। payroll प्रणाली खाते को विफल चिह्नित करती है और HR portal से कर्मचारी से नया खाता माँगती है। नया खाता अगले रन से पहले जाँचा जाता है, और सुधार-रन में कर्मचारी को भुगतान होता है। विफल खाते में दूसरी बार कोई भुगतान नहीं गया।

थोक refund का रन

एक खुदरा विक्रेता किसी वापस मँगाए गए उत्पाद के थोक refund से पहले 8,000 refund-payees की पहले से जाँच करता है। batch 300 ग़लत पंक्तियों को बिना call के गिरा देता है, 150 दोहराव हटा देता है, और बाक़ी को नापी हुई रफ़्तार से जाँचता है। कुछ सौ समीक्षा में जाते हैं और बाक़ी छूट जाते हैं। रन जाँचे, रोके और लौटे हुए की गिनती के मिलान के साथ पूरा होता है।

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

ये सुझाव हैं जिन्हें आपकी नीति ढाले।

• अनजाँचे खाते में पहला payout नहीं। द्वार payout सेवा में रहे।
• payout-प्रकार के हिसाब से नीति। हर प्रकार की सीमाएँ, संस्करण के साथ दर्ज।
• हर बदलाव पर रोक, फिर ठंडक। नया खाता जाँचिए, पुराने और नए संपर्कों को सूचना दीजिए, पहले payout से पहले रुकिए।
• मूल्य-सीमाएँ। सीमा से ऊपर दूसरा मंज़ूरीकर्ता और भुगतान से ठीक पहले नई जाँच।
• विफल call पर अपने-आप भुगतान नहीं। timeout पास नहीं है।
• duplicate की पहचान। एक से ज़्यादा payees पर एक ही खाता समीक्षा में जाए।
• समीक्षा के कारण लिखे जाएँ। समीक्षक छोटी सूची से कारण चुनें और चाहें तो text जोड़ें।
• वापसी पर कार्रवाई। लौटा हुआ payout खाते को तब तक फ़्रीज़ करे जब तक दोबारा जाँच न हो।

टीम का ढाँचा

ज़्यादातर ज़रूरतें दो queue से पूरी होती हैं। payout-समीक्षा queue में आंशिक और कमज़ोर नाम-मिलान, खाता-बदलाव और duplicate हैं, जिसे payout operations के विश्लेषक सँभालते हैं और एक नामित वरिष्ठ मंज़ूरीकर्ता रहता है। platform queue में विफल calls, wallet अलर्ट और batch के रुकने की घटनाएँ हैं, जो इंजीनियरिंग या on-call ऑपरेटर की है। लक्ष्य payees की उम्मीद से मेल खाते रखिए: पैसे का इंतज़ार करते payees उसी दिन जवाब चाहते हैं, इसलिए समीक्षा के मामले घंटों में नापे जाएँ और सबसे पुराना मामला पूरी टीम को दिखे। नियम बेहतर होते रहें इसके लिए हर हफ़्ते बेमेल के कारणों और वापसियों की समीक्षा कीजिए।

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

हर verification के लिए referenceId, समय, मुख्य response fields (valid flag, खाता-स्थिति, score, नतीजा), फ़ैसला, नियम का संस्करण, समीक्षक और कारण रखिए। खाता संख्याएँ एन्क्रिप्टेड fields में पहुँच-नियंत्रण के साथ रखिए, ढककर दिखाइए, और logs से बाहर रखिए। duplicate की पहचान के लिए कच्चे मानों की जगह खाते और IFSC का keyed hash इस्तेमाल कीजिए। बैंक पर का नाम निजी डेटा है: उसे सबूत-भंडार में उन्हीं नियंत्रणों के साथ रखिए और सिर्फ़ समीक्षकों को दिखाइए।

अवधि भुगतान और लेखा नियमों, कर कानून, आपके अनुबंधों, आप नियंत्रित संस्था हों तो नियामक की ज़रूरतों, और व्यक्तिगत payees के लिए डेटा-सुरक्षा कानून पर निर्भर है। आँकड़े हम नहीं दे सकते। अपने सलाहकार से पूछिए, schedule में लिखिए और मिटाना स्वचालित कीजिए। StampMitra का डेटा-संचालन उसके retention और deletion schedule और data processing addendum में है। आप GET /v1/logs से अपने खाते के request logs और GET /v1/usage/summary से उपयोग के योग भी देख सकते हैं, logs का रखाव plan पर निर्भर है और ब्योरा pricing पेज पर है।

लागत: हर जाँच पर एक-सी दर, तीन मात्राएँ

bank-account जाँच pay as you go, Growth और Scale तीनों पर ₹4 प्रति call है। सभी राशियाँ 18 प्रतिशत GST से पहले की हैं। इसका एक असामान्य नतीजा है जिसे सीधे कहना ठीक रहेगा: दर plan के साथ घटती नहीं, इसलिए plan फ़ीस इस endpoint को कभी सस्ता नहीं बनाती। अकेली bank जाँचें चलाने के लिए pay as you go सबसे सस्ता है। Growth और Scale तभी सार्थक हैं जब आप standard calls (PAN, GSTIN आदि) भी चलाते हैं जो सस्ती होती हैं, या आपको ऊँची rate limits, लंबा log-रखाव और दूसरी plan-सुविधाएँ चाहिए।

एक जाँच की लागत:

और यही जाँच payee के PAN verification के साथ, जैसे बहुत-से payout-प्रवाह दोनों को जोड़ते हैं:

तीन मात्राओं के नए जाँचे payees का मासिक चित्र। महीने में 1,000 payees पर, सिर्फ़ bank जाँचें:

महीने में 10,000 payees पर:

महीने में 1,00,000 payees पर, बहुत बड़ा प्लेटफ़ॉर्म:

अब मान लीजिए महीने के 10,000 payees में 3,000 PAN जाँचें भी शामिल हैं, शायद उन payee-प्रकारों के लिए जहाँ आपकी नीति खाते के साथ पहचान भी माँगती है। standard calls plan की तुलना बदल देती हैं:

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

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

Sandbox। द्वार, समीक्षा queue और batch job sandbox keys पर बनाइए, जहाँ responses नमूना डेटा हैं और wallet नहीं कटता। bank-account endpoint के लिए sandbox responder के दर्ज test values वैध और अवैध नतीजे देते हैं, पर test लिखने से पहले dashboard में ताज़ा मान देख लीजिए, क्योंकि live validator में खाता संख्या नौ से अठारह अंकों की होती है और आपको देखना चाहिए कि कौन-से sandbox मान उसे पार करते हैं। बाक़ी किसी इनपुट पर स्थिर पर मनमाना नतीजा आता है, इसलिए उस पर assertion मत लगाइए। फ़ैसला-तालिका की हर पंक्ति, ठंडक-अवधि के नियम, duplicate नीति, batch के restart और 402, 429, 502 के रास्तों का test कीजिए।

Pilot। production access माँगिए, जिसके लिए आपके संगठन की KYC मंज़ूरी और product-वार आवेदन चाहिए। एक payout-प्रकार, जैसे एक शहर के seller payouts, को द्वार पर ले जाइए जबकि पुरानी प्रक्रिया कुछ हफ़्ते साथ-साथ चलती रहे। नतीजे और वापसियाँ मिलाइए।

Production। payout-प्रकार के हिसाब से बढ़ाइए, सबसे सख़्त पहले। wallet balance ख़त्म होने से बहुत पहले अलर्ट रखिए, नीचे के मापदंड देखिए, और scopes व IP allowlist के लिए sandbox बनाम production keys गाइड हाथ में रखिए।

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

• पहले payout से पहले सत्यापित payees का हिस्सा, जो लगभग सबका होना चाहिए।
• payout-प्रकार के हिसाब से समीक्षा-दायरे की दर और सबसे पुराने समीक्षा-मामले की उम्र।
• रोक की दर और उनमें से जो बाद में छोड़ी गईं।
• प्रति हज़ार लौटे payouts, द्वार से पहले और बाद। यही संख्या द्वार के काम करने को दिखाती है।
• प्रति हज़ार payees खाता-बदलाव, और उनमें ठंडक-अवधि के लिए रोके गए का हिस्सा।
• duplicate-खाता के मिलान और उनके नतीजे।
• प्रति payee calls। एक सत्यापित खाते पर एक से ज़्यादा हों तो retries या cache की कमी है।
• खाता डालने से छोड़ने तक का समय।

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

• नाम के बिना जाँचना। name के बिना नाम-मिलान नहीं होता, जो मुख्य मूल्य है।
• सब payout-प्रकारों पर एक सीमा। प्रकार के हिसाब से ट्यून कीजिए।
• payout पर नहीं, प्रवेश पर रोकना। द्वार payout सेवा में लगाइए।
• खाता-बदलाव की जाँच छोड़ना। धोखा वहीं रहता है।
• payees को बैंक पर का नाम दिखाना। इससे दूसरों की जानकारी खुलती है।
• valid: false पर retry। वही जवाब, फिर बिल।
• timeout को पास मानना। बंद दरवाज़े से चलिए।
• नतीजे cache न करना। एक ही खाता अवधि में एक बार जाँचिए।
• पूरी खाता संख्याएँ logs में लिखना। उन्हें ढकिए और logs से बाहर रखिए।
• बिना दोबारा जाँचे लौटे payouts फिर भेजना। इससे वही विफलता दोहराई जाती है।

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

यहाँ इस्तेमाल हुआ endpoint bank account verification reference में दर्ज है, जो verification API reference का हिस्सा है। संबंधित पढ़ाई के लिए disbursal के मामले के लिए NBFC लोन origination पेज, सप्लायर भुगतान के लिए vendor onboarding पेज, seller payouts के लिए marketplace seller verification पेज, वेतन के खातों के लिए कर्मचारी background verification पेज, PAN verification गाइड और errors गाइड देखिए। सारे उद्योग-वार पेज solutions पेज पर हैं, और इस जाँच के साथ अक्सर चलने वाली पहचान-जाँच का PAN endpoint reference देखिए। मौजूदा दरें pricing पेज पर हैं।

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

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

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