Bitcoin Payment Processor

تخيّل عميلًا يطلب كتابًا عبر الإنترنت. يطلب المتجر من المعالج إنشاء invoice، أي طلب دفع يحدد المبلغ والعملة، ويحفظ معرّفه إلى جانب رقم طلب الشراء. يفتح العميل صفحة الدفع أو يمسح رمز QR ويدفع. تتيح العلاقة المحفوظة للمتجر معرفة الشراء الذي تخصه الأموال. ومن دونها لا يكفي اكتشاف وصول بيتكوين إلى مكان ما. كما أن العودة إلى صفحة «شكرًا لطلبك» لا تثبت أن المتجر تلقّى الدفعة. [1]

يمكن لـ BTCPay Server إنشاء عناوين استلام من البيانات العامة لمحفظة موجودة، من دون الحصول على المفاتيح الخاصة التي تسمح بالإنفاق. يختلف هذا عن محفظة ساخنة مفاتيحها على الخادم، أو الوصول إلى أموال عقدة Lightning التي تعالج المدفوعات السريعة. وفي الخدمة قد يسيطر المزود على الأموال قبل صرفها. لذلك لا تكفي تسمية non-custodial، أي عدم تسليم المفاتيح للمزود، وحدها. افحص الصلاحيات الفعلية، ومَن يستطيع إرسال الأموال، وهل تحتاج إلى موافقة طرف آخر للحصول عليها. [2] [6]

قد يُسعّر الكتاب بعملة معتادة بينما يرسل العميل بيتكوين. يحدد BTCPay Server المبلغ وسعر الصرف في طلب الدفع لفترة محدودة. لا يمنع انتهاء المدة وصول تحويل متأخر، وعلى المتجر التعامل معه بطريقة صحيحة، كما يفعل مع النقص والزيادة في المبلغ. يُحفظ المبلغ الأصلي وسعر الصرف للمطابقة المحاسبية. وقد يتطلب طلب جديد بسعر صرف مختلف عددًا مختلفًا من وحدات ساتوشي، أصغر وحدات بيتكوين، رغم بقاء سعر الكتاب كما هو. [3]

تعني Processing في BTCPay Server أن المبلغ المطلوب دُفع، لكن شروط الإتمام لم تتحقق بعد، مثل تأكيد المعاملة في الكتل. وتعني Settled تحقق تلك الشروط؛ ولا تنتظر مدفوعات Lightning عادةً تأكيدًا في كتلة. وتعرّف الخدمات الأخرى حالاتها بنفسها. يحذّر BitPay صراحةً من أن paid ليست ضمانًا للدفع. لذلك يجب أن تستند قاعدة الشحن إلى وثائق الخدمة المختارة وطريقة الدفع. وضع علامة «مدفوع» يدويًا لا يعوّض التحقق من الدفعة الفعلية. [3] [5]

يبلغ المعالج عن التغييرات عبر webhook، وهي رسالة آلية بين الخوادم. يتحقق المتجر من مصدرها ومحتواها. في BTCPay تُحسب HMAC-SHA256 من بايتات الرسالة الأصلية وسر مشترك؛ إنها شفرة تحقق من الأصالة، وليست تأكيدًا من شبكة بيتكوين. أما BitPay فلا يوقّع إشعار IPN، لذا ينبغي استخدامه فقط لبدء الاستعلام عن الحالة الفعلية عبر API، واجهة التواصل بين البرامج. قد تصل الرسالة ثانيةً، فيسجل المتجر تنفيذ الطلب كي لا تؤدي الإعادة إلى شحنة أخرى. وبعد الانقطاع يطابق الحالات المحفوظة مع المعالج. [4] [5]

استلام دفعة العميل واستلام تحويل من الخدمة حدثان مختلفان. يتيح BitPay تحديد عملة تسوية مدعومة وحساب مصرفي أو عنوان عملة مشفرة؛ وقد يتطلب التغيير موافقة. يفحص التاجر أيضًا المواعيد والحدود والرسوم ومَن يتحكم في الأموال قبل صرفها. وقد لا توجد هذه الخطوة الوسيطة عند الاستلام المباشر في محفظته. يجب أن يميز نظام البيع بين الترتيبين حتى لا توحي كلمة «مدفوع» بأن المال أصبح متاحًا بالفعل. [6] [2]

لا يمحو رد المال معاملة بيتكوين الأصلية. يعالج المتجر طلب العميل أولًا، ويحدد المبلغ والعملة ويتحقق من المستلم، ثم يرتب دفعة جديدة. وجود رابط للمطالبة برد الأموال لا يعني أنها أُرسلت. تبقى سجلات طلب الشراء وطلب الدفع والاستلام وسعر الصرف والرسوم والرد محفوظة. تساعد التقارير المصدّرة المحاسب، لكنها لا تفي وحدها بجميع الالتزامات المحلية. كذلك لا يحسم تأكيد الشبكة نزاعًا حول التسليم ولا يلغي الواجبات التعاقدية أو القانونية عند معالجة الشكوى. [7] [8] [10]

لا تكفي عملية شراء تجريبية ناجحة قبل الإطلاق. ينبغي اختبار الدفع الناقص والمتأخر والإشعارات المكررة والتعافي من الانقطاع. مفتاح API هو بيانات اعتماد وصول البرنامج، فيُمنح فقط الصلاحيات اللازمة للمتجر المعني. ولا تُرفق بيانات شخصية غير ضرورية عن العميل. يتطلب التشغيل الذاتي استضافة وتحديثات ودعمًا؛ ويحتاج Lightning أيضًا إلى إدارة السيولة، أي الأموال والمساحة المتاحة في القنوات لإجراء المدفوعات. البرنامج المجاني لا يجعل التشغيل مجانيًا. تُفحص الإتاحة وحماية المفاتيح وصحة الربط بالمتجر كلٌّ على حدة. [1] [9]