Bitcoin Payment Processor

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

يمكن لـ ⁦BTCPay Server⁩ اشتقاق عناوين الاستلام من البيانات العامة لمحفظة موجودة من دون مفتاحها الخاص. ويختلف ذلك عن محفظة ساخنة مخزنة على الخادم وعن الوصول إلى أموال عقدة ⁦Lightning⁩. وقد يحتفظ مزود الخدمة بالأموال حتى صرفها. قيّم الحيازة الفعلية للمفاتيح والصلاحيات وإمكانية السحب، لا اسم المنتج أو كلمة ⁦non-custodial⁩ وحدهما. [BTCPay Server — General FAQ] [BitPay — Configuring settlements]

تثبّت فاتورة ⁦BTCPay Server⁩ المعتادة سعر الصرف لفترة محدودة. ولا يعني انتهاء الصلاحية استحالة وصول تحويل لاحق. للدفع الناقص والزائد والمتأخر حالات مختلفة تتطلب إجراءات لاحقة. احتفظ بالمبلغ الأصلي وسعر الصرف المستخدم؛ فقد يطلب طلب دفع جديد عددًا مختلفًا من وحدات ساتوشي إذا تغيّر السعر. [BTCPay Server — Invoice lifecycle]

يميّز ⁦BTCPay Server⁩ بين ⁦Processing⁩، التي تنتظر التأكيدات المضبوطة، و⁦Settled⁩؛ وتنتقل مدفوعات ⁦Lightning⁩ الناجحة إلى ⁦Settled⁩ من دون انتظار كتلة. لا يمكن مساواة أسماء حالات المزودين الآخرين آليًا: يحذّر ⁦BitPay⁩ صراحة من أن ⁦paid⁩ ليست ضمانًا للدفع. يجب أن يضع المتجر قاعدة لتسليم البضاعة تخص الحالة وطريقة الدفع المحددتين. ولا ينشئ تغيير الحالة يدويًا تأكيدًا من الشبكة. [BTCPay Server — Invoice lifecycle] [BitPay — Invoice webhooks]

يتحقق ⁦BTCPay⁩ من ⁦webhook⁩ باستخدام ⁦HMAC-SHA256⁩ على بايتات جسم الرسالة الأصلية وسر مشترك. ويصف ⁦BitPay⁩ إشعارات ⁦IPN⁩ غير موقّعة: الإشعار دافع للاستعلام عن حالة الفاتورة عبر ⁦API⁩، وليس في ذاته دليلًا موثوقًا. قد تتكرر الإشعارات. لذلك يجب أن يتعرف التكامل بثقة على الحدث المعاد تسليمه ويمنع شحن الطلب نفسه مرة ثانية؛ وبعد الانقطاع ينبغي مطابقة الحالات المحفوظة مع المعالج. [BTCPay Server — Webhook validation example] [BitPay — Invoice webhooks]

قد لا يتزامن تأكيد دفعة العميل مع صرف الأموال من المزود. يتيح ⁦BitPay⁩ ضبط عملة التسوية وحساب مصرفي أو عنوان عملة مشفرة؛ وقد يتطلب التغيير موافقة. تحقق من العملات المتاحة والحدود والمواعيد والرسوم والسيطرة على الأموال حتى صرفها. الاستلام المباشر في محفظتك لا يستخدم تلقائيًا نموذج الصرف هذا عبر مزود الخدمة. [BitPay — Configuring settlements] [BTCPay Server — General FAQ]

يتطلب رد الأموال دفعة أخرى والتحقق من المستلم؛ ولا يغيّر معاملة بيتكوين الأصلية. افصل بين الاعتراض على الطلب وقرار مبلغ الرد وإرسال الأموال فعليًا. احتفظ بالروابط بين الطلب والفاتورة والدفعة، وأسعار الصرف والرسوم والمبالغ المردودة. يساعد تصدير التقرير في التوثيق، لكنه لا يحل وحده كل الالتزامات المحاسبية المحلية ولا نزاعًا حول تسليم البضاعة. حتى التحويل المؤكد لا يحسم وحده نهائية الصفقة قانونيًا: تحقق من الاعتراضات وأي آلية ⁦chargeback⁩ والالتزامات بحسب مسار الدفع والعقد والاختصاص القضائي. [BTCPay Server — Refunds] [BTCPay Server — Reporting] [BitPay — Merchant and shopper terms]

اختبر الدفع الناجح والناقص والمتأخر والمتكرر الإشعارات، واستعادة العمل بعد الانقطاع. امنح مفتاح ⁦API⁩ الصلاحيات اللازمة فقط واقصره على المتجر المعني. لا تنقل بيانات غير ضرورية عن العميل في البيانات الوصفية. احسب تكاليف الاستضافة والتحديثات والسيولة والدعم؛ فالبرمجيات المجانية لا تعني انعدام تكاليف التشغيل. توافر الخدمة وحيازة المفاتيح وصحة التكامل شروط منفصلة. [BTCPay Server — eCommerce integration] [BTCPay Server — Lightning operations]