Merchant Adoption का अर्थ है कि दुकानें और सेवा प्रदाता ऐसे bitcoin भुगतान शुरू करें जिनका ग्राहक वास्तव में उपयोग कर सकें। इसमें भौतिक दुकानें और ऑनलाइन स्टोर दोनों आते हैं। bitcoin स्वीकार करना उसे लंबे समय तक रखने से अलग है। व्यापारी सीधे रकम ले सकता है या ऐसी सेवा चुन सकता है जो तय शर्तों के अनुसार दूसरी मुद्रा में भुगतान करे।
मान लीजिए नक्शे पर दुकान Bitcoin स्वीकार करती दिखती है, लेकिन आज के कर्मचारी को भुगतान शुरू करना नहीं आता। तब वह रिकॉर्ड ग्राहक की खास मदद नहीं करता। खास दुकान, समर्थित भुगतान तरीका और जाँच की तारीख देखनी चाहिए। इसीलिए BTC Map स्थानीय सहयोगियों और मौजूदा जगहों की दोबारा जाँच पर निर्भर करता है। सफल परीक्षण-खरीद बताती है कि उस क्षण प्रक्रिया काम करती है। इससे नियमित ग्राहकों की संख्या नहीं पता चलती; उसके लिए तय अवधि में वास्तविक खरीद देखनी होगी। [1]
व्यापारी अपने नियंत्रण वाली कुंजियों के वॉलेट में bitcoin पा सकता है। कुंजियाँ रकम खर्च करने का अधिकार देती हैं, इसलिए उनका बैकअप भी सुरक्षित रखना चाहिए। दूसरा विकल्प भुगतान संसाधित करने वाला प्रदाता है जो समर्थित स्थानीय मुद्रा में निपटान देता है। BitPay ऐसी व्यवस्था बताता है। ग्राहक bitcoin देता है, लेकिन व्यापारी को उसके बदलते भाव का जोखिम बनाए रखना ज़रूरी नहीं। पता करें कि भुगतान निकलने तक रकम किसके नियंत्रण में रहती है, कब मिलती है और क्या शर्तें या सीमाएँ हैं। भुगतान विधि और धन की अभिरक्षा अलग निर्णय हैं। [2] [3]
बिलिंग प्रणाली खरीद को राशि और भुगतान विधि से जोड़ती है। BTCPay Server इसे invoice कहता है: ऐसा अनुरोध जो सीमित समय के लिए राशि और विनिमय दर तय करता है। ग्राहक समझता है कि अपने ऑर्डर के लिए कितना भेजना है। अवधि समाप्त होने, कम या अधिक रकम मिलने पर अलग कार्रवाई चाहिए। भेजने से पहले राशि, प्राप्तकर्ता और सही नेटवर्क जाँचें। QR कोड केवल जानकारी वॉलेट में पहुँचाता है; वह अपने आप उसकी शुद्धता या भुगतान के सही ऑर्डर से जुड़े होने की गारंटी नहीं देता। [4]
ग्राहक भेजे गए भुगतान की स्क्रीन दिखाता है। फिर भी कर्मचारी अपनी प्रणाली जाँचता है। BTCPay Server में Processing का अर्थ है कि माँगी गई रकम चुकाई गई है, लेकिन निपटान की कुछ शर्तें बाकी हैं, जैसे ब्लॉकों में लेनदेन की पुष्टि। Settled का अर्थ है कि वे शर्तें पूरी हुईं। Lightning भुगतान सामान्यतः ब्लॉक पुष्टियों का इंतज़ार नहीं करते। सामान देना दुकान की नीति, भुगतान विधि और खरीद मूल्य पर निर्भर है। स्थिति हाथ से बदलना नेटवर्क की पुष्टि का प्रमाण नहीं; असामान्य भुगतान पहले सत्यापित करें। [4]
Lightning Network भुगतान चैनलों से तेज़ भुगतान करता है। ये प्रतिभागियों के बीच पहले बनाए गए संबंध हैं। रकम पाने के लिए चालू कनेक्शन और इनबाउंड लिक्विडिटी चाहिए, यानी उन चैनलों से और रकम आने की गुंजाइश। यह व्यापारी की पहले से मौजूद रकम से अलग है। अपना नोड, भुगतान सॉफ़्टवेयर चलाने वाला कंप्यूटर, रखने में चैनल प्रबंधन और नियमित देखभाल चाहिए। कोई सेवा काम आसान कर सकती है, पर व्यापारी उसके संचालन पर निर्भर होगा और मॉडल के अनुसार उसे पैसा भी सौंप सकता है। [2]
समाधान चुनते समय विज्ञापन की एक दर की तुलना पर्याप्त नहीं। नेटवर्क और सेवा शुल्क के अलावा विनिमय दर में लागत हो सकती है: लागू दर और तुलना के लिए चुनी दर का अंतर। इनबाउंड लिक्विडिटी, उपकरण, रखरखाव और कर्मचारियों का समय भी जोड़ें। स्वयं प्रबंधन नियंत्रण और चालू रखने की जिम्मेदारी देता है। सरल सेवा में सीमाएँ तथा प्रदाता के बंद पड़ने या विफल होने का जोखिम हो सकता है। अगली शिफ़्ट को भी प्रक्रिया आनी चाहिए, जिसमें बाधा या गलत राशि संभालना शामिल है। [2] [4]
हिसाब मिलाने के लिए ऑर्डर, भुगतान, विनिमय दर, शुल्क और प्रदाता से मिली रकम का संबंध सुरक्षित रखें। BTCPay Server रिपोर्ट निर्यात कर सकता है, लेकिन केवल उनसे स्थानीय लेखा दायित्व पूरे होने की गारंटी नहीं मिलती। रिफ़ंड नया भुगतान है, मूल लेनदेन मिटाना नहीं। वापसी की मुद्रा और रकम की गणना पहले तय करें तथा ग्राहक के प्राप्ति विवरण जाँचें। BTCPay की बताई प्रक्रिया में रिफ़ंड लिंक बनाना काफ़ी नहीं: ग्राहक द्वारा गंतव्य देने के बाद भुगतान को संसाधित करना भी ज़रूरी है। [5] [6]
उपयोगी सवाल केवल “कितनी जगहें जोड़ीं?” नहीं, बल्कि “क्या वहाँ अब भी भुगतान होता है और ग्राहक लौटते हैं?” भी है। चालू दुकानों, सफल खरीद, दोबारा उपयोग और भुगतान की दिक्कतों को अलग देखें। समान अवधि और परिभाषा की तुलना करें; बंद जगहें और पुरानी जानकारी भी दर्ज रखें। स्थानीय मदद और नियमित जाँच सुविधा को उपयोगी बनाए रखती हैं। जगहों की संख्या ग्राहकों की संख्या नहीं है, और Bitcoin स्वीकार करना अपने आप बिक्री या उसके भाव में बढ़ोतरी की गारंटी नहीं देता। [1] [5]
कॉफ़ी चुक गई, कुछ सवाल बाकी हैं
एक काल्पनिक कैफ़े में कर्मचारी खास ऑर्डर के लिए अनुरोध बनाता है। ग्राहक उसे स्कैन करके Lightning Network से भुगतान करता है। कर्मचारी अपनी प्रणाली में वास्तविक प्राप्ति सत्यापित करके बिक्री पूरी करता है; फ़ोन की तस्वीर पर्याप्त नहीं। यह खरीद बताती है कि उस क्षण प्रक्रिया काम करती थी, नियमित ग्राहकों की संख्या नहीं। कैफ़े bitcoin रखता है या प्रदाता से दूसरी मुद्रा पाता है, इसे अलग दर्ज किया जाता है।
पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें Bitcoin Point of Sale, Bitcoin Payment Processor, BTC Map, Lightning Network, Medium of Exchange, Grassroots Bitcoin Adoption. इस प्रविष्टि का उल्लेख यहाँ भी है Bitcoin Pizza Day, Paralelní Polis, Bitcoin Coffee, BTC Prague.
01क्या व्यापारी को मिला bitcoin रखना ही होगा?+
नहीं। वह स्वयं संभाल सकता है या समर्थित स्थानीय मुद्रा में निपटान देने वाला प्रदाता चुन सकता है। शुल्क, भुगतान की शर्तें और तब तक रकम का नियंत्रण किसके पास है, यह जानना चाहिए। “ग्राहक ने bitcoin दिया” से व्यापारी की अंतिम प्राप्ति-मुद्रा पता नहीं चलती।
02क्या स्टिकर या नक्शा स्वीकार करने की पुष्टि के लिए काफ़ी है?+
वे घोषित या दर्ज सुविधा दिखाते हैं, जो पुरानी हो सकती है। खास जगह और वहाँ आज पूरी भुगतान प्रक्रिया काम करती है या नहीं, जाँचें। लगातार उपयोग का निष्कर्ष निकालने के लिए वास्तविक और दोहराई गई खरीद का डेटा भी चाहिए। एक सफल परीक्षण उसका विकल्प नहीं है।