अपना पेमेंट सिस्टम बनाने की 14 परेशानियाँ
(arnon.dk)- पेमेंट और revenue सिस्टम monetization के लिए ज़रूरी हैं, लेकिन ये finance, product, customer support, legal, compliance और sales तक जुड़े हुए जटिल core systems होते हैं, इसलिए छोटी गड़बड़ी भी बड़े operational issue में बदल सकती है
- शुरुआती कंपनियाँ या नए product टीमें अक्सर पेमेंट को सिर्फ एक engineering problem समझकर खुद बनाने लगती हैं, लेकिन असल विकल्प self-build, third-party, और hybrid में बँटे होते हैं
- वास्तविक पेमेंट सिस्टम को idempotency, date handling, usage metering, tax, refund, customer hierarchy, custom contracts, pricing changes, और revenue recognition को एक साथ संभालना पड़ता है
- कुछ समस्याएँ एक बार हल हो जाने पर स्थिर रहती हैं, लेकिन tax rules, customer mistakes, manual corrections, और देश-विशेष invoice requirements growth और global expansion के साथ लगातार बढ़ती जाती हैं
- product के अपने usage updates और customer lifecycle events पर ध्यान देना, और subscription, billing, accounting, तथा revenue recognition को जहाँ तक संभव हो तैयार payment systems और ERP पर छोड़ना ज़्यादा सुरक्षित है
पेमेंट सिर्फ एक साधारण फीचर क्यों नहीं है
- किसी भी business को revenue कमाने के लिए पेमेंट और revenue सिस्टम अनिवार्य होते हैं
- जब सब कुछ ठीक चलता है, तो ये दिखते नहीं हैं, लेकिन वास्तव में ये कई teams और functions को एक साथ छूने वाले octopus जैसे systems हैं
- finance
- product
- user experience
- customer support
- customer
- legal
- compliance
- sales
- अगर एक हिस्सा टूटता है, तो जुड़ी हुई दूसरी जगहों तक समस्या बहुत जल्दी फैल सकती है, और ऐसा अक्सर होता भी है
- अगर revenue को कानूनी और सही तरीके से collect नहीं किया जा रहा, तो business operators के लिए समस्याएँ बहुत बढ़ जाती हैं
बनाने के तीन पैटर्न
- पेमेंट सिस्टम के लिए आमतौर पर तीन तरीके होते हैं
- self-build
- पूरी तरह third-party system
- self-build और third-party को मिलाकर hybrid
- शुरुआती कंपनियाँ या नया product शुरू करने वाली टीमें, क्योंकि उनके पास engineers होते हैं और वे चीज़ों को simple रखना चाहती हैं, इसलिए अक्सर इसे खुद बनाने की ओर झुकती हैं
- अगर पेमेंट को “S3 में billing file डालो, CRON job उसे उठाए और पेमेंट कर दे” जैसी समस्या मान लिया जाए, तो पेमेंट को सिर्फ engineering problem समझने की गलती होती है
- जैसे आप security या date handling को पूरी तरह खुद implement नहीं करते, वैसे ही पेमेंट भी शुरू से पूरा खुद बनाना सही नहीं है
- सबसे अच्छा पेमेंट सिस्टम वही है, जिसे पूरा खुद बनाने की ज़रूरत ही नहीं पड़ी
अपने पेमेंट सिस्टम की 14 परेशानियाँ
-
Idempotency
- हर billing और payment collection request unique और idempotent होनी चाहिए
- API limits की वजह से retry करते समय या payment system instances बढ़ाते समय यह समस्या सामने आती है
- इसे सही तरह न संभाला जाए तो duplicate billing का खतरा होता है
-
Date handling
- यह तय करना पड़ता है कि billing हर 30 दिन में होगी या हर महीने signup date के आधार पर
- leap day, time zone जैसी स्थितियाँ भी साथ में संभालनी पड़ती हैं
-
Proration और remainder
- यह तय करना पड़ता है कि proration सिर्फ upgrade पर लागू होगा या downgrade पर भी
- refund, credit, ignore, या upgrade/downgrade को block करने जैसे विकल्प होते हैं
-
Usage metering
- usage calculate करने के दर्जनों तरीके हो सकते हैं
- यह customer type के हिसाब से अलग हो सकता है या बार-बार बदल सकता है
-
Invoice format
- अगर सिर्फ एक देश में काम कर रहे हों, तो यह आसान लग सकता है
- लेकिन विस्तार के साथ सिर्फ sales tax नहीं, बल्कि VAT, GST, और देश-विशेष अतिरिक्त charges भी संभालने पड़ते हैं
- अलग-अलग markets के लिए अलग templates की ज़रूरत पड़ सकती है
B2B और global expansion में बढ़ती complexity
-
जटिल customer hierarchy
- खासकर B2B customers में subsidiaries और partners हो सकते हैं, और वे billing relationship को manage करना चाह सकते हैं
- इसके लिए usage को असली paying entity तक aggregate करने का तरीका चाहिए
- ऐसी ज़रूरतें अक्सर growth और expansion के बाद ही सामने आती हैं
- अगर customer entity या usage location अलग हो, तो tax भी बदल सकता है
- कानूनी रूप से bill और invoice को अलग रखना पड़ सकता है
- संबंधित नियम हर कुछ महीनों में बदल सकते हैं
-
Payment collection और churn prevention
- यह तय करना पड़ता है कि payment retries कब तक की जाएँ और कब छोड़ दिया जाए
- chargeback होने पर account बंद करना है, suspend करना है, या refund देना है, यह भी तय करना पड़ता है
-
Pause और resume
- जब customer subscription pause करता है, तब किस स्तर की access देनी है, यह तय करना पड़ता है
-
Credit और refund
- अगर केवल full refund किया जाता है, तो चीज़ें अपेक्षाकृत simple रहती हैं
- लेकिन partial error होने पर partial refund या store credit में से चुनना पड़ सकता है
- credit expire होगा या नहीं, यह भी अलग से तय करना पड़ता है
टैक्स, contracts, और इंसानी गलतियाँ
-
Tax handling
- अलग-अलग items पर अलग tax rates लगना ही अपने आप में जटिल है
- global scale पर tax rates और tax rules अक्सर बदलते रहते हैं
-
Custom contracts
- अगर केवल PLG किया जा रहा हो, तो यह समस्या नहीं भी हो सकती
- लेकिन जैसे ही contracts शुरू होते हैं, पुराने assumptions से configure न हो सकने वाले exceptions और special terms तेज़ी से बढ़ने लगते हैं
-
इंसानी गलतियाँ
- customers गलती करते हैं, और फिर correction की ज़रूरत पड़ती है
- कंपनी के अंदर भी customer configuration गलत हो सकती है, जिसे बाद में ठीक करना पड़ता है
- credit issue करना और invoice फिर से जारी करना समय लेने वाले काम हैं
- customer की legal information बदलने के मामले भी संभालने पड़ते हैं
- address
- VAT ID आदि
-
Selective pricing changes
- pricing changes अक्सर सभी customers पर लागू नहीं होते
- अगर वे सिर्फ नए customers पर लागू होते हैं, तो पुराने contracts बनाए रखने के लिए अलग-अलग price versions संभालने पड़ते हैं
-
Revenue recognition और accrued revenue
- IFRS-15 revenue recognition rules के लिए 64-पेज PDF specification मौजूद है
- अगर custom ERP integration भी खुद किया जाए, तो complexity और बढ़ जाती है
एक बार खत्म होने वाली समस्याएँ बनाम लगातार बढ़ती समस्याएँ
- कुछ समस्याएँ उम्मीद से कहीं ज़्यादा बार बदलती हैं, जबकि कुछ ऐसी होती हैं जिन्हें एक बार संभाल लेने के बाद शायद ही दोबारा छूना पड़े
- Idempotency ऐसी engineering problem का उदाहरण है, जिसे एक बार हल कर लेने के बाद बहुत कम दोबारा बदलना पड़ता है
- tax rules दुनिया भर में अक्सर बदलते रहते हैं
- जितने ज़्यादा देशों में विस्तार होगा, उतने ज़्यादा tax laws track करने पड़ेंगे
- customer mistakes अपेक्षाकृत लगातार होती रहती हैं
- growth के साथ इनका scale भी बढ़ता है
- ज़्यादा customer support और manual correction की ज़रूरत पड़ती है
- शुरुआत में पेमेंट एक engineering problem जैसा दिखता है, लेकिन वास्तव में इसकी जड़ें ऐसे जटिल problem space में होती हैं जिसे industry experts के लिए भी समझना आसान नहीं है
वे क्षेत्र जिन्हें खुद बनाने की ज़रूरत नहीं है
- जहाँ तक संभव हो, पेमेंट से जुड़ी अधिकतम समस्याएँ external systems को सौंप देना बेहतर है
- जितना हो सके उतने ready-made solutions खरीदने वाला approach recommend किया जाता है
- subscription और billing का बड़ा हिस्सा payment systems संभाल सकते हैं
- revenue recognition और accounting को पहले से इस्तेमाल हो रहे ERP या दूसरे systems की built-in functionality पर छोड़ना बेहतर है
- product teams को सिर्फ product-विशेष हिस्सों पर ध्यान देना चाहिए, जैसे usage updates और बुनियादी customer lifecycle events
1 टिप्पणियां
Hacker News की राय
जिन लोगों को billing से जुड़े फैसले लेने हैं लेकिन अनुभव ज़्यादा नहीं है, उनके लिए यह अच्छा लेख है, और अनुभवी लोगों के लिए भी reference के तौर पर उपयोगी है
हालांकि “क्या बिल करने वाली फाइलों को S3 में dump करके CRON job से payment collect नहीं करवा सकते?” वाली लाइन पढ़कर खूब हंसी आई। engineering mindset से देखें तो यह किसी भी स्थिति में अच्छा विचार नहीं है
billing architecture का मेरा पसंदीदा फैसला यह है कि system में billing और entitlements को जितना हो सके अलग रखा जाए। अगर prepaid subscription है, तो entitlement में सिर्फ expiry date और active अवधि में मिलने वाले अधिकारों की details रखना, और billing system में subscription store करके जरूरत पड़ने पर entitlement side में sync करना मुझे अच्छा लगा। इससे किसी व्यक्ति के लिए manual billing करना, temporary problem को debug/patch करना, या Stripe integration जोड़ना आसान हो जाता है
बेशक future expansion के लिए जगह छोड़नी चाहिए, लेकिन यह फैसला अपने-आप में system को बहुत सीमित नहीं करता। यह मेरा मौलिक idea नहीं है, पर दूसरे तरीकों को कम सफलता के साथ आज़माने के बाद मुझे यह खास तौर पर पसंद आने लगा
कई समस्याएं payment और billing के फर्क से पैदा होती हैं https://www.wingback.com/blog/saas-payment-vs-saas-billing. जब शुरुआती customers आते हैं, तो कुछ recurring payments ही लेने होते हैं, इसलिए Stripe या manual invoices से शुरुआत करना आसान होता है
लेकिन समय के साथ ज्यादा जटिल entitlements, कई pricing plans, मौजूदा customers की protection, और custom billing cycles/terms/entitlements चाहने वाले enterprise customers बढ़ने लगते हैं। billing अक्सर technical focus नहीं बन पाती, इसलिए छोटे-छोटे hacks और extra features जमा होते जाते हैं, और आखिर में यह ऐसी गड़बड़ी बन जाती है जो product development resources खा जाती है, sales की speed घटाती है, या उन products को सीमित कर देती है जिन्हें बेचा जा सकता है
billing की complexity में कई छिपे हुए traps और exceptions होते हैं, और आजकल ज्यादातर pricing plans में कई limits और usage-based elements होते हैं, साथ ही SaaS पूरी दुनिया में बेचा जाता है, इसलिए complexity और बढ़ गई है। late-stage companies में सिर्फ billing संभालने वाली 15+ engineers की teams भी होती हैं। अगर यह product का core नहीं है, तो अपना billing system खुद नहीं बनाना चाहिए—इस बात से मैं सहमत हूं। संदर्भ के लिए, मैं SaaS billing platform Wingback का CTO हूं
अब मुझे ऐसा system बनाना है, और लग रहा है कि मैं उम्मीद से कहीं ज्यादा योग्य हूं
https://arnon.dk/why-you-should-separate-your-billing-from-e...
customer entitlements को हमारे system में store करते हैं और जरूरत पड़ने पर check करते हैं; और जब payment provider की तरफ subscription renew/delete होता है, तो rules और entitlements add करते हैं। इससे एक या कई payment providers के साथ काम करना आसान हो जाता है और separation of concerns भी साफ रहता है। इस context में ज्यादा relevant होने के कारण ये related posts भी share कर रहा हूं: https://warrant.dev/use-cases/pricing-tiers-and-entitlements..., https://arnon.dk/why-you-should-separate-your-billing-from-e...
आदर्श entitlement system dynamic होना चाहिए—यानी rules database में store होने चाहिए—enterprise customers जैसे one-off scenarios संभाल सकने चाहिए, और उसके ऊपर एक policy layer होनी चाहिए। उदाहरण के लिए Pro plan में 5 seats तक, Growth plan में किसी feature को दिन में N बार तक, जैसे लगभग हर scenario को support कर सकना चाहिए
non-technical लोगों के लिए ऐसा UI भी बड़ा advantage है, जिससे वे engineering intervention के बिना customer-specific changes कर सकें। पिछले engineering roles में ऐसी चीजें हमेशा dev team की रफ्तार रोकती थीं
entitlement set भी है, लेकिन उनके बीच एक policy mechanism है जो तय करता है कि entitlement कब लागू करना है और कब नहीं। मुख्य बात यह है कि entitlement सिर्फ billing की समस्या नहीं है। policy mechanism entitlements और बाकी हर चीज़ को जोड़ने वाला glue है, इसलिए सबसे बड़े customer के executive को billing से जोड़े बिना भी entitlement दिया जा सकता है
पहले मैंने एक छोटी pharmacy chain के लिए billing और accounts receivable system बनाया था, और insurers बिना किसी warning के काफी बड़े cheques भेज दिया करते थे
हमने कुछ bill भी नहीं किया होता, फिर भी mail से 150,000 dollar का cheque आ जाता, और कुछ महीनों बाद उन्हें अपनी गलती समझ आती और वापस मांगते। ऐसे पैसे रखने के लिए magic money नाम का एक special account था। billing की दुनिया सचमुच पागल इलाका है
यानी बस उसे magic money कह दिया और individuals के accounts में debt वैसे ही छोड़ दिया?
मुझे नहीं लगता कि इस विषय को सिर्फ अपना billing system बनाने की तकलीफ के नजरिए से देखना सही है। अगर बहुत-सी कंपनियां उस रास्ते पर जाना चाहती हैं, तो उन्हें जाने देना चाहिए
मैं मानता हूं कि billing system बहुत जटिल होते हैं। लेकिन अगर Chargebee, Solvimon, Stripe, Recurly, Orb, Metronome, Lago, Togai वगैरह के पास यह ज्ञान है, तो उस ज्ञान को एक जगह इकट्ठा भी किया जा सकता है
आखिर सही जवाब वही तरीका है जो आपके लिए फिट बैठे। subscription-based SaaS के लिए उसके हिसाब का समाधान है, और usage-based API के लिए उसके हिसाब का billing समाधान है
किसी practice को रोकने के बजाय ज्ञान, तरीके, paradigms, programming patterns, अच्छी practices और best practices को एक जगह इकट्ठा किया जा सकता है। कुछ अपवाद भी हैं, जैसे अमेरिका या यूरोप के बाहर की कंपनियां जो Stripe जैसे billing solutions इस्तेमाल नहीं कर सकतीं। उदाहरण के लिए, अगर आप Venezuela की कंपनी हैं और Stripe account नहीं बना सकते, तो आखिरकार आपको अपना billing solution बनाकर किसी local payment gateway की मुश्किल SOAP-XML API से जोड़ना ही पड़ेगा
अलग से कहूं तो, “अपना billing system बनाना” Elastic + Grafana setup से “अपना SIEM बनाना” जैसा लगता है। मैं इसकी सिफारिश नहीं करूंगा, लेकिन समझता हूं कि IT security departments में इतने लोग ऐसा रास्ता क्यों चुनते हैं
billing system उन चीजों से कम जटिल है जिनसे developers आम तौर पर निपटते हैं। लेख कठिन legal requirements को मुश्किलों की तरह दिखाता है, लेकिन असल में इसका मतलब यह भी है कि specifications आसानी से मिल जाती हैं और अच्छी तरह documented होती हैं। कुछ हिस्से अक्सर बदलते हैं, पर वे भी अच्छे से labeled और explained होते हैं
मैं इस बात से सहमत हूं कि subscription-based SaaS और usage-based API के लिए अलग-अलग billing तरीके उपयुक्त होते हैं। लेकिन असली सवाल यह है कि क्या आप ग्राहक को जिम्मेदारी का बोझ आप पर डालने देंगे, क्या revenue इतना महत्वपूर्ण है कि इसे validate किया जाए, और क्या आप fees या losses झेल सकते हैं
इस लेख में जिस चीज पर बात नहीं हुई, उनमें से एक affiliate sales है, और आप इसे कितनी गहराई तक implement करते हैं, उसके हिसाब से यह काफी काम बढ़ा सकती है
यह ऐसा system है जो platform के अंदर हुई sales पर किसी दूसरे व्यक्ति को commission-based payout लेने देता है
affiliate code को sale और user तक track करना, affiliate द्वारा set किए गए payment provider पर payouts भेजना, और ठीक से करना हो तो visitors metrics, conversion rate और payout history देखने के लिए UI भी देना पड़ता है
अच्छी बात यह है कि ज्यादातर चीजें धीरे-धीरे बनाई जा सकती हैं। बस unique code को user से जोड़ दें, और उस code को किसी specific commission rate वाली sale से जोड़ दें; बाकी सब manual process किया जा सकता है या छोड़ा भी जा सकता है। उदाहरण के लिए, मैं महीने में एक बार Zelle या PayPal से affiliates को payout करता हूं और इसमें 10 मिनट भी नहीं लगते। conversion tracking frontend नहीं है, और इस वजह से किसी ने affiliate बनने से मना भी नहीं किया
सच में प्रभावशाली बात यह थी कि इस पूरी Rube Goldberg machine को उल्टा चलाने की जरूरत पड़ सकती है
“order” को आप जितना हो सके static रखना चाहते हैं, और “invoice” के साथ legal obligations भी जुड़े होते हैं
मान लीजिए किसी ने 5 items खरीदे और discount मिला, लेकिन अब उसे सिर्फ 3 चाहिए, और नाम व address में typo भी था। कोई दिक्कत नहीं—invoice को cancel कर दें, उसी amount के लिए सही नाम/address वाला नया invoice बनाएं, return आने और inspection होने तक इंतजार करें, फिर credit process करें और फिर एक और नया invoice बनाएं
return shipment कुछ समय तक अस्पष्ट स्थिति में रहता है, customer 5 और items order कर देता है, उनमें से एक टूटा हुआ पहुंचता है, और उसे replacement नहीं बल्कि refund चाहिए। delivery dates दो हिस्सों में बंट जाती हैं, इसलिए system 5 या उससे ज्यादा items वाला discount apply नहीं करता। जो शुरुआत में सिर्फ 2 simple orders लग रहे थे, वे पलक झपकते ही ढेर सारे transactions और paperwork में बदल जाते हैं। customer password भी भूल गया और दूसरे email से नया account बना लिया। एक साल बाद logs देखने पर समझना मुश्किल हो जाता है कि उसने सिर्फ 3 items खरीदे फिर भी discount क्यों मिला
इस सलाह को लेकर मैं पक्का नहीं हूँ। लेख में बताई गई आधी features शायद ज़रूरी न हों, और business बढ़ने के साथ उन्हें पर्याप्त रूप से धीरे-धीरे बनाया जा सकता है
invoice, credits, tax periods, prorated changes जैसे concepts समझने होंगे। लेकिन यह knowledge हर हाल में outsource/खरीदने की वजह नहीं, बल्कि build vs buy का फैसला बेहतर करने की सामग्री है
SaaS के लिए ज़रूरी external API सिर्फ एक credit card processor है, और थोड़ा fancy बनें तो दो। बेशक पहले साल के बाद काफी manual काम आने लगेगा, accountant बेवकूफी भरी गलतियाँ बताएगा, और accounting भी काफी सीखनी पड़ेगी
फिर भी अगर आज कोई नया business शुरू करूँ, तो कई solutions compare करूँगा, लेकिन मुझे यह भरोसा है कि खुद बनाना इतना डरावना नहीं है
system बनाना हमेशा आसान दिखता है और पहले दिन वाकई आसान होता है। लेकिन जल्द ही आप finance head को यह समझाने में बहुत समय लगाएंगे कि reports पूरी तरह गड़बड़ क्यों हैं, support team को यह बताना पड़ेगा कि invoice fail क्यों हुआ, subscription price गलत क्यों charge हुआ, और ऐसे कई edge cases समझाने पड़ेंगे जिनके अस्तित्व का आपको पता भी नहीं था
उसके बाद बदले हुए regulations के अनुरूप होना पड़ेगा, या चुना हुआ gateway उस region को support नहीं कर सकता जहाँ आप grow कर रहे हैं
“बस और बेहतर बना लो” कहने से पहले याद रखें कि वह भी time ही है। वह time जो product पर नहीं लगा, pricing model सुधारने पर नहीं लगा, और business growth बनाने के बजाय treadmill पर खड़े रहने में लगा
बाकी चीज़ों को नज़रअंदाज़ किया जा सकता है, लेकिन बाद में tax calculate न कर पाना या KYC laws तोड़ देना सच में बहुत मुश्किल बना देगा
साथ ही, कोई system अपेक्षा से महंगा है और कई smart दिखने वाली companies उसे इस्तेमाल करती हैं, इसका मतलब यह नहीं कि वह उद्देश्य के लिए सही है। खासकर आपके desired purpose के लिए सही होगा, इसकी तो बिल्कुल guarantee नहीं। खरीद लेने का मतलब यह नहीं कि research नहीं करनी पड़ेगी
ऐसी billing संभालने वाले व्यक्ति का goal simple है। sales team deal close कर सके, इसके लिए सही options देने होंगे। sales team के साथ मिलकर यह पता करना होगा कि “implement करने में आसान और deal close करने के लिए पर्याप्त” क्षेत्र क्या है
इस बात पर जितना ज़ोर दिया जाए कम है। sales team सचमुच revenue बना रही है। perfect billing system नहीं है, इसलिए रोना-धोना नहीं करना चाहिए। यह चौंकाने वाला हो सकता है, लेकिन business relationship दाँव पर हो तो कभी-कभी sleeves चढ़ाकर हाथ से काम करना पड़ता है
तरीका जितना हो सके simple रखें, लेकिन system ऐसा हो जिसे company की दूसरी teams पढ़ और समझ सकें, और automation चल रही हो तब भी आसानी से manual adjustment किया जा सके। Stripe इस्तेमाल में अच्छा महसूस होता है, इसकी 80% वजह यही है। manual adjustment life का हिस्सा है, और कुछ businesses में rare होने पर भी आखिरकार इसकी ज़रूरत पड़ती है
proration, अलग-अलग billing schedules, trials, नई pricing test करना, regional pricing, regional taxes, कई currencies में bundled products list करना, नई pricing rollout करना—ये अचानक 6 currencies × X regions × Y products × Z billing schedules × L languages का combination बन जाते हैं
इसमें नई subscription जोड़ना, subscription plans merge करना, पुराने plans बंद करते हुए customers को smoothly नए alternative plans पर ले जाना, और customers से अच्छी तरह communicate करना भी शामिल है। अगर SaaS है तो लगभग सब कुछ automated, self-service और well-tested होना चाहिए; वरना customer support और churn में डूबकर मर जाएंगे
pricing changes rollout करने में 3 दिन से 2 महीने तक लग सकते हैं, और शुरुआती custom contracts के निशान संभालना nightmare है। अगर आसानी से automate नहीं किया जा सकता, तो किया ही नहीं जा सकता। time बहुत ज्यादा लगता है
अगर हमने billing को यहाँ बताए गए products जैसे किसी चीज़ पर base किया होता, तो customer segments के हिसाब से custom contracts और pricing changes rollout शायद कहीं बेहतर कर पाते
यहाँ cover नहीं किया गया, लेकिन मैंने खुद 2 समस्याएँ handle की हैं
पहली है month-end/quarter-end close। लेख account ledger की बात करता है, लेकिन जब आप ऐसी public companies से deal करना शुरू करते हैं जिन्हें numbers report करने होते हैं, तो strict closing timelines होती हैं और सब कुछ smoothly चलना चाहिए
दूसरी है cash in transit accounting। यह लेख मानकर चलता है कि payment processor 100% accurate है और कोई problem नहीं होती। जब आप काफी बड़े हो जाते हैं, तो bank account में आए हर पैसे को किसी specific invoice या billing line item से match कर पाना चाहिए। ऐसे invoices भी ढूँढने होंगे जिनके corresponding bank statement lines नहीं हैं, और उलटा, ऐसे incoming funds भी handle करने होंगे जो invoice line items से linked नहीं हैं। billing invoice से linked न होने वाले bank account credits handle करने की ability भी important है
आप कह सकते हैं कि यह सब accounting department की problem है, लेकिन यह system से बहुत closely coupled है, इसलिए दोनों teams को मिलकर काम करना होगा ताकि books के बीच mismatches न रहें
असली accountants को close की वजह से बार-बार आधी रात तक रुकना पड़ता है, और tech/business side के लोगों को यह स्थिति झेलनी पड़ती है कि accounting team से कुछ चाहिए, लेकिन close period के दौरान वे मानो पृथ्वी से गायब हो गए हों। family member के रूप में अनुभव करें तो भी यही हाल है
internal accounting और bank accounts धीरे-धीरे अलग होने लगते हैं, और accountant को समझ नहीं आता कि problem कहाँ से ढूँढनी शुरू करे
मुझे जानना है कि सब लोग entitlement management के लिए क्या इस्तेमाल करते हैं। क्या feature flag system इस्तेमाल करते हैं, Stigg जैसा अलग SaaS, या फिर कोई अलग internal system रखते हैं?
आज सुबह HN पर आने की वजह भी यही है कि मैंने entitlement management के लिए feature flags इस्तेमाल करने पर एक लेख लिखा था: https://prefab.cloud/blog/modeling-product-entitlements-with.... Arnon के SKU format वाले लेख से भी प्रेरणा मिली थी
Feature flags entitlement management के लिए बिल्कुल perfect जगह नहीं लगते, लेकिन अनुभव से ऐसे कामों को संभालते समय हाथ में मौजूद tools में अक्सर यही सबसे बेहतर विकल्प रहे हैं। दूसरे विचार सुनना चाहूंगा
ये limits और flags “plan” से जुड़े होते हैं, और plan को account से जोड़ा जा सकता है। अगर plans को combine किया जाए तो numeric value में बड़ी value ली जाती है और tags को union के रूप में merge किया जाता है। साथ ही account-by-account values override या add की जा सकती हैं, इसलिए अगर किसी customer को PlanX चाहिए लेकिन custom API quota भी चाहिए, तो सिर्फ वही एक value सीधे account पर override कर देते हैं
इसे पुराने ढर्रे का कह सकते हैं, लेकिन समझ नहीं आता कि ऐसी चीज़ third party को outsource क्यों करनी चाहिए
Basic solution feature flags से किया जा सकता है, लेकिन billing·pricing से जुड़े entitlements, जैसे plans और editions की organization और changes, समय के साथ आसपास की requirements बढ़ने से complex हो जाते हैं। features, seats, usage-based·metering strategies के अलग-अलग combinations, team subscriptions, plan migrations, one-off enterprise plans, multiple subscriptions वाले customers, promotional periods और tiered subscriptions, usage aggregation, automatic upsell आदि के बारे में सोचें
लेख में दिखता है कि numeric values वाले flags से limits को express किया जा सकता है, लेकिन usage tracking infrastructure फिर भी business को खुद implement करना पड़ता है। इसके बजाय सोचें कि वह usage entitlement service को export हो, और usage-based entitlements teams के बीच भी real time में update हों। साथ ही उस entitlement पर निर्भर दूसरे entitlements भी update हो सकते हैं। Limit के पास पहुंचने या उसे पार करने पर soft limit चुन सकते हैं, जिसमें use जारी रहने दिया जाए लेकिन sales team को notify किया जाए, या hard limit, जिसमें upgrade prompt दिखे
मूल लेख के आशय की तरह, हम billing को फिर से बनाने के बजाय existing billing solutions के साथ काम करते हैं। पिछली successful exit से bootstrapped हैं और शुरुआती customers के साथ काम कर रहे हैं, इसलिए अगर कोई सिर्फ इस विषय पर बात करना चाहता हो तो trent at planship.io पर संपर्क कर सकता है
Beta rollout, role-based authorization, billing entitlements, one-off customer requests—सब feature flags से बनाए जा सकते हैं। सबसे अच्छे feature flags में optional values भी attached हो सकती हैं, इसलिए API plan limits भी feature flag बन सकती हैं
अगर पूछें कि क्या यह best है, तो हर use case के लिए शायद नहीं। लेकिन एक बार बना लें तो उसे हर जगह इस्तेमाल करने का temptation बहुत बड़ा होता है
Entitlements का customer-facing features से स्पष्ट connection होना चाहिए, और conceptually ये कहीं बड़े feature blocks होते हैं। इस approach की कठिनाई यह है कि अभी भी billing से जुड़े कई पहलुओं पर विचार करना पड़ता है। Delinquent customers को handle करना, किसी limit से ऊपर जाने पर overage charges, एक ही feature के लिए multiple pricing models, plan change·upgrade पर usage counters reset करना या carry over करना—ये सब समय के साथ बड़ी complexity जोड़ते हैं
इसलिए हमने Wingback में billing chain और metering से tightly coupled अलग feature entitlements देने का फैसला किया। संदर्भ के लिए, मैं CTO हूं। आखिर में, plan complexity और आपने पहले से feature flags में कितना invest किया है, इस पर निर्भर करते हुए दोनों approaches अच्छी तरह काम कर सकते हैं। Customer-facing feature gating हो तो customer account provisioning और custom packages देना काफी आसान हो जाता है
“System X बहुत complex है, इसलिए खुद मत बनाइए और ready-made solution इस्तेमाल कीजिए” वाले पूरे logical structure को स्वीकार करना मुश्किल है
X का general solution बहुत tricky और complex हो सकता है, लेकिन मेरे use case में complexity का सिर्फ खास हिस्सा चाहिए। इसलिए मैं अपनी जरूरत की complexity ही संभालने वाला custom solution बना सकता हूं, और वह off-the-shelf tool से बहुत सरल हो सकता है
मैं यह रुख date·time के मामले में पूरी तरह अपनाता हूं। मेरा date·time approach यह है कि library सिर्फ दो function calls दे। Epoch time को किसी खास timezone के ISO format time string में बदलने वाला function, और उसका inverse function। Library के बाकी code को बिल्कुल नहीं छूता, और बाकी time manipulation अपने code में उन्हीं दो functions के आधार पर handle करता हूं
शुरुआत से ही personal data handling के dos and don’ts, कई billing options के cycles और lifetimes, refund limits, idempotency support, task के हिसाब से model वाला sensible database transaction management, invoice issuing और customer exposure आदि समझने पड़ते हैं
सब कुछ एक साथ जरूरी नहीं होता, लेकिन पहले working implementation में भी कम से कम आधा तो चाहिए ही
यह कुछ ऐसा लगता है जैसे “सड़क पार करने की 14 परेशानियां और आपको मेरी किताब खरीदकर क्यों पढ़नी चाहिए”
बहुत से लोग सोचते हैं कि आंखें बंद करके चलना शुरू कर देना ठीक है, और फिर उन्हें समय से पहले चोट लगती है या मौत हो जाती है
हर देश में, बल्कि हर शहर में भी सड़क पार करने के नियम अलग होते हैं। शायद आपको अभी पता न हो, लेकिन दोनों तरफ देखना चाहिए। कई लोग यह जाने बिना कि वे color blind हैं, red और green में फर्क नहीं कर पाते और मर जाते हैं या घायल हो जाते हैं। आपने दोनों तरफ देखा, लेकिन ऊपर भी देखा क्या? शहर में खिड़कियों से चीज़ें गिरती हैं, गांव में पक्षी सिर के ऊपर उड़ सकते हैं, और space debris भी increasingly पृथ्वी पर गिर रहा है। Objects कई दिशाओं से आ सकते हैं
यह लेख इतना खराब तो नहीं है, लेकिन अगर इसे methodology article के रूप में structured किया गया होता तो बेहतर होता। Negative framing वाले लेख की तुलना में मैं ऐसा लेख कहीं ज्यादा पढ़ना चाहूंगा
“कितना मुश्किल हो सकता है?” joke project का ideal example है, लेकिन समस्या यह है कि सारी बातें सच हैं
उदाहरण अनगिनत हैं, लेकिन अगर समस्या को गलत तरीके से approach किया तो जल्द ही “customer को कितना pay करना चाहिए” वाले सवाल से सामना होगा, और फिर “हमने इस amount के बजाय दूसरा amount charge क्यों किया” आता है। अगर ऐसा बहुत बार हो, तो finance team आकर पूछेगी कि आपने ऐसा क्या किया जिससे company operating reports, यहां तक कि layoffs तय करने वाली reports तक unreliable हो गईं