Saltar al contenido principal

Header

Resumen de pagos y pasarelas admitidas de BDX

BDX.market es el principal mercado de depósito de juegos y bienes digitales de Bangladés. Para proteger tanto a compradores como a vendedores contra el fraude, las estafas de recuperación de cuentas y la no entrega, BDX opera una estricta arquitectura de depósito de protección al comprador.

Bajo esta arquitectura, cuando un comprador paga por una oferta o recarga, los fondos no se envían directamente a la cuenta personal del vendedor. En cambio, BDX retiene los pagos de forma segura en depósito hasta que el pedido se entrega correctamente y el comprador lo verifica o hasta que pasa la ventana estándar de protección al comprador de 7 días.

Este documento detalla el ecosistema de pagos que impulsa BDX.market, incluida la configuración del sistema, los controladores de pago activos, las tarifas, los modelos de seguridad y las especificaciones técnicas de los proveedores.

Pasarelas de pago admitidas y adaptadores​

BDX.market implementa una arquitectura de pasarela conectable definida en App\Support\Payments\PaymentGatewayManager. El sistema selecciona e inicializa dinámicamente los proveedores de pago según la configuración del entorno (.env) y las banderas administrativas globales gestionadas vía 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. Pasarela manual (manual)​

  • Clase: App\Support\Payments\ManualPaymentGateway
  • Canales admitidos: bKash, Nagad, Rocket o transferencias bancarias directas.
  • Mecanismo: Los compradores envían el pago manualmente a los números comerciales o personales de bKash/Nagad administrativos proporcionados durante el pago, y luego suben el comprobante de pago (ID de transacción y/o captura de pantalla). Los administradores revisan el envío vía el panel de administración Filament (App\Filament\Resources\MarketplacePaymentResource) y aprueban o rechazan el comprobante.
  • Caso de uso: Modo sin tarifa de procesamiento de pasarela; estado predeterminado del sistema.

2. Pasarela PipraPay (piprapay)​

  • Clase: App\Support\Payments\PipraPayGateway

  • Canales admitidos: bKash, Nagad, Rocket, Upay, Visa y MasterCard automatizados.

  • Mecanismo: Una integración automatizada de pasarela de pago bangladesí autoalojada. Inicia cargos vía una API RESTful (POST /api/create-charge) y devuelve una URL de página de pago alojada (pp_url). Tras completar el pago, PipraPay emite un webhook de servidor a servidor con una cabecera de clave API (mh-piprapay-api-key). BDX verifica dos veces cada transacción en el servidor vía POST /api/verify-payments usando la referencia de transacción (pp_id) antes de liberar el depósito.

  • Requisitos de configuración:

    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 — Pasarela del sistema de pago fácil (eps)​

  • Clase: App\Support\Payments\EpsPaymentGateway

  • Canales admitidos: Agregador con licencia del Banco de Bangladés que cubre las principales tarjetas bancarias bangladesíes, bKash, Nagad, Rocket, CellFin y tap.

  • Mecanismo: Flujo totalmente automatizado de redirección alojada.

    1. Se autentica con los servidores de EPS (POST /v1/Auth/GetToken) usando una firma x-hash HMAC-SHA512 para recibir un token portador de API.
    2. Inicializa la transacción (POST /v1/EPSEngine/InitializeEPS) con credenciales y parámetros de tienda, obteniendo una RedirectURL de EPS.
    3. Recibe IPN cifradas AES-256-CBC en https://bdx.market/eps/ipn.
    4. Siempre ejecuta una llamada autoritativa de verificación de servidor a servidor (GET /v1/EPSEngine/CheckMerchantTransactionStatus) usando MerchantTransactionId antes de actualizar el estado del pedido.

  • Requisitos de configuración:

    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. Saldo de BDX (bdx_balance)​

  • Clase de soporte: App\Support\BdxBuyerWallet
  • Mecanismo: Pago instantáneo fuera del libro mayor con crédito prefinanciado del comprador. El saldo de BDX no requiere pasos externos de pasarela al pagar. El stock se reserva atómicamente, el pedido se marca instantáneamente como paid y la entrega automática digital se activa de inmediato cuando corresponde.

Arquitectura de depósito y estructuras de tarifas​

BDX aplica límites seguros de transacción y cálculos transparentes de tarifas al pagar.

Desglose financiero de un pedido​

Cuando un comprador crea un pedido, el precio final se calcula en taka bangladesí (BDT / ৳) con tres componentes básicos:

Precio total = Precio del artículo * Cantidad + Tarifa de protección + Recargo de pasarela

  1. Subtotal del artículo: Precio unitario base fijado por el vendedor multiplicado por la cantidad seleccionada.
  2. Tarifa de protección al comprador: Calculada por categoría del mercado con MarketplaceCategory::resolvedBuyerFlatFee() y resolvedBuyerPctFee(). Por defecto, una tarifa fija de plataforma de ৳15 si no está configurada. Esta tarifa financia el procesamiento de disputas, la cobertura de protección al comprador de 7 días y la infraestructura de la plataforma.
  3. Recargo de pasarela (repercusión de MDR): Aplicado condicionalmente según el método de pago seleccionado. Para pagos manuales estándar y saldo de BDX, la tarifa es ৳0. Para pasarelas en línea con recargos de procesamiento (p. ej., MDR del 3 % de EPS), EpsPaymentGateway::feeFor() calcula y añade el recargo directamente a la instantánea del pedido (gateway_fee).

Modelo de comisión del vendedor​

BDX no cobra tarifas de publicación ni suscripciones mensuales a los vendedores. En cambio, BDX retiene una comisión por categoría (5 % por defecto) al completar correctamente un pedido.

Cuando se completa un pedido, el pago neto del vendedor se calcula como:

Ganancias del vendedor = (Subtotal del artículo) * (1 - % de comisión)

Los fondos pasan del depósito de BDX al clearing_balance del vendedor y posteriormente al available_balance tras la ventana obligatoria de liquidación.

Modelos de seguridad e integridad de webhooks​

Las integraciones automatizadas de pago deben defenderse contra falsificaciones, ataques de repetición de transacciones y manipulación de parámetros. BDX implementa protocolos estrictos de validación para todos los webhooks entrantes y puntos de retorno:

  1. Invariante de reverificación en el servidor: BDX nunca confía en IPN sin procesar ni en cadenas de consulta de redirección del navegador para marcar un pedido como pagado o acreditar una billetera. Independientemente del estado informado en el cuerpo de un webhook, BDX emite una llamada HTTP saliente aislada directamente a la API oficial de verificación del proveedor (verifyByReference() o CheckMerchantTransactionStatus) con credenciales secretas de comercio.
  2. Coincidencia estricta de importes: Los webhooks entrantes se comprueban contra Order::total_price. Si el importe pagado difiere aunque sea ৳0,01 del registro archivado, el sistema se detiene con un código HTTP 409 Conflict.
  3. Firmas criptográficas y descifrado:
    • PipraPay: Valida la presencia y coincidencia de la cabecera compartida mh-piprapay-api-key antes de analizar las cargas.
    • EPS: Descifra las cargas AES-256-CBC entrantes con el ipn_secret secreto del comercio. El paso de inicialización genera un MerchantTransactionId único de más de 10 dígitos que incorpora microsegundos de marca de tiempo y entropía aleatoria para evitar colisiones.
  4. Prevención de condiciones de carrera y doble gasto: Las transiciones de estado de pedidos usan transacciones de base de datos con restricciones lockForUpdate() para garantizar que devoluciones duplicadas o dobles clics rápidos no puedan procesar pagos dos veces.

Guías relacionadas​

Última actualización en