Pagamentos e antifraude

A plataforma que decide se um pedido pago pode ser faturado. Atende as seis marcas do grupo através de e-commerce, aplicativo, mais de duzentas lojas físicas, televendas, atacado e produtos financeiros. É onde trabalhei mais tempo e onde estão as decisões de arquitetura mais consequentes que eu tomei.

O problema

Um pedido pago não é um pedido liberado. Entre uma coisa e outra existe uma sequência de verificações: confirmação do adquirente, análise antifraude, motor de decisão e, às vezes, análise humana. Quais dessas etapas se aplicam depende da combinação de empresa, negócio, tipo de operação, canal, país e filial, e ainda do meio de pagamento usado no pedido.

O espaço de combinações é grande e cresce, porque cada negócio novo do grupo é uma combinação nova. Escrever isso como condicional produz uma árvore que ninguém altera sem medo, e transforma toda mudança de política comercial em fila de desenvolvimento: a área comercial abre um canal e espera a próxima janela de deploy.

O que eu construí

• Orquestração multi-adquirente. Um núcleo decide o caminho e cada meio de pagamento é um serviço satélite que só sabe executar a sua parte: cartão, Pix, boleto, voucher, link e carteira digital
• Política de verificação em configuração. A sequência de etapas de cada canal é um conjunto de indicadores em dado, com abertura de canal novo sem publicar versão
• Máquina de estado da transação, com a transição escrita como cadeia ordenada e explícita: a primeira condição verdadeira vence, e cada estado tem tempo esperado de permanência
• Ciclo de vida por pagamento coexistindo com o da transação — pré-autorização, captura, efetivação, estorno, expiração — com regra explícita de quando um destrava o outro
• Dossiê histórico de risco: contagem por janela de tempo, reincidência, comparação difusa de endereço e cruzamento com lista de bloqueio
• Devolução e estorno pós-venda com rateio proporcional entre os pagamentos elegíveis, resíduo de arredondamento no último e idempotência por identificador de origem
• Painel de pedido com erro, juntando falha de integração com transação parada além do tempo esperado
• Idempotência em toda entrada externa, porque adquirente reenvia, callback chega fora de ordem e robô reprocessa fila

Decisões que eu defendo

Regra em dado. Mudar a política antifraude de um negócio inteiro passou a não exigir publicação de versão. O custo é real: a configuração virou estado crítico do sistema e precisa de cuidado próprio. Aceitei porque erro de configuração é reversível em minutos, e deploy errado não é. O raciocínio inteiro está em ADR 1 — Política de risco em dado, não em código.

Ordem explícita como precedência. Numa cadeia de regras, deixar a ordem das linhas ser a precedência faz com que ler o código de cima para baixo seja ler a política. Quem chega novo entende qual regra ganha de qual sem precisar simular.

Um caso especial que resume o domínio. Quando a pré-análise reprova mas todos os pagamentos do pedido são boleto ou Pix, a transação segue liberada com marcação de não faturar, em vez de ir para estorno. Não há o que estornar numa cobrança que ainda não foi paga. É o tipo de regra que não aparece em diagrama nenhum e decide se o sistema funciona.

Resultado

Plataforma única de decisão para todos os canais do grupo, com abertura de canal novo por configuração. Segue ativa e em evolução.

Limite

A superfície de configuração cresceu mais do que eu previ. Hoje não existe um lugar único que responda “o que esta combinação faz” — a resposta é reconstruída lendo dado espalhado, e o custo apareceu no suporte. Um simulador de pedido hipotético teria resolvido isso e teria sido barato construir junto.

Integrações

Adquirentes e meios de pagamento (Cielo, Braspag, Pix, boleto, voucher, carteira digital) · antifraude (ClearSale) · birôs de crédito · ERP (SAP) · plataforma de atendimento (Zendesk) · geolocalização de IP · notificação corporativa

Stack

.NET · Oracle · Entity Framework Core · Dapper · arquitetura de serviços

Ver também

ADR 1 — Política de risco em dado, não em código · Modelagem de domínio, DDD e CQRS · Integrações e sistemas distribuídos · Logística reversa e devoluções