वॉलेट ॲड्रेस ही पेमेंट सिस्टम नाही. ती फक्त एक डेस्टिनेशन आहे, त्यापेक्षा जास्त काहीही नाही. ज्यांच्याकडे तो स्ट्रिंग (string) आहे, ते कोणालाही, कधीही त्यावर काहीही पाठवू शकतात. दोन एकमेकांवर विश्वास असलेल्या व्यक्तींमधील एकदाच होणाऱ्या व्यवहारासाठी ते पुरेसे असू शकते. पण जर तुम्ही SaaS उत्पादन, मार्केटप्लेस किंवा ऑनलाइन स्टोअर चालवत असाल, तर चेकआउट पेजवर एक स्टॅटिक ॲड्रेस पेस्ट करणे म्हणजे ऑपरेशनल गोंधळाला आमंत्रण देणे आहे. तुम्हाला कोणाचे किती पैसे आले, कोणाचे कोणते ट्रान्झॅक्शन आहे हे ओळखण्यासाठी आणि कोणी चुकीच्या नेटवर्कवर चुकीचे टोकन पाठवले तर तो गोंधळ सोडवण्यासाठी दिवसभर मेहनत करावी लागेल.

स्केलेबल (scalable) काहीतरी तयार करण्यासाठी, तुम्हाला 'दानपेटी' सारखा विचार करणे थांबवून एका स्ट्रक्चर्ड (structured) पेमेंट सिस्टमप्रमाणे विचार करण्यास सुरुवात करावी लागेल.

वॉलेट ॲड्रेस मोठ्या प्रमाणावर (at scale) का अपयशी ठरतो

समस्या संदर्भाची (context) आहे, किंवा संदर्भाच्या अभावाची आहे. जेव्हा एखादा ग्राहक तुमचा वॉलेट ॲड्रेस कॉपी करतो आणि एक्सचेंज किंवा सेल्फ-कस्टडी वॉलेटमधून क्रिप्टो पाठवतो, तेव्हा ब्लॉकचेन फक्त काय हलले तेच रेकॉर्ड करते: एक रक्कम, एक टाइमस्टॅम्प आणि दोन पब्लिक ॲड्रेस. ते तुमचा इनव्हॉइस नंबर रेकॉर्ड करत नाही. त्यात कस्टमर आयडी (customer ID) समाविष्ट नसतो. ट्रान्सफर हे सबस्क्रिप्शन रिन्यूअल आहे, प्रो-रेटेड अपग्रेड आहे की पूर्णपणे नवीन खरेदी आहे, हे देखील ते सांगत नाही.

समजा एखादी SaaS कंपनी दर महिन्याला पाचशे ग्राहकांना स्टेबलकॉइन्समध्ये (stablecoins) बिलिंग करते. जर प्रत्येक ग्राहकाने एकाच स्टॅटिक ॲड्रेसवर USDT पाठवले, तर तुमच्या अकाउंटिंग टीमसमोर स्प्रेडशीटमधील nightmare (भयंकर समस्या) उभा राहील. एक ट्रान्सफर दुसऱ्यासारखाच दिसतो. पहाटे २ वाजता आलेले वीस डॉलर्स हे कस्टमर A ने त्यांचे प्लॅन रिन्यू केले आहेत की कस्टमर B ने सायकलच्या मध्यात अपग्रेड केले आहे, हे तुम्ही सांगू शकत नाही. ब्लॉकचेनला फक्त एक आकडा दिसतो. तुमच्या व्यवसायाला मात्र एक 'गोष्ट' (context) हवी असते.

मार्केटप्लेसना व्यवहाराच्या दोन्ही बाजूंनी या त्रासाचा सामना करावा लागतो. खरेदीदाराने निधी जमा केला आहे हे तुम्हाला माहित असणे आवश्यक आहे, विक्रेता माल पाठवतोपर्यंत तो निधी रोखून धरणे आणि डिलिव्हरी कन्फर्मेशन मिळाल्यावरच तो मुक्त करणे आवश्यक आहे. एका कच्च्या (raw) ॲड्रेसमुळे खरेदीदाराचा डिपॉझिट आणि एखादा रँडम इनबाउंड ट्रान्सफर किंवा विक्रेत्याचा स्वतःचा निधी यातील फरक ओळखण्याचा कोणताही प्रोग्रामॅटिक (programmatic) मार्ग मिळत नाही. ई-कॉमर्स देखील तितकेच गोंधळलेले आहे. ट्रान्झॅक्शनला विशिष्ट ऑर्डरशी लिंक केल्याशिवाय, तुम्ही फुलफिलमेंट (fulfillment) सुरू करू शकत नाही. कोणालातरी मॅन्युअली चेन स्कॅन करावी लागेल, ट्रान्सफर शोधावे लागेल आणि तुमचा डेटाबेस अपडेट करावा लागेल. दिवसातून दहा वेळा असे केले तर तुमच्याकडून मॅचेस (matches) सुटतील. हजार वेळा केले तर तुमचे नुकसान होईल.

हा बदल साधा पण अत्यंत महत्त्वाचा आहे. निधी एखाद्या ॲड्रेसवर आला का, हे विचारण्याऐवजी, एखादी विशिष्ट पेमेंट रिक्वेस्ट (payment request) योग्य स्थितीत (state) पोहोचली आहे का, हे विचारण्यास सुरुवात करा.

पेमेंट रिक्वेस्टच्या (Payment Request) भोवती रचना करा

एक विश्वासार्ह क्रिप्टो पेमेंट फ्लो पेमेंट रिक्वेस्टला मुख्य ऑब्जेक्ट (central object) मानतो. वॉलेट ॲड्रेस हा त्या रिक्वेस्टच्या सेवेसाठी अस्तित्वात असलेला एक तात्पुरता कंटेनर (container) बनतो. ही रिक्वेस्ट त्या मेटाडेटाला (metadata) सोबत घेऊन येते जो ब्लॉकचेन ट्रान्सफरला एक ओळखण्यायोग्य बिझनेस इव्हेंट (business event) मध्ये रूपांतरित करतो.

चेकआउट पर्याय देण्यापूर्वी, पेमेंट ओळखण्यायोग्य बनवणारे डेटा पॉइंट्स (data points) निश्चित करा:

  • एक खरेदी किंवा सबस्क्रिप्शन आयडी (purchase or subscription ID), जेणेकरून पैसे का हलत आहेत हे तुम्हाला नक्की समजेल.
  • अपेक्षित रक्कम (expected amount), जी दशांश चिन्हापर्यंत (decimal) स्पष्ट असावी.
  • अचूक ॲसेट (asset) आणि नेटवर्क प्रकार, कारण Ethereum वर USDT पाठवणे आणि Tron किंवा Polygon वर पाठवणे हे सारखे नाही.
  • ग्राहक किंवा अंतर्गत खात्याचा संदर्भ (reference).
  • एक्सपायरी वेळ (expiration time), जेणेकरून मार्चमधील अर्धवट भरलेले कोटेशन जूनमध्ये चुकून ऑर्डर क्लोज करणार नाही.

जेव्हा ग्राहक 'पे' (pay) वर क्लिक करतो, तेव्हा तुमची सिस्टम या फील्ड्ससह एक रिक्वेस्ट जनरेट करते. त्यानंतर ग्राहक केवळ एका ॲड्रेसवर नाही, तर त्या विशिष्ट रिक्वेस्टसाठी पेमेंट करतो. आता चेनवरील ट्रान्झॅक्शनला ऑफ-चेन ओळख (off-chain identity) प्राप्त होते. ब्लॉक एक्सप्लोररला क्वेरी करण्यापूर्वीच तुमची सिस्टम पेमेंट कशासाठी आहे हे जाणून घेते.

स्टेटसचे (Status) प्रामाणिकपणे मॉडेलिंग करा

ब्लॉकचेनवरील पैसे टप्प्याटप्प्याने (stages) हलतात. तुमच्या अंतर्गत सिस्टमला अशा शब्दावलीची (vocabulary) गरज आहे जी या टप्प्यांशी जुळते, अन्यथा तुमची इंजिनिअरिंग, सपोर्ट आणि ऑपरेशन्स टीम्स एकमेकांशी संवाद साधताना गोंधळात पडतील.

मॉडेल साधे आणि वर्णनात्मक ठेवा. तांत्रिक ज्ञान नसलेल्या सपोर्ट एजंटला स्टेटस वाचून ग्राहकाला काय सांगायचे आहे, हे समजले पाहिजे.

  • Created: विनंती अस्तित्वात आहे, परंतु ब्लॉकचेनवर अद्याप काहीही दिसत नाहीये. ग्राहकाने अद्याप व्यवहार (transaction) प्रसारित केलेला नाही.
  • Detected: तुमच्या मॉनिटरिंगने मेम्पूल (mempool) किंवा अलीकडील ब्लॉक मध्ये संबंधित व्यवहार शोधला आहे, परंतु त्याला अद्याप अंतिम स्वरूप (finality) मिळालेले नाही. उत्पादन पाठवू नका.
  • Confirming: व्यवहार चेनवर आहे आणि कन्फर्मेशन्स (confirmations) जमा होत आहेत. वेगवेगळ्या चेन्सचा वेग वेगवेगळा असतो. बिटकॉइनसाठी सहा ब्लॉक्सची आवश्यकता असू शकते. तुमच्या जोखीम घेण्याच्या क्षमतेनुसार (risk appetite) इथरियमला बारा किंवा त्यापेक्षा जास्त ब्लॉक्सची गरज भासू शकते. तुमच्या सिस्टमने नेटवर्कच्या स्वतःच्या कार्यपद्धतीचा आदर केला पाहिजे.
  • Completed: पेमेंट अपेक्षित रक्कम, मालमत्ता (asset), नेटवर्क आणि संदर्भाशी जुळते. तुम्ही ठरवलेले सर्व नियम पूर्ण झाले आहेत. आता तुम्ही ऑर्डर पूर्ण करू शकता, सबस्क्रिप्शन सक्रिय करू शकता किंवा एस्क्रो (escrow) मोकळे करू शकता.
  • Expired: ग्राहक पेमेंटच्या वेळेत पैसे भरण्यास अपयशी ठरला आहे. जोपर्यंत तुम्ही ती विनंती स्पष्टपणे पुन्हा सक्रिय करत नाही, तोपर्यंत ती भविष्यातील पेमेंट स्वीकारू नये.
  • Mismatch: ग्राहकाने निधी पाठवला आहे, परंतु काहीतरी चुकीचे आहे. रक्कम कमी आहे, नेटवर्क वेगळे आहे किंवा मालमत्ता (asset) जुळत नाहीये. हे सपोर्ट टीमकडे पाठवा. तुमच्या फुलफिलमेंट सिस्टमला अंदाज लावू देऊ नका.

ही पाइपलाइन चेन डेटाच्या गोंधळलेल्या प्रवाहाचे रूपांतर अशा प्रक्रियेत करते जी तुमच्या संपूर्ण कंपनीला सहज समजू शकते.

पोलिंग (Polling) थांबवा. लिसनिंग (Listening) सुरू करा.

इन्फ्रास्ट्रक्चर बजेट खर्च करण्याचा सर्वात जलद मार्ग म्हणजे तुमच्या बॅकएंडने दर काही सेकंदांनी तुमच्या प्रोव्हायडरला पैसे आले आहेत का, असे विचारणे. यामुळे दोन्ही बाजूंचे रिसोर्सेस वाया जातात आणि अनावश्यक विलंब (latency) निर्माण होतो.

एक उत्तम आर्किटेक्चर 'स्टेटस-नोटिफिकेशन मॉडेल' वापरते. स्टेटस बदलताच तुमच्या पेमेंट प्रोव्हायडरने किंवा नोड इन्फ्रास्ट्रक्चरने तुमच्या सिस्टमला एक इव्हेंट (event) पाठवला पाहिजे. जेव्हा व्यवहार शोधला जातो (detected), तेव्हा तुम्हाला एक वेबहुक (webhook) मिळतो; जेव्हा तो कन्फर्म होत असतो (confirming), तेव्हा दुसरा; आणि जेव्हा तो पूर्ण होतो किंवा अयशस्वी होतो, तेव्हा अंतिम वेबहुक मिळतो.

यामुळे अनावश्यक CPU सायकल खर्च न करता तुमची सिस्टम प्रतिसादक्षम (responsive) राहते.