BTCPay Server

किताबों की ऑनलाइन दुकान की कल्पना कीजिए। ग्राहक बिटकॉइन चुनता है और BTCPay Server एक invoice बनाता है, यानी तय रकम चुकाने का अनुरोध। दुकान की सेटिंग के अनुसार भुगतान पृष्ठ पर पता या Lightning भुगतान अनुरोध दिखता है। सॉफ़्टवेयर रकम मिलने पर नज़र रखता है और स्थिति बदलने की सूचना जुड़े हुए स्टोर को देता है। इससे हर रकम भेजने वाले को हाथ से पहचानने की ज़रूरत घटती है। इसे दुकान के काउंटर या दान लेने के लिए भी इस्तेमाल कर सकते हैं। खुला स्रोत कोड प्रोग्राम की जाँच और उसमें बदलाव की सुविधा देता है; इससे किसी खास स्थापना की सुरक्षा अपने-आप साबित नहीं होती। [1]

पहले से मौजूद वॉलेट के लिए सर्वर को विस्तारित सार्वजनिक कुंजी दी जा सकती है। इस जानकारी से वॉलेट के प्राप्ति पते निकाले जा सकते हैं। रकम आगे भेजने की अनुमति देने वाली निजी कुंजियाँ सर्वर से बाहर, जैसे हार्डवेयर वॉलेट में, रह सकती हैं। हॉट वॉलेट अलग है: उसकी गोपनीय जानकारी इंटरनेट से जुड़े उपकरण पर रखी होती है। तेज़ भुगतान संभालने वाले Lightning नोड तक पहुँच भी खर्च करने की अनुमति दे सकती है। इसलिए सर्वर चलाना और पैसे पर नियंत्रण रखना अलग सवाल हैं। self-hosted, यानी अपना सर्वर खुद चलाना, कह देने से दोनों के जवाब नहीं मिलते। [2] [3]

किसी और का सर्वर इस्तेमाल करने से स्थापना और रखरखाव का काम बच सकता है। लेकिन रकम अपने वॉलेट में लेने पर भी आप उसके संचालक पर निर्भर रहते हैं। बदला हुआ या हैक किया गया सर्वर आपके पतों की जगह हमलावर के पते दिखा सकता है। केवल सार्वजनिक कुंजी मिलने से पहले प्राप्त सिक्के खर्च नहीं किए जा सकते, लेकिन छेड़छाड़ वाला भुगतान पृष्ठ भविष्य के भुगतान कहीं और भेज सकता है। इसलिए अलग वॉलेट में भी रकम आने की पुष्टि करें। अपना सर्वर हैक होने पर भी यही हो सकता है; बाहरी होस्ट सेवा की उपलब्धता और भुगतान की निजता को भी प्रभावित करता है। [4]

किताब की कीमत चेक क्राउन में हो सकती है, जबकि ग्राहक बिटकॉइन देता है। Invoice सीमित समय के लिए दर और चुकाई जाने वाली रकम तय करता है। Processing का अर्थ है कि पूरी माँगी गई रकम मिल गई है, लेकिन भुगतान पूरा मानने की शर्तें, जैसे ब्लॉक पुष्टियाँ, अभी बाकी हैं। Settled का अर्थ है कि वे शर्तें पूरी हो गईं; Lightning भुगतान को आम तौर पर ब्लॉक का इंतज़ार नहीं करना पड़ता। दुकान को कम, ज़्यादा और देर से आए भुगतान भी संभालने होते हैं। स्थिति हाथ से बदलने से नेटवर्क पुष्टि नहीं बनती। और कीमत को क्राउन से बिटकॉइन में दिखाने भर से बैंक खाते में क्राउन नहीं आते: प्लगइन या प्रदाता के ज़रिए मुद्रा बदलना अपनी शर्तों और लागत वाली अलग सेवा है। [5] [6] [3]

प्रोग्राम Greenfield API से जुड़ते हैं, जो उनके बीच बातचीत का माध्यम है। दुकान invoice का पहचानकर्ता ऑर्डर के साथ सहेजती है। बदलाव की खबर webhook से मिलती है, यानी सर्वर का अपने-आप भेजा गया संदेश, जिसकी प्रामाणिकता दस्तावेज़ में बताए तरीके से जाँचना ज़रूरी है। API पहुँच कुंजी को केवल उसी स्टोर के लिए आवश्यक अनुमतियाँ दें। एक संदेश दोबारा आने पर दूसरी किताब नहीं भेजी जानी चाहिए। ग्राहक का धन्यवाद पृष्ठ पर लौट आना भी भुगतान का प्रमाण नहीं है। सेवा रुकने के बाद स्थानीय रिकॉर्ड को invoices और वास्तविक भुगतान से मिलाएँ। [7]

Lightning Network भुगतान चैनलों के ज़रिए काम करता है, ताकि हर भुगतान को अलग से ब्लॉक में दर्ज न करना पड़े। अपना नोड उपलब्ध होना चाहिए और उसमें आने वाली रकम के लिए तरलता होनी चाहिए: चैनलों में इतनी जगह कि रकम आप तक पहुँच सके। इसलिए लगातार देखभाल चाहिए। तरलता में मदद, भुगतान नेटवर्कों के बीच अदला-बदली या ग्राहक की ओर से पैसे नियंत्रित करने वाली कस्टोडियल सेवा ली जा सकती है। इन विकल्पों की अनुमतियाँ, शुल्क और जोखिम अलग हैं। भुगतान पृष्ठ पर BTCPay Server नाम होने से यह नहीं पता चलता कि दुकान कौन-सा विकल्प इस्तेमाल करती है, और न ही हर भुगतान सफल होने की गारंटी मिलती है। [8]

वॉलेट की रिकवरी जानकारी पूरी दुकान का बैकअप नहीं है। कुंजियों के साथ invoice रिकॉर्ड, सेटिंग और सेटअप के अनुसार दूसरे डेटा भी चाहिए। Lightning में चैनलों की पुरानी स्थिति से नोड चालू करना खास तौर पर खतरनाक है: गलत रिकवरी से रकम जोखिम में पड़ सकती है। नए सर्वर पर योजनाबद्ध स्थानांतरण और खराबी के बाद रिकवरी अलग काम हैं। स्थानांतरण के दौरान मूल नोड की स्थिति आगे नहीं बदलनी चाहिए और उसे बहाल की गई कॉपी के साथ-साथ नहीं चलाना चाहिए। इस्तेमाल किए जा रहे सॉफ़्टवेयर की प्रक्रिया अपनाएँ। Lightning की बहाली का परीक्षण नेटवर्क और जुड़े नोडों से अलग करके करें, ताकि चालू चैनलों पर असर न पड़े। Docker ऐसा परिवेश है जो एप्लिकेशन के हिस्सों को अलग कंटेनरों में चलाता है; उसका मार्गदर्शन उसी स्थापना विधि के लिए है। [9]

फायदा यह है कि भुगतान व्यवस्था के फैसले आप कर सकते हैं। फिर भी अपडेट, एडमिन पहुँच, इंटरनेट पर खुली सेवाओं और बहाल किए जा सकने वाले बैकअप का ध्यान किसी को रखना होगा। सॉफ़्टवेयर हर भुगतान का प्रतिशत नहीं लेता, लेकिन होस्टिंग, हार्डवेयर, नेटवर्क शुल्क और Lightning सहायता पर खर्च हो सकता है। ग्राहकों का गैरज़रूरी निजी डेटा न रखें। किताब खो जाने या वापस आने पर शिकायत और पैसे लौटाने की ज़िम्मेदारी व्यापारी की है; BTCPay Server के डेवलपर उस बिक्री के मध्यस्थ नहीं हैं। Invoice रिकॉर्ड हिसाब रखने में मदद करते हैं, लेकिन सारी लेखांकन ज़िम्मेदारियों की जगह नहीं लेते। [10] [3] [7]