495 / 736PAY·PROC

Bitcoin Payment Processor

बिटकॉइन भुगतान प्रोसेसर

ग्राहक बिटकॉइन से भुगतान कर देता है, लेकिन दुकान को अभी जानना है कि किस ऑर्डर का पैसा आया, राशि सही है या नहीं और सामान कब भेजना है। Bitcoin Payment Processor इन कदमों को जोड़ता है। इस नाम के तहत खुद चलाया जाने वाला सॉफ़्टवेयर भी हो सकता है और ऐसी सेवा भी, जिससे दुकान को पैसे मिलने की प्रतीक्षा करनी पड़े।

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

मान लीजिए ग्राहक ऑनलाइन एक किताब मँगाता है। दुकान प्रोसेसर से invoice, यानी राशि और मुद्रा वाला भुगतान अनुरोध बनवाती है। उसकी पहचान ऑर्डर नंबर के साथ सहेजती है। ग्राहक भुगतान पृष्ठ खोलता है या QR कोड स्कैन करके भुगतान करता है। सहेजा हुआ संबंध बताता है कि पैसा किस खरीद का है। इसके बिना सिर्फ़ यह देख लेना पर्याप्त नहीं कि कहीं बिटकॉइन पहुँच गया है। “आपके ऑर्डर के लिए धन्यवाद” वाले पृष्ठ पर लौटना भी दुकान को भुगतान मिलने का प्रमाण नहीं है। [1]

BTCPay Server मौजूदा वॉलेट के सार्वजनिक डेटा से प्राप्ति पते बना सकता है, बिना वे निजी कुंजियाँ लिए जिनसे धन खर्च किया जाता है। यह सर्वर पर कुंजियाँ रखने वाले हॉट वॉलेट या तेज़ भुगतान संभालने वाले Lightning नोड के धन तक पहुँच से अलग है। किसी सेवा में प्रदाता भुगतान भेजने से पहले धन नियंत्रित कर सकता है। इसलिए non-custodial, यानी प्रदाता को कुंजियाँ न सौंपने का लेबल अकेले पर्याप्त नहीं। वास्तविक अनुमतियाँ, पैसा भेज सकने वाला पक्ष और पैसा पाने के लिए किसी और की मंज़ूरी की ज़रूरत जाँचें। [2] [6]

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

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

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

ग्राहक का भुगतान प्राप्त होना और सेवा से दुकान को पैसा मिलना अलग घटनाएँ हैं। BitPay समर्थित निपटान मुद्रा और बैंक खाता या क्रिप्टोकरेंसी पता चुनने देता है; बदलाव के लिए स्वीकृति लग सकती है। व्यापारी को समय, सीमाएँ, शुल्क और भुगतान मिलने से पहले धन का नियंत्रण भी जाँचना चाहिए। सीधे अपने वॉलेट में प्राप्त करने पर यह बीच का चरण नहीं भी हो सकता। बिक्री प्रणाली को दोनों तरीकों में अंतर रखना चाहिए ताकि “भुगतान हुआ” से उपलब्ध धन का गलत अंदाज़ा न लगे। [6] [2]

रिफ़ंड मूल Bitcoin लेनदेन को मिटाता नहीं। दुकान पहले ग्राहक का अनुरोध संभालती है, राशि और मुद्रा तय करती है, प्राप्तकर्ता की जाँच करती है और नया भुगतान करवाती है। रिफ़ंड माँगने का लिंक होने का अर्थ यह नहीं कि पैसा भेज दिया गया। ऑर्डर, भुगतान अनुरोध, प्राप्ति, विनिमय दर, शुल्क और रिफ़ंड रिकॉर्ड में रहते हैं। निर्यात की गई रिपोर्ट लेखांकन में मदद करती है, लेकिन अकेले सभी स्थानीय दायित्व पूरे नहीं करती। नेटवर्क पुष्टि भी डिलीवरी विवाद का फ़ैसला नहीं करती और शिकायत पर अनुबंध या कानून से बने कर्तव्य समाप्त नहीं करती। [7] [8] [10]

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

उदाहरण · PAY·PROC

चुकाई गई किताब और दोहराया संदेश

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

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

01क्या मुझे प्रोसेसर को बिटकॉइन सौंपना होगा?

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

02ग्राहक दुकान पर लौटते ही क्या सामान भेज सकता हूँ?

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

DOC · 001BTCPay Server — eCommerce integrationदस्तावेज़ DOC · 002BTCPay Server — General FAQदस्तावेज़ DOC · 003BTCPay Server — Invoice lifecycleदस्तावेज़ DOC · 004BTCPay Server — Webhook validation exampleदस्तावेज़ DOC · 005BitPay — Invoice webhooksदस्तावेज़ DOC · 006BitPay — Configuring settlementsदस्तावेज़ DOC · 007BTCPay Server — Refundsदस्तावेज़ DOC · 008BTCPay Server — Reportingदस्तावेज़ DOC · 009BTCPay Server — Lightning operationsदस्तावेज़ DOC · 010BitPay — Merchant and shopper termsप्राथमिक स्रोत
समीक्षा की गई: स्रोत पहले · यह निवेश सलाह नहीं है