Property Manager और ब्रोकरेज के लिए किरायानामा e-Stamping

मुख्य बातें

• क़रारों को नाम वाले चरणों की pipeline मानिए, "नवीनीकरण बाक़ी" से "दस्तावेज़ पहुँचा" तक। हर चरण का एक मालिक, एक API call, एक विफलता-रूप और एक मापदंड होता है।
• भारत में आवासीय किरायेदारी के क़रार आम तौर पर ग्यारह महीने के होते हैं, इसलिए N फ़्लैटों के पोर्टफ़ोलियो में लगभग N भाग ग्यारह नवीनीकरण हर महीने बनते हैं। इसी से अपना काम, wallet और टीम का आकार आँकिए।
• शुल्क, article संख्या या राज्य के नियम कभी कोड में मत लिखिए। हर बार lookup और calculation endpoints से पूछिए, और किसी राज्य को चालू करने से पहले वहाँ की प्रक्रिया पर सलाहकार की मंज़ूरी लीजिए।
• शर्तें अंतिम होने और पक्षों के सत्यापित होने के बाद ही stamp कराइए। जारी stamp पर नाम की ग़लती सुधारना महँगा है, जबकि ऑर्डर से पहले PAN या बैंक की जाँच कुछ रुपये की है।
• order बनाने और payment intents पर Idempotency-Key भेजिए, और अपने डेटाबेस में externalOrderId को अनूठा रखिए, ताकि दोबारा चला batch दूसरा order न बना दे।
• पैसे की तीन परतें हैं: StampMitra की प्रति-order API फ़ीस, राज्य की procurement फ़ीस और वैधानिक stamp duty। आख़िरी दो पर छूट नहीं मिलती और राज्य के हिसाब से बदलती हैं, इसलिए ग्राहक को उन्हें API से बताइए, अपनी बनाई किसी तालिका से नहीं।
• रोज़ मिलान कीजिए: बने orders, पुष्ट payments, पहुँचे दस्तावेज़, wallet की हलचल और उपयोग के योग एक ही कहानी कहें।
• पंजीकरण stamping से अलग कानूनी चरण है। आपकी प्रक्रिया यह नहीं जताए कि सिर्फ़ stamping से किरायेदारी पूरी हो गई।

यह पेज किनके लिए है

चार तरह के संचालकों के सामने यह काम आता है।

Property manager मालिकों के फ़्लैट सँभालते हैं और क़रार को सेवा की तरह करते हैं। उनकी मात्रा अनुमान-योग्य है क्योंकि नवीनीकरण कैलेंडर से चलते हैं, और जोखिम यह कि लैप्स हुआ क़रार मालिक को असुरक्षित छोड़ देता है।

ब्रोकरेज किराये का सौदा बंद करने के साथ नए क़रार बनाती हैं। उनकी मात्रा बाज़ार के साथ चलती है और जोखिम देरी का है: जिस किरायेदार को उसी दिन stamp वाला क़रार नहीं मिला वह कहीं और जा सकता है।

Co-living और managed-stay संचालक अलग-अलग कमरों और बिस्तरों के लिए बहुत-से छोटे क़रार बनाते हैं। उनका जोखिम मात्रा का है, हर संपत्ति पर कई पक्ष और बार-बार बदलाव।

वकील के दफ़्तर और secretarial फ़र्में कई मकान-मालिक ग्राहकों के लिए क़रार तैयार करती हैं। उनका जोखिम सटीकता और पता लगा पाने का है, क्योंकि हर दस्तावेज़ की बाद में जाँच हो सकती है।

चारों को चार चीज़ें चाहिए: रफ़्तार, सटीकता, रिकॉर्ड, और लागत को सही पक्ष पर डालने का तरीक़ा।

नवीनीकरण की फ़ैक्टरी: काम का आकार

इसे चलाने का सबसे आसान तरीक़ा कैलेंडर पर सोचना है। आपके मानक क़रार की अवधि ग्यारह महीने हो तो 1,100 फ़्लैटों का पोर्टफ़ोलियो महीने में लगभग 100 नवीनीकरण बनाता है, 11,000 का लगभग 1,000 और 1,10,000 का लगभग 10,000। नई लेटिंग्स, बीच की तब्दीलियाँ और समय से पहले समाप्ति इनके ऊपर आती हैं।

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

नीचे की तालिका की संख्याएँ लागत वाले खंड में काम आने वाली मान्यता हैं। उन्हें अपनी संख्याओं से बदलिए।

महीने में सैकड़ों करने पर क्या बदलता है

मात्रा बढ़ने पर पाँच बातें बदलती हैं जो अकेले क़रार वाले उत्पाद को कभी दिखती ही नहीं।

पहली यह कि अपवाद हावी हो जाते हैं। बीस में एक क़रार में डेटा की समस्या हो तो एक-बारगी ऐप उसे कभी-कभार देखता है, जबकि 1,000 नवीनीकरण वाला manager महीने में पचास देखता है। आपकी प्रक्रिया को असली अपवाद queue और उसका मालिक चाहिए।

दूसरी यह कि पहचान की जाँच थोक का काम बन जाती है। मालिक बार-बार आने वाले पक्ष हैं, इसलिए उन्हें एक बार जाँचकर उनकी हर संपत्ति के नवीनीकरण पर वही नतीजा इस्तेमाल कीजिए। किरायेदार हर चक्र में नए होते हैं और हर क़रार पर जाँच माँगते हैं।

तीसरी यह कि लागत की दृश्यता मायने रखती है। महीने में दस हज़ार orders पर प्रति-order की छोटी बचत या छूटा हुआ pass-through असली पैसा है।

चौथी यह कि समय एक सेवा-स्तर बन जाता है। stamp वाला दस्तावेज़ दो दिन देर से पहुँचाना टूटा हुआ वादा है, इसलिए pipeline में घड़ियाँ चाहिए।

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

pipeline, चरण-दर-चरण

काम की pipeline के चरण छोटे, देखे जा सकने वाले और मालिक वाले होते हैं। तालिका एक ठीक-ठाक सेट और हर चरण को चलाने वाला API call दिखाती है।

चरण को क़रार के रिकॉर्ड का एक field रखिए और हर बदलाव समय के साथ दर्ज कीजिए। घड़ियाँ और मापदंड उन्हीं समय-मुहरों से चलते हैं।

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

1. नवीनीकरण पहले से तैयार कीजिए। एक निर्धारित job आने वाले हफ़्तों में समाप्त हो रहे क़रार चुनकर pipeline रिकॉर्ड बनाती है। फ़ैसला: हर समाप्ति के लिए रिकॉर्ड हो, कोई छूटे नहीं।
2. पक्षों से शर्तें पक्की कीजिए। किराया, जमानत, अवधि, शुरू होने की तारीख़ और संपत्ति का पता। फ़ैसला: शर्तें अंतिम हैं या नहीं। जिस मसौदे पर अभी मोल-भाव चल रहा हो उस पर भाव की ओर मत बढ़िए।
3. मालिक को एक बार जाँचिए। मालिक के PAN और कानूनी नाम के साथ POST /v1/verify/pan, और मालिक को किराया या जमानत की वापसी transfer से मिलनी हो तो खाते और नाम के साथ POST /v1/verify/bank-account। नतीजे मालिक के नाम पर रखिए, क़रार के नहीं। फ़ैसला: मालिक की स्थिति वैध, समीक्षा या रोक।
4. इस क़रार के लिए किरायेदार को जाँचिए। वही PAN जाँच, और जमानत उस खाते में लौटानी हो जो आप अभी ले रहे हैं तो बैंक जाँच भी। फ़ैसला: मालिक की तरह।
5. राज्य, instrument और article तय कीजिए। lookup endpoints से, अपनी तालिका से नहीं। फ़ैसला: article उस नियम से चुना जाए जिसे आपके सलाहकार ने राज्य के लिए मंज़ूर किया, या किसी इंसान से।
6. गणना कीजिए। stateCode, articleCode और stampDutyAmount के साथ POST /v1/estamp/duty/calculate, और जहाँ राज्य माँगे वहाँ district या SRO के मान। फ़ैसला: भुगतानकर्ता को भाव दिखाइए, इनपुट बदलें तो फिर गणना कीजिए।
7. order बनाइए और पक्ष जोड़िए। externalOrderId, externalCustomerId, serviceCode और details के साथ Idempotency-Key लगाकर POST /v1/orders, फिर POST /v1/estamp/orders/:orderId/parties। फ़ैसला: कुछ और होने से पहले order id दर्ज।
8. भुगतान। externalOrderId, amountMinor, currency और paymentConnectionId के साथ POST /v1/payments/intents। फ़ैसला: पुष्ट स्थिति का इंतज़ार कीजिए, browser से कभी "paid" मत चिह्नित कीजिए।
9. नज़र रखिए। backoff के साथ GET /v1/orders/:id/status poll कीजिए, या जहाँ आपके खाते को order events मिलते हों उनका इस्तेमाल। फ़ैसला: पूर्ण, चालू या विफल।
10. दस्तावेज़ लाकर रखिए। GET /v1/orders/:id/documents, फिर download endpoint, और bytes रखिए। फ़ैसला: रखी हुई प्रति ही रिकॉर्ड है, अस्थायी URL कभी नहीं।
11. पहुँचाइए और चरण बंद कीजिए। पक्षों और ग्राहक को भेजिए। दर्ज कीजिए कि किसे क्या कब मिला।

नमूना request और response: order बनाना

order का कदम वह जगह है जहाँ आपके अपने संदर्भ StampMitra के संदर्भों से मिलते हैं। e-Stamp service code के साथ generic order endpoint का दस्तावेज़ में दर्ज request और उसके बाद दर्ज response:

curl -X POST "https://api-b2b.stampmitra.in/v1/orders" \
  -H "Authorization: Bearer $STAMPMITRA_API_KEY" \
  -H "Idempotency-Key: order-RENT-2026-000481-v1" \
  -H "Content-Type: application/json" \
  -d '{
    "externalOrderId": "ord_ext_123",
    "externalCustomerId": "cust_ext_456",
    "serviceCode": "estamp.instrument.rent_agreement",
    "details": { "state": "MH", "stampValue": 500, "note": "Shape not finalized - illustrative only" }
  }'

{
  "externalOrderId": "ord_ext_123",
  "createdAt": "2026-10-15T09:41:07.000Z",
  "serviceCode": "estamp.instrument.rent_agreement"
}

details वाला हिस्सा सावधानी माँगता है: दस्तावेज़ कहते हैं कि e-Stamp के लिए उसका रूप अंतिम नहीं है, इसलिए schema endpoint पढ़िए, mapping एक जगह रखिए और हर release से पहले दोबारा देखिए। ऊपर का नमूना उदाहरण-मात्र है, जैसा उसके भीतर के note में लिखा है।

नीचे का Node function ऐसा renewal batch दिखाता है जो दोबारा शुरू करना सुरक्षित है। यह idempotency key के लिए क़रार के संदर्भ का इस्तेमाल करता है, जिन क़रारों का order पहले से है उन्हें छोड़ देता है, और wallet की त्रुटि पर endpoint पर चोट करते रहने की जगह रुक जाता है।

const BASE = "https://api-b2b.stampmitra.in";
const sleep = (ms) => new Promise((r) => setTimeout(r, ms));

async function createOrder(agreement) {
  const res = await fetch(`${BASE}/v1/orders`, {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.STAMPMITRA_API_KEY}`,
      "Content-Type": "application/json",
      "Idempotency-Key": `order-${agreement.ref}-v1`,
    },
    body: JSON.stringify({
      externalOrderId: agreement.ref,
      externalCustomerId: agreement.ownerId,
      serviceCode: agreement.serviceCode,
      details: agreement.details,
    }),
  });
  return { status: res.status, body: await res.json() };
}

export async function runRenewalBatch(agreements, store) {
  for (const a of agreements) {
    if (await store.hasOrder(a.ref)) continue;
    let out = await createOrder(a);
    for (let attempt = 0; attempt < 3 && (out.status === 429 || out.status === 502); attempt++) {
      await sleep(1000 * 2 ** attempt + Math.random() * 400);
      out = await createOrder(a);
    }
    if (out.status === 402) throw new Error("WALLET_LOW: batch रोकिए और finance को बताइए");
    await store.recordOrderAttempt(a.ref, out);
    await sleep(1100);
  }
}

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

यह तालिका लोगों और order दोनों को कवर करती है, क्योंकि दोनों विफल हो सकते हैं।

एक प्लेटफ़ॉर्म, कई राज्य: राज्य कैसे चालू करें

stamp duty और उससे जुड़े नियम राज्य-स्तर पर तय होते हैं, यानी आपकी pipeline बिना कोड में शाखाएँ बनाए हर राज्य में अलग बर्ताव कर सके। जो तरीक़ा चलता है वह है राज्य-प्रोफ़ाइल, डेटा के रूप में, हर राज्य के लिए एक switch के साथ।

जिस भी राज्य में आप सेवा देते हैं उसके लिए एक प्रोफ़ाइल रखिए जिसमें दर्ज हो: क्या राज्य आपके entitlement के lookup endpoints में है, हर क़रार-प्रकार के लिए आपके सलाहकार ने कौन-से articles मंज़ूर किए, गणना को कौन-से अतिरिक्त इनपुट चाहिए (district, SRO मान, डिलीवरी के विकल्प), पंजीकरण और रिपोर्टिंग पर आप कौन-सा notice दिखाते हैं, और राज्य चालू है या नहीं। राज्य तभी चालू कीजिए जब सलाहकार notice और article-नियम देख चुका हो और उस राज्य का sandbox रन हो चुका हो।

दरें, सीमाएँ या समय-सीमाएँ प्रोफ़ाइल में कॉपी मत कीजिए। जहाँ कोई संख्या मायने रखती है, वहाँ API उसे लौटाती है या राज्य का प्राधिकरण प्रकाशित करता है, और आपकी प्रोफ़ाइल उसी स्रोत की ओर इशारा करती है। प्रोफ़ाइल प्रक्रिया को चलाती है, संख्याओं को कभी नहीं।

पैसा: भुगतानकर्ता से क्या लिया जाता है

e-stamp order में लागत की तीन परतें हैं, और ग्राहक को उन्हें अलग-अलग दिखना चाहिए।

पहली वैधानिक stamp duty है, जो राज्य तय करता है। दूसरी राज्य-वार procurement फ़ीस है, जो production access मंज़ूर होने पर StampMitra बताता है और order लगाने से पहले पूरी राशि बताता है। तीसरी StampMitra की प्रति-order e-Stamp API फ़ीस है, जो आपके plan पर निर्भर है। न duty पर plan से छूट मिलती है न procurement फ़ीस पर। हर plan की API फ़ीस pricing पेज पर दी है।

गणना का API response ही बताता है कि duty और सेवा-शुल्क के रूप में क्या लेना है, और उस राशि को अपनी ओर से दोबारा नहीं निकालना या बदलना है। आप अपनी सेवा-फ़ीस जोड़ें तो उसे अलग पंक्ति में दिखाइए। अपनी फ़ीस को उस राशि में मत मिलाइए जो आप payment intent को देते हैं, जब तक आपका उत्पाद जान-बूझकर वैसे इकट्ठा न करता हो, और पक्का कीजिए कि आपका invoice बँटवारा दिखाए।

भुगतान order के payment intent से होता है, और verification व order की calls आपके fulfilment wallet से चलती हैं। StampMitra के invoices GST invoices हैं, और plan व उपयोग के शुल्क पर 18 प्रतिशत GST लगता है। wallet के अलर्ट उस balance से काफ़ी ऊपर रखिए जो एक दिन के चरम पर चाहिए, और महीने के आख़िरी उछाल से पहले रक़म डालिए।

थोक नवीनीकरण: batch, रफ़्तार और भुगतान

नवीनीकरण देय तारीख़ के हिसाब से batches में चलाइए, workers का pool अपने plan की rate limit के भीतर रखते हुए (दस्तावेज़ में दर्ज error का उदाहरण 60 सेकंड में 60 requests है, अपनी सीमा dashboard और pricing पेज से पढ़िए)। पहले orders बनाइए, फिर payment intents, फिर poll, अलग चरणों में और उनकी अपनी queues के साथ, ताकि धीमा चरण दूसरों को न रोके। retry सिर्फ़ 429 और 502 पर, backoff के साथ। 402 को रुकने का संकेत मानिए और finance को बताइए, क्योंकि बाद की हर call उसी तरह विफल होगी।

भुगतान उस तरह कीजिए जैसे आप ग्राहकों से लेते हैं। ग्राहक पहले से रक़म दे तो हर intent order बनते ही चुकाइए। आप बाद में invoice भेजते हों तो पक्का कीजिए कि wallet और payment connection batch सह सके। हर order पर एक ही payment intent रखिए, और किसी भी timeout के बाद दूसरा बनाने से पहले intent की स्थिति पढ़िए, ताकि दो बार भुगतान न हो।

मिलान: चार स्रोतों से एक कहानी

रोज़ का मिलान और महीने का मिलान चलाइए। रोज़ की जाँच चार चीज़ें मिलाती है: आपके सिस्टम के बने orders बनाम API के जाने हुए orders, पुष्ट payments बनाम भुगतान की प्रतीक्षा वाले orders, रखे गए दस्तावेज़ बनाम पूर्ण हुए orders, और wallet की हलचल बनाम वह जो ख़र्च होना चाहिए। महीने की जाँच उपयोग को invoices से और ग्राहकों से लिए बिल से जोड़ती है।

StampMitra की तरफ़ से GET /v1/usage/summary मौजूदा billing अवधि के उपयोग के योग लौटाता है, service और दिन के हिसाब से calls के साथ, और GET /v1/logs service और status के filters के साथ request logs, cursor से पन्नों में। इन्हें अपने रिकॉर्ड का स्वतंत्र दृश्य मानिए। फ़र्क़ आम तौर पर तीन में से कोई निकलता है: order बना पर कभी चुकाया नहीं गया, ऐसा payment जिसका order आपको मालूम नहीं क्योंकि retry ने duplicate बना दिया, या दस्तावेज़ लाया गया पर कभी रखा नहीं गया। हर एक का इलाज है, और जितनी जल्दी मिले उतना सस्ता पड़ता है।

import os
import requests

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

def api_usage_by_service():
    r = requests.get(f"{BASE}/v1/usage/summary", headers=HEADERS, timeout=20)
    r.raise_for_status()
    return r.json()["callsByService"]

def reconcile(expected_counts: dict[str, int]) -> list[str]:
    actual = api_usage_by_service()
    problems = []
    for service, expected in expected_counts.items():
        got = actual.get(service, 0)
        if got != expected:
            problems.append(f"{service}: ledger says {expected}, API says {got}")
    return problems

जिन अपवादों से आपका सामना होगा

अपवाद queue का ज़्यादातर काम पाँच अपवादों से बनता है।

जारी होने के बाद किसी पक्ष का नाम ग़लत निकला। stamp बन चुका है। क़रार को चुपचाप मत बदलिए। सलाहकार के साथ तय कीजिए कि सुधरा order चाहिए या नहीं, उसे पुराने से जुड़े नए order की तरह बनाइए, और दोनों रिकॉर्ड में रखिए।

ग़लत article चुना गया। यही तरीक़ा, साथ में यह देखना कि नियम ने उसे क्यों चुना। राज्य-प्रोफ़ाइल का नियम ठीक कीजिए।

किरायेदार भुगतान से पहले पीछे हट गया। बिना चुकाया order बस बिना चुकाया पड़ा रहता है, कारण दर्ज कीजिए और pipeline रिकॉर्ड बंद कीजिए। भुगतान के बाद क्या होता है, refunds समेत, यह प्लेटफ़ॉर्म की billing और refund नीतियों और order की स्थिति से तय होता है, billing, API credits और refund policy पढ़िए और अंदाज़ा लगाने की जगह सपोर्ट से पूछिए।

duplicate order मौजूद है। आम तौर पर बिना idempotency key वाला retry। externalOrderId और अपनी अनूठेपन-जाँच से खोजिए, और दूसरा intent चुकाने से पहले requestId के साथ सपोर्ट से संपर्क कीजिए।

प्रमाणपत्र तैयार नहीं है। backoff के साथ poll कीजिए, status response जाँचिए, और अपेक्षित समय से ऊपर अटके रहने पर requestId के साथ सपोर्ट से संपर्क कीजिए।

property manager की मेज़ से पाँच स्थितियाँ

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

नवीनीकरण का महीना

महीने में लगभग हज़ार नवीनीकरण वाला manager उन्हें छह हफ़्ते पहले तैयार करता है। मालिक का PAN और बैंक नतीजे पिछले साल के चक्र से रखे हैं, इसलिए सिर्फ़ किरायेदार की जाँचें चलती हैं। हर क़रार के अंतिम होते ही उसका भाव निकलता है। बीसवीं तक ज़्यादातर के orders बन और चुक चुके होते हैं, बाक़ी कारणों के साथ अपवाद queue में हैं।

PAN पर अलग नाम वाला मालिक

विरासत में फ़्लैट पाने वाले मालिक के PAN पर कानूनी नाम पिछले क़रार के नाम से अलग है। समीक्षा queue क़रार को तब तक रोके रखती है जब तक मालिक नाम-बदलाव समझाने वाला दस्तावेज़ न दे। नया क़रार PAN का कानूनी नाम इस्तेमाल करता है, और मालिक का रिकॉर्ड समीक्षक की टिप्पणी के साथ अपडेट होता है।

कम पड़ता wallet

महीने के आख़िरी दिन एक batch 402 से टकराता है। worker रुक जाता है, finance को अलर्ट मिलता है, wallet में रक़म डलती है, और batch वहीं से चलता है जहाँ रुका था। order बनाने में idempotency keys हैं और batch उन क़रारों को छोड़ता है जिनका order पहले से है, इसलिए कुछ दोहराया नहीं जाता।

नया राज्य

ब्रोकरेज ऐसे राज्य में सेवा शुरू करना चाहती है जो उसने अब तक कवर नहीं किया। राज्य lookups में दिखता है, सलाहकार article-नियम और पंजीकरण-notice मंज़ूर करता है, sandbox रन सफल होता है, और आम इस्तेमाल से पहले कुछ क़रारों के pilot के लिए राज्य चालू किया जाता है।

देर से आता प्रमाणपत्र

एक order अपेक्षा से ज़्यादा देर "चालू" रहता है। pipeline की घड़ी उस पर निशान लगाती है, विश्लेषक status और logs जाँचता है, और requestId के साथ सपोर्ट से संपर्क होता है। किरायेदार को बताया जाता है कि दस्तावेज़ देर से आएगा और नया अपेक्षित समय दिया जाता है, चुप्पी के बजाय।

संपत्ति-संचालक के लिए अपनाने लायक़ समीक्षा-नियम

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

• stamp से पहले सत्यापन। जब तक मालिक और किरायेदार की जाँचें साफ़ या समीक्षित न हों, order नहीं।
• सिर्फ़ कानूनी नाम। क़रार में वह नाम जो PAN पर सत्यापित है, कोई उपनाम अलग से लिखा जाए।
• मसौदों पर order नहीं। शर्तें अंतिम हों और दोनों पक्षों ने मानी हों।
• राज्य-वार सलाहकार-मंज़ूर articles। जहाँ नियम तय नहीं, article कोई इंसान चुने।
• दूसरा मंज़ूरीकर्ता सुधरे orders के लिए और उस हर order के लिए जिसका मूल्य आपकी तय सीमा से ऊपर हो।
• wallet की न्यूनतम सीमा। एक दिन के चरम को ढकने वाले balance पर अलर्ट, और उससे नीचे की सीमा पर batches के लिए पक्की रोक।
• key के बिना हाथ से retry नहीं। हाथ से दोबारा भेजने में भी वही idempotency key।
• पंजीकरण-notice दर्ज। उपयोगकर्ता अपने राज्य का notice देखे और माने।

टीम का ढाँचा

काम तीन queue में बाँटिए। pipeline queue में वे क़रार हैं जो पक्षों या भुगतान के इंतज़ार में हैं, जिनके मालिक वे coordinators हैं जो दस्तख़त और रक़म का पीछा करते हैं। समीक्षा queue में पहचान के बेमेल और article के सवाल हैं, जिसके मालिक विश्लेषक हैं, एक नामित वरिष्ठ समीक्षक और सलाहकार तक रास्ते के साथ। platform queue में विफल calls, wallet के अलर्ट और अटके orders हैं, जिसका मालिक इंजीनियरिंग या on-call ऑपरेटर है।

हर चरण को घड़ी दीजिए और साझा स्क्रीन पर हर queue का सबसे पुराना मामला दिखाइए। शुरुआती सुझाव: देय तारीख़ के पास की समीक्षा के मामले उसी कार्य-दिवस में निपटें, और भुगतान से डिलीवरी तक का एक तय समय जिसे आप नापें और ट्यून करें। औसत के लिए नहीं, महीने के चरम के लिए स्टाफ़ रखिए।

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

हर क़रार के लिए अपना संदर्भ, order id, राज्य, article, गणना के इनपुट और मिला हुआ response, जैसे जमा किए गए पक्ष, verification के referenceId, payment का संदर्भ, हर status-बदलाव समय के साथ, checksum समेत दस्तावेज़ की फ़ाइलें, और किसने किसे क्या पहुँचाया, रखिए। प्रमाणपत्र के bytes अपने एन्क्रिप्टेड, पहुँच-नियंत्रित भंडार में रखिए और अपने authenticated endpoint से दिखाइए। अस्थायी download URL पर कभी भरोसा मत कीजिए।

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

लागत: तीन पोर्टफ़ोलियो आकार

StampMitra की API फ़ीस pay as you go पर ₹5 प्रति order है, और Growth व Scale पर कम। verification calls में PAN की ₹5 प्रति call और बैंक खाते की ₹4। सभी राशियाँ 18 प्रतिशत GST से पहले की हैं। इनमें दो चीज़ें शामिल नहीं हैं जो आपको जोड़नी होंगी: वैधानिक stamp duty और राज्य की procurement फ़ीस, जो हर plan पर एक-सी हैं और order से पहले आपको बताई जाती हैं। duty-calculation की calls आपके wallet से मीटर होती हैं, अपने plan पर उनका भाव सपोर्ट से पक्का कीजिए इससे पहले कि आप quote की मात्रा का मॉडल बनाएँ, क्योंकि नीचे की तालिकाओं में वे शामिल नहीं हैं।

पहले प्रति-क़रार दृश्य। एक क़रार जिसमें हर पक्ष पर PAN जाँच, मालिक पर बैंक जाँच और एक order है, और फिर अकेली API फ़ीस एक order की:

अब मासिक मॉडल, पहले के तीन पोर्टफ़ोलियो आकारों के साथ, हर अपेक्षित नवीनीकरण पर महीने में एक order गिनते हुए। मालिक की जाँचें सालों तक दोबारा इस्तेमाल होती हैं, पर मॉडल सरल रखने के लिए हम उन्हें हर बार गिनते हैं, जो लागत को बढ़ाकर दिखाता है। महीने में 100 क़रारों पर: 200 PAN जाँचें, 100 बैंक जाँचें और 100 orders।

महीने में 1,000 क़रारों पर: 2,000 PAN जाँचें, 1,000 बैंक जाँचें और 1,000 orders।

महीने में 10,000 क़रारों पर: 20,000 PAN जाँचें, 10,000 बैंक जाँचें और 10,000 orders।

तालिकाओं को ऐसे पढ़िए: महीने में 100 क़रारों पर pay as you go सबसे सस्ता है क्योंकि plan फ़ीस कम दरों से भारी पड़ती है, 1,000 पर तीनों plans कुछ हज़ार रुपये के भीतर पास-पास आते हैं और इस मॉडल में Growth सबसे सस्ता है, और 10,000 पर Scale सबसे सस्ता है, जहाँ ख़र्च उस बिंदु से ऊपर है जहाँ StampMitra enterprise व्यवस्था का सुझाव देता है, जिसकी बात contact पेज पर होती है। तालिकाएँ मानती हैं कि GST plan फ़ीस पर भी लगता है, invoice से पक्का कीजिए। इन्हीं orders पर लगने वाली stamp duty और procurement फ़ीस के सामने ये योग छोटे हैं, इसलिए plans के बीच का असली फ़ैसला शायद ही कभी अकेली API फ़ीस से होता है। उपयोग सफल response के बाद दर्ज होता है, इसलिए error पर ख़त्म हुई calls का शुल्क नहीं लगता, पर valid: false सफल जवाब है और उसका शुल्क लगता है।

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

Sandbox। pipeline sandbox keys पर बनाइए, जहाँ responses नमूना डेटा हैं और wallet कभी नहीं कटता। services सूची, schema और lookup endpoints से वे असली रूप खोजिए जिन्हें e-Stamp के दस्तावेज़ जगह-भराई बताते हैं। sandbox PAN SNDBX0000A पर वैध और SNDBX9999F पर अवैध नतीजा देता है, और बाक़ी इनपुट पर स्थिर पर मनमाना नतीजा आता है, इसलिए उन पर assertion मत लगाइए। dashboard में ताज़ा test values देखिए। दोबारा-शुरू की सुरक्षा, idempotency, wallet-रोक का बर्ताव, राज्य-प्रोफ़ाइल का switch और फ़ैसला-तालिका की हर पंक्ति का test कीजिए।

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

Production। राज्य और ग्राहक के हिसाब से बढ़ाइए। पहले दिन से रोज़ का मिलान चलाइए। wallet balance पर और हर उस चरण-घड़ी पर अलर्ट रखिए जो अपने लक्ष्य से आगे निकले। keys, scopes और IP allowlist के लिए sandbox बनाम production keys गाइड देखिए।

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

• देय नवीनीकरण, पहले से तैयार नवीनीकरण, और समाप्ति से पहले पहुँचे नवीनीकरण। आख़िरी वही है जिसकी आपके ग्राहकों को परवाह है।
• हर चरण और शुरू से अंत तक का समय, सबसे धीमे दस प्रतिशत की हर हफ़्ते जाँच के साथ।
• कारण के हिसाब से अपवाद queue का आकार, और सबसे पुराने मामले की उम्र।
• सभी orders में सुधारे गए orders का हिस्सा। इससे intake पर डेटा की गुणवत्ता पता चलती है।
• पकड़े गए duplicate orders, जो शून्य होने चाहिए।
• अनुमान के मुक़ाबले wallet का balance, और 402 की घटनाएँ।
• रोज़ के मिलान के फ़र्क़, और हर एक को सुलझाने में कितना समय लगा।
• पहुँचाए गए प्रति क़रार की लागत, लागत की तीनों परतों समेत।

जो ग़लतियाँ संचालकों को चोट पहुँचाती हैं

• शर्तें अंतिम होने से पहले stamp कराना। duty पहले चुकती है, बदलाव का मतलब नए orders।
• हर नवीनीकरण पर मालिक को दोबारा जाँचना। एक बार जाँचिए, दोबारा इस्तेमाल कीजिए, घटनाओं पर फिर जाँचिए।
• duty या article की तालिकाएँ कोड में लिखना। वे बदलती हैं और राज्य-दर-राज्य अलग हैं।
• idempotency keys न रखना। दोबारा चला batch duplicate orders बना देता है।
• download URL को रिकॉर्ड मानकर रखना। वह ख़त्म हो जाता है, bytes रखिए।
• महीने में एक ही बार मिलान। समस्याएँ उसी दिन सबसे सस्ती हैं जिस दिन दिखती हैं।
• ग्राहकों से वादा कि stamping से किरायेदारी पूरी हो जाती है। पंजीकरण और रिपोर्टिंग अलग और राज्य-विशिष्ट हैं।
• अपनी फ़ीस को duty की राशि में मिलाना। भाव और invoice में पंक्तियाँ अलग रखिए।

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

यहाँ इस्तेमाल हुए endpoints e-Stamp API documentation में हैं: duty calculation, orders, parties, payment और documents, साथ में PAN और bank account verification endpoints। और पढ़ने के लिए proptech के लिए किरायानामा use case, e-stamp order flow गाइड, payout से पहले bank account verification, कानूनी और compliance टीमों के लिए verification पेज, errors गाइड और order events के लिए webhooks पेज देखिए। सारे उद्योग-वार पेज solutions पेज पर हैं, और मौजूदा दरें pricing पेज पर।

API reference एक नज़र में

{
  "externalOrderId": "ord_ext_123",
  "createdAt": "2026-10-15T09:41:07.000Z",
  "serviceCode": "estamp.instrument.rent_agreement"
}

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

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