Bitcoin Payment Processor क्या है? परिभाषा, संदर्भ और स्रोत

01Bitcoin Payment Processor क्या है?

Bitcoin Payment Processor भुगतान अनुरोध बनाता है, प्राप्त भुगतानों को ऑर्डर से मिलाता है और उनका रिकॉर्ड रखने में मदद करता है। इसे स्वयं चलाया जा सकता है या सेवा के रूप में लिया जा सकता है। यह Bitcoin सहमति का नियम नहीं है और प्रोसेसर नाम यह नहीं बताता कि धन पर नियंत्रण किसका है।

02ऑर्डर से पहचाने गए भुगतान तक

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

03धन की अभिरक्षा और भुगतान प्रसंस्करण अलग हैं

BTCPay Server मौजूदा वॉलेट के सार्वजनिक डेटा से उसकी निजी कुंजी के बिना प्राप्ति पते निकाल सकता है। यह सर्वर पर रखे हॉट वॉलेट और Lightning नोड के धन तक पहुँच से अलग है। प्रदाता भुगतान भेजने तक धन रख सकता है। केवल उत्पाद के नाम या non-custodial शब्द के बजाय कुंजियों की वास्तविक अभिरक्षा, अनुमतियाँ और निकासी की क्षमता जाँचें। [BTCPay Server — General FAQ] [BitPay — Configuring settlements]

04इनवॉइस की विनिमय दर और वैधता होती है

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

05भुगतान प्राप्त होना और माल भेजने की तैयारी

BTCPay Server निर्धारित पुष्टियों की प्रतीक्षा करने वाले Processing और Settled में अंतर करता है; सफल Lightning भुगतान ब्लॉक की प्रतीक्षा किए बिना Settled हो जाते हैं। दूसरे प्रदाताओं की स्थिति के नामों को सीधे समान नहीं मान सकते: BitPay स्पष्ट चेतावनी देता है कि paid भुगतान की गारंटी नहीं है। दुकान को विशिष्ट स्थिति और भुगतान विधि के लिए माल देने का नियम चाहिए। स्थिति को हाथ से बदलने से नेटवर्क पुष्टि नहीं बनती। [BTCPay Server — Invoice lifecycle] [BitPay — Invoice webhooks]

06सूचनाएँ सत्यापित करें और दोहरी पूर्ति रोकें

BTCPay मूल बॉडी बाइट्स और साझा सीक्रेट पर HMAC-SHA256 का उपयोग करके webhook सत्यापित करता है। BitPay बिना हस्ताक्षर वाले IPN का वर्णन करता है: सूचना API से इनवॉइस की स्थिति पूछने का संकेत है, अपने आप में भरोसेमंद प्रमाण नहीं। सूचनाएँ दोबारा आ सकती हैं। इसलिए इंटीग्रेशन को फिर भेजे गए इवेंट की विश्वसनीय पहचान करके उसी ऑर्डर की दूसरी शिपमेंट रोकनी चाहिए; बाधा के बाद सहेजी स्थितियों का प्रोसेसर से मिलान करना ज़रूरी है। [BTCPay Server — Webhook validation example] [BitPay — Invoice webhooks]

07व्यापारी को निपटान एक और स्तर है

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

08रिफ़ंड और लेखांकन का रिकॉर्ड

रिफ़ंड के लिए एक और भुगतान और प्राप्तकर्ता का सत्यापन चाहिए; इससे मूल बिटकॉइन लेनदेन नहीं बदलता। ऑर्डर की शिकायत, लौटाई जाने वाली राशि का निर्णय और वास्तविक धन भेजने को अलग रखें। ऑर्डर–इनवॉइस–भुगतान संबंध, विनिमय दरें, शुल्क और रिफ़ंड सुरक्षित रखें। रिपोर्ट निर्यात रिकॉर्ड रखने में मदद करता है, लेकिन अकेले सभी स्थानीय लेखांकन दायित्व या माल की डिलीवरी का विवाद नहीं सुलझाता। पुष्ट ट्रांसफ़र भी अपने आप सौदे की कानूनी अंतिमता तय नहीं करता: भुगतान मार्ग, अनुबंध और क्षेत्राधिकार के अनुसार शिकायतें, उपलब्ध chargeback व्यवस्था और दायित्व जाँचें। [BTCPay Server — Refunds] [BTCPay Server — Reporting] [BitPay — Merchant and shopper terms]

09इंटीग्रेशन लागू करने से पहले क्या जाँचें

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

∑व्यावहारिक उदाहरण

उदाहरण · PAY·PROC

वही सूचना एक और खरीद नहीं है

एक काल्पनिक इंटीग्रेशन में ऑर्डर OBJ-101 के साथ इनवॉइस पहचानकर्ता सहेजा गया है। निपटान सत्यापित होने पर सिस्टम एक बार शिपमेंट बनाता है। बाद में उसी इवेंट की दोहराई गई सूचना आने पर वह उसे पहले से पूरे ऑर्डर से जोड़ता है और नई शिपमेंट नहीं बनाता। केवल धन्यवाद पृष्ठ दिखने से यह परिवर्तन नहीं होना चाहिए।

प्रोसेसर भुगतान को ऑर्डर से जोड़ता है; Bitcoin नेटवर्क के नियम नहीं तय करता।
कुंजियाँ और अनुमतियाँ जाँचें: प्रोसेसर धन रख भी सकता है और नहीं भी।
ब्राउज़र में लौटना या असत्यापित सूचना भुगतान का प्रमाण नहीं है।
दोहराए इवेंट, बाधाएँ, रिफ़ंड और प्रदाता से भुगतान के लिए अपनी प्रक्रियाएँ चाहिए।

↗संदर्भ सहित पढ़ें

पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें BTCPay Server, Bitcoin Point of Sale, Merchant Adoption, Lightning Network, Bitcoin. इस प्रविष्टि का उल्लेख यहाँ भी है Alza Bitcoin payments, Merchant Adoption, BTCPay Server, Bitcoin Point of Sale.

?व्यावहारिक प्रश्न

01क्या हर भुगतान प्रोसेसर मेरे बिटकॉइन रखता है?

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

02क्या ग्राहक के भुगतान पृष्ठ से लौटने पर दुकान माल भेज सकती है?

केवल लौटना पर्याप्त नहीं है। दुकान को संबंधित प्रोसेसर की प्रक्रिया से सही इनवॉइस और उसकी स्थिति सत्यापित करनी चाहिए। सूचनाएँ दस्तावेज़ के अनुसार सत्यापित होती हैं और दोबारा आने से फिर पूर्ति शुरू नहीं होनी चाहिए। माल देना भुगतान पुष्टि की चुनी हुई शर्तों के अनुसार होता है।