Confirmo

الطرف المتعاقد في أوروبا هو Confirmo Limited الأيرلندية. يسجل ESMA إخطارا بتاريخ 16.12.2025 لخدمات مبادلة الأصول المشفرة مقابل الأموال، والمبادلة بينها، والتحويلات. تصف الشروط المحدثة في 02.10.2026 الاستخدام التجاري والمهني والمؤسسي، لا حسابا شخصيا للتسوق. يحتاج التسجيل إلى موافقة وفحوص AML، أي إجراءات مكافحة غسل الأموال. ويذكر المزود أيضا أنه غير مرخص لحفظ الأصول المشفرة. لذلك لا ينبغي فهم رصيد معالجة المدفوعات على أنه خدمة تخزين طويل الأجل. هذه الشروط الأوروبية لا تنطبق تلقائيا على شركات أخرى تحمل العلامة نفسها. [1] [2]

تخيل متجرا يسعر باليورو وعميلا يدفع BTC. قد تختلف عملة السعر والبيتكوين المرسل والأصل المقيد للتاجر. تنشئ API، وهي الواجهة التي يتواصل عبرها المتجر مع البوابة، فاتورة ورابطا إلى صفحة الدفع. يحدد currencyFrom أساس التسعير، ويختار العميل أصلا وشبكة مدعومين. أما settlement.currency فيحدد ما يتلقاه التاجر. وتعني null هنا الاحتفاظ بالأصل الذي دفعه العميل. القيد في حساب Confirmo ليس بعد تحويلا إلى محفظة يتحكم التاجر بنفسه في مفاتيحها. [4]

تعرض صفحة الدفع المبلغ والعنوان والشبكة ومدة صلاحية العرض. تحدد Commercial Policy افتراضيا 15 دقيقة للتسوية بالنقود التقليدية و30 دقيقة بالأصول المشفرة؛ ويعيد التمديد حساب سعر الصرف. يجب بث المعاملة إلى العنوان والشبكة الصحيحين خلال المدة السارية. ويمكن أن تتبعها تأكيدات الشبكة المطلوبة لاحقا؛ في Bitcoin ترتبط هذه التأكيدات بإدراج المعاملة في الكتل. لذلك ليست confirming هي paid بعد. وتنتظر pending_verification بيانات المشاركين في التحويل التي تتطلبها Travel Rule. كما أن عودة العميل عبر returnUrl لا تثبت سداد الطلب. [3] [5]

Webhook رسالة آلية ترسلها البوابة إلى المتجر عند تغير الدفع. ولمنع تسليم بضاعة بناء على رسالة مزورة، يجب التحقق من مصدرها ثم جلب الحالة النهائية عبر GET invoice API. تحسب الطريقة الموثقة bp-signature كبصمة SHA256 لجسم الرسالة الأصلي كاملا، متبوعا بـ callback password، وهو سر مشترك للتحقق. لا يكفي إعادة بناء JSON بصياغة مختلفة. يتكرر الإرسال حتى استجابة 200، بحد أقصى 20 محاولة. لذا على المتجر تمييز إشعارات الفاتورة نفسها كي لا ينفذ الطلب مجددا. [6]

قد يخطئ العميل في المبلغ أو يدفع بعد انتهاء العرض. عند الدفع الزائد قد تبقى الفاتورة paid، بينما تشير unhandledExceptions إلى فائض لم يعالج. المطلوب عندئذ معالجة رد الزيادة، لا رد كامل قيمة الطلب تلقائيا. ويمكن ضبط سماحية النقص، فهي ليست موحدة لكل المتاجر. قبول الدفعة المتأخرة يستخدم سعر الصرف الحالي. تمنح الشروط الأوروبية 30 يوما من إنشاء الفاتورة لمعالجة الاستثناء؛ وبعدها لا تقرر التزاما برد الأموال وتنص على رسم. وقد تستهلك التكاليف المبالغ الصغيرة. ظهور الطلب الأساسي كمدفوع ليس سببا لتجاهل المشكلة الباقية. [2] [7]

رصيد البوابة مخصص للمعالجة المستمرة للمدفوعات. تنص الشروط الأوروبية على تحويل الأصول المشفرة كل يوم عمل إلى محفظة التاجر الخاصة والمتحقق منها. وإذا احتفظت الشركة بها يومي عمل، تحولها تلقائيا إلى نقود تقليدية بنهاية اليوم الثاني؛ وقد تمنع ذلك تسوية أو تعليمة دفع في الوقت المناسب. قد يوقف التحويل عنوان غير متحقق منه، أو مبلغ غير كاف بعد الرسوم، أو فحوص AML. تشير عبارة self-custody wallets إلى محافظ يتحكم فيها المزود. ولا تعني أن التاجر يملك مفاتيحها الخاصة التي تسمح بإنفاق الأموال. [2] [3]

يستطيع التاجر أيضا استخدام الرصيد للدفع إلى مستفيد آخر. وإذا أراد إرسال أصل مختلف، تتضمن العملية مبادلة. قبل التأكيد قارن المبلغ المخصوم والمبلغ المرسل وسعر الصرف والرسوم؛ فالعرض المنتهي يحتاج إلى تسعير جديد. يتضمن السعر spread، أي تعديلا مقارنة بالسعر السوقي المرجعي. وفي الفاتورة الواردة، ميز أيضا رسم محفظة العميل عن رسم شبكة Confirmo ورسم المعالجة المخصوم من التاجر. قبول التعليمة لا يثبت وصول الأموال. وقد يتعذر تصحيح عنوان أو شبكة خاطئين. [3]

إلغاء الشراء لا يمحو الدفعة الأصلية من سلسلة الكتل. بموجب الشروط الأوروبية، رد الأموال معاملة مشفرة جديدة، تسبقها عند الحاجة مبادلة رصيد بالنقود التقليدية. يستخدم سعر التنفيذ وتترتب تكاليف جديدة، بينما لا يعاد رسم المعالجة الأصلي. لذلك لا يضمن مجرد استخدام البوابة للعميل القيمة السوقية الأصلية. وقد يرفض المزود الرد إذا بلغت التكاليف المبلغ المراد إعادته أو منعه القانون. على التاجر شرح قواعده قبل أن يدفع العميل. [2]