Pular para o conteúdo principal

Header

Visão geral de pagamentos e gateways aceitos na BDX

A BDX.market é o principal marketplace de jogos e produtos digitais com custódia de Bangladesh. Para proteger compradores e vendedores contra fraudes, golpes de recuperação de conta e não entrega, a BDX opera uma arquitetura rígida de custódia com proteção ao comprador.

Nessa arquitetura, quando um comprador paga por uma oferta ou recarga, os valores não são enviados diretamente para a conta pessoal do vendedor. Em vez disso, os pagamentos são capturados e retidos com segurança pela BDX.market em custódia até o pedido ser entregue com sucesso e verificado pelo comprador, ou até passar o prazo padrão de proteção ao comprador de 7 dias.

Este documento detalha o ecossistema de pagamentos que move a BDX.market, incluindo configuração do sistema, drivers de pagamento ativos, taxas, modelos de segurança e especificações técnicas dos provedores.

Gateways de pagamento e adaptadores aceitos​

A BDX.market implementa uma arquitetura conectável de gateways definida em App\Support\Payments\PaymentGatewayManager. O sistema seleciona e inicializa provedores de pagamento dinamicamente com base na configuração de ambiente (.env) e em sinalizadores administrativos globais gerenciados via 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. Gateway manual (manual)​

  • Classe: App\Support\Payments\ManualPaymentGateway
  • Canais aceitos: Transferências diretas de bKash, Nagad, Rocket ou banco.
  • Mecanismo: Compradores enviam o pagamento manualmente para números administrativos de bKash/Nagad (comerciante/pessoal) informados durante a finalização e depois enviam o comprovante de pagamento (ID da transação e/ou captura de tela). Administradores revisam o envio pelo painel administrativo Filament (App\Filament\Resources\MarketplacePaymentResource) e aprovam ou rejeitam o comprovante.
  • Caso de uso: Modo sem taxa de processamento de gateway; estado padrão do sistema.

2. Gateway PipraPay (piprapay)​

  • Classe: App\Support\Payments\PipraPayGateway

  • Canais aceitos: bKash, Nagad, Rocket, Upay, Visa, MasterCard automatizados.

  • Mecanismo: Integração automatizada de gateway de pagamento de Bangladesh auto-hospedado. Inicia cobranças via API RESTful (POST /api/create-charge) e retorna uma URL de página de pagamento hospedada (pp_url). Após o comprador concluir o pagamento, o PipraPay emite um webhook servidor a servidor com cabeçalho de chave de API (mh-piprapay-api-key). A BDX verifica novamente cada transação no servidor via POST /api/verify-payments usando a referência da transação (pp_id) antes de liberar a custódia.

  • Requisitos de configuração:

    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 — Sistema de pagamento fácil (eps)​

  • Classe: App\Support\Payments\EpsPaymentGateway

  • Canais aceitos: Agregador licenciado pelo Banco de Bangladesh cobrindo os principais cartões bancários de Bangladesh, bKash, Nagad, Rocket, CellFin e tap.

  • Mecanismo: Fluxo totalmente automatizado com redirecionamento hospedado.

    1. Autentica-se nos servidores EPS (POST /v1/Auth/GetToken) usando uma assinatura HMAC-SHA512 x-hash para receber um token de API.
    2. Inicializa a transação (POST /v1/EPSEngine/InitializeEPS) com credenciais e parâmetros da loja, obtendo um RedirectURL do EPS.
    3. Recebe IPNs criptografadas AES-256-CBC em https://bdx.market/eps/ipn.
    4. Executa sempre uma chamada autoritativa de verificação servidor a servidor (GET /v1/EPSEngine/CheckMerchantTransactionStatus) usando o MerchantTransactionId antes de atualizar o status do pedido.

  • Requisitos de configuração:

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

  • Classe de suporte: App\Support\BdxBuyerWallet
  • Mecanismo: Pagamento instantâneo fora do razão usando crédito pré-financiado do comprador na loja. O saldo BDX não exige nenhuma etapa de gateway externo na finalização. O estoque é reservado atomicamente, o pedido é marcado como paid na hora e a entrega automática digital é acionada imediatamente quando aplicável.

Arquitetura de custódia e estruturas de taxas​

A BDX aplica limites seguros de transação e cálculos transparentes de taxas na finalização.

Detalhamento financeiro de um pedido​

Quando um comprador cria um pedido, o preço final é calculado em Taka de Bangladesh (BDT / ৳) usando três componentes centrais:

Preço total = Preço do item * Quantidade + Taxa de proteção + Sobretaxa do gateway

  1. Subtotal de itens: Preço unitário base definido pelo vendedor multiplicado pela quantidade escolhida.
  2. Taxa de proteção ao comprador: Calculada por categoria do marketplace usando MarketplaceCategory::resolvedBuyerFlatFee() e resolvedBuyerPctFee(). O padrão é uma taxa fixa de ৳15 da plataforma se não configurada. Essa taxa financia o processamento de disputas, a cobertura de proteção ao comprador de 7 dias e a infraestrutura da plataforma.
  3. Sobretaxa do gateway (repasse de MDR): Aplicada condicionalmente conforme o método de pagamento escolhido. Para pagamentos manuais padrão e saldo BDX, a taxa é ৳0. Para gateways online com sobretaxas de processamento (por ex., MDR de 3% do EPS), EpsPaymentGateway::feeFor() calcula e anexa a sobretaxa diretamente ao snapshot do pedido (gateway_fee).

Modelo de comissão do vendedor​

A BDX não cobra taxas de anúncio nem mensalidades dos vendedores. Em vez disso, a BDX retém uma comissão por categoria (padrão de 5%) após a conclusão do pedido.

Quando um pedido é concluído, o pagamento líquido do vendedor é calculado como:

Ganhos do vendedor = (Subtotal de itens) * (1 - % de comissão)

Os valores passam da custódia da BDX para o clearing_balance do vendedor e depois para o available_balance após o prazo obrigatório de liberação.

Modelos de segurança e integridade de webhooks​

Integrações automatizadas de pagamento devem se defender contra falsificação, ataques de replay de transação e adulteração de parâmetros. A BDX implementa protocolos rígidos de validação para todos os webhooks recebidos e endpoints de retorno:

  1. Invariante de reverificação no servidor: A BDX nunca confia em IPNs brutas nem em query strings de redirecionamento do navegador para marcar um pedido como pago ou creditar uma carteira. Independentemente do status relatado no corpo do webhook, a BDX emite uma chamada HTTP isolada de saída diretamente para a API oficial de verificação do provedor (verifyByReference() ou CheckMerchantTransactionStatus) usando credenciais secretas de comerciante.
  2. Correspondência rígida de valores: Webhooks recebidos são conferidos contra Order::total_price. Se o valor pago diferir em até ৳0,01 do registro arquivado, o sistema interrompe com um código de status HTTP 409 Conflict.
  3. Assinaturas criptográficas e descriptografia:
    • PipraPay: Valida a presença e a correspondência do cabeçalho compartilhado mh-piprapay-api-key antes de analisar os payloads.
    • EPS: Descriptografa payloads AES-256-CBC recebidos usando o ipn_secret secreto do comerciante. A etapa de inicialização gera um MerchantTransactionId único de 10+ dígitos incorporando microssegundos de timestamp e entropia aleatória para evitar ataques de colisão.
  4. Prevenção de condição de corrida e gasto duplo: Transições de estado de pedido usam transações de banco de dados com restrições lockForUpdate() para garantir que callbacks duplicados ou cliques duplos rápidos não processem pagamentos duas vezes.

Guias relacionados​

Última atualização em