إنتقل إلى المحتوى الرئيسي

Header

نظرة عامة على مدفوعات BDX والبوابات المدعومة

BDX.market هو سوق الضمان الرائد في بنغلاديش للألعاب والسلع الرقمية. لحماية المشترين والبائعين معًا من الاحتيال وحيل استعادة الحسابات وعدم التسليم، يشغّل BDX بنية ضمان صارمة لحماية المشتري.

بموجب هذه البنية، عندما يدفع المشتري مقابل عرض أو شحن، لا تُرسَل الأموال مباشرة إلى الحساب الشخصي للبائع. بدلًا من ذلك، تُلتقَط المدفوعات بأمان وتُحفَظ لدى BDX.market في الضمان حتى يُسلَّم الطلب بنجاح ويتحقق منه المشتري أو حتى مرور فترة حماية المشتري القياسية 7 أيام.

توثق هذه الصفحة نظام الدفع الذي يشغّل BDX.market، بما في ذلك تكوين النظام وموفري الدفع النشطين والرسوم ونماذج الأمان والمواصفات التقنية للموفرين.


بوابات الدفع وتكييفات المدعومة​

ينفذ BDX.market بنية بوابات قابلة للتركيب معرّفة تحت App\Support\Payments\PaymentGatewayManager. يختار النظام موفري الدفع ويهيئهم ديناميكيًا بناءً على تكوين البيئة (.env) والأعلام الإدارية على مستوى الموقع المُدارة عبر App\Support\BdxSettings.

+----------------------------------+
| PaymentGatewayManager |
| App\Support\Payments |
+-----------------+----------------+
|
+--------------------+------------+------------+--------------------+
| | | |
+-----v-------+ +-------v------+ +-------v------+ +-------v------+
| Manual | | PipraPay | | EPS | | WooCommerce |
| Gateway | | Gateway | | Gateway | | Bridge (WC) |
+-------------+ +--------------+ +--------------+ +--------------+
(bKash/Nagad/ (Self-hosted (BB-Licensed (Legacy WP/WC
Rocket Proofs) bKash/Nagad/ Aggregator Integration)
Cards API) Cards/MFS)

1. البوابة اليدوية (manual)​

  • الفئة: App\Support\Payments\ManualPaymentGateway
  • القنوات المدعومة: تحويلات bKash وNagad وRocket أو Bank المباشرة.
  • الآلية: يقدم المشترون الدفعة يدويًا إلى أرقام bKash/Nagad التجارية/الشخصية الإدارية المقدمة أثناء الدفع، ثم يرفعون إثبات الدفع (معرّف المعاملة و/أو لقطة شاشة). يراجع المشرفون التقديم عبر لوحة إدارة Filament (App\Filament\Resources\MarketplacePaymentResource) ويقبلون الإثبات أو يرفضونه.
  • حالة الاستخدام: وضع صفر رسوم معالجة بوابة؛ حالة النظام الافتراضية الجاهزة.

2. بوابة PipraPay (piprapay)​

  • الفئة: App\Support\Payments\PipraPayGateway

  • القنوات المدعومة: bKash وNagad وRocket وUpay وVisa وMasterCard آليًا.

  • الآلية: تكامل بوابة دفع بنغلاديشية آلية مستضافة ذاتيًا. تبدأ الرسوم عبر RESTful API (POST /api/create-charge) وتُرجِع رابط صفحة دفع مستضافة (pp_url). بعد إتمام المشتري الدفع، تُصدِر PipraPay webhook من خادم إلى خادم يحتوي ترويسة مفتاح API (mh-piprapay-api-key). يتحقق BDX مرتين من كل معاملة على الخادم عبر POST /api/verify-payments باستخدام مرجع المعاملة (pp_id) قبل تحرير الضمان.

  • متطلبات التكوين:

    BDX_PIPRAPAY_ENABLED=true
    BDX_PIPRAPAY_BASE_URL=https://your-piprapay-instance.com
    BDX_PIPRAPAY_API_KEY=your_secret_api_key
    BDX_PIPRAPAY_CURRENCY=BDT

3. بوابة EPS — نظام الدفع السهل (eps)​

  • الفئة: App\Support\Payments\EpsPaymentGateway

  • القنوات المدعومة: مجمّع مرخص من بنك بنغلاديش يغطي بطاقات البنوك البنغلاديشية الكبرى وbKash وNagad وRocket وCellFin وtap.

  • الآلية: مسار إعادة توجيه مستضاف آلي بالكامل.

    1. المصادقة مع خوادم EPS (POST /v1/Auth/GetToken) باستخدام توقيع HMAC-SHA512 x-hash لتلقي رمز API bearer.
    2. تهيئة المعاملة (POST /v1/EPSEngine/InitializeEPS) ببيانات اعتماد المتجر والمعلمات، للحصول على RedirectURL من EPS.
    3. استلام IPNs مشفرة AES-256-CBC على https://bdx.market/eps/ipn.
    4. تنفيذ استدعاء تحقق موثوق من خادم إلى خادم دائمًا (GET /v1/EPSEngine/CheckMerchantTransactionStatus) باستخدام MerchantTransactionId قبل تحديث حالة الطلب.
  • متطلبات التكوين:

    BDX_EPS_ENABLED=true
    BDX_EPS_MODE=live # or sandbox
    BDX_EPS_FEE_RATE=3 # 3% gateway surcharge passed to buyer
    BDX_EPS_TRANSACTION_TYPE=1
    BDX_EPS_CURRENCY=BDT
    BDX_EPS_LIVE_BASE_URL=https://pgapi.eps.com.bd
    BDX_EPS_MERCHANT_ID=your_merchant_id
    BDX_EPS_STORE_ID=your_store_id
    BDX_EPS_USERNAME=your_username
    BDX_EPS_PASSWORD=your_password
    BDX_EPS_HASH_KEY=your_sha512_hash_key
    BDX_EPS_IPN_SECRET=your_aes_ipn_secret

4. رصيد BDX (bdx_balance)​

  • فئة الدعم: App\Support\BdxBuyerWallet
  • الآلية: دفع فوري خارج الدفتر باستخدام رصيد متجر المشتري المموّل مسبقًا. رصيد BDX لا يتطلب خطوات بوابة خارجية عند الدفع. يُحجَز المخزون ذريًا، ويُعلَّم الطلب paid فورًا، ويُطلَق التسليم التلقائي الرقمي فورًا حيثما ينطبق.

بنية الضمان وهياكل الرسوم​

يفرض BDX حدود معاملات آمنة وحسابات رسوم شفافة عند الدفع.

التفصيل المالي للطلب​

عندما ينشئ المشتري طلبًا، يُحسَب السعر النهائي بالتاكا البنغلاديشية (BDT / ৳) باستخدام ثلاثة مكونات أساسية:

السعر الإجمالي = سعر المنتج × الكمية + رسوم الحماية + رسوم البوابة الإضافية

  1. المجموع الفرعي للمنتج: سعر الوحدة الأساسي الذي حدده البائع مضروبًا بالكمية المختارة.
  2. رسوم حماية المشتري: تُحسَب لكل فئة سوق باستخدام MarketplaceCategory::resolvedBuyerFlatFee() وresolvedBuyerPctFee(). الافتراضي رسوم منصة ثابتة ৳15 إذا لم تُهيَّأ. تمول هذه الرسوم معالجة النزاعات وتغطية حماية المشتري 7 أيام وبنية المنصة.
  3. رسوم البوابة الإضافية (تمرير MDR): تُطبَّق شرطيًا حسب طريقة الدفع المختارة. للمدفوعات اليدوية القياسية ورصيد BDX، الرسم ৳0. للبوابات عبر الإنترنت ذات الرسوم الإضافية للمعالجة (مثل EPS بضريبة 3% MDR)، تحسب EpsPaymentGateway::feeFor() الرسوم الإضافية وتُلحِقها مباشرة بلقطة الطلب (gateway_fee).

نموذج عمولة البائع​

لا يفرض BDX رسوم عرض أو رسوم اشتراك شهرية على البائعين. بدلًا من ذلك، يحتفظ BDX بعمولة حسب الفئة (الافتراضي 5%) عند الإتمام الناجح للطلب.

عند إتمام الطلب، يُحسَب صافي مبلغ البائع على النحو التالي:

أرباح البائع = (المجموع الفرعي للمنتج) × (1 - نسبة العمولة %)

تنتقل الأموال من ضمان BDX إلى clearing_balance للبائع ثم تنتقل لاحقًا إلى available_balance بعد فترة التسوية الإلزامية.


نماذج الأمان وسلامة Webhook​

يجب أن تدافع تكاملات الدفع الآلية ضد التزوير وهجمات إعادة المعاملات والعبث بالمعلمات. ينفذ BDX بروتوكولات تحقق صارمة لجميع webhooks الواردة ونقاط الإرجاع:

  1. ثبات إعادة التحقق على الخادم: لا يثق BDX أبدًا بـ IPNs الخام أو سلاسل استعلام إعادة توجيه المتصفح لتعليم طلب كمدفوع أو قيد محفظة. بغض النظر عن الحالة المبلغة في جسم webhook، يُصدِر BDX استدعاء HTTP صادرًا معزولًا مباشرة إلى API التحقق الرسمي للموفر (verifyByReference() أو CheckMerchantTransactionStatus) باستخدام بيانات اعتماد التاجر السرية.
  2. مطابقة المبلغ الصارمة: تُفحَص webhooks الواردة مقابل Order::total_price. إذا اختلف المبلغ المدفوع حتى ৳0.01 عن السجل المحفوظ، يتوقف النظام برمز حالة HTTP 409 Conflict.
  3. التوقيعات المشفرة وفك التشفير:
    • PipraPay: يتحقق من وجود ومطابقة ترويسة mh-piprapay-api-key المشتركة قبل تحليل الحمولات.
    • EPS: يفك تشفير حمولات AES-256-CBC الواردة باستخدام ipn_secret السري للتاجر. خطوة التهيئة تولّد MerchantTransactionId فريدًا من 10+ أرقام يدمج الميكروثواني للطابع الزمني وعشوائية لمنع هجمات التصادم.
  4. منع حالات التسابق والإنفاق المزدوج: انتقالات حالة الطلب تستخدم معاملات قاعدة بيانات مع قيود lockForUpdate() لضمان عدم معالجة الردود المكررة أو النقرات المزدوجة السريعة للمدفوعات مرتين.

أدلة ذات صلة​