BTCPay Server

व्यापारी काउंटर या ऑनलाइन दुकान को इनवॉइस और चुने हुए प्राप्ति तरीके से जोड़ता है। BTCPay Server on-chain भुगतान पते और Lightning अनुरोध बनाता है, भुगतान देखता है और इनवॉइस का अवलोकन देता है। इसमें बिक्री केंद्र और दान के ऐप तथा इंटीग्रेशन इंटरफ़ेस भी हैं। खुला स्रोत निरीक्षण और बदलाव संभव करता है, लेकिन अपने आप किसी विशेष इंस्टॉलेशन की सुरक्षा साबित नहीं करता। [BTCPay Server — Source repository]

मौजूदा on-chain वॉलेट को विस्तारित सार्वजनिक कुंजी से जोड़ सकते हैं: सर्वर उसकी निजी कुंजी के बिना प्राप्ति पते निकालता है। सर्वर पर बनाए हॉट वॉलेट का जोखिम मॉडल अलग है। Lightning नोड की अनुमतियाँ भी उसके धन को इस्तेमाल करने का अधिकार दे सकती हैं। प्राप्ति, हस्ताक्षर और प्रशासन की कुंजियाँ अलग समझें; self-hosted शब्द अकेले यह तय नहीं करता कि पैसा कौन खर्च कर सकता है। [BTCPay Server — Wallet setup] [BTCPay Server — General FAQ]

बाहरी होस्ट सर्वर चलाता है जबकि उपयोगकर्ता अपने वॉलेट में सीधे प्राप्त कर सकता है। इससे विश्वास की आवश्यकता नहीं मिटती: दुर्भावनापूर्ण या समझौता किए गए सर्वर पर सार्वजनिक कुंजी बदलकर भविष्य के भुगतान मोड़े जा सकते हैं। अपने वॉलेट में पहले प्राप्त सिक्के और नए दिखाए भुगतान विवरण अलग बातें हैं। काउंटर से स्वतंत्र रूप से भी प्राप्ति जाँचें। यही हमला अपने समझौता किए गए इंस्टेंस पर भी हो सकता है; होस्ट उपलब्धता और गोपनीयता को भी प्रभावित करता है। [BTCPay Server — Third-party hosting risks]

दुकान मुद्रा, दर का स्रोत, वैधता और आवश्यक पुष्टियाँ तय करती है। on-chain भुगतान का Processing निर्धारित शर्त की प्रतीक्षा करता है और Settled उसका पूरा होना दिखाता है। सफल Lightning भुगतान को ब्लॉक की प्रतीक्षा नहीं करनी पड़ती। कम, अधिक, देर से प्राप्त भुगतान और हाथ से स्थिति बदलाव भी संभालें; हाथ से बदलाव नेटवर्क पुष्टि नहीं बनाते। कीमत को बिटकॉइन में गणना करना fiat में बेचना नहीं है: रूपांतरण प्लगइन या प्रदाता अपने शुल्क और विश्वास संबंध जोड़ता है। [BTCPay Server — Invoice lifecycle] [BTCPay Server — Store rates and policies] [BTCPay Server — General FAQ]

ऑनलाइन दुकान को ऑर्डर और इनवॉइस पहचानकर्ता का संबंध रखना चाहिए। Greenfield API संबंधित दुकान तक अनुमतियाँ सीमित कर सकता है; कुंजी को आवश्यकता से अधिक पहुँच न दें। दस्तावेज़ के अनुसार webhook सत्यापित करें और दोहराए इवेंट को दूसरी शिपमेंट के बिना संभालें। ग्राहक का धन्यवाद पृष्ठ पर लौटना अकेले भुगतान साबित नहीं करता। बाधा के बाद स्थानीय रिकॉर्ड का वास्तविक इनवॉइस और भुगतान स्थितियों से मिलान करें। [BTCPay Server — eCommerce integration]

अपने नोड को उपलब्धता, चैनल प्रबंधन और आने वाली तरलता चाहिए। तरलता सेवा, swap या अभिरक्षक वॉलेट समस्या के अलग भाग हल करते हैं और एक ही मॉडल नहीं हैं। अभिरक्षक सेवा में धन का नियंत्रण प्रदाता के पास रहता है; बाकी विकल्पों में विशिष्ट अनुमतियाँ और जोखिम जाँचना आवश्यक है। BTCPay Server का लोगो हर भुगतान की सफलता या शून्य शुल्क की गारंटी नहीं है। [BTCPay Server — Lightning options]

तैनाती के अनुसार दुकान के डेटा, इनवॉइस, कॉन्फ़िगरेशन और आवश्यक वॉलेट डेटा का बैकअप लें; seed ऑर्डर डेटाबेस की जगह नहीं लेता। Docker दस्तावेज़ बैकअप की बहाली जाँचने को कहते हैं। पुराने Lightning चैनल की स्थिति को गलत बहाल करने से धन खो सकता है। मूल नोड को सही ढंग से रोककर नियोजित स्थानांतरण करना आपदा बहाली से अलग है; विकल्प चालू करने के बाद उसी नोड की पुरानी कॉपी न चलाएँ। प्रक्रिया उपयोग किए backend के अनुरूप होनी चाहिए। [BTCPay Server — Backup and restore]

अपडेट, प्रशासक की पहुँच की सुरक्षा, नेटवर्क पर खुला दायरा, उपलब्धता निगरानी और सत्यापित बैकअप की योजना बनाएँ। होस्टिंग, हार्डवेयर, नेटवर्क शुल्क, तरलता और सहायता पर पैसा लग सकता है, भले सॉफ़्टवेयर हर भुगतान का प्रतिशत न ले। सहेजी ग्राहक जानकारी कम रखें। रिफ़ंड और डिलीवरी विवाद व्यापारी संभालता है, परियोजना के डेवलपर नहीं; इनवॉइस निर्यात सभी लेखांकन दायित्व पूरे होने की गारंटी नहीं देता। [BTCPay Server — Maintenance] [BTCPay Server — General FAQ] [BTCPay Server — eCommerce integration]