BTCPay Server

يربط التاجر نقطة البيع أو المتجر الإلكتروني بفاتورة وطريقة الاستلام المختارة. ينشئ ⁦BTCPay Server⁩ عناوين دفع ⁦on-chain⁩ وطلبات ⁦Lightning⁩، ويتابع المدفوعات ويعرض الفواتير. ويشمل تطبيقات لنقاط البيع والتبرعات وواجهات للتكامل. تتيح الشيفرة المفتوحة الفحص والتعديل، لكنها لا تثبت وحدها أمان تثبيت معين. [BTCPay Server — Source repository]

يمكن ربط محفظة ⁦on-chain⁩ موجودة بمفتاح عام موسع: يشتق الخادم عناوين الاستلام من دون حاجته إلى مفتاحها الخاص. للمحفظة الساخنة المنشأة على الخادم نموذج مخاطر مختلف. وقد تسمح صلاحيات عقدة ⁦Lightning⁩ بالتصرف في أموالها. افصل مفاتيح الاستلام والتوقيع والإدارة؛ فكلمة ⁦self-hosted⁩ وحدها لا تحدد مَن يستطيع إنفاق المال. [BTCPay Server — Wallet setup] [BTCPay Server — General FAQ]

يشغّل طرف ثالث الخادم بينما يستطيع المستخدم الاستلام مباشرة في محفظته. هذا لا يلغي الثقة: قد يستبدل خادم خبيث أو مخترق المفتاح العام ويوجّه المدفوعات المستقبلية إلى جهة أخرى. العملات المستلمة بالفعل في محفظتك وبيانات الدفع الجديدة المعروضة أمران مختلفان. تحقق من الاستلام مستقلًا عن نقطة الدفع أيضًا. قد يصيب الهجوم نفسه نسخة خاصة مخترقة؛ كما يؤثر المضيف في التوافر والخصوصية. [BTCPay Server — Third-party hosting risks]

يضبط المتجر العملة ومصدر السعر والصلاحية والتأكيدات المطلوبة. تنتظر ⁦Processing⁩ في الدفع ⁦on-chain⁩ الشرط المضبوط، وتدل ⁦Settled⁩ على تحققه. لا يلزم أن ينتظر دفع ⁦Lightning⁩ الناجح كتلة. عالج الدفع الناقص والزائد والوصول المتأخر وتغييرات الحالة اليدوية التي لا تنشئ تأكيدًا من الشبكة. حساب السعر ببيتكوين ليس بيعًا مقابل عملة ورقية: يضيف ملحق التحويل أو مزوده رسومه ومتطلبات الثقة الخاصة به. [BTCPay Server — Invoice lifecycle] [BTCPay Server — Store rates and policies] [BTCPay Server — General FAQ]

يجب أن يحتفظ المتجر بصلة الطلب بمعرّف الفاتورة. تتيح ⁦Greenfield API⁩ تحديد الصلاحيات للمتجر المعني؛ لا تعطِ المفتاح وصولًا أكثر مما يلزم. تحقق من ⁦webhook⁩ وفق الوثائق وعالج الحدث المكرر من دون شحنة ثانية. عودة العميل إلى صفحة شكر لا تثبت الدفع وحدها. بعد الانقطاع طابق السجل المحلي مع الحالات الفعلية للفواتير والمدفوعات. [BTCPay Server — eCommerce integration]

تحتاج العقدة الخاصة إلى التوافر وإدارة القنوات وسيولة واردة. تعالج خدمة السيولة أو ⁦swap⁩ أو المحفظة الوصائية أجزاء مختلفة من المشكلة، وليست نموذجًا واحدًا. تبقى السيطرة على الأموال لدى المزود في الخدمة الوصائية؛ أما البدائل الأخرى فتحتاج فحص الصلاحيات والمخاطر المحددة. لا يضمن شعار ⁦BTCPay Server⁩ نجاح كل دفعة أو انعدام الرسوم. [BTCPay Server — Lightning options]

انسخ بيانات المتاجر والفواتير والإعدادات وبيانات المحافظ اللازمة بحسب النشر؛ ولا تستبدل ⁦seed⁩ قاعدة بيانات الطلبات. تشترط وثائق ⁦Docker⁩ التحقق من إمكانية استعادة النسخة الاحتياطية. قد تسبب حالة قديمة لقناة ⁦Lightning⁩ فقدان الأموال إذا استُعيدت خطأ. يختلف الانتقال المخطط مع إيقاف العقدة الأصلية بصورة سليمة عن التعافي من كارثة؛ وبعد تشغيل البديل لا تشغّل النسخة الأصلية للعقدة نفسها. يجب أن يلائم الإجراء النظام الخلفي المستخدم. [BTCPay Server — Backup and restore]

خطط للتحديثات وحماية وصول المسؤول والانكشاف الشبكي ومراقبة التوافر والنسخ الاحتياطية المتحقق منها. قد تكلف الاستضافة والأجهزة ورسوم الشبكة والسيولة والدعم مالًا حتى إن لم يأخذ البرنامج نسبة من كل دفعة. قلل بيانات العملاء المخزنة. يعالج التاجر رد الأموال ونزاعات التسليم، لا مطورو المشروع؛ ولا يضمن تصدير الفواتير الوفاء بكل الالتزامات المحاسبية. [BTCPay Server — Maintenance] [BTCPay Server — General FAQ] [BTCPay Server — eCommerce integration]