हर card processor और हर hosted crypto gateway आपके और आपके customer के बीच बैठता है, एक percentage लेता है, यह सूची रखता है कि किसने आपको क्या चुकाया, और रोकने का अधिकार अपने पास रखता है। BTCPay Server वह software है जो इन्हें हटा देता है: एक open-source, self-hosted, non-custodial payment processor, जहाँ coins सीधे उस wallet में जाते हैं जिससे server खर्च नहीं कर सकता। गुमनाम तरीके से किराए पर लिए गए box पर काम करने वाले Bitcoin और Lightning checkout तक पहुँचने के छह चरण — वह node shape जो बजट तय करता है, watch-only key, inbound-liquidity की समस्या, और वह backup नियम जिसे Lightning तोड़ देता है। box की कीमत $7.90 प्रति माह है। Debian 12 पर परखा गया।
चुनें
Full, pruned या external node
Provision
पहले domain, फिर चार ports
तैनात करें
एक generator, एक command
Connect करें
Watch-only key, कभी seed नहीं
Lightning
Channels और inbound capacity
लॉन्च करें
Checkout, backups, upgrades
blockchain पर किया गया payment बीच में किसी company की माँग नहीं करता। customer एक transaction sign करता है, network उसे confirm करता है, और पैसा आपका हो जाता है — न कोई acquirer, न settlement window और न ही कोई ऐसा व्यक्ति जिसकी मंज़ूरी पर payment निर्भर हो। यही इस पूरी चीज़ का मूल मकसद है, और यही वजह है कि यह technology सिरे से मौजूद है।
फिर एक shop को असल में payments लेने होते हैं, और व्यावहारिक ज़रूरतें एक साथ आ पहुँचती हैं। हर invoice को अपना address चाहिए, ताकि payments अलग-अलग पहचाने जा सकें। किसी को chain पर नज़र रखनी होती है और तय करना होता है कि कोई invoice कब चुकाया गया। रकम उस currency में बतानी होती है जिसमें customer सोचता है, और उस rate पर जो send दबाने तक टिकी रहे। order status वापस shop में पहुँचना होता है। और यह बिना किसी की निगरानी के रात के दो बजे भी काम करना होता है। यह सब बनाना एक प्रोजेक्ट है; इसे न बनाना ही वजह है कि लगभग हर कोई इसके बजाय किसी hosted gateway के साथ sign up कर लेता है — और, एक फ़ॉर्म भरने भर में, उस सिस्टम में फिर से एक बिचौलिया जोड़ देता है जिसे बिना बिचौलिये के डिज़ाइन किया गया था।
वह बिचौलिया असल में क्या-क्या रखता है, यह साफ़-साफ़ कहना ज़रूरी है, क्योंकि यह सिर्फ़ fee से कहीं ज़्यादा है। यह coins रखता है, कम से कम जब तक कोई payout न चले, यानी यह उसे टाल सकता है। यह सूची रखता है: हर customer, हर रकम, हर timestamp, हर product, एक ऐसे database में जिसे आप न पढ़ सकते हैं न मिटा सकते हैं। यह आप पर एक पहचान फ़ाइल रखता है, क्योंकि दूसरों का पैसा छूने वाली किसी company को यह इकट्ठा करना ज़रूरी होता है। और यह वह स्विच रखता है, क्योंकि terms of service यह तय करने का अधिकार अपने पास रखते हैं कि आपका व्यवसाय अब स्वागत-योग्य नहीं रहा — एक ऐसा फ़ैसला जो email से आता है, balance और account दोनों पर लागू होता है, और व्यवहार में अपील के लायक नहीं होता।
BTCPay Server ठीक इसी समस्या का जवाब है, और किसी और चीज़ का नहीं। यह एक free, open-source payment processor है जिसे आप अपनी ही मशीन पर चलाते हैं: यह हर invoice के लिए एक address derive करता है, chain पर नज़र रखता है, fiat कीमतें बताता है, एक checkout और एक API उपलब्ध कराता है, और Lightning भी बोलता है। यह आपके coins कभी नहीं रखता, क्योंकि जिस wallet पर यह नज़र रखता है वह पहले से आपका अपना है। crypto payment लेने के चार तरीके, और हर एक की असली कीमत क्या है:
| विशेषता | एक hosted crypto gateway | footer में एक कच्चा address | किसी और के instance पर BTCPay | अपने ही VPS पर BTCPay |
|---|---|---|---|---|
| coins किसके पास हैं | Gateway, payout तक | आप | आप — यह नज़र रखता है, यह खर्च नहीं कर सकता | आप — यह नज़र रखता है, यह खर्च नहीं कर सकता |
| आपका व्यापार कौन रोक सकता है | Gateway, email के ज़रिए | कोई नहीं | instance का operator | कोई नहीं |
| हर customer और रकम कौन देखता है | Gateway, स्थायी रूप से | सबके लिए — एक address, एक सार्वजनिक कुल | instance का operator | आप |
| पहचान-पत्र ज़रूरी | हाँ, पहले payout से पहले | नहीं | operator जो भी माँगे | नहीं |
| प्रति transaction लागत | एक percentage, हमेशा के लिए | कुछ नहीं | कुछ नहीं | कुछ नहीं — $7.90 प्रति माह, तय |
| एक invoice को दूसरे से अलग बताता है | हां | नहीं — आप हाथ से reconcile करते हैं | हां | हां |
| इसे चुनें जब | आपको शून्य operations चाहिए और आप शर्तें स्वीकार करते हैं | Donations, साल में मुट्ठी-भर | आपको software चाहिए पर server नहीं | कमाई आपकी है और सूची भी आपकी ही है |
दूसरा column भी कोई मज़ाक नहीं है — footer में एक अकेला address किसी donation link के लिए सचमुच ठीक है, और इससे उलट मान लेना ऐसा software बेचना है जिसकी किसी को ज़रूरत नहीं। यह ठीक रहना उसी पल बंद हो जाता है जब दो लोग एक ही दिन एक ही रकम चुकाते हैं, या जिस पल आप चाहेंगे कि आपकी सालाना आमदनी कोई ऐसा सार्वजनिक आँकड़ा न हो जिसे कोई भी जोड़ सके।
एक payment processor को ईमानदारी से एक सवाल का जवाब देना होता है: क्या यह invoice चुका दिया गया है? इसका जवाब देने के लिए Bitcoin network पर नज़र रखनी पड़ती है, और उसे सही तरीके से देखने का मतलब है ऐसा node चलाना जो खुद blocks को validate करे, न कि किसी और की बात पर भरोसा करे। वह node ही इस प्रोजेक्ट का पूरा hardware बजट है — BTCPay खुद, indexer और database मिलकर भी उसके सामने एक rounding error भर हैं।
तीन व्यवस्थाएँ ऐसी हैं जो मायने रखती हैं और एक ऐसी है जो नहीं रखती। एक archival node अब तक mine हुआ हर block रखता है: 2026 में आराम से 700 GB पार और हर साल करीब 50 GB बढ़ते हुए। अगर आप एक block explorer भी चलाना चाहते हैं या historical analysis करना चाहते हैं तो यही चाहिए, और किसी shop के लिए यह ज़रूरत से ज़्यादा है। एक pruned node हर block को ठीक उसी तरह download और पूरी तरह validate करता है, फिर पुराने blocks फेंककर एक rolling window रखता है। security model बिल्कुल एक जैसा है — यहीं लोग गलती करते हैं, क्योंकि "pruned" सुनने में "partial" जैसा लगता है, जबकि है नहीं — और deployment generator इसके लिए तैयार fragments देता है।
External node तीसरा विकल्प है: stack को उस Bitcoin node की ओर इंगित करें जिसे आप पहले से खुद चला रहे हैं, एक private link के ज़रिए। अगर आपने पहले ही Lightning node गाइड फॉलो कर लिया है तो chain की दूसरी copy रखने की कोई वजह नहीं है, और दोनों boxes के बीच एक mesh VPN उन्हें जोड़ने का सबसे सीधा तरीका है। जो व्यवस्था कोई मायने नहीं रखती वह है shop को किसी अजनबी के public node पर इंगित करना: इससे वह हर वह address जान लेता है जिसे आप देख रहे हैं, जो आपका राजस्व है, और वह यह झूठ बोलने की स्थिति में भी है कि कोई invoice चुकाया गया था या नहीं।
| Deployment | Disk पर chain | कुल ज़रूरी volume | आप क्या खो देते हैं |
|---|---|---|---|
| Pruned, सबसे छोटी window | ~5–25 GB | ~40 GB | Rescans, और गलती के लिए कोई भी गुंजाइश। सबसे छोटी setting की सलाह नहीं दी जाती। |
| Pruned, ~50 GB window | ~50 GB | ~80 GB | जो किसी shop को नज़र ही नहीं आता। समझदारी भरा न्यूनतम स्तर। |
| Pruned, ~100 GB window | ~100 GB | ~140 GB | कुछ नहीं। आरामदायक default, Lightning के लिए गुंजाइश के साथ। |
| Archival, पूरा इतिहास | 700 GB + | ~960 GB | कुछ नहीं — पर आप इसे हर महीने, हमेशा के लिए चुकाते हैं। |
| बाहरी node जिसे आप पहले से चला रहे हैं | इस box पर कोई नहीं | ~40 GB | स्वतंत्रता — checkout तभी बंद होता है जब दूसरा box बंद हो। |
एक pruned node उन blocks को rescan नहीं कर सकता जिन्हें वह पहले ही फेंक चुका है। व्यवहार में इसका मतलब है कि वह ऐसे wallet का इतिहास फिर से नहीं बना सकता जिसके transactions deployment से पहले के हों — indexer उसी दिन से आगे scan करता है जिस दिन आप key जोड़ते हैं, इसलिए उस account को हुए पुराने payments store में बिल्कुल नहीं दिखेंगे। अगर आप वही करते हैं जो चरण 04 सुझाता है और shop को एक बिल्कुल नया बनाया account देते हैं, तो यह कोई समस्या नहीं है; लेकिन अगर आप तीन साल से इस्तेमाल हो रहा wallet जोड़ते हैं और उसका आधा इतिहास गायब है, तो यह सचमुच उलझन भरी दोपहर बन जाती है। install करने से पहले ही तय कर लें कि आप क्या करने जा रहे हैं, बाद में नहीं।
एक और फ़ैसला बाद में नहीं बल्कि यहीं का है, क्योंकि यह तय करता है कि installer क्या बनाएगा: क्या आपको पहले दिन से ही Lightning चाहिए। On-chain-only एक पूरा configuration है और वहाँ से launch करने की जगह पूरी तरह सम्मानजनक है। Lightning को बाद में जोड़ना supported है और दर्दनाक नहीं, लेकिन यह अपने funds और अपने backup नियमों वाला एक दूसरा daemon है, और जटिल रास्ता अपनाने से पहले यह साबित कर लेने में बहुत मायने है कि असली पैसा साधारण रास्ते से पहुँचता है।
box order करें। panel में: Order → VPS → Garrison, image Debian 12, जिस भी bastion में आप shop के records रखना चाहें — Helsinki, Stockholm, Oslo या Reykjavík। Garrison सही default है क्योंकि यह एक 100 GB pruned chain, एक Lightning node और database को बिना आपको वर्षों तक disk के बारे में दोबारा सोचे रखता है। Sentinel एक तंग prune के साथ काम करता है; Bulwark archival node के लिए tier है। account खोलने के लिए किसी email address की ज़रूरत नहीं है और invoice Monero, Bitcoin, Lightning या किसी अन्य supported asset में settle होता है — जो इस खास प्रोजेक्ट का सुखद हिस्सा है, क्योंकि आप crypto payments लेने वाली मशीन बना रहे हैं और उसी में इसका भुगतान भी कर रहे हैं।
फिर बाकी सब कुछ से पहले पहले घंटे वाली hardening checklist चलाएँ — किसी बदले हुए port पर सिर्फ़-key वाला SSH, unattended upgrades, एक default-deny firewall। यह box आगे चलकर आपके हर customer का रिकॉर्ड और जीवित funds वाले Lightning node की key सामग्री रखेगा। यह ऐसा box नहीं है जिसे हफ़्ते भर password authentication के भरोसे छोड़ दिया जाए।
अब DNS record की बारी है, और इसे installer चलाने के बाद नहीं बल्कि पहले करें। वह hostname चुनें जिस पर checkout रहेगा — shop.example.com, pay.example.com, जो भी फिट बैठे — और VPS के address की ओर एक A record इंगित करें, साथ में अगर IPv6 पर पहुँच चाहिए तो एक AAAA भी। इसे propagate होने दें। installer जो reverse proxy सेट करता है वह अपने पहले boot के दौरान ठीक उसी नाम के लिए एक certificate पाने की कोशिश करेगा, एक HTTP challenge के ज़रिए जिसे यह चाहिए कि वह नाम पहले से इसी मशीन तक resolve हो। एक ऐसा record जो अभी live नहीं है, पहले install के उलझन भरी गलती में ख़त्म होने का सबसे आम तरीका है।
deployment बाद में domain बदलने के लिए एक script देता है, इसलिए यह घातक नहीं बल्कि सुधारा जा सकने वाला मामला है। जो एक command में ठीक नहीं होता वह है आगे की हर चीज़: certificate दोबारा जारी होता है, आपने जो भी pay button और webhook URL बाँटे हैं वे पुराने नाम पर ही इंगित करते रहते हैं, एक Lightning address किसी domain पर एक नाम होता है और उसी के साथ चलता है, और किसी भी shop plugin को दोबारा configure करना पड़ता है। ऐसा नाम चुनें जिसे आप वर्षों तक letterhead पर रखने को तैयार हों, और मशीन क्या करती है यह बताने वाले किसी नए domain के बजाय अपने पहले से प्रकाशित domain के किसी subdomain को तरजीह दें।
फिर, जब तक कुछ भी listen नहीं कर रहा, firewall नियम लिख डालें। चार ports, बस चार। checkout ज़रूरी तौर पर एक सार्वजनिक HTTPS endpoint है — किसी customer के browser को इस तक पहुँचना ही है — और port 80 खुला रहता है क्योंकि certificate renewal इसका इस्तेमाल करता है। Lightning peer-to-peer port तभी चाहिए जब आप चाहें कि दूसरे nodes आपकी ओर channels खोल सकें, और चरण 05 तर्क देगा कि आपको यह चाहिए। Bitcoin peer-to-peer port को बिल्कुल भी खुला रखने की ज़रूरत नहीं: आपका node outbound connections बख़ूबी बना लेता है, और इसे inbound खोलने से बस इसे ढूँढना आसान हो जाता है।
ufw default deny incoming
ufw allow 47222/tcp # administrative SSH, moved off 22
ufw allow 80/tcp # ACME HTTP-01 challenge and the redirect
ufw allow 443/tcp # the checkout
ufw allow 9735/tcp # Lightning peer-to-peer, only if you want inbound channels
ufw enable
ufw status numbered
आगे बढ़ने से पहले resource से जुड़े दो नोट्स। अगर box में swap नहीं है तो इसे दें — शुरुआती block download इस प्रोजेक्ट का memory-भूखा घंटा है और 2 GB swap के साथ 4 GB RAM अकेले 4 GB से कहीं बेहतर व्यवहार करता है। और चरण 01 का disk हिसाब उस tier से मिलाकर देखें जो आपने असल में order किया है, क्योंकि sync के बीच में अपना volume भर देने वाला node विनम्रता से फेल नहीं होता; यह अपना ही index corrupt कर देता है और फिर से शुरू हो जाता है।
fallocate -l 2G /swapfile && chmod 600 /swapfile
mkswap /swapfile && swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab
df -h / # confirm the volume matches step 01
आधिकारिक deployment कोई docker-compose.yml नहीं है जिसे आप edit करें। यह एक generator है: आप चाहा गया deployment environment variables में describe करते हैं, और एक script fragments की एक library से compose file जोड़ देता है — एक Bitcoin Core के लिए, एक indexer के लिए, एक PostgreSQL के लिए, एक BTCPay application के लिए, हर Lightning implementation के लिए एक, एक reverse proxy के लिए, और वैकल्पिक अतिरिक्त चीज़ों की एक लंबी सूची। यह पहली नज़र में दिखने से बेहतर design है, क्योंकि upgrades किसी और के बदलाव आपके अपने में मिलाने के बजाय file को दोबारा बना देते हैं। इसका यह भी मतलब है कि नीचे दिया environment block आपके deployment का असली configuration है, और इसे अपने बाकी infrastructure नोट्स के साथ ही रखने लायक है।
repository को clone करें और environment export करें। नीचे की हर line सीधे चरण 01 के किसी फ़ैसले से जुड़ी है: host name वही domain है जिसे आपने चरण 02 में इंगित किया था, storage fragment वही prune window है जो आपने चुना, और Lightning variable या तो कोई implementation है या on-chain-only launch के लिए पूरी तरह छोड़ दिया गया है।
mkdir BTCPayServer && cd BTCPayServer
git clone https://github.com/btcpayserver/btcpayserver-docker
cd btcpayserver-docker
export BTCPAY_HOST="pay.example.com" # exactly the name you pointed in step 02
export NBITCOIN_NETWORK="mainnet"
export BTCPAYGEN_CRYPTO1="btc"
export BTCPAYGEN_REVERSEPROXY="nginx"
export BTCPAYGEN_LIGHTNING="clightning" # or "lnd", or omit for on-chain only
export BTCPAYGEN_ADDITIONAL_FRAGMENTS="opt-save-storage-s" # ~50 GB pruned window
export BTCPAY_ENABLE_SSH=true
export LETSENCRYPT_EMAIL="you@example.com"
. ./btcpay-setup.sh -i
उस block में दो बातें एक-एक वाक्य की हक़दार हैं। . ./btcpay-setup.sh -i में शुरुआती dot कोई typo नहीं है — script execute होने के बजाय source होती है, इसलिए यह जो environment सेट करती है वह आपके shell में बना रहता है और मददगार commands बाद में भी काम करते हैं। और storage fragment का नाम version-sensitive है: generator ने करीब 100, 50, 25 और 5 GB तक prune करने वाले variants ऐसे नामों के साथ दिए हैं जो releases के बीच बदलते रहे हैं। किसी blog post से — इसमें शामिल — कॉपी की गई value पर भरोसा करने के बजाय अभी clone की गई repository में fragment list पढ़ें।
installer कुछ मिनट लेगा, कई images pull करेगा, certificate प्राप्त करेगा और सब कुछ शुरू कर देगा। फिर इंतज़ार शुरू होता है: shop किसी payment की पुष्टि कर पाए इससे पहले node को chain download और validate करनी होती है, जो pruned होने पर भी मिनटों में नहीं बल्कि घंटों में होता है, क्योंकि pruning काम छोड़ने के बजाय blocks को validate करने के बाद ही फेंकती है। web interface तुरंत उपलब्ध हो जाता है और आपको एक synchronisation बैनर दिखाएगा। जब तक वह गायब न हो जाए, तब तक कोई असली invoice जारी न करें।
./bitcoin-cli.sh getblockchaininfo | grep -E 'blocks|headers|verificationprogress|pruned'
docker ps --format '{{.Names}}\t{{.Status}}'
एक ताज़ा instance में कोई user नहीं होता, और register करने वाला पहला account administrator बन जाता है। जब तक आप इस पर दावा नहीं करते, URL तक पहुँचने वाला कोई भी व्यक्ति ऐसा कर सकता है — और URL गुप्त नहीं है: certificate जारी होते ही, hostname सार्वजनिक certificate-transparency logs में प्रकाशित हो जाता है, जिन्हें ठीक इसी चीज़ की तलाश करने वाले लोग लगातार index और scan करते रहते हैं। सबसे पहले site खोलकर register करें, फिर Server Settings जाँचें और पुष्टि करें कि registration अजनबियों के लिए खुला नहीं है। यह पाँच मिनट की खिड़की है जिसे लोग दिनों तक खुला छोड़ देते हैं क्योंकि उनका मानना होता है कि shop "अभी live नहीं है"।
जब तक आप configuration में ही हैं, दो वैकल्पिक fragments जानने लायक हैं। एक Tor hidden service जोड़ता है, ताकि checkout clearnet वाले के साथ-साथ एक v3 onion address पर भी पहुँच में रहे — उन customers के लिए उपयोगी जो आपका domain resolve नहीं करना चाहते, और यह वही विचार है जो onion service गाइड में है। दूसरा एक दूसरी cryptocurrency जोड़ता है। दोनों एक ही तरीके से सेट होते हैं, additional-fragments variable में जोड़कर और setup script फिर से चलाकर; generator compose file को दोबारा बनाता है और सिर्फ़ बदली हुई चीज़ों को restart करता है।
एक store बनाएँ, और फिर इस page का वह इकलौता फ़ैसला लें जो वाकई मायने रखता है। BTCPay Bitcoin wallet जोड़ने के दो तरीके देगा: कोई मौजूदा wallet जोड़ें, या इसे एक नया wallet बनाने दें और seed को server पर रखें। पहला तरीका watch-only है और यही वह है जो आपको चाहिए। दूसरा तरीका एक सार्वजनिक, internet-facing मशीन को आपकी कमाई रखने वाला hot wallet बना देता है, और चाहे कितनी भी hardening कर लें, ऐसे box के लिए यह अच्छा सौदा नहीं बनता जिसका पूरा काम ही अजनबियों तक पहुँच में रहना है।
इस सलाह के पीछे की व्यवस्था इतनी सुरुचिपूर्ण है कि समझने लायक है। आधुनिक wallets hierarchical होते हैं: एक seed keys का पूरा पेड़ derive करता है, और एक extended public key होती है — एक xpub, या native segwit के लिए इसका zpub रूप — जिससे किसी account का हर receiving address बिना sign करने की किसी क्षमता के निकाला जा सकता है। इसे store को दे दें और यह हर invoice के लिए एक नया address बना सकता है, हर एक पर होने वाले payments के लिए chain देख सकता है, और आपको balance दिखा सकता है। यह एक satoshi भी हिला नहीं सकता। private half आपके wallet में, या आपके hardware device पर ही रहता है, और कभी बाहर नहीं जाता।
तो: Sparrow, Electrum, या अपने hardware wallet का desktop app खोलें, इस shop के लिए dedicated एक नया account बनाएँ, और इसकी extended public key export करें। store की wallet settings में कोई मौजूदा wallet जोड़ने का विकल्प चुनें, key paste करें, और BTCPay जो पहले कुछ addresses derive करता है उन्हें अपने wallet में दिखने वाले addresses से मिलाकर देखें। अगर वे मेल खाते हैं, तो derivation path सही है और जोड़ना पूरा हो गया। अगर नहीं, तो आपने गलत script type चुना है — xpub और zpub के बीच का फ़र्क़ दो पूरी तरह अलग-अलग सेट के addresses जितना बड़ा है।
यह खर्च नहीं कर सकता, और यही अहम बात है — लेकिन यह गिन ज़रूर सकता है। जिसके पास भी यह पहुँचे वह उन सभी addresses को derive कर सकता है जो वह account कभी इस्तेमाल करेगा, और इसलिए जब तक आप इसे इस्तेमाल करते हैं, तब तक उसे मिले और मिलने वाले हर payment को पढ़ सकता है। यह आपकी shop की कमाई का एक स्थायी, न पलटा जा सकने वाला खुलासा है, और यही वजह है कि जो account आप जोड़ें वह आपकी बचत रखने वाले account के बजाय shop के लिए dedicated होना चाहिए। key को गोपनीय मानें, इसे screenshots और support tickets से दूर रखें, और अगर यह लीक हो ही जाए तो उम्मीद लगाने के बजाय shop को एक नए account पर ले जाएँ।
अब invoice settings की बारी है, जहाँ असल में shop को tune किया जाता है। Expiry default रूप से करीब पंद्रह मिनट की होती है और यह कोई technical सीमा नहीं बल्कि एक rate lock है: यह बताती है कि आप किसी अस्थिर asset के मुकाबले fiat में तय कीमत कितनी देर तक थामे रखना चाहते हैं। किसी अस्थिर बाज़ार के लिए इसे छोटा करें, अगर customers धीमे हैं तो इसे लंबा करें। Confirmations तय करते हैं कि कोई invoice कब settled गिना जाए — zero-confirmation तुरंत होता है और कॉफ़ी के लिए ठीक है, एक confirmation सामान्य default है, और छह उन रकमों के लिए है जहाँ एक घंटे का इंतज़ार विकल्प से सस्ता पड़ता है। Underpayment tolerance आपको ऐसा invoice स्वीकार करने देती है जो थोड़ी-सी कम राशि में पहुँचे, जो तब लगातार होता है जब customer का wallet रकम में जोड़ने के बजाय उसमें से अपनी fee काट लेता है; यहाँ थोड़ा-सा percentage support email की एक पूरी category हटा देता है।
फिर इसे असली पैसों से परखें, testnet से नहीं। किसी मामूली रकम के लिए एक payment request जारी करें, इसे किसी phone wallet से चुकाएँ, और invoice को new से processing होते हुए settled तक जाते देखें। वह अकेला transaction साबित कर देता है कि node synchronised है, derivation path सही है, rate provider काम कर रहा है, certificate mobile browser पर मान्य है, और पैसा आपके नियंत्रण वाले wallet में पहुँच गया। और कुछ भी इन पाँचों को एक साथ साबित नहीं करता।
On-chain Bitcoin एक $400 वाले invoice को बख़ूबी settle करता है और एक $4 वाले को बुरी तरह: customer एक confirmation का इंतज़ार करता है और एक ऐसी fee चुकाता है जो खरीद का एक ध्यान देने लायक हिस्सा हो सकती है। Lightning दोनों को उलट देता है — करीब दो सेकंड में settlement, और fees सेंट के अंशों में — यही वजह है कि छोटी चीज़ें बेचने वाली shop को इसकी ज़रूरत होती है और बड़ी चीज़ें बेचने वाली shop को शायद न हो। अगर आपने चरण 03 में कोई Lightning implementation सेट किया है, तो daemon पहले से चल रहा है और BTCPay उससे पहले ही जुड़ चुका है; store settings में बस Lightning को एक payment method के तौर पर चालू करना बाकी रहता है।
आपने जो implementation चुना उसके नाम लेने लायक नतीजे हैं। Core Lightning साफ़-सुथरे plugin architecture वाला रूढ़िवादी, हल्का विकल्प है। LND सबसे ज़्यादा deploy किया गया है और इसके इर्द-गिर्द management tools का सबसे बड़ा ecosystem है। अब एक तीसरी तरह का विकल्प भी है — एक हल्का daemon जो keys आपकी मशीन पर रखते हुए channel management किसी service provider को सौंप देता है — जो कुछ स्वतंत्रता के बदले अगले तीन paragraphs की हर चीज़ को गायब कर देता है। यह उस shop के लिए एक वाजिब विकल्प है जिसे Lightning तो चाहिए पर node operator नहीं बनना, बस यह एक अलग सौदा है, मुफ़्त वाला नहीं।
एक Lightning channel में एक तय राशि होती है, जो दोनों छोर के बीच बँटी होती है। जब आप कोई channel खोलते हैं और उसे fund करते हैं, तो वह पूरी राशि आपके पक्ष में होती है — यानी send करने की क्षमता, और receive करने की बिल्कुल शून्य क्षमता। एक shop को इसका उल्टा चाहिए होता है। इसलिए तीन healthy channels वाला ताज़ा-fund किया गया node भी हर एक incoming invoice में फेल हो सकता है, और यह विफलता किसी configuration की गलती के बजाय routing error जैसी दिखती है। यही सबसे आम वजह है कि एक self-hosted Lightning checkout पहले ही दिन खराब नज़र आता है।
inbound capacity पाने के तीन ईमानदार तरीके हैं, और ये एक-दूसरे को नकारते नहीं। आप outbound channels खोल सकते हैं और फिर उनके ज़रिए खर्च कर सकते हैं — कुछ खरीदकर, कोई invoice चुकाकर, किसी exchange में पैसा भेजकर — जो आपके balance को दूसरे छोर पर धकेल देता है और send करने की क्षमता को receive करने की क्षमता में बदल देता है। आप किसी अच्छी तरह जुड़े हुए node से अपनी ओर channel खोलने को कह सकते हैं, जो Lightning समुदाय में एक सामान्य अनुरोध है और peer की on-chain fee के अलावा मुफ़्त है। या आप इसे बेचने वाली कई services में से किसी एक से inbound liquidity खरीद सकते हैं, जिसकी कीमत थोड़ा-सा percentage होती है और यह हफ़्तों की जगह मिनटों में हो जाता है। इस page पर कोई affiliate सिफ़ारिश नहीं है और न कभी होगी; प्रतिष्ठा और मौजूदा कीमत के आधार पर चुनें।
एक बार जब आपको भुगतान मिल सकता है, तो दो features node को एक shop front में बदल देते हैं। एक Lightning address — बिल्कुल किसी email address जैसी शक्ल में, आपके अपने domain पर — किसी को भी बिना पहले से किसी invoice के, किसी भी आधुनिक wallet से आपको पैसे भेजने देता है, जो कहीं भी उपलब्ध donation और tipping का सबसे सुगम तरीका है। और checkout page पर मौजूद QR code एक साथ दोनों rails दे सकता है, ताकि Lightning wallet वाला customer सेकंडों में भुगतान करे और बिना वाला customer उसी screen से, बिना आपकी किसी फ़ैसले की ज़रूरत के, on-chain भुगतान करे।
पहला Lightning payment आने से पहले, वह backup वाला चरण पूरा कर लें जो अभी होना चाहिए, बाद में नहीं। हर implementation एक छोटी-सी file रखता है जो आपके channels की मौजूदा state बताती है — LND इसे static channel backup कहता है — और यही वह artefact है जो मशीन खो जाने पर आपको funds वापस पाने देता है। यह हर बार channel खुलने या बंद होने पर बदल जाती है, इसलिए इसे हाथ से नहीं बल्कि अपने-आप box से बाहर copy करें। यह मान लेने से पहले कि आपका रात वाला archive पहले से इसे cover करता है, चरण 06 की चेतावनी पढ़ लें, क्योंकि खासतौर पर Lightning के लिए ऐसा नहीं है।
वह सबसे छोटा checkout surface चुनें जो आपके पास पहले से मौजूद चीज़ों में फिट बैठे। एक payment request एक link है जो आप किसी को भेजते हैं — किसी website की ज़रूरत नहीं, और किसी client को invoice भेजने का सबसे तेज़ तरीका। एक point of sale app उसी instance को product list वाले एक till में बदल देता है, जो market stall पर फ़ोन से भी काम करता है। एक pay button किसी static site के लिए HTML का एक snippet भर है। एक shop plugin किसी असली storefront में Bitcoin को एक payment method के तौर पर जोड़ता है और order status अपने-आप वापस लिख देता है। और REST API invoices जारी करता है, उनकी state बताता है और settle होने पर एक webhook कॉल करता है, जो सबसे अच्छी तरह टिकने वाला integration है क्योंकि यह सिर्फ़ HTTP और एक shared secret पर निर्भर है।
आप जो भी चुनें, webhook जोड़ें और फिर परखें कि वह चलता है। ऐसा invoice जो settle हो जाए और आपके application को कभी सूचित न करे, वह failure mode है जिसे कोई नहीं पकड़ पाता, क्योंकि अलग-अलग देखने पर दोनों तरफ़ सब सही लगता है: पैसा पहुँच गया, customer ने एक confirmation page देखा, और order अधूरा पड़ा रह गया। जान-बूझकर खुद को एक settled-invoice webhook भेजें, पुष्टि करें कि आपके endpoint को यह मिला, और payload पर भरोसा करने के बजाय signature जाँचें — वह endpoint सार्वजनिक है और कोई भी उस पर post कर सकता है।
इस page पर यही एक चेतावनी है जो आपका समय नहीं बल्कि पैसा ले सकती है, और प्रोजेक्ट का अपना documentation भी ठीक इन्हीं शब्दों में इसे कहता है: पुरानी Lightning channel state ज़हरीली होती है। कल रात के channel database की copy restore करके node को चलने देने का मतलब है ऐसी state प्रसारित करना जिसे आपका counterparty पहले ही बदल चुका है — जिसे protocol धोखा देने की कोशिश मानता है और उन्हें पूरा channel balance देकर सज़ा देता है। इसलिए store database, configuration और invoice इतिहास के लिए archive सही है, पर यह channels के लिए कोई recovery योजना नहीं है। static channel backup को लगातार मशीन से बाहर copy करें, सबसे नई वाली रखें, और अगर आप कभी किसी archive से पूरा server restore करें, तो यह जानते हुए करें कि Lightning वाले हिस्से को सीधे restore के बजाय documented recovery प्रक्रिया चाहिए।
यह समझ लेने के बाद, रूटीन छोटा है। deployment एक backup script देता है जो volumes को archive करता है और blockchain data छोड़कर database dump करता है, और यह एक passphrase स्वीकार करता है ताकि archive box से निकलने से पहले ही encrypt हो जाए। इसे किसी timer पर चलाएँ, फिर नतीजे को किसी दूसरे jurisdiction वाली मशीन पर उसी तरह भेजें जैसे backups गाइड बताता है — यहाँ अतिरिक्त दस मिनट खर्च करके एक append-only repository बनाना उचित है, क्योंकि किसी compromised payment server को यह मिटा पाने में सक्षम नहीं होना चाहिए कि उसने क्या-क्या process किया।
cd ~/BTCPayServer/btcpayserver-docker
export BTCPAY_BACKUP_PASSPHRASE="a long passphrase you keep elsewhere"
./btcpay-backup.sh # archives volumes + database, skips the chain
# then ship the archive offsite, and keep the channel backup separately
इसके बाद upgrades आते हैं, और payment box वह अकेली मशीन है जहाँ "इसे बाद में, जान-बूझकर update करें" सही नीति है। deployment का अपना update script है जो compose file दोबारा बनाता है और नई images pull करता है; इसे तब चलाएँ जब आपने release notes पढ़ लिए हों, तब नहीं जब किसी cron job का मन करे। पहले archive लें। एक बार में एक ही release बढ़ाएँ। और पिछला version कहीं लिखकर रखें, क्योंकि एक मिनट में किया जा सकने वाला rollback ही पूरी चीज़ को कम-जोखिम वाला बनाता है।
./btcpay-update.sh # deliberate, after reading the release notes
df -h / # the check that should be an alert, not a habit
आख़िर में, एक अलर्ट और एक रिमाइंडर सेट करें। अलर्ट disk usage पर है — एक blockchain node मशीन की वह अकेली process है जो अपने-आप बढ़ती है, और एक भरा हुआ volume checkout को ऐसे तरीके से गिरा देता है जिसे पहचानना मुश्किल होता है क्योंकि और कुछ नहीं बदला। इसे अस्सी प्रतिशत पर चलाएँ, पचानवे पर नहीं। रिमाइंडर मासिक है, और इसका मकसद है store खोलकर दो चीज़ें देखना: कि invoices अब भी settle हो रहे हैं, और कि आपके खोले गए Lightning channels अब भी जीवित हैं। एक payment processor चुपचाप फेल होता है, और आपको इसका पता तब चलता है जब कोई customer बताता है कि वह भुगतान नहीं कर सका।
processor को self-host करना एक असली और सुनिश्चित सुधार है, और यह कोई गायब हो जाने वाला जादू नहीं है। ऊपर बताई गई हर चीज़ हो जाने के बाद भी पाँच बातें सच बनी रहती हैं, और इन्हें जानना ही किसी सचमुच के बचाव और सिर्फ़ मन बहलाने वाली कहानी के बीच का फ़र्क़ है।
Bitcoin ledger सार्वजनिक और स्थायी है। gateway हटाने से किसी company का private database हट गया; इससे chain encrypt नहीं हुई। आपकी shop को मिलने वाला हर payment किसी भी ऐसे व्यक्ति को हमेशा के लिए दिखता है जो कोई address जानता है, और addresses क्लस्टर बनाते हैं: जो wallet दो payments को एक ही खर्च में मिला देता है, वह दुनिया को बता देता है कि वे दोनों customers एक ही shop को चुका रहे थे। यह asset का गुण है, software का नहीं, और यही वजह है कि सच्ची privacy ज़रूरत वाला कोई व्यवसाय Monero को भी देखता है।
checkout का hostname बनते ही प्रकाशित हो जाता है। Certificate transparency logs सार्वजनिक होते हैं और लगातार index किए जाते हैं, इसलिए चरण 02 में चुना गया नाम खोजा जा सकता है, भले ही आप उसे कभी link न करें। यही वजह है कि administrator account पहले हफ़्ते में नहीं बल्कि पहले मिनटों में claim करना ज़रूरी है, और login page को पहले दिन से ही एक मज़बूत password और एक second factor मिलना चाहिए।
fiat की ओर निकास वह जगह है जहाँ पहचान वापस आ जाती है। इस stack में कुछ भी आपको payment स्वीकार करने के लिए खुद की पहचान बताने पर मजबूर नहीं करता। कमाई को बैंक के पैसे में बदलना लगभग हमेशा ऐसा करता है, क्योंकि वह conversion किसी regulated exchange या broker पर होता है। Self-hosting पहचान की माँग को बिक्री के बिंदु से हटाकर निकास के बिंदु पर ले जाती है — यह जोखिम में एक असली सुधार है, इसकी अनुपस्थिति जैसा नहीं।
आपके reporting दायित्व server के साथ नहीं गए। व्यवसाय कहाँ registered है और उसका मालिक कहाँ रहता है, यही तय करता है कि क्या देना है और क्या declare करना है। invoices जारी करने वाली मशीन का jurisdiction इसमें कोई भूमिका नहीं निभाता। ज़्यादातर जगहों पर, सामान या सेवाओं के बदले crypto पाना उसी दिन की कीमत पर सामान्य आय है, और बाद में इसे बेचना फिर से एक अलग घटना है। एक self-hosted instance किसी ऐसे processor account से बेहतर रिकॉर्ड है जिसे आप खो सकते हैं — यह रिकॉर्ड न रखने का तरीका नहीं है।
कोई chargebacks नहीं होते, और इसका असर दोनों तरफ़ पड़ता है। एक confirmed payment अंतिम होता है, और यही वह गुण है जो merchant के खिलाफ धोखाधड़ी को लगभग असंभव बनाता है और जिसकी वजह से fee शून्य होती है। यही वजह है कि किसी नाखुश customer के पास आपकी सद्भावना के अलावा कोई तंत्र नहीं होता। एक refund policy प्रकाशित करें, उसे निभाने के लिए payout feature का इस्तेमाल करें, और यह समझें कि अब dispute-resolution का वह काम आपके ज़िम्मे है जिसके लिए पहले वह percentage चुकाया जाता था।
आपने असल में जो ठीक-ठीक ख़रीदा है वह यह है: पैसा एक ऐसे wallet में पहुँचता है जिससे सिर्फ़ आप ही खर्च कर सकते हैं, कोई बिक्री रोक नहीं सकता, कोई हिस्सा नहीं लेता, और किसने आपको क्या चुकाया इसकी सूची सिर्फ़ उस मशीन पर मौजूद है जिसे आप बिना किसी खास नाम के किराए पर लेते हैं। यह एक संकरा दावा है और एक असली भी। यह अपनी कीमत तभी वसूल करता है जब चरण 06 पूरा हो — बिना परखे गए restore वाला self-hosted payment processor कोई व्यावसायिक सुधार नहीं है, यह आपकी कमाई थामे हुए एक single point of failure है।
| स्तर | मासिक | संसाधन | यह आराम से क्या चला सकता है |
|---|---|---|---|
| Sentinel | $3.90 | 2 vCPU · 4 GB · 120 GB · 1 Gbps | Lightning के साथ एक 25–50 GB pruned node। swap जोड़ें; disk पर नज़र रखें। |
| Garrison | $7.90 | 4 vCPU · 8 GB · 240 GB · 1 Gbps | एक 100 GB pruned node, Lightning और वर्षों का headroom। Default विकल्प। |
| Ravelin | $16.90 | 8 vCPU · 16 GB · 480 GB · 2.5 Gbps | वही, साथ में एक दूसरी chain या plugins वाला व्यस्त store। |
| Bulwark | $32.90 | 16 vCPU · 32 GB · 960 GB · 5 Gbps | बढ़ते रहने की गुंजाइश वाला एक archival node। सिर्फ़ तभी जब आपको इतिहास चाहिए। |
node के synchronise होने के बाद BTCPay, indexer और PostgreSQL मिलकर बस कुछ ही gigabytes और लगभग न के बराबर CPU लेते हैं; रोज़ सौ payments लेने वाली shop भी compute के मामले में सबसे छोटे tier को परेशान नहीं करेगी। tiers में जो चीज़ अलग होती है वह है disk, और disk पूरी तरह चरण 01 से तय होती है। Sync ही इस प्रोजेक्ट का सचमुच भारी घंटा है — यह CPU-bound नहीं बल्कि IO-bound है, यही वजह है कि यहाँ NVMe मायने रखता है और core की गिनती नहीं। हर tier पर bandwidth असीमित है, इसलिए सार्वजनिक रूप से पहुँच योग्य Lightning node चलाने में कोई अतिरिक्त लागत नहीं आती।
किसी ताज़ा instance पर register करने वाला पहला व्यक्ति administrator बन जाता है, और certificate जारी होते ही hostname certificate-transparency logs में प्रकाशित हो चुका होता है। install खत्म होने के कुछ ही मिनटों में register करें, फिर Server Settings में पुष्टि करें कि registration अजनबियों के लिए खुला नहीं है।
server को wallet बनाने देना बस एक क्लिक है और seed को उस मशीन पर रख देता है जिसका काम ही अजनबियों को जवाब देना है। इसके बजाय एक extended public key जोड़ें: store नज़र रखता है, derive करता है और reconcile करता है, और खर्च नहीं कर सकता। private half को किसी wallet में या किसी hardware device पर रखें।
कल का channel database एक ऐसी state बताता है जिसे आपके counterparty ने पहले ही बदल दिया है। इसे वापस online लाना उन्हें पूरा channel balance जुर्माने के तौर पर सौंप सकता है। रात वाला archive store को cover करता है; channels को documented recovery path और लगातार copy होने वाले channel backup की ज़रूरत होती है।
एक channel को fund करना आपको send करने की क्षमता देता है, receive करने की नहीं। पैसों वाला एक नया node भी हर incoming payment में फेल होता रहता है, और error किसी routing समस्या जैसा दिखता है। Lightning विकल्प का प्रचार करने से पहले inbound liquidity हासिल करें, पहली शिकायत के बाद नहीं।
किसी तीन-साल पुराने account को pruned node से जोड़ने पर उसके पुराने transactions कभी नहीं दिखते, क्योंकि जिन blocks में वे थे उन्हें फेंक दिया गया था। कुछ भी टूटा नहीं है और कुछ भी यह बताता नहीं है। shop को एक बिल्कुल नया बनाया account दें, या archival चलाएँ।
node वह अकेली process है जो अपने-आप बढ़ती रहती है, और एक भरी हुई disk विनम्रता से रुकने के बजाय index को corrupt कर देती है — यानी download फिर से शुरू करना पड़ता है। चरण 01 का हिसाब उस tier से मिलाएँ जो आपने order किया है, और अस्सी प्रतिशत पर अलर्ट लगाएँ, पचानवे पर नहीं।
यह बनाते समय जो ग्यारह सवाल उठते हैं — उन दो सवालों से शुरू जो तय करते हैं कि आपको इसे बनाना भी चाहिए या नहीं।
यह सचमुच मुफ़्त है, और इस बात का आकार कीमत से ज़्यादा मायने रखता है। BTCPay Server एक permissive licence के तहत जारी किया गया open-source software है और इसे किसी revenue-लक्ष्य वाली company के बजाय एक foundation चलाता है; न कोई per-transaction fee, न percentage, न न्यूनतम volume, न खोलने के लिए कोई account और न sign करने के लिए कोई contract, क्योंकि यहाँ कोई counterparty है ही नहीं — आप अपने ही server पर एक program चला रहे हैं, ठीक वैसे ही जैसे आप web server चलाते हैं। इसके बदले आप जो चुकाते हैं वह असली है पर अलग तरह का है: box के लिए महीने के कुछ डॉलर, इसे सेट करने के लिए एक शाम, और payment-handling service को patched रखने का स्थायी दायित्व। जो तुलना लोगों को असल में करनी चाहिए वह "मुफ़्त बनाम एक प्रतिशत" नहीं है। यह है "आपके अपने ज़िम्मे का एक परिचालन काम बनाम एक ऐसी dependency जो आपकी नहीं", और ईमानदार जवाब यह है कि साल में बीस payments लेने वाली shop को शायद कोई hosted चीज़ बेहतर सूट करती है, जबकि हफ़्ते में बीस लेने वाली shop को यहाँ सस्ता और आज़ाद दोनों मिलता है।
आप रखते हैं, और इस तंत्र को भरोसा करने के बजाय समझ लेना बेहतर है। सुझाया गया setup BTCPay को आपके नियंत्रण वाले किसी wallet की एक extended public key देता है। उस key से server हर invoice के लिए एक नया receiving address derive कर सकता है और उस पर होने वाले payments के लिए chain देख सकता है — और यह कोई मान्य spend नहीं बना सकता, क्योंकि private half कभी आपके wallet से बाहर नहीं जाती। पैसा customer से सीधे ऐसे address में जाता है जिसे सिर्फ़ आप ही sweep कर सकते हैं; server पर कभी कुछ रखा ही नहीं जाता, इसलिए किसी breach में रोकने, फ़्रीज़ करने या खोने लायक कुछ है ही नहीं। BTCPay आपके लिए एक wallet बनाने और seed को server पर रखने का प्रस्ताव भी देगा, जो सुविधाजनक है और यही वह इकलौता configuration है जिसके खिलाफ़ यह गाइड असली कमाई रखने वाली किसी भी चीज़ के लिए तर्क देती है: यह एक सार्वजनिक, internet-facing box को hot wallet बना देता है। Lightning सचमुच का अपवाद है — route करने के लिए channel funds का जीवित होना ज़रूरी है — यही वजह है कि Lightning balance को vault नहीं बल्कि till की तरह देखा जाना चाहिए।
यह पूरी तरह एक फ़ैसले पर निर्भर करता है, और इसकी रेंज दो order of magnitude जितनी है। एक archival Bitcoin Core node हर block रखता है जो कभी mine हुआ: 2026 में आराम से 700 GB पार, और हर साल करीब 50 GB बढ़ते हुए, इसलिए इसे इसी हिसाब से sized tier चाहिए और आगे भी और चाहिए होगा। एक pruned node हर block को ठीक उसी तरह validate करता है और फिर पुराने blocks फेंककर एक rolling window रखता है — deployment generator ऐसे fragments देता है जो करीब 100, 50, 25 या 5 GB तक prune करते हैं, और 50 GB से ऊपर कुछ भी किसी merchant के लिए पूरी तरह गंभीर production विकल्प है। indexer, database, Lightning node और operating system के लिए करीब 10 से 20 GB और जोड़ें, तो हिसाब यूँ बैठता है: एक 120 GB tier 25–50 GB का pruned deployment चलाता है, एक 240 GB tier वर्षों की गुंजाइश के साथ 100 GB वाला चलाता है, और archival को 960 GB चाहिए। जब तक कोई खास वजह न हो, pruned चुनें; security model बिल्कुल एक जैसा है।
आंशिक रूप से, और यह जानना ज़रूरी है कि लाइन ठीक कहाँ है। stack को कहीं और चल रहे किसी Bitcoin node की ओर इंगित किया जा सकता है — एक ही tailnet में मौजूद कोई box, या किसी tunnel के पीछे वाला — और यह पूरी तरह supported व्यवस्था है जो अगर आपने Lightning node गाइड में पहले ही यह काम किया है तो chain की दूसरी copy बचाती है। जो आप समझदारी से नहीं कर सकते वह है किसी और के public node के भरोसे payment processor चलाना, और इसकी वजह licensing नहीं बल्कि privacy और trust है: जो भी आपके queries का जवाब देता है वह आपकी shop द्वारा देखे जा रहे हर address को जान लेता है, जो आपका राजस्व जानने जैसा ही है, और आपसे यह झूठ भी बोल सकता है कि कोई invoice चुकाया गया या नहीं। एक तीसरा विकल्प भी है जिसकी ओर लोग जाते हैं — किसी तीसरे पक्ष द्वारा चलाए जा रहे hosted BTCPay instance का इस्तेमाल — और शुरुआत करने का यह भी एक पूरी तरह उचित तरीका है। बस यह साफ़ रहे कि इससे store का data किसी ऐसे operator तक पहुँच जाता है जो उसे देख सकता है, जबकि self-hosting का ज़्यादातर मकसद यही रोकना था।
नहीं, और पहले ही दिन इसे छोड़ देना पूरी तरह उचित है। On-chain-only एक पूरा, काम करने वाला configuration है: invoices चुकाए जाते हैं, customer confirmation का इंतज़ार करता है, shop settle होती है। Lightning जो चीज़ देता है वह है "करीब दस मिनट और एक ऐसी fee जो छोटी रकम पर चुभती है" और "दो सेकंड और सेंट के एक अंश जितनी fee" के बीच का फ़र्क़ — यानी वह फ़र्क़ जो एक $400 वाले invoice के लिए काम करने वाले checkout और एक $4 वाले के लिए भी काम करने वाले checkout के बीच होता है। इसकी कीमत यह है कि Lightning अपने funds, अपने failure modes और अपने backup अनुशासन वाला एक दूसरा daemon है — जिसमें चरण 05 की inbound-liquidity समस्या और चरण 06 की toxic-state चेतावनी भी शामिल है। एक समझदार क्रम यह है कि पहले on-chain launch करें, असली पैसों से पूरी pipeline के काम करने की पुष्टि करें, और फिर उसी शाम में जोड़ने के बजाय Lightning को एक सोचा-समझा दूसरा प्रोजेक्ट बनाकर जोड़ें।
कोई भी wallet जो किसी एक account के लिए extended public key export कर सके — Sparrow, Electrum, BlueWallet, या इनमें से किसी के ज़रिए कोई hardware wallet — और यहाँ अहम चीज़ brand नहीं बल्कि यह है कि वह account आपकी बचत रखने वाले account के बजाय dedicated हो। इसकी दो वजहें हैं। पहली privacy है, और यह स्थायी है: एक extended public key उन सभी addresses की एक मास्टर index होती है जो वह कभी भी derive करेगी, इसलिए जिसके पास भी यह पहुँच जाए वह उस account को अब तक मिले और आगे मिलने वाले हर payment को गिन सकता है। store को उसका अपना account देने का मतलब है कि कोई leak सिर्फ़ shop की कमाई उजागर करे, और कुछ नहीं। दूसरी वजह परिचालन से जुड़ी है: एक dedicated account शॉप की आमदनी को बिना किसी मिली-जुली history पर जाँच-पड़ताल किए साफ़-सुथरा बनाता है, और cold storage में समेटना एक सीधा, नीरस फ़ैसला बन जाता है। जो व्यवस्था हासिल करनी चाहिए वह है कि private key किसी hardware wallet में रहे और store सिर्फ़ public key पर नज़र रखे।
हाँ, इस शर्त के साथ कि हर अतिरिक्त chain अपनी disk, अपने synchronisation समय और अपने maintenance वाला एक पूरा अतिरिक्त node है। generator सीधे एक दूसरी और तीसरी cryptocurrency को support करता है, और एक Monero integration एक अतिरिक्त fragment के तौर पर उपलब्ध है — फिर वही deployment checkout पर customer को rails का एक विकल्प देता है। जिसे लोग कम आँकते हैं वह है resource का बिल: आपकी चालू की गई हर chain उसी volume पर एक और ledger index करने वाला एक और daemon है, और एक के हिसाब से sized tier पर दो chains ही वह वजह है जिससे payment box किसी रविवार को disk ख़त्म कर बैठता है। अगर Monero आपकी shop के लिए ज़रूरी है, तो पहले Monero node गाइड पढ़ें और इसे अपना अलग box देने पर विचार करें; ऐसा payment processor जो किसी असंबंधित daemon के disk भर देने से ठप हो जाए, उस processor से बुरा है जो सिर्फ़ Bitcoin लेता है।
चार तरीके, इस क्रम में कि आपके पास पहले से कितना software है। अगर आपके पास कुछ नहीं है, तो BTCPay एक hosted point of sale और एक payment request page देता है जिसे आप link के तौर पर भेज सकते हैं — यह किसी client को invoice भेजने या बिना किसी website के market stall पर payment लेने के लिए काफ़ी है। अगर आपके पास एक static site है, तो एक pay button बस HTML का एक snippet है। अगर आपके पास असली storefront है, तो आम e-commerce platforms के लिए maintained plugins मौजूद हैं जो Bitcoin को checkout पर एक और payment method बना देते हैं और order status अपने-आप वापस भेज देते हैं। और अगर आपका अपना application है, तो REST API invoices जारी करता है, उनकी state बताता है, और settle होने पर आपके तय किए गए webhook को कॉल करता है — यही वह integration है जो सबसे अच्छी तरह टिकती है, क्योंकि यह सिर्फ़ HTTP पर निर्भर है। एक payment request से शुरू करें, साबित करें कि पैसा पहुँचता है, फिर integrate करें।
on-chain के लिए, नहीं, और यही watch-only डिज़ाइन का शांत फ़ायदा है: coins कभी server पर थे ही नहीं। Addresses एक public key से derive होते हैं, इसलिए वही extended public key इस्तेमाल करने वाला एक नया install हर payment फिर से खोज लेता है; पूरी तरह फेल होने पर आप जो खोते हैं वह है store की configuration और उसका invoice इतिहास, और बैकअप script इसी के लिए है। Lightning सचमुच अलग जवाब है और इसका अपना वाक्य बनता है: channel funds जीवित होते हैं, हर payment के साथ channel state बदलता है, और उस state की पुरानी copy restore करना सीधे-सीधे channel balance गँवा सकता है, क्योंकि पहले से बदली जा चुकी state प्रकाशित करना ठीक वही है जिसे protocol सज़ा देता है। इसलिए सही रुख असममित है। database और configuration को नियमित रूप से backup करें, इसे encrypt करें, इसे किसी ऐसी जगह भेजें जो यह मशीन न हो — और Lightning static channel backup को रात वाले archive की एक लाइन नहीं बल्कि एक अलग, लगातार copy होने वाला artefact मानें।
नहीं, और इस बारे में साफ़ बात करना ज़रूरी है क्योंकि आमतौर पर इसका उल्टा मान लिया जाता है। payment processor हटाने से एक बिचौलिया, एक fee, और आपके funds फ़्रीज़ कर सकने वाला एक पक्ष हट जाता है। इससे यह नहीं बदलता कि आप क्या और किसे देते हैं, या कोई बिक्री कर-योग्य है या नहीं — ये बातें इस पर निर्भर करती हैं कि आप और आपका व्यवसाय कहाँ हैं, न कि इस पर कि server कहाँ है या invoice किस software ने जारी किया। ज़्यादातर jurisdictions में सामान या सेवाओं के बदले cryptocurrency मिलना उसी दिन की कीमत पर सामान्य व्यावसायिक आय है, और बाद में इसे बेचना फिर से एक अलग घटना है; यह तथ्य कि अब यह रिकॉर्ड किसी processor के बजाय आपके अपने database में रहता है, इसे वैकल्पिक नहीं बनाता, और एक self-hosted instance व्यवहार में उस account के किसी screenshot से बेहतर audit trail है जो अब आपके पास नहीं रहा। ईमानदार privacy फ़ायदा जहाँ है वह इससे संकरा और असली है: कोई तीसरा पक्ष आपके customers और रकम की चलती सूची नहीं रखता। बाकी के लिए अपने ही jurisdiction में किसी accountant से पूछें।
हाँ — एक BTCPay instance एक साधारण database और एक साधारण blockchain daemon वाला एक साधारण web application है, और acceptable-use policy में ऐसा कुछ नहीं है जो इसे किसी shop या blog से अलग तरह से देखे। व्यावहारिक बातें policy की नहीं बल्कि resources की हैं: synchronise होता हुआ node अपने पहले दिन disk-भारी और IO-भारी होता है और फिर लगभग निष्क्रिय रहता है, हर tier पर bandwidth असीमित है इसलिए सार्वजनिक Lightning node मीटर नहीं किया जाता, और peer connections के लिए inbound ports खोलना आपके अपने हाथ में है। जो चीज़ बाकी site से मेल खाती है वह है यह समानता: account को आपके क़ानूनी नाम की ज़रूरत नहीं, invoice Monero, Bitcoin या Lightning में settle होता है, और अब आपके हर customer को जानने वाली मशीन एक ऐसी company से किराए पर ली गई है जो नहीं जानती कि आप कौन हैं। किसी पहचानी हुई account पर self-host किया गया processor सिर्फ़ ledger को हटाता है, जोखिम को नहीं।
Garrison — 4 vCPU, 8 GB और 240 GB NVMe, $7.90 प्रति माह में, Helsinki, Stockholm, Oslo या Reykjavík में। एक pruned Bitcoin node, एक Lightning daemon, indexer और store के लिए काफ़ी, और वर्षों की गुंजाइश के साथ। signup पर कोई email नहीं, कोई पहचान-पत्र नहीं, और किसी company के पास आपको भुगतान करने वाले हर व्यक्ति की सूची नहीं।
अंतिम review · 2026-10-12 · स्रोत · BTCPay Server documentation (Docker deployment, storage fragments, backup और restore, store settings), pruning पर Bitcoin Core documentation, static channel backups पर Lightning implementation documentation · आवृत्ति · वार्षिक
This guide is one spoke of a larger series. The pillar walks the three privacy layers end to end — the sibling spokes below dive into the specifics.
Three independent layers — signup, payment, network — explained, legal context included, common mistakes flagged.
Your own LN node — bitcoind + LND or Core Lightning, on a VPS.
आपका अपना monerod — full या pruned, एक tunnel के पीछे RPC, Tor broadcast।
Deploy your own MCP server on a no-KYC VPS — TLS, streamable HTTP, OAuth.
Host an MCP server with no ID — the privacy stack, crypto-paid.
निजी होस्टिंग, उत्तर में निर्मित।