Quem utiliza
A plataforma atende três tipos de consumidor:Usuários do painel
Operadores autenticados em
painel.dlpay.cloud — administradores, suporte, distribuidores, agentes. Autenticam-se com JWT.Backends de lojistas
Integrações servidor-a-servidor que agem em nome de um único lojista. Autenticam-se com chave de API do lojista.
Compradores públicos
Consumidores finais que pagam por meio de uma página de checkout (eventos, assinaturas). Um pequeno conjunto de endpoints é intencionalmente público.
Que problemas resolve
Uma API única sobre múltiplos adquirentes
Uma API única sobre múltiplos adquirentes
Cada parceiro de processamento tem formatos próprios, esquemas de autenticação distintos e ciclos de vida diferentes. A plataforma expõe um conjunto único de recursos unificados (contas, transações, recebíveis, depósitos, documentos) e traduz tudo isso para cada parceiro nos bastidores.
Conciliação em tempo real via webhooks e filas de jobs
Conciliação em tempo real via webhooks e filas de jobs
Os parceiros de processamento enviam eventos; a plataforma enfileira jobs em segundo plano que buscam o dado autoritativo e atualizam tanto os registros específicos do adquirente quanto os modelos unificados. Não há sincronização manual.
Splits, comissões e hierarquia de canais
Splits, comissões e hierarquia de canais
Toda conta pode pertencer a um plano de split que distribui comissões para um agente, dois níveis de distribuição (N1, N2), um desenvolvedor e a própria plataforma. Os splits são aplicados automaticamente na captura.
Métricas pré-agregadas
Métricas pré-agregadas
Contagens e totais (vendas por data, recebíveis esperados por conta, vendas de ingressos por hora etc.) são mantidos em tabelas separadas, atualizadas atomicamente quando o status muda. Endpoints de listagem permanecem rápidos mesmo em larga escala.
Funcionalidades de domínio sobre pagamentos
Funcionalidades de domínio sobre pagamentos
Bilheteria de eventos, cobrança recorrente por assinatura, contas virtuais e webhooks de saída pertencentes ao lojista são recursos de primeira classe, e não produtos separados.
Módulos em um relance
A plataforma é organizada em módulos focados. Cada módulo contribui com URLs, modelos de dados e, quando aplicável, rotinas em segundo plano e ouvintes de webhook.| Módulo | Prefixo de URL | O que vive aqui |
|---|---|---|
user | /user/ | Login, refresh, recuperação de senha, usuários, grupos, tabela de acessos. |
seller | /seller/ | Registros específicos de lojistas (merchants) por adquirente e seu cadastro junto à infraestrutura de processamento. |
sales | /sales/ | Links de checkout, vendas online, transações, recebíveis, transferências, meios de pagamento, planos de pagamento. Hospeda o despachante de webhooks de adquirência. |
plans | /plans/ | Planos de pagamento (condições de parcelamento) e planos de split (modelos de comissão). |
unified | /unified/ | Contas, transações, recebíveis, depósitos, documentos, ponto de venda, links de convite, métricas e estatísticas unificadas. |
event | /event/ | Bilheteria de eventos — eventos, ingressos, cupons, checkout público, métricas em tempo real. |
subscriptions | /subscriptions/ | Cobrança recorrente — planos, assinantes, pagamentos, fluxo público de assinatura. |
uniconta | /uniconta/ | Contas virtuais e lançamentos usados para conciliação. |
seller_integrations | /integrations/ | Chaves de API e webhooks de saída para lojistas que constroem em cima da plataforma. |
webhooks | /webhook/ | Ponto de entrada para webhooks recebidos da infraestrutura de processamento. |
jobs | (sem URLs) | Fila de jobs em segundo plano. Os demais módulos registram tipos de job aqui. |
A forma de um dia típico
Um lojista é habilitado
Um usuário do painel (ou um link de convite) cria uma
Account unificada. A plataforma envia o cadastro à infraestrutura de processamento em segundo plano, anexa dados bancários e atribui um plano de split padrão.Um comprador paga
Um link de checkout, um checkout de evento ou uma cobrança de assinatura é criado. A plataforma solicita a criação da transação ao parceiro de processamento e armazena tanto o registro específico do adquirente quanto a
Transaction unificada.O parceiro de processamento dispara um webhook
Uma chamada
POST chega ao endpoint de webhooks. O evento é persistido, despachado para os ouvintes e dispara um job em segundo plano que busca o estado mais recente da transação.Recebíveis, splits e depósitos são atualizados
O job atualiza o registro específico do adquirente, propaga para a camada unificada, atualiza métricas pré-agregadas, aplica splits e emite webhooks de saída para cada lojista que esteja escutando.
Características técnicas
- API REST com respostas em JSON.
- Autenticação JWT (com refresh rotativo) para usuários do painel e chaves de API para integrações de lojista.
- Fila de jobs persistente, com bloqueio em nível de linha para execução paralela segura.
- Conexões seguras com os parceiros de processamento usando autenticação baseada em certificado.
- Armazenamento de mídia em nuvem.
- Telemetria de erros centralizada.
- Idioma e fuso horário:
pt-BR,America/Sao_Paulo. Todos os valores monetários são inteiros em centavos de BRL.
Para onde ir em seguida
Arquitetura
A arquitetura em camadas, o ciclo de vida das requisições e como o sistema de jobs e o sistema de webhooks se encaixam.
Modelo de dados unificado
O padrão da camada unificada. Por que ela existe e como os dados fluem até ela.
Autenticação
JWT, chaves de API de lojista, permissões e endpoints públicos.
Início rápido
Autentique-se, liste lojistas e faça sua primeira requisição.