كل معالج بطاقات وكل بوابة عملات مشفّرة مُستضافة تقف بينك وبين زبونك، وتأخذ نسبة، وتحتفظ بقائمة من دفع لك وكم دفع، وتحتفظ بحق التوقف متى شاءت. BTCPay Server هو البرنامج الذي يزيلها من المعادلة: معالج دفع مفتوح المصدر وذاتي الاستضافة وغير وصائي، تذهب فيه العملات مباشرة إلى محفظة لا يستطيع الخادم الإنفاق منها. ست خطوات للوصول إلى واجهة دفع Bitcoin وLightning تعمل على خادم تستأجره دون كشف هويتك — شكل العقدة الذي يحدد الميزانية، والمفتاح المخصص للمراقبة فقط، ومشكلة السيولة الواردة، وقاعدة النسخ الاحتياطي التي يكسرها Lightning. يكلّف الخادم $7.90 شهريًا. جُرِّب على Debian 12.
الاختيار
عقدة كاملة، أو مُقلَّمة، أو خارجية
التوفير
النطاق أولاً، ثم أربعة منافذ
نشر
مولّد واحد، وأمر واحد
اتصل
مفتاح مخصص للمراقبة فقط، لا بذرة أبدًا
Lightning
القنوات وسعة الاستقبال
الإطلاق
واجهة الدفع، والنسخ الاحتياطي، والترقيات
الدفعة على سلسلة الكتل لا تحتاج إلى شركة في المنتصف. يوقّع الزبون معاملة، وتؤكّدها الشبكة، ويصبح المال ملكك — لا جهة تحصيل، ولا نافذة تسوية، ولا أحد تتوقف الدفعة على موافقته. هذه هي الفكرة كلها، وهذا هو سبب وجود هذه التقنية أصلاً.
بعد ذلك يحتاج المتجر إلى قبول الدفعات فعليًا، وتصل المتطلبات العملية كلها دفعة واحدة. كل فاتورة تحتاج إلى عنوانها الخاص، ليتسنى تمييز الدفعات عن بعضها. وعلى شخص ما أن يراقب السلسلة ويقرر متى تُدفع فاتورة. ويجب عرض المبلغ بعملة يفكّر بها الزبون، بسعر يبقى ثابتًا مدة كافية ليضغط زر الإرسال. ويجب أن تتدفق حالة الطلب عائدة إلى المتجر. ويجب أن يعمل كل ذلك في الثانية صباحًا دون أن يراقبه أحد. بناء كل ذلك مشروع بحد ذاته؛ وعدم بنائه هو سبب اشتراك معظم الناس بدلاً من ذلك في بوابة مُستضافة — ليعيدوا بذلك، في مساحة استمارة واحدة، وسيطًا إلى نظام صُمم أصلاً ليخلو منه.
يستحق ما يحتفظ به ذلك الوسيط أن يُقال بوضوح، لأنه أكثر من مجرد الرسوم. فهو يحتفظ بالعملات، على الأقل إلى حين تنفيذ عملية صرف، ما يعني أنه يستطيع تأخيرها. ويحتفظ بالقائمة: كل زبون، وكل مبلغ، وكل طابع زمني، وكل منتج، في قاعدة بيانات لا يمكنك قراءتها ولا حذفها. ويحتفظ بملف هوية عنك، لأن أي شركة تتعامل مع أموال الآخرين مُلزَمة بجمع واحد. ويحتفظ بالمفتاح، لأن شروط الخدمة تحتفظ بحق تقرير أن نشاطك التجاري لم يعد مرحبًا به — قرار يصل عبر البريد الإلكتروني، وينطبق على الرصيد كما ينطبق على الحساب، وليس، من الناحية العملية، قابلاً للاستئناف.
BTCPay Server هو الحل لهذه المشكلة بالتحديد ولا شيء غيرها. إنه معالج دفع مجاني ومفتوح المصدر تُشغّله على جهازك الخاص: يشتق عنوانًا لكل فاتورة، ويراقب السلسلة، ويعرض أسعارًا بعملة تقليدية، ويوفّر واجهة دفع وAPI، ويتحدث Lightning. وهو لا يحتفظ بعملاتك أبدًا، لأن المحفظة التي يراقبها هي محفظة تملكها أنت أصلاً. أربع طرق لقبول دفعة بعملة مشفّرة، وما تكلفه كل طريقة فعليًا:
| الخاصية | بوابة عملات مشفّرة مُستضافة | عنوان خام في تذييل الصفحة | BTCPay على نسخة يستضيفها شخص آخر | BTCPay على VPS الخاص بك |
|---|---|---|---|---|
| من يحتفظ بالعملات | البوابة، إلى حين الصرف | أنت | أنت — فهو يراقب، ولا يستطيع الإنفاق | أنت — فهو يراقب، ولا يستطيع الإنفاق |
| من يستطيع منعك من التجارة | البوابة، عبر البريد الإلكتروني | لا أحد | مُشغِّل النسخة | لا أحد |
| من يرى كل زبون ومبلغ | البوابة، بشكل دائم | الجميع — عنوان واحد، ومجموع عام واحد | مُشغِّل النسخة | أنت |
| وثيقة هوية مطلوبة | نعم، قبل أول عملية صرف | لا | أيًّا كان ما يطلبه المُشغِّل | لا |
| التكلفة لكل معاملة | نسبة مئوية، إلى الأبد | لا شيء | لا شيء | لا شيء — $7.90 شهريًا، مبلغ ثابت |
| يميّز بين الفواتير | نعم | لا — تُطابق يدويًا | نعم | نعم |
| اخترها حين | تريد صفر مهام تشغيلية، وتقبل الشروط | تبرعات، حفنة منها في السنة | تريد البرنامج لكن لا تريد الخادم | الإيرادات ملكك، والقائمة أيضًا ملكك |
والعمود الثاني ليس مزحة أيضًا — عنوان واحد في تذييل الصفحة أمر مقبول تمامًا لرابط تبرع، والتظاهر بعكس ذلك يروّج لبرنامج لا يحتاجه أحد. يتوقف عن كونه مقبولاً في اللحظة التي يدفع فيها شخصان المبلغ نفسه في اليوم نفسه، أو في اللحظة التي تفضّل فيها ألا يكون دخلك السنوي رقمًا عامًا يستطيع أي شخص جمعه.
على أي معالج دفع أن يكون قادرًا على الإجابة بصدق عن سؤال واحد: هل دُفعت هذه الفاتورة؟ والإجابة عنه تعني مراقبة شبكة Bitcoin، ومراقبتها كما ينبغي تعني تشغيل عقدة تتحقق من الكتل بنفسها بدل تصديق ما يخبرها به طرف آخر. تلك العقدة هي كامل ميزانية العتاد لهذا المشروع — أما BTCPay نفسه، والمفهرس، وقاعدة البيانات مجتمعة، فهي هامش تقريب لا يُذكر بجانبها.
هناك ثلاثة ترتيبات منطقية وترتيب واحد ليس كذلك. العقدة الأرشيفية تحتفظ بكل كتلة عُدِّنت على الإطلاق: أكثر من 700 GB براحة في 2026، وتنمو بنحو 50 GB سنويًا. وهي ما تريده إن كنت تنوي أيضًا تشغيل مستكشف كتل أو إجراء تحليل تاريخي، وهي مبالغ فيها بالنسبة لمتجر. العقدة المُقلَّمة تُنزّل وتتحقق من كل كتلة بالكامل وبالطريقة نفسها تمامًا، ثم تتخلص من القديمة منها وتحتفظ بنافذة متجددة. نموذج الأمان مطابق تمامًا — وهذا هو الجزء الذي يخطئ فيه الناس، لأن كلمة "مُقلَّمة" تبدو وكأنها تعني "جزئية" وهي ليست كذلك — ويوفّر مولّد النشر أجزاءً جاهزة لها.
العقدة الخارجية هي الخيار الثالث: وجّه الحزمة نحو عقدة Bitcoin تُشغّلها أنت بالفعل، عبر رابط خاص. إن كنت قد اتبعت بالفعل دليل عقدة Lightning فلا داعي للاحتفاظ بنسخة ثانية من السلسلة، وVPN شبكي بين الخادمين هو الطريقة النظيفة لربطهما. أما الترتيب الذي لا معنى له فهو توجيه متجر نحو عقدة عامة يملكها شخص غريب: فهي تتعرّف على كل عنوان تراقبه، وهو إيرادك، وهي في موقع يسمح لها بالكذب بشأن ما إذا كانت فاتورة قد دُفعت أم لا.
| النشر | السلسلة على القرص | إجمالي المساحة المطلوبة | ما الذي تتنازل عنه |
|---|---|---|---|
| مُقلَّمة، بأصغر نافذة | ~5–25 GB | ~40 GB | عمليات إعادة الفحص، وأي هامش للخطأ. الإعداد الأصغر غير مُوصى به. |
| مُقلَّمة، بنافذة ~50 GB | ~50 GB | ~80 GB | لا شيء يلاحظه المتجر. الحد الأدنى المعقول. |
| مُقلَّمة، بنافذة ~100 GB | ~100 GB | ~140 GB | لا شيء. الخيار الافتراضي المريح، مع مساحة لـLightning. |
| أرشيفية، بتاريخ كامل | 700 GB + | ~960 GB | لا شيء — لكنك تدفع ثمنه كل شهر، إلى الأبد. |
| عقدة خارجية تُشغّلها أنت بالفعل | لا شيء على هذا الخادم | ~40 GB | استقلالية — تتوقف واجهة الدفع حين يتوقف الخادم الآخر. |
العقدة المُقلَّمة لا يمكنها إعادة فحص كتل تخلّصت منها بالفعل. وهذا يعني عمليًا أنها لا تستطيع إعادة بناء تاريخ محفظة تسبق معاملاتها تاريخ النشر — فالمفهرس يفحص إلى الأمام ابتداءً من يوم ربط المفتاح، لذا فإن الدفعات القديمة إلى ذلك الحساب لن تظهر في المتجر ببساطة. هذا ليس مشكلة إن فعلت ما توصي به الخطوة 04 ومنحت المتجر حسابًا أُنشئ حديثًا؛ لكنه بعد ظهر مُربِك فعلاً إن ربطت محفظة تستخدمها منذ ثلاث سنوات ونصف تاريخها مفقود. قرر أيّهما تفعل قبل التثبيت، لا بعده.
هناك قرار إضافي مكانه هنا لا لاحقًا، لأنه يغيّر ما يبنيه المُثبِّت: هل تريد Lightning من الأساس في اليوم الأول. الاقتصار على السلسلة فقط إعداد كامل ونقطة انطلاق محترمة تمامًا. إضافة Lightning لاحقًا مدعومة وغير مؤلمة، لكنها خدمة خلفية ثانية بأموالها الخاصة وقواعد النسخ الاحتياطي الخاصة بها، وهناك ما يستحق قوله عن إثبات وصول أموال حقيقية عبر المسار البسيط قبل إدخال المسار المعقد.
اطلب الخادم. في اللوحة: اطلب → VPS → Garrison، والصورة Debian 12، في أي حصن تريد أن تقيم فيه سجلات المتجر — هلسنكي أو ستوكهولم أو أوسلو أو ريكيافيك. Garrison هو الخيار الافتراضي الصحيح لأنه يحمل سلسلة مُقلَّمة بحجم 100 GB، وعقدة Lightning، وقاعدة البيانات، دون أن تضطر إلى التفكير في القرص مجددًا لسنوات. Sentinel يعمل مع تقليم أضيق؛ وBulwark هي الفئة المناسبة لعقدة أرشيفية. لا حاجة إلى عنوان بريد إلكتروني لفتح الحساب، وتُسدَّد الفاتورة بـMonero أو Bitcoin أو Lightning أو أي أصل آخر مدعوم — وهذا هو الجزء المُبهج في هذا المشروع بالذات، إذ إنك تبني خادمًا لقبول دفعات بالعملات المشفّرة وتدفع ثمنه بواحدة منها.
ثم نفّذ قائمة التصليب في الساعة الأولى قبل أي شيء آخر — SSH بالمفتاح فقط على منفذ مُغيَّر، وترقيات تلقائية بلا إشراف، وجدار حماية بسياسة الرفض الافتراضي. سيحمل هذا الخادم في النهاية سجل كل زبون لديك ومادة مفاتيح عقدة Lightning بأموال حيّة فيها. إنه ليس خادمًا تتركه بمصادقة كلمة مرور لمدة أسبوع.
الآن سجل DNS، ونفّذه قبل تشغيل المُثبِّت لا بعده. اختر اسم المضيف الذي ستقيم عليه واجهة الدفع — shop.example.com، أو pay.example.com، أو أي اسم يناسبك — ووجّه سجل A نحو عنوان VPS، وسجل AAAA أيضًا إن أردته قابلاً للوصول عبر IPv6. اترك له وقتًا لينتشر. سيحاول الوكيل العكسي الذي يُعِدّه المُثبِّت الحصول على شهادة لذلك الاسم بالتحديد أثناء إقلاعه الأول، مستخدمًا تحديًا عبر HTTP يتطلب أن يكون الاسم مُحلَّلاً بالفعل نحو هذا الخادم. سجل لم يصبح فعّالاً بعد هو، براحة، الطريقة الأكثر شيوعًا التي ينتهي بها أول تثبيت إلى خطأ مُربِك.
يأتي النشر مع سكربت لتغيير النطاق لاحقًا، لذا فالأمر قابل للتدارك لا كارثي. أما ما لا يمكن تداركه بأمر واحد فهو كل ما يترتب عليه: تُعاد إصدار الشهادة، وكل زر دفع وعنوان webhook سلّمته للآخرين يشير إلى الاسم القديم، وعنوان Lightning اسم على نطاق ويتحرك معه، وأي إضافة متجر تحتاج إلى إعادة ضبط. اختر اسمًا أنت مستعد للاحتفاظ به على الترويسة الرسمية لسنوات، وفضّل نطاقًا فرعيًا من نطاق تنشره بالفعل على نطاق جديد يصف وظيفة الخادم.
ثم اكتب قواعد جدار الحماية بينما لا شيء يستمع بعد. أربعة منافذ، وأربعة فقط. واجهة الدفع نقطة نهاية عامة عبر HTTPS بالضرورة — إذ يجب أن يصل إليها متصفح الزبون — والمنفذ 80 يبقى مفتوحًا لأن تجديد الشهادة يستخدمه. منفذ Lightning من نظير إلى نظير لا تحتاج إليه إلا إذا أردت أن تستطيع عقد أخرى فتح قنوات نحوك، وهو ما ستحاجج الخطوة 05 بأنك تريده. أما منفذ Bitcoin من نظير إلى نظير فلا حاجة إلى فتحه على الإطلاق: فعقدتك تُجري اتصالات صادرة دون أي مشكلة، وفتحه للاتصالات الواردة لا يجعل سوى العثور عليها أسهل.
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
ملاحظتان بخصوص الموارد قبل أن تواصل. امنح الخادم swap إن لم يكن يملك أيًا منها — فالتنزيل الأولي للكتل هو الساعة الأكثر استهلاكًا للذاكرة في هذا المشروع، و4 GB من RAM مع 2 GB من swap يتصرفان بشكل أفضل بكثير من 4 GB وحدها. وتحقق من حساب القرص من الخطوة 01 مقابل الفئة التي طلبتها فعلاً، لأن عقدة تملأ وحدة تخزينها في منتصف المزامنة لا تفشل بأدب؛ بل تُتلِف فهرسها الخاص وتبدأ من جديد.
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
النشر الرسمي ليس ملف docker-compose.yml تُعدّله بنفسك. إنه مولّد: تصف النشر الذي تريده في متغيرات البيئة، ويُجمِّع سكربت ملف compose من مكتبة أجزاء — جزء لـBitcoin Core، وجزء للمفهرس، وجزء لـPostgreSQL، وجزء لتطبيق BTCPay، وجزء لكل تنفيذ من تنفيذات Lightning، وجزء للوكيل العكسي، وذيل طويل من الإضافات الاختيارية. هذا تصميم أفضل مما يبدو للوهلة الأولى، لأن الترقيات تُعيد توليد الملف بدل أن تطلب منك دمج تعديلات شخص آخر مع تعديلاتك. وهذا يعني أيضًا أن كتلة متغيرات البيئة أدناه هي الإعداد الحقيقي لنشرك، وتستحق أن تُحفَظ في المكان نفسه مع ملاحظات بنيتك التحتية الأخرى.
استنسخ المستودع وصدّر متغيرات البيئة. كل سطر أدناه يقابل مباشرة قرارًا من الخطوة 01: اسم المضيف هو النطاق الذي وجّهته في الخطوة 02، وجزء التخزين هو نافذة التقليم التي اخترتها، ومتغيّر Lightning إما تنفيذ معيّن أو يُحذف بالكامل من أجل إطلاق يقتصر على السلسلة فقط.
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
يستحق تفصيلان في تلك الكتلة جملة لكل منهما. النقطة البادئة في . ./btcpay-setup.sh -i ليست خطأ مطبعيًا — فالسكربت يُحمَّل عبر source بدل أن يُنفَّذ، لذا تبقى البيئة التي يضبطها داخل الصدفة الخاصة بك وتعمل الأوامر المساعدة بعدها. واسم جزء التخزين حساس للإصدار: فقد أصدر المولّد صيغًا تُقلِّم إلى نحو 100 أو 50 أو 25 أو 5 GB، تحت أسماء عُدِّلت بين الإصدارات. اقرأ قائمة الأجزاء في المستودع الذي استنسخته للتو بدل الوثوق بقيمة منسوخة من تدوينة، بما في ذلك هذه التدوينة.
سيستغرق المُثبِّت بضع دقائق، ويسحب عددًا كبيرًا من الصور، ويحصل على الشهادة، ويشغّل كل شيء. ثم يبدأ الانتظار: يجب على العقدة تنزيل السلسلة والتحقق منها قبل أن يستطيع المتجر تأكيد أي دفعة، وهذا يستغرق ساعات لا دقائق حتى مع التقليم، لأن التقليم يتخلص من الكتل بعد التحقق منها لا بتخطي العمل نفسه. تتوفر واجهة الويب فورًا وستعرض لك شريط مزامنة. لا تُصدر فاتورة حقيقية إلى أن يختفي.
./bitcoin-cli.sh getblockchaininfo | grep -E 'blocks|headers|verificationprogress|pruned'
docker ps --format '{{.Names}}\t{{.Status}}'
النسخة الجديدة لا تضم أي مستخدمين، وأول حساب يُسجَّل فيها يصبح هو حساب المسؤول. وإلى أن تستولي عليه، يستطيع أي شخص يصل إلى العنوان أن يفعل ذلك — والعنوان ليس سرًا: فمنذ لحظة إصدار الشهادة، يُنشر اسم المضيف في سجلات شفافية الشهادات العامة، وهي سجلات تُفهرَس وتُفحَص باستمرار من قِبل أشخاص يبحثون بالضبط عن هذا النوع من الثغرات. افتح الموقع وسجّل حسابك قبل أي شيء آخر، ثم تحقق من إعدادات الخادم وتأكد من أن التسجيل غير متاح للغرباء. هذه نافذة مدتها خمس دقائق يتركها الناس مفتوحة أيامًا لأن المتجر "لم يُطلَق بعد".
يستحق جزآن اختياريان أن تعرفهما وأنت لا تزال في مرحلة الإعداد. أحدهما يضيف خدمة Tor مخفية، بحيث تصبح واجهة الدفع قابلة للوصول عبر عنوان onion من النسخة v3 إضافةً إلى عنوان الشبكة العادية — وهذا مفيد للزبائن الذين يفضّلون عدم تحليل نطاقك، وهي الفكرة نفسها التي يتناولها دليل خدمة onion. والآخر يضيف عملة مشفّرة ثانية. يُضبَط كلاهما بالطريقة نفسها، بالإضافة إلى متغيّر الأجزاء الإضافية وإعادة تشغيل سكربت الإعداد؛ ويعيد المولّد بناء ملف compose ويعيد تشغيل ما تغيّر فقط.
أنشئ متجرًا، ثم اتخذ القرار الوحيد في هذه الصفحة الذي يهم فعلاً. سيعرض عليك BTCPay طريقتين لربط محفظة Bitcoin: ربط محفظة قائمة بالفعل، أو تركه يُنشئ محفظة جديدة ويحتفظ بالبذرة على الخادم. الطريقة الأولى مراقبة فقط وهي ما تريده. أما الثانية فتحوّل خادمًا عامًا مكشوفًا على الإنترنت إلى محفظة ساخنة تحمل إيراداتك، ولا يوجد قدر من التصليب يجعل تلك مقايضة جيدة لخادم مهمته بأكملها أن يكون قابلاً للوصول من الغرباء.
الآلية الكامنة خلف هذه التوصية أنيقة بما يكفي لتستحق أن تُفهَم. المحافظ الحديثة هرمية: بذرة واحدة تشتق شجرة من المفاتيح، وهناك مفتاح عام ممتد — إما xpub، أو نسخته zpub لـsegwit الأصلي — يمكن من خلاله حساب كل عنوان استقبال في الحساب دون أي قدرة على التوقيع. سلّم ذلك للمتجر ليستطيع توليد عنوان جديد لكل فاتورة، ومراقبة السلسلة بحثًا عن دفعات لكل واحد منها، وعرض الرصيد عليك. لكنه لا يستطيع تحريك ساتوشي واحد. يبقى النصف الخاص في محفظتك، أو على جهازك العتادي، ولا يغادر أبدًا.
إذن: افتح Sparrow، أو Electrum، أو تطبيق سطح المكتب لمحفظتك العتادية، وأنشئ حسابًا جديدًا مخصصًا لهذا المتجر، وصدّر مفتاحه العام الممتد. في إعدادات محفظة المتجر، اختر ربط محفظة قائمة بالفعل، والصق المفتاح، وتحقق من أول بضعة عناوين يشتقّها BTCPay مقارنة بتلك التي تعرضها محفظتك. إن تطابقت، فمسار الاشتقاق صحيح والاتصال تم. وإن لم تتطابق، فأنت اخترت نوع السكربت الخطأ — فالفارق بين xpub وzpub هو الفارق بين مجموعتين منفصلتين تمامًا من العناوين.
لا يستطيع الإنفاق، وهذا بيت القصيد — لكنه يستطيع الحصر. أي شخص يحصل عليه يستطيع اشتقاق كل عنوان سيستخدمه ذلك الحساب على الإطلاق، وبالتالي قراءة كل دفعة تلقّاها أو سيتلقّاها، طوال مدة استخدامك له. هذا كشف دائم ولا رجعة فيه لإيرادات متجرك، ولهذا ينبغي أن يكون الحساب الذي تربطه مخصصًا للمتجر لا الحساب الذي يحمل مدخراتك. عامل المفتاح بوصفه سرًا، وأبقِه بعيدًا عن لقطات الشاشة وتذاكر الدعم الفني، وإن تسرّب فعلاً، فانقل المتجر إلى حساب جديد بدل أن تعوّل على الأمل.
الآن إعدادات الفاتورة، وهي الموضع الذي يُضبَط فيه المتجر فعليًا. مدة الصلاحية افتراضيًا نحو خمس عشرة دقيقة، وهي قفل سعر لا حد تقني: فهي المدة التي أنت مستعد خلالها للاحتفاظ بسعر مُقوَّم بعملة تقليدية مقابل أصل متقلب. قصّرها في سوق متقلب، وأطلها إن كان زبائنك بطيئين. التأكيدات تحدد متى تُحسَب الفاتورة مُسوّاة — صفر تأكيدات فوري ومناسب لفنجان قهوة، وتأكيد واحد هو الافتراضي المعتاد، وستة تأكيدات لمبالغ تكون فيها ساعة انتظار أرخص من البديل. هامش التساهل مع النقص يتيح لك قبول فاتورة تصل بمبلغ أقل بجزء يسير، وهو أمر يحدث باستمرار حين تخصم محفظة الزبون رسومها من المبلغ بدل أن تضيفها إليه؛ ونسبة صغيرة هنا تزيل فئة كاملة من رسائل الدعم الفني.
ثم اختبره بأموال حقيقية، لا بشبكة testnet. أصدر طلب دفع بمبلغ زهيد، وادفعه من محفظة هاتف، وراقب الفاتورة وهي تنتقل من جديدة إلى قيد المعالجة إلى مُسوّاة. تلك المعاملة الواحدة تثبت أن العقدة متزامنة، وأن مسار الاشتقاق صحيح، وأن مزوّد أسعار الصرف يعمل، وأن الشهادة صالحة على متصفح جوال، وأن المال وصل إلى محفظة تتحكم فيها أنت. لا شيء آخر يثبت الأمور الخمسة معًا.
Bitcoin على السلسلة يُسوّي فاتورة قيمتها $400 بشكل ممتاز وأخرى قيمتها $4 بشكل سيئ: ينتظر الزبون تأكيدًا ويدفع رسومًا قد تكون جزءًا ملحوظًا من قيمة الشراء. Lightning يقلب الحالتين معًا — تسوية خلال نحو ثانيتين، ورسوم تُقاس بأجزاء من السنت — ولهذا يحتاجه متجر يبيع أشياء صغيرة القيمة بينما قد لا يحتاجه متجر يبيع أشياء كبيرة القيمة. إن ضبطت تنفيذًا لـLightning في الخطوة 03، فإن الخدمة الخلفية تعمل بالفعل وBTCPay متصل بها بالفعل؛ ولا تحتاج إعدادات المتجر إلا إلى تفعيل Lightning كوسيلة دفع.
التنفيذ الذي تختاره له عواقب تستحق أن تُذكَر بالاسم. Core Lightning هو الخيار المحافظ خفيف الوزن ذو بنية إضافات نظيفة. LND هو الأوسع انتشارًا وله أكبر منظومة من أدوات الإدارة المحيطة به. وهناك الآن نوع ثالث من الخيارات أيضًا — خدمة خلفية خفيفة الوزن تُسند إدارة القنوات إلى مزوّد خدمة مع الاحتفاظ بالمفاتيح على خادمك — وهي تقايض بعض الاستقلالية مقابل زوال كل ما ستذكره الفقرات الثلاث التالية. وهذا خيار مشروع لمتجر يريد Lightning لكنه لا يريد أن يصبح مُشغِّل عقدة؛ إنها ببساطة مقايضة مختلفة، لا مقايضة مجانية.
تحمل قناة Lightning مبلغًا ثابتًا من المال، مُقسَّمًا بين طرفيها. حين تفتح قناة وتموّلها، يكون كل ذلك المال في جهتك — وهذا يعني سعة إرسال، وسعة استقبال تساوي صفرًا تمامًا. المتجر يحتاج إلى العكس تمامًا. لذا يمكن لعقدة مُموَّلة حديثًا وبثلاث قنوات سليمة أن تفشل مع ذلك في كل فاتورة واردة دون استثناء، ويبدو الفشل وكأنه خطأ في التوجيه لا خطأ في الإعداد. هذا هو السبب الأكثر شيوعًا وراء ظهور واجهة دفع Lightning ذاتية الاستضافة معطوبة في يومها الأول.
هناك ثلاث طرق صادقة للحصول على سعة استقبال، وهي ليست متنافية. يمكنك فتح قنوات صادرة ثم الإنفاق عبرها — شراء شيء ما، دفع فاتورة، تحويل مال إلى منصة تداول — وهذا يدفع رصيدك إلى الطرف البعيد ويحوّل سعة الإرسال إلى سعة استقبال. ويمكنك أن تطلب من عقدة جيدة الاتصال أن تفتح قناة نحوك، وهو طلب عادي في مجتمع Lightning ومجاني باستثناء رسوم النظير على السلسلة. أو يمكنك شراء سيولة واردة من إحدى الخدمات العديدة التي تبيعها، وهذا يكلّف نسبة صغيرة ويستغرق دقائق لا أسابيع. لا توجد أي توصية بعمولة تسويقية في هذه الصفحة ولن تكون هناك واحدة؛ اختر بناءً على السمعة والسعر الحالي.
بمجرد أن تصبح قادرًا على تلقّي الدفعات، تحوّل ميزتان العقدة إلى واجهة متجر. عنوان Lightning — بنفس شكل عنوان البريد الإلكتروني، على نطاقك الخاص — يتيح لأي شخص إرسال المال إليك من أي محفظة حديثة دون وجود فاتورة مسبقًا، وهو أكثر آلية تبرع وإكرامية سهولة في أي مكان. ورمز QR على صفحة الدفع يمكنه عرض المسارين معًا في آن واحد، فيدفع الزبون الذي يملك محفظة Lightning خلال ثوانٍ، ويدفع الزبون الذي لا يملكها على السلسلة، من الشاشة نفسها ودون أن يُطلَب منك اتخاذ أي قرار.
قبل وصول أول دفعة عبر Lightning، نفّذ خطوة النسخ الاحتياطي التي يجب أن تحدث الآن لا لاحقًا. كل تنفيذ يحتفظ بملف صغير يصف الحالة الراهنة لقنواتك — يسمّيه LND نسخة احتياطية ثابتة للقناة — وهو الملف الذي يتيح لك استرداد الأموال إن فُقد الخادم. يتغيّر هذا الملف في كل مرة تُفتح فيها قناة أو تُغلق، لذا انسخه خارج الخادم تلقائيًا لا يدويًا. اقرأ التحذير في الخطوة 06 قبل أن تفترض أن أرشيفك الليلي يغطي هذا الأمر بالفعل، لأنه بالنسبة لـLightning تحديدًا لا يغطيه.
اختر أصغر واجهة دفع تناسب ما تملكه بالفعل. طلب الدفع رابط ترسله إلى شخص ما — لا حاجة إلى موقع إلكتروني، وهو أسرع طريقة لإصدار فاتورة لعميل. تطبيق نقطة البيع يحوّل النسخة نفسها إلى صندوق نقدي بقائمة منتجات، يعمل من هاتف في كشك بسوق. زر الدفع مقتطف HTML لموقع ثابت. إضافة المتجر تضيف Bitcoin كوسيلة دفع إلى متجر حقيقي وتكتب حالة الطلب تلقائيًا. أما REST API فيُصدر الفواتير، ويُبلغ عن حالتها، ويستدعي webhook حين تُسوَّى إحداها، وهذا هو التكامل الذي يصمد أفضل مع الزمن لأنه لا يعتمد إلا على HTTP وسر مشترك.
أيًّا كان اختيارك، اربط webhook ثم اختبر أنه يُطلَق فعلاً. الفاتورة التي تُسوَّى ولا تُخطر تطبيقك أبدًا هي نمط الفشل الذي لا يلاحظه أحد، لأن كل شيء يبدو صحيحًا على الجانبين بمعزل عن بعضهما: وصل المال، ورأى الزبون صفحة تأكيد، ويبقى الطلب دون تنفيذ. أرسل لنفسك عن قصد webhook لفاتورة مُسوّاة، وتأكد من أن نقطة النهاية لديك استلمته، وتحقق من التوقيع بدل الوثوق بالحمولة — فتلك النقطة عامة ويستطيع أي شخص إرسال طلب إليها.
هذا هو التحذير الوحيد في هذه الصفحة الذي قد يكلّفك مالاً لا وقتًا فقط، وتوثيق المشروع نفسه يذكره بالكلمات ذاتها: حالة قناة Lightning القديمة سامة. استعادة نسخة قاعدة بيانات القناة من ليلة أمس وترك العقدة تعمل يعني بث حالة يكون الطرف المقابل قد تجاوزها بالفعل — وهو ما يعامله البروتوكول كمحاولة غش ويعاقب عليه بمنحه رصيد القناة بأكمله. لذا فالأرشيف مناسب لقاعدة بيانات المتجر والإعدادات وسجل الفواتير، لكنه ليس خطة استرداد للقنوات. انسخ النسخة الاحتياطية الثابتة للقناة خارج الخادم باستمرار، واحتفظ بأحدثها، وإن استعدت يومًا خادمًا كاملاً من أرشيف، فافعل ذلك وأنت تعلم أن جانب Lightning يحتاج إلى إجراء الاسترداد الموثَّق لا إلى استعادة مباشرة.
بعد فهم ذلك، يصبح الروتين قصيرًا. يأتي النشر مع سكربت نسخ احتياطي يؤرشف وحدات التخزين ويُفرغ قاعدة البيانات مع تخطي بيانات سلسلة الكتل، ويقبل عبارة مرور بحيث يُشفَّر الأرشيف قبل أن يغادر الخادم. شغّله وفق مؤقّت، ثم ادفع بالنتيجة إلى خادم في ولاية قضائية مختلفة بالطريقة التي يصفها دليل النسخ الاحتياطي — ومستودع للإلحاق فقط يستحق العشر دقائق الإضافية هنا، لأن خادم دفع مخترقًا لا ينبغي أن يستطيع محو سجل ما عالجه.
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
الترقيات تأتي بعد ذلك، وخادم الدفع هو الخادم الوحيد الذي تكون فيه سياسة "حدّثه لاحقًا، عن قصد" هي السياسة الصحيحة. يملك النشر سكربت تحديث خاصًا به يُعيد توليد ملف compose ويسحب الصور الجديدة؛ شغّله بعد أن تقرأ ملاحظات الإصدار، لا حين تشعر مهمة cron مجدولة برغبة في ذلك. خذ الأرشيف أولاً. ارتقِ بإصدار واحد في كل مرة. واحتفظ بالإصدار السابق مكتوبًا في مكان ما، لأن التراجع الذي يمكنك تنفيذه خلال دقيقة هو ما يجعل الأمر برمته منخفض المخاطر.
./btcpay-update.sh # deliberate, after reading the release notes
df -h / # the check that should be an alert, not a habit
أخيرًا، اضبط تنبيهًا واحدًا وتذكيرًا واحدًا. التنبيه يخص استخدام القرص — فعقدة سلسلة الكتل هي العملية الوحيدة على الخادم التي تنمو من تلقاء نفسها، ووحدة تخزين ممتلئة تُسقط واجهة الدفع بطريقة يصعب تشخيصها لأن لا شيء آخر تغيّر. أطلقه عند ثمانين بالمئة، لا خمسة وتسعين. أما التذكير فشهري، ومهمته أن تفتح المتجر وتنظر في أمرين: أن الفواتير لا تزال تُسوَّى، وأن قنوات Lightning التي فتحتها لا تزال حيّة. معالج الدفع يفشل بهدوء، والطريقة التي تكتشف بها ذلك هي أن يخبرك زبون أنه لم يستطع الدفع.
استضافة المعالج بنفسك تحسين حقيقي ومحدد، وهي ليست خدعة اختفاء. خمسة أشياء تبقى صحيحة بعد إنجاز كل ما سبق، ومعرفتها هي الفارق بين دفاع حقيقي وقصة مطمئنة فقط.
سجل Bitcoin عام ودائم. إزالة البوابة أزالت قاعدة بيانات خاصة تابعة لشركة؛ لكنها لم تُشفّر السلسلة. كل دفعة يتلقّاها متجرك مرئية لأي شخص يعرف عنوانًا، إلى الأبد، والعناوين تتكتّل: فمحفظة تجمع دفعتين في إنفاق واحد تكون قد أخبرت العالم للتو أن هذين الزبونين دفعا للمتجر نفسه. هذه خاصية في الأصل نفسه لا في البرنامج، وهي السبب الذي يجعل أي نشاط تجاري له متطلب خصوصية حقيقي ينظر إلى Monero أيضًا.
اسم مضيف واجهة الدفع يُنشر في اللحظة التي يوجد فيها. سجلات شفافية الشهادات عامة ومُفهرَسة باستمرار، لذا فإن الاسم الذي اخترته في الخطوة 02 قابل للاكتشاف حتى لو لم تربطه بأي مكان أبدًا. ولهذا يجب الاستيلاء على حساب المسؤول في الدقائق الأولى لا في الأسبوع الأول، ولهذا تستحق صفحة تسجيل الدخول كلمة مرور قوية وعامل تحقق ثانٍ منذ اليوم الأول.
الخروج إلى العملة التقليدية هو حيث تعود الهوية إلى الظهور. لا شيء في هذه الحزمة يتطلب منك إثبات هويتك لقبول دفعة. أما تحويل العائدات إلى مال مصرفي فيتطلب ذلك في الغالب دائمًا، لأن ذلك التحويل يجري عبر منصة تداول أو وسيط خاضع للتنظيم. الاستضافة الذاتية تنقل شرط إثبات الهوية من نقطة البيع إلى نقطة الخروج — وهذا تحسّن حقيقي في مستوى التعرّض، وليس مماثلاً لانعدامه تمامًا.
التزامات الإبلاغ الخاصة بك لم تنتقل مع الخادم. مكان تسجيل النشاط التجاري ومكان إقامة صاحبه هما ما يحددان ما هو مُستحَق وما يجب الإفصاح عنه. أما الولاية القضائية للخادم الذي يُصدر الفواتير فلا دخل لها في الأمر. في معظم الأماكن، يُعد تلقّي عملة مشفّرة مقابل سلع أو خدمات دخلاً عاديًا بقيمته يوم تلقّيه، والتصرف فيها لاحقًا حدث منفصل مرة أخرى. والنسخة ذاتية الاستضافة سجل أفضل من حساب معالج دفع قد تفقده — وهي ليست طريقة لعدم امتلاك سجل من الأساس.
لا وجود لعمليات ارتداد المدفوعات، وهذا سيف ذو حدين. الدفعة المؤكَّدة نهائية، وهذه بالضبط هي الخاصية التي تجعل الاحتيال على التاجر شبه مستحيل، وهي سبب كون الرسوم صفرًا. وهي أيضًا السبب في أن الزبون غير الراضي لا يملك أي آلية على الإطلاق سوى حسن نيتك. انشر سياسة استرداد، واستخدم ميزة الصرف لتطبيقها، وأدرك أنك توليت مهمة تسوية النزاعات التي كانت تلك النسبة تُدفَع أصلاً لتغطية تكلفتها.
ما اشتريته فعليًا، بدقة: المال يصل إلى محفظة لا يستطيع الإنفاق منها سواك، ولا أحد يستطيع إيقاف عملية البيع، ولا أحد يأخذ حصة، وقائمة من دفع لك وكم دفع لا توجد إلا على خادم تستأجره دون اسم محدد. هذا ادعاء ضيق النطاق، لكنه حقيقي. وهو يستحق ما يكلّفه فقط إذا أُنجزت الخطوة 06 — فمعالج دفع ذاتي الاستضافة بلا استعادة مُختبَرة ليس تحسينًا تجاريًا، بل نقطة فشل وحيدة تحمل إيرادك.
| الفئة | شهرياً | الموارد | ما يشغّله براحة |
|---|---|---|---|
| Sentinel | $3.90 | 2 vCPU · 4 GB · 120 GB · 1 Gbps | عقدة مُقلَّمة بحجم 25–50 GB مع Lightning. أضف swap؛ وراقب القرص. |
| Garrison | $7.90 | 4 vCPU · 8 GB · 240 GB · 1 Gbps | عقدة مُقلَّمة بحجم 100 GB، مع Lightning وهامش يكفي لسنوات. الخيار الافتراضي. |
| Ravelin | $16.90 | 8 vCPU · 16 GB · 480 GB · 2.5 Gbps | الشيء نفسه، إضافةً إلى سلسلة ثانية أو متجر نشط بإضافات. |
| Bulwark | $32.90 | 16 vCPU · 32 GB · 960 GB · 5 Gbps | عقدة أرشيفية بمساحة كافية لمواصلة النمو. فقط إن كنت بحاجة إلى التاريخ الكامل. |
BTCPay والمفهرس وPostgreSQL مجتمعة لا تتجاوز بضعة غيغابايتات ولا تكاد تستهلك أي معالجة بعد مزامنة العقدة؛ ومتجر يستقبل مئة دفعة يوميًا لن يُثقل حتى أصغر فئة من ناحية المعالجة. ما تختلف فيه الفئات هو القرص، والقرص يُحدَّد بالكامل في الخطوة 01. المزامنة هي الساعة الوحيدة الثقيلة فعلاً في هذا المشروع — وهي مُقيَّدة بالإدخال والإخراج لا بالمعالج، ولهذا يهم NVMe هنا بينما لا يهم عدد الأنوية. النطاق الترددي غير محدود في كل الفئات، لذا فإن تشغيل عقدة Lightning يمكن الوصول إليها علنًا لا يكلّف شيئًا إضافيًا.
أول شخص يسجّل على نسخة جديدة يصبح هو المسؤول، وقد نُشر اسم المضيف في سجلات شفافية الشهادات لحظة إصدار الشهادة. سجّل خلال دقائق من انتهاء التثبيت، ثم تحقق في إعدادات الخادم من أن التسجيل غير متاح للغرباء.
ترك الخادم يُنشئ المحفظة نقرة واحدة، لكنه يضع البذرة على خادم مهمته الرد على الغرباء. اربط بدلاً من ذلك مفتاحًا عامًا ممتدًا: يراقب المتجر، ويشتق العناوين، ويطابقها، ولا يستطيع الإنفاق. احتفظ بالنصف الخاص في محفظة أو على جهاز عتادي.
قاعدة بيانات قناة من الأمس تصف حالة تجاوزها الطرف المقابل بالفعل. إعادة تشغيلها يمكن أن تمنحه رصيد القناة بأكمله كعقوبة. الأرشيف الليلي يغطي المتجر؛ أما القنوات فتحتاج إلى مسار الاسترداد الموثَّق ونسخة احتياطية للقناة تُنسخ باستمرار.
تمويل قناة يمنحك سعة إرسال، لا سعة استقبال. عقدة جديدة تحمل مالاً تفشل مع ذلك في كل دفعة واردة، ويبدو الخطأ وكأنه مشكلة توجيه. احصل على سيولة واردة قبل أن تعلن عن خيار Lightning، لا بعد أول شكوى.
اربط حسابًا عمره ثلاث سنوات بعقدة مُقلَّمة، ولن تظهر معاملاته القديمة أبدًا، لأن الكتل التي كانت تحتويها أُسقطت. لا شيء معطوب ولا شيء يقول ذلك. امنح المتجر حسابًا أُنشئ حديثًا، أو شغّل عقدة أرشيفية.
العقدة هي العملية الوحيدة التي تنمو من تلقاء نفسها، والقرص الممتلئ يُتلِف الفهرس بدل أن يتوقف بأدب — أي أن عليك بدء التنزيل من جديد. قارن حساب الخطوة 01 بالفئة التي طلبتها، واضبط التنبيه عند ثمانين بالمئة لا خمسة وتسعين.
أحد عشر سؤالًا يتكرر طرحها أثناء بناء هذا — بدءًا بالسؤالين اللذين يحددان ما إذا كان ينبغي عليك بناؤه أصلًا.
إنه مجاني فعلاً، وشكل تلك المجانية أهم من السعر نفسه. BTCPay Server برنامج مفتوح المصدر صادر برخصة متساهلة وتُشرف عليه مؤسسة لا شركة ذات هدف ربحي؛ لا رسوم لكل معاملة، ولا نسبة مئوية، ولا حد أدنى للحجم، ولا حساب يُفتح، ولا عقد يُوقَّع، لأنه لا يوجد طرف مقابل على الإطلاق — أنت تُشغّل برنامجًا على خادمك الخاص تمامًا كما تُشغّل خادم ويب. ما تدفعه بدلاً من ذلك حقيقي لكنه مختلف: بضعة دولارات شهريًا مقابل الخادم، وأمسية لإعداده، والتزام دائم بإبقاء خدمة معالجة الدفعات محدَّثة بالتصحيحات. المقارنة التي ينبغي على الناس إجراؤها فعلاً ليست "مجاني مقابل واحد بالمئة". بل هي "مهمة تشغيلية تتولاها بنفسك مقابل اعتمادية لا تتحكم فيها"، والإجابة الصادقة هي أن متجرًا يستقبل عشرين دفعة في السنة يُخدَم على الأرجح بشكل أفضل عبر حل مُستضاف، بينما متجر يستقبل عشرين دفعة في الأسبوع يحصل هنا على حل أرخص وأكثر حرية في آن واحد.
أنت من يحتفظ بها، والآلية تستحق أن تُفهَم لا أن تُصدَّق على الثقة. الإعداد المُوصى به يمنح BTCPay مفتاحًا عامًا ممتدًا من محفظة تتحكم فيها أنت بالفعل. ومن ذلك المفتاح يستطيع الخادم اشتقاق عنوان استقبال جديد لكل فاتورة ومراقبة السلسلة بحثًا عن دفعات إليه — ولا يستطيع تكوين عملية إنفاق صالحة، لأن النصف الخاص لا يغادر محفظتك أبدًا. ينتقل المال من الزبون مباشرة إلى عنوان لا يستطيع تحويل رصيده سواك؛ ولا شيء يُحتفَظ به على الخادم على الإطلاق، لذا لا يوجد ما يمكن حجبه أو تجميده أو خسارته في اختراق. سيعرض عليك BTCPay أيضًا إنشاء محفظة لك والاحتفاظ بالبذرة على الخادم، وهذا مريح وهو الإعداد الوحيد الذي يعارضه هذا الدليل لأي شيء يحمل إيرادًا حقيقيًا: فهو يحوّل خادمًا عامًا مكشوفًا على الإنترنت إلى محفظة ساخنة. أما Lightning فهي الاستثناء الحقيقي — إذ يجب أن تكون أموال القناة حيّة لتوجيه الدفعات — ولهذا ينبغي معاملة رصيد Lightning كصندوق نقدي لا كخزنة.
يعتمد الأمر كليًا على قرار واحد، والمدى بين طرفيه رتبتان من الحجم. عقدة Bitcoin Core الأرشيفية تحتفظ بكل كتلة عُدِّنت على الإطلاق: أكثر من 700 GB براحة في 2026، وتضيف نحو 50 GB سنويًا، لذا فهي تحتاج إلى فئة مصمَّمة لها وستظل بحاجة إلى المزيد باستمرار. أما العقدة المُقلَّمة فتتحقق من كل كتلة بالطريقة نفسها تمامًا ثم تتخلص من القديمة منها، محتفظة بنافذة متجددة — ويوفّر مولّد النشر أجزاءً تُقلِّم إلى نحو 100 أو 50 أو 25 أو 5 GB، وأي رقم من 50 GB فما فوق خيار إنتاجي جاد تمامًا لتاجر. أضف نحو 10 إلى 20 GB للمفهرس وقاعدة البيانات وعقدة Lightning ونظام التشغيل، وينتج الحساب التالي: فئة بسعة 120 GB تُشغّل نشرًا مُقلَّمًا بحجم 25–50 GB، وفئة بسعة 240 GB تُشغّل نشرًا بحجم 100 GB مع هامش يكفي لسنوات، والنشر الأرشيفي يريد 960 GB. اختر التقليم ما لم يكن لديك سبب محدد يمنعك من ذلك؛ فنموذج الأمان مطابق تمامًا في الحالتين.
جزئيًا، ويستحق الأمر أن تعرف بالضبط أين يقع الخط الفاصل. يمكن توجيه الحزمة نحو عقدة Bitcoin تُشغّلها أنت بالفعل في مكان آخر — خادم على tailnet نفسها، أو خادم خلف نفق — وهذا ترتيب مدعوم بالكامل يوفّر عليك نسخة ثانية من السلسلة إن كنت قد أنجزت العمل بالفعل في دليل عقدة Lightning. أما ما لا يمكنك فعله بمنطق سليم فهو تشغيل معالج دفع في مواجهة عقدة عامة يملكها شخص آخر، والسبب ليس الترخيص بل الخصوصية والثقة: فأيًّا كان من يجيب عن استعلاماتك يتعرّف على كل عنوان يراقبه متجرك، وهو ما يعادل معرفة إيرادك، ويمكنه أيضًا أن يكذب عليك بشأن ما إذا كانت فاتورة قد دُفعت. هناك خيار ثالث يلجأ إليه الناس — استخدام نسخة BTCPay مُستضافة يُشغّلها طرف ثالث — وهو طريقة معقولة تمامًا للبدء. لكن كن واضحًا أن ذلك ينقل بيانات المتجر إلى مُشغِّل قادر على رؤيتها، وهو معظم ما كانت الاستضافة الذاتية من أجله.
لا، ومن المعقول تمامًا تخطّيه في اليوم الأول. الاقتصار على السلسلة إعداد كامل وعامل: تُدفع الفواتير، وينتظر الزبون تأكيدًا، ويُسوّي المتجر الحساب. ما يشتريه لك Lightning هو الفارق بين "نحو عشر دقائق ورسوم مؤلمة على المبالغ الصغيرة" و"ثانيتين وجزء من السنت"، وهو الفارق بين واجهة دفع تعمل مع فاتورة قيمتها $400 وأخرى تعمل أيضًا مع فاتورة قيمتها $4. أما الثمن فهو أن Lightning خدمة خلفية ثانية بأموالها الخاصة، وأنماط أعطالها الخاصة، وانضباطها الخاص في النسخ الاحتياطي — بما في ذلك مشكلة السيولة الواردة في الخطوة 05 وتحذير الحالة السامة في الخطوة 06. الترتيب المعقول هو الإطلاق على السلسلة أولاً، والتأكد من أن خط الأنابيب بأكمله يعمل بأموال حقيقية، ثم إضافة Lightning كمشروع ثانٍ مقصود بدل إقحامه في الأمسية نفسها.
أي محفظة قادرة على تصدير مفتاح عام ممتد لحساب واحد — Sparrow، أو Electrum، أو BlueWallet، أو محفظة عتادية عبر إحدى هذه المحافظ — والجزء المهم هنا ليس العلامة التجارية بل أن يكون الحساب مخصصًا لا الحساب الذي تحفظ فيه مدخراتك. لسببين. الأول خصوصي ودائم: المفتاح العام الممتد فهرس رئيسي لكل عنوان سيشتقّه هذا الحساب مستقبلاً، فأي شخص يحصل عليه يستطيع حصر كل دفعة تلقّاها ذلك الحساب أو سيتلقّاها. ومنح المتجر حسابه الخاص يعني أن أي تسريب لن يكشف سوى إيرادات المتجر ولا شيء غيرها. والثاني عملي: الحساب المخصص يجعل دخل المتجر واضحًا للقراءة دون أن تُجري تحقيقًا جنائيًا في تاريخ مختلط، ويجعل تحويل الأموال إلى التخزين البارد قرارًا واحدًا مملًا لا أكثر. والترتيب الذي ينبغي أن تسعى إليه هو محفظة عتادية تحمل المفتاح الخاص بينما يراقب المتجر المفتاح العام.
نعم، مع تحفظ أن كل سلسلة إضافية عقدة كاملة إضافية بقرصها الخاص، ووقت مزامنتها الخاص، وصيانتها الخاصة. يدعم المولّد عملة مشفّرة ثانية وثالثة مباشرة، وهناك تكامل مع Monero متاح كجزء إضافي — ويعرض النشر نفسه عندئذٍ على الزبون خيارًا بين مسارات الدفع عند إتمام الشراء. ما يقلل الناس من تقديره هو فاتورة الموارد: فكل سلسلة تفعّلها خدمة خلفية إضافية تُفهرِس سجلاً آخر على وحدة التخزين نفسها، وسلسلتان على فئة مصمَّمة لواحدة هما الطريقة التي ينفد بها القرص من خادم دفع في يوم أحد. إن كانت Monero مهمة لمتجرك، فاقرأ دليل عقدة Monero أولاً وفكّر في تخصيص خادم مستقل لها؛ فمعالج دفع متوقف بسبب خدمة خلفية غير ذات صلة ملأت القرص أسوأ من معالج يقبل Bitcoin فقط.
أربع طرق، بترتيب تصاعدي بحسب مقدار البرمجيات التي تملكها بالفعل. إن لم يكن لديك شيء، يوفّر BTCPay صفحة نقطة بيع مُستضافة وصفحة طلب دفع يمكنك إرسالها كرابط — وهذا يكفي لإصدار فاتورة لعميل أو لقبول دفعات في كشك بسوق دون أي موقع إلكتروني على الإطلاق. إن كان لديك موقع ثابت، فإن زر الدفع مجرد مقتطف HTML. وإن كان لديك متجر حقيقي، فهناك إضافات مُصانة لمنصات التجارة الإلكترونية الشائعة تحوّل Bitcoin إلى وسيلة دفع إضافية عند إتمام الشراء مع إعادة حالة الطلب تلقائيًا. وإن كان لديك تطبيقك الخاص، فإن REST API يُصدر الفواتير، ويُبلغ عن حالتها، ويستدعي webhook تحدده أنت حين تُسوَّى إحداها — وهذا هو التكامل الذي يصمد أفضل مع الزمن، لأنه لا يعتمد على شيء سوى HTTP. ابدأ بطلب دفع، تأكد من وصول المال، ثم ادمجه في تطبيقك.
بالنسبة للسلسلة، لا، وهذه هي الميزة الهادئة لتصميم المراقبة فقط: العملات لم تكن على الخادم قط. تُشتق العناوين من مفتاح عام، لذا فإن تثبيتًا جديدًا بنفس المفتاح العام الممتد يعيد اكتشاف كل دفعة؛ وما تخسره في فشل تام هو إعدادات المتجر وسجل فواتيره، وهذا بالضبط ما وُجد سكربت النسخ الاحتياطي من أجله. أما Lightning فهي إجابة مختلفة فعلاً وتستحق جملة خاصة بها: أموال القناة حيّة، وحالة القناة تتغيّر مع كل دفعة، واستعادة نسخة قديمة من تلك الحالة يمكن أن تكلّفك رصيد القناة بالكامل، لأن نشر حالة تم تجاوزها هو بالضبط ما يعاقب عليه البروتوكول. لذا فالموقف الصحيح غير متماثل. انسخ قاعدة البيانات والإعدادات احتياطيًا وفق جدول، وشفّرها، وأرسلها إلى مكان غير هذا الخادم — وعامل النسخة الاحتياطية الثابتة لقناة Lightning بوصفها ملفًا منفصلاً يُنسخ باستمرار لا سطرًا في الأرشيف الليلي.
لا، ومن المفيد أن نكون صريحين في هذا الشأن لأن العكس هو المُفترَض ضمنيًا وبصمت. إزالة معالج الدفع تزيل وسيطًا، ورسومًا، وطرفًا كان بإمكانه تجميد أموالك. لكنها لا تغيّر ما تدين به، ولمن تدين به، ولا ما إذا كانت عملية بيع خاضعة للضريبة — فتلك أمور تابعة لمكان وجودك أنت ونشاطك التجاري، لا لمكان الخادم ولا لأي برنامج أصدر الفاتورة. في معظم الولايات القضائية، يُعد تلقّي عملة مشفّرة مقابل سلع أو خدمات دخلاً تجاريًا عاديًا بقيمته يوم تلقّيه، والتصرف فيها لاحقًا حدث منفصل مرة أخرى؛ وكون السجل يعيش الآن في قاعدة بياناتك الخاصة لا في قاعدة بيانات معالج دفع لا يجعله أمرًا اختياريًا، والنسخة ذاتية الاستضافة هي عمليًا مسار تدقيق أفضل من لقطة شاشة لحساب لم يعد بحوزتك. أما موضع المكسب الحقيقي في الخصوصية فهو أضيق نطاقًا وحقيقي في آن واحد: لا يحتفظ أي طرف ثالث بقائمة جارية بزبائنك ومبالغهم. اسأل محاسبًا في ولايتك القضائية عن البقية.
نعم — نسخة BTCPay تطبيق ويب عادي بقاعدة بيانات عادية وخدمة خلفية عادية لسلسلة الكتل، ولا شيء في سياسة الاستخدام المقبول يعامله بشكل مختلف عن متجر أو مدونة. الملاحظات العملية تخص الموارد لا السياسة: عقدة قيد المزامنة ثقيلة على القرص وعلى الإدخال والإخراج في يومها الأول ثم شبه خاملة بعد ذلك، والنطاق الترددي غير محدود في كل الفئات فلا يخضع تشغيل عقدة Lightning عامة لأي قياس استهلاك، والمنافذ الواردة لاتصالات النظراء متاحة لك لفتحها. أما الجزء المتّسق مع بقية الموقع فهو التماثل: الحساب لا يحتاج إلى اسمك القانوني، وتُسوَّى الفاتورة بـMonero أو Bitcoin أو Lightning، والخادم الذي بات يعرف الآن كل زبون لديك مستأجَر من شركة لا تعرف من أنت. معالج دفع تستضيفه بنفسك على حساب معروف الهوية نقل السجل، لا التعرّض.
Garrison — 4 vCPU، و8 GB، و240 GB من NVMe مقابل $7.90 شهريًا، في هلسنكي أو ستوكهولم أو أوسلو أو ريكيافيك. يكفي لعقدة Bitcoin مُقلَّمة، وخدمة Lightning الخلفية، والمفهرس، والمتجر، مع هامش يكفي لسنوات. لا بريد إلكتروني عند التسجيل، ولا وثيقة هوية، ولا شركة تحتفظ بقائمة كل من دفع لك على الإطلاق.
آخر مراجعة · 2026-10-12 · المصادر · توثيق BTCPay Server (النشر عبر Docker، وأجزاء التخزين، والنسخ الاحتياطي والاسترداد، وإعدادات المتجر)، وتوثيق Bitcoin Core حول التقليم، وتوثيق تنفيذات Lightning حول النسخ الاحتياطية الثابتة للقنوات · الدورية · سنوياً
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 الخاص بك — كامل أو مقلَّم، RPC خلف نفق، بث عبر Tor.
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.
استضافة خاصة، مبنية في الشمال.