Bitcoin Point of Sale

कर्मचारी उत्पाद चुनता है या राशि दर्ज करता है और मुद्रा, टिप तथा अंतिम कुल जाँचता है। BTCPay Server कैटलॉग, कार्ट और अंकीय कीपैड देता है। प्रत्येक खरीद को ऑर्डर और इनवॉइस से खोजा जा सकना चाहिए; स्क्रीन दोबारा खोलने पर दूसरा बिक्री रिकॉर्ड नहीं बनना चाहिए। [BTCPay Server — Point of Sale app] [BTCPay Server — Invoice lifecycle]

स्थानीय मुद्रा की कीमत को निर्धारित दर-स्रोत से बदला जाता है; काउंटर को अपेक्षित बिटकॉइन राशि और प्रस्ताव की वैधता दिखानी चाहिए। BOLT 11 में Lightning इनवॉइस का डेटा होता है, जिसमें भुगतान हैश और समाप्ति समय शामिल हैं; राशि वैकल्पिक हो सकती है। किसी विशेष खरीद के लिए वास्तविक राशि, नेटवर्क और प्राप्तकर्ता की जाँच जरूरी है। कीमत की गणना का अर्थ बिटकॉइन को फ़िएट में बेचना नहीं है। [BTCPay Server — Store rates and policies] [Lightning BOLTs — Invoice protocol]

QR कोड केवल भुगतान विवरण देता है। ग्राहक की स्क्रीन का चित्र व्यापारी के सिस्टम की स्थिति का विकल्प नहीं है। BTCPay Server में Processing चुनी गई on-chain पुष्टियों का इंतजार करता है; Settled का अर्थ नीति पूरी होना है, लेकिन इसे हाथ से भी सेट किया जा सकता है। सफल Lightning भुगतान ब्लॉक पुष्टि का इंतजार नहीं करता। इसलिए माल देना सत्यापित भुगतान पर आधारित होना चाहिए, केवल स्क्रीन के रंग पर नहीं। [BTCPay Server — Invoice lifecycle]

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

अपने Lightning नोड के लिए संचालन, चैनल और आने वाली तरलता चाहिए। प्रदाता कुछ काम कर सकता है, लेकिन लागत और भरोसा बदल जाते हैं। रूटिंग विफलता या तरलता की कमी सफल भुगतान नहीं है। दूसरी भुगतान विधि अपनाने से पहले कर्मचारी मूल प्रयास का परिणाम जाँचता है ताकि एक खरीद के लिए दो भुगतान न हों। [BTCPay Server — Lightning setup] [Lightning BOLTs — Invoice protocol]

इंटरनेट, बैकएंड या दर-स्रोत उपलब्ध न होने से नया अनुरोध या प्राप्ति की जाँच रुक सकती है। स्क्रीन पर या कागज़ पर मौजूद कोड ताजा स्थिति के बिना भी पढ़ा जा सकता है। संचालन प्रक्रिया में वैकल्पिक कनेक्शन, बिक्री टालना और बाद में भुगतान खोजना तय होना चाहिए। कम, अधिक और समय समाप्त होने के बाद आए भुगतान अलग-अलग जाँचें; स्थिति हाथ से बदलने से नेटवर्क का इतिहास नहीं बदलता। [BTCPay Server — Invoice lifecycle] [BTCPay Server — Store rates and policies]

धन लौटाने के लिए मूल खरीद से संबंध, सहमत राशि और मुद्रा, सत्यापित गंतव्य तथा अधिकृत मंजूरी चाहिए। BTCPay Server धनवापसी अनुरोध बनाना और रकम भेजना अलग रखता है। इससे मूल हस्तांतरण मिटता नहीं है। कर्मचारी को बनाए गए अनुरोध, लंबित भुगतान और वास्तव में पूरी धनवापसी में फर्क करना चाहिए। [BTCPay Server — Refund workflow]

शिफ्ट खत्म होने पर ऑर्डर, प्राप्त भुगतान, शुल्क, धनवापसी और प्रदाता से संभावित भुगतान का मिलान करें। BTCPay Server भुगतान, बिके उत्पाद और on-chain वॉलेट की रिपोर्ट निर्यात करता है; केवल निर्यात स्थानीय लेखांकन और कर आवश्यकताओं की पूर्ति की गारंटी नहीं देता। कर्मचारी प्रक्रिया, बाधा और पुनर्प्राप्ति का परीक्षण करें, ग्राहक डेटा तक पहुँच सीमित रखें और डिवाइस, कनेक्शन तथा संचालन लागत शामिल करें। [BTCPay Server — Reporting] [BTCPay Server — Point of Sale app] [BTCPay Server — Third-party hosting risks]