Bitcoin Point of Sale

يختار الموظف القهوة أو يدخل سعرها، ثم يتحقق من العملة والإكرامية والمجموع. يوفر BTCPay Server مثلًا قائمة منتجات وسلة ولوحة أرقام. ثم ينشئ invoice، أي طلب دفع مرتبط بهذه المشتريات. يتيح هذا الربط معرفة سبب كل مبلغ وارد لاحقًا. يجب ألّا تسجّل إعادة تحميل الشاشة قهوة إضافية مبيعة. ينبغي أن يظل الطلب وسجل دفعه قابلين للتتبّع. [1] [2]

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

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

قد تستقبل نقطة البيع في محفظة التاجر الخاصة أو تستخدم خدمة تحتفظ بأمواله. الحاسم هو المفاتيح الخاصة التي تتيح الإنفاق والصلاحيات وشروط السحب، لا شعار Bitcoin. قد تكفي بيانات المحفظة العامة لتوليد عناوين الاستلام. مع ذلك، تستطيع نقطة بيع مخترقة عرض عنوان المهاجم للدفعات المقبلة. لذلك لا يحتاج الموظف إلى جميع حقوق المدير: بيع القهوة يختلف عن تغيير المستلم أو الموافقة على ردّ المال. [5] [6] [7]

ترسل Lightning المدفوعات عبر قنوات متصلة. يجب أن تكون عقدتك، أي البرنامج المشارك في الشبكة، متاحة وأن تمتلك سيولة واردة: مساحة في القنوات لاستقبال الأموال. يمكن لخدمة أن تتولى بعض العمل، لكنها تغيّر التكلفة والجهة التي تثق بها. غياب المسار أو السيولة ليس دفعًا ناجحًا. قبل أن يجرّب الزبون وسيلة أخرى، يتحقق الموظف من نتيجة المحاولة الأولى كي لا يدفع ثمن القهوة مرتين. [7] [4]

قد يفقد الجهاز اللوحي الإنترنت أو يتوقف الخادم أو يتعذر تحميل سعر الصرف. عندها قد يستحيل إنشاء طلب أو التحقق من الاستلام. يبقى رمز QR المطبوع قابلًا للقراءة، لكن ذلك لا يثبت عمل النظام. يلزم إجراء متفق عليه: اتصال بديل، تأجيل البيع أو البحث عن الدفعة لاحقًا. الانقطاع وحده لا يثبت أن الزبون لم يدفع. تُراجع الدفعات الناقصة والزائدة والواردة بعد انتهاء الطلب كلٌّ على حدة؛ تعديل السجل يدويًا لا يعيد كتابة تاريخ الشبكة. [2] [3]

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

في نهاية الوردية، تُطابق الطلبات والمقبوضات والرسوم والمبالغ المعادة وأي دفعات من المزوّد. يصدّر BTCPay Server المدفوعات والمنتجات المبيعة وحركات محفظة on-chain، أي التي تتعامل مباشرة مع سلسلة Bitcoin. تساعد التقارير في السجلات لكنها لا تفي وحدها بجميع المتطلبات المحاسبية والضريبية المحلية. قبل التشغيل الفعلي، تدرّبوا على بيع عادي وانقطاع واستعادة الخدمة. قيّدوا الوصول إلى بيانات الزبائن بحسب الحاجة، واحسبوا تكاليف الأجهزة والاتصال والصيانة. [9] [1] [6]