Resposta rápida: Integrar uma API pagamento subadquirente envolve escolher a plataforma certa, conectar via plugin ou SDK, testar em sandbox e monitorar métricas como aprovação e chargeback. A migração traz controle sobre taxas, prazos de recebimento e serviços como antifraude e roteamento entre adquirentes — mas exige planejamento técnico, conformidade com a LGPD e operação em paralelo durante a transição.
Integrar uma API de pagamento de subadquirente é uma das decisões que mais impacta aprovação, custo por transação e autonomia operacional em um e-commerce. Neste material, explicamos como funciona a stack de pagamento com subadquirente, quando faz sentido migrar do adquirente tradicional, como escolher a API certa e o que considerar em plugins, SDKs e automações com inteligência artificial para sua operação crescer com segurança.
O que é uma API de pagamento de subadquirente e por que ela existe
Ela é a interface programática que conecta sua loja à camada intermediária entre o gateway de pagamento e o adquirente, permitindo autorizar, capturar e conciliar transações com controle sobre taxas e repasses. A API existe porque o modelo tradicional de integração direta com adquirente concentra pouco poder de negociação: a loja recebe uma tabela de preços fixa, prazos definidos e, geralmente, um único caminho de processamento. O subadquirente, ao atuar como camada de controle, abre espaço para roteamento entre adquirentes, antifraude embarcado e regras de repasse customizáveis — e é a API que expõe esses recursos para o seu sistema.
Diferença prática entre adquirente, gateway e subadquirente na stack de pagamentos
O adquirente é a instituição financeira autorizada a processar o cartão e liquidar o valor junto à bandeira; o gateway é a ponte tecnológica que transmite os dados da transação de forma segura; o subadquirente assume a gestão comercial do processamento, incluindo repasses, taxas e serviços agregados. Na prática, quando sua loja se conecta a uma API de subadquirente, o fluxo passa por essa camada intermediária antes de chegar ao adquirente efetivo — o que abre espaço para decisões automatizadas, como escolher o adquirente com maior taxa de aprovação para determinada bandeira. Essa distinção importa porque define quem controla a negociação de preço, quem responde por chargebacks e quem define as regras de antifraude.
O papel do subadquirente como camada de controle e repasse financeiro
O subadquirente opera como uma camada de governança financeira: ele recebe o valor processado, aplica as taxas negociadas e repassa o saldo ao lojista conforme o cronograma acordado. Essa estrutura permite que a loja trabalhe com políticas de recebimento mais flexíveis — antecipação de recebíveis, parcelamento embutido ou recebimento em D+1 para Pix, por exemplo. Além do controle financeiro, essa camada costuma agregar serviços de valor: análise de risco em tempo real, retentativa automática de transações recusadas e painéis de conciliação que eliminam parte do trabalho manual do time financeiro.
Quando a API do subadquirente passa a ser a escolha estratégica
A escolha se torna estratégica quando o volume de transações justifica renegociar taxas, quando a operação precisa de mais autonomia sobre o fluxo de recebimento ou quando recursos como roteamento inteligente entre adquirentes passam a ser diferenciais competitivos. Lojas em crescimento acelerado, marketplaces e operações com forte componente de recorrência costumam ser as primeiras a migrar, porque o custo de manter uma única via de processamento supera rapidamente o investimento de integração. Uma opção popular nessa área é o FastPay, Subadquirente para Ecommerce, que oferece exatamente esse modelo de camada intermediária com foco em lojas virtuais brasileiras.
Como funciona o fluxo de uma transação via API de subadquirente
O fluxo percorre quatro etapas principais — autorização, captura, liquidação e repasse — e cada uma delas é disparada ou confirmada por chamadas à API. Entender esse ciclo é essencial para implementar corretamente o tratamento de status no seu sistema e evitar divergências de conciliação. Abaixo, detalhamos cada etapa e como ela se conecta à sua infraestrutura de checkout.
Autorização, captura, liquidação e repasse: o ciclo completo
Na autorização, a API valida os dados do cartão, o limite disponível e o score de risco, devolvendo um código de aprovação ou recusa. A captura ocorre quando o lojista confirma o envio do produto e “captura” o valor reservado — em algumas operações, autorização e captura acontecem em chamada única (autorização e captura simultânea). A liquidação é o processo em que a bandeira confirma a transação e o adquirente libera o valor, e o repasse é o credito final na conta do lojista, respeitando o prazo negociado. Cada uma dessas etapas gera um webhook ou status consultável na API, e tratar corretamente cada transição é o que garante que o seu sistema saiba, em tempo real, se o pedido pode ser faturado.
Integração com checkout transparente, transparente redirecionado ou hospedado
O checkout transparente mantém o comprador no seu site, com os dados do cartão tokenizados antes de chegar ao servidor; o transparente redirecionado leva o usuário a uma página segura do subadquirente por alguns segundos e retorna ao site; o hospedado delega toda a experiência de pagamento à plataforma. A escolha entre os três equilibra controle de design, esforço de implementação e conformidade PCI: quanto mais controle você mantém, maior a responsabilidade sobre a segurança dos dados. Para operações que precisam de personalização profunda no funil de conversão, o checkout transparente costuma ser preferível; para quem busca velocidade de go-live, o hospedado resolve em dias.
Conciliação financeira e retorno de status para o seu sistema
A conciliação é o cruzamento entre as transações registradas no seu sistema e os valores efetivamente repassados pelo subadquirente. Uma boa API oferece relatórios exportáveis, webhooks confiáveis com reenvio automático em caso de falha e uma API de consulta de status para reconciliar divergências. Sem esse processo, é comum encontrar cenários em que o pedido está marcado como pago no e-commerce, mas a transação foi estornada — ou o inverso, gerando perdas silenciosas. Ferramentas com painéis de conciliação automatizada, como as disponíveis em plataformas de subadquirente modernas, reduzem drasticamente o tempo dedicado a esse cruzamento manual.
Escolhendo a API certa: critérios técnicos e comerciais
Escolher a API certa significa avaliar dois eixos simultaneamente: a qualidade técnica da plataforma e as condições comerciais que ela oferece. Muitas integrações falham porque a decisão foi tomada apenas por preço, sem considerar documentação, disponibilidade e flexibilidade de recursos. Para um aprofundamento prático nesse processo, veja também o guia Como Escolher o Melhor Subadquirente para sua Loja Virtual, que detalha os critérios de avaliação ponta a ponta.
Documentação, sandbox, uptime e suporte como fatores decisivos
Documentação completa e atualizada é o primeiro filtro: sem exemplos claros de payloads, códigos de erro documentados e guias de webhook, o tempo de integração dobra. O sandbox deve permitir simular cenários reais — cartões recusados, timeouts, chargebacks — e não apenas o caminho feliz. Uptime declarado e histórico público de disponibilidade são igualmente críticos: uma indisponibilidade de 30 minutos no pico de sexta-feira pode custar mais do que meses de economia em taxas. Por fim, o suporte precisa ser acessível em português, com canais definidos e SLA de resposta, porque problemas de pagamento não podem esperar dias por um retorno.
Taxas, prazos de recebimento e política de chargeback
Taxas variam conforme bandeira, modalidade (débito, crédito, parcelado) e volume negociado — é sempre prudente comparar a taxa efetiva por transação, não apenas a taxa nominal anunciada. Prazos de recebimento直接影响 o fluxo de caixa: operações com D+30 ou D+14 têm impacto direto na capacidade de reinvestimento. Quanto ao chargeback, entenda quem assume a responsabilidade pela contestação e se a plataforma oferece ferramentas de defesa automática, como envio de comprovantes e evidências de entrega. Esses três fatores juntos definem o custo real de aceitar cartões na sua operação.
Compatibilidade com Pix, cartão recorrente e antifraude
Um subadquirente moderno precisa suportar Pix com QR Code dinâmico e devolução, cartão recorrente com tokenização e retentativa automática de cobrança, e antifraude nativo ou integrável. A ausência de qualquer um desses recursos força workarounds que aumentam custo e complexidade. Para e-commerces com assinatura, por exemplo, o recuperação automática de cobranças recusadas (dunning) pode representar diferença relevante na receita mensal. Valide cada um desses requisitos em sandbox antes de assinar contrato — não depois da migração.
Plugin subadquirente para e-commerce: quando usar e como configurar
Para a maioria das lojas em estágio inicial, um plugin subadquirente para e-commerce resolve a integração em horas, sem necessidade de desenvolvimento dedicado. Plugins prontos para WooCommerce, Shopify e VTEX conectam o checkout nativo da plataforma à API do subadquirente, com configuração via painel administrativo. No entanto, plugins têm limites claros: personalizações avançadas de checkout, fluxos multi-vendedor ou regras específicas de conciliação costumam exigir customização. A decisão entre plugin e API direta deve considerar o estágio da operação, o time técnico disponível e os requisitos futuros do funil de conversão.
Vantagens e limites de plugins prontos para WooCommerce, Shopify e VTEX
A principal vantagem é velocidade: o plugin já resolve tokenização, tratamento de status e webhooks, reduzindo o risco de erro de implementação. Em plataformas como Shopify, onde o ecossistema de apps é maduro, plugins são atualizados automaticamente e recebem suporte do marketplace. O limite aparece quando a loja precisa de lógica condicional no checkout — por exemplo, exibir Pix apenas para pedidos acima de R$ 100 ou aplicar antifraude diferente por categoria de produto. Nesses casos, o plugin padrão raramente cobre o cenário sem extensões adicionais, que por sua vez aumentam a superfície de manutenção.
Cenários em que vale customizar em vez de usar plugin padrão
Customização vale a pena quando o checkout é um ativo estratégico da marca, quando há integrações internas (ERP, WMS, CRM) que precisam de eventos de pagamento específicos, ou quando a operação já atinge volume em que micro-otimizações de conversão justificam o investimento. Operações com funis de checkout altamente personalizados, como lojas de alto ticket ou marketplaces multi-vendedor, normalmente migram para integração via API ou SDK. Nesses casos, ter um parceiro técnico dedicado — ou uma plataforma com bom time de suporte de integração — torna-se um fator determinante.
Boas práticas de atualização, segurança e teste antes do go-live
Antes do go-live, teste em sandbox com ao menos 15 cenários: aprovação, recusa por limite, recusa por fraude, timeout, webhook duplicado, estorno parcial e devolução via Pix. Após o lançamento, mantenha o plugin sempre atualizado — versões antigas costumam conter vulnerabilidades conhecidas e podem deixar de funcionar após atualizações da plataforma. Monitore logs de erro semanalmente e defina alertas para falhas de webhook, porque uma interrupção silenciosa nesse canal gera divergência de conciliação que só aparece no fechamento do mês.
SDK de pagamento online: desenvolvendo checkout próprio com controle total
Um SDK pagamento online é a biblioteca de código que permite montar o checkout dentro da sua própria interface, sem depender de páginas hospedadas. Ele oferece controle total sobre a experiência do usuário e permite personalizar cada etapa do funil — do preenchimento do cartão à confirmação do pedido. Para times de desenvolvimento maduros, o SDK é a escolha natural quando a conversão precisa ser otimizada em nível de pixel.
O que um SDK precisa entregar: tokenização, 3DS, mobile e web
Um SDK robusto precisa entregar tokenização de dados do cartão (para que o número nunca toque seu servidor), suporte a 3D Secure 2.0, compatibilidade com web e mobile (React Native, Flutter, iOS nativo e Android nativo), tratamento de erros claro e documentação completa. Sem tokenização, sua operação fica exposta a requisitos PCI desnecessários; sem 3DS, você perde a chance de reduzir chargebacks via autenticação forte. Antes de adotar, valide a qualidade dos exemplos de código e a existência de um ambiente de testes completo — são indicadores diretos da maturidade da plataforma.
Arquitetura recomendada para reduzir falhas de integração
A arquitetura recomendada isola o SDK em um módulo de pagamento independente, com filas assíncronas para processamento de webhooks e retries automáticos para chamadas de captura. O front-end deve tratar timeouts com feedback claro ao usuário, evitando que o comprador clique em “pagar” duas vezes. No back-end, implemente idempotência em todas as chamadas financeiras: um mesmo identificador de transação nunca deve gerar duas cobranças. Essas práticas eliminam as três causas mais comuns de falha em integrações de pagamento — duplicidade, perda de status e tratamento incorreto de erros transitórios.
Como o SDK se conecta à camada antifraude e ao score de risco
O SDK coleta sinais do dispositivo (impressão digital do navegador, geolocalização aproximada, comportamento de digitação) e os envia junto com a transação para a camada antifraude. O subadquirente, por sua vez, combina esses sinais com seu modelo de score de risco para decidir aprovação, revisão manual ou recusa. Essa integração é o que permite decidir em milissegundos se uma transação de alto valor deve passar por análise adicional. Quanto mais sinais o SDK coleta de forma não-invasiva, maior a precisão do score e menor a taxa de falsos positivos que bloqueiam compradores legítimos.
Inteligência artificial aplicada à API de subadquirente
IA aplicada à camada de pagamento deixou de ser experimento e passou a ser fator competitivo: operações que usam modelos de machine learning para roteamento e antifraude tendem a alcançar taxas de aprovação significativamente superiores às que dependem de regras estáticas. A aplicação prática se dá em três frentes: aprovação, detecção de fraude e conciliação. Cada uma resolve um problema concreto e mensurável da operação financeira.
IA na aprovação: retentativa inteligente e roteamento entre adquirentes
Quando uma transação é recusada, modelos de IA analisam o motivo da recusa, a bandeira, o adquirente e o histórico daquele BIN para decidir se vale a pena reenviar — e para qual adquirente. Essa retentativa inteligente pode recuperar uma parcela relevante de vendas que, em um cenário sem IA, seriam perdidas. O roteamento entre adquirentes funciona de forma semelhante: em vez de enviar sempre ao mesmo processador, o sistema escolhe o caminho com maior probabilidade de aprovação para cada transação, com base em dados históricos atualizados continuamente.
Detecção de fraude em tempo real na própria camada de pagamento
Na camada de pagamento, modelos de detecção de fraude avaliam cada transação em tempo real usando centenas de variáveis — velocidade de compra, padrão de endereço, consistência do dispositivo e comportamento de compra do titular. A vantagem é a latência baixa: a decisão acontece na mesma chamada da autorização, sem impacto perceptível no checkout. Para a loja, isso significa bloquear tentativas de fraude antes que gerem chargeback, que é um dos indicadores com maior impacto direto na reputação junto às bandeiras.
Automação de conciliação e previsão de recebíveis com machine learning
Machine learning também se aplica à conciliação, identificando automaticamente divergências entre transações registradas e repasses recebidos, e sinalizando padrões recorrentes que indicam falhas de integração. Já na gestão de fluxo de caixa, modelos preditivos estimam recebíveis futuros com base no histórico de vendas, sazonalidade e prazos de repasse — informação valiosa para planejar estoque e campanhas. Plataformas que já embarcam essas capacidades, como ferramentas de subadquirente com painéis analíticos avançados, permitem que o time financeiro opere com dados em vez de planilhas.
Erros comuns na integração e como evitá-los
A maioria dos problemas em integrações de pagamento não vem de falhas exóticas, mas de omissões básicas: não tratar timeout, não implementar idempotência, testar apenas o caminho feliz ou ignorar requisitos de segurança. Reconhecer esses padrões antes da implementação economiza semanas de correção em produção. Abaixo, os três erros mais comuns e como evitá-los.
Timeouts, idempotência e tratamento correto de respostas de erro
Timeouts acontecem — a rede falha, o adquirente demora, a resposta se perde. Se o seu sistema não tiver lógica de retry com backoff exponencial, uma transação pode ficar em estado indefinido, nem aprovada nem recusada. Idempotência é igualmente crítica: envie um identificador único em cada chamada para que o subadquirente reconheça reenvios e não cobre duas vezes. Trate códigos de erro de forma granular — alguns pedem nova tentativa, outros exigem correção de dados, e outros significam recusa definitiva. Mapeie todos os códigos documentados antes de ir para produção.
Subestimar testes em sandbox com cenários reais de falha
Testar apenas o caminho feliz é o erro mais comum em integrações de pagamento. Um sandbox bem utilizado deve simular recusas por saldo insuficiente, timeouts deliberados, webhooks duplicados e fora de ordem, estornos parciais e devoluções via Pix. Monte uma suíte de testes automatizados que cubra esses cenários e rode-a a cada atualização da API. Operações que tratam sandbox como formalidade costumam descobrir problemas críticos no primeiro dia de pico de vendas — o pior momento possível para encontrar falhas.
Ignorar LGPD e requisitos de segurança na coleta de dados do comprador
A coleta e o tratamento de dados do comprador precisam seguir a LGPD, com atenção especial a tokenização, minimização de dados e consentimento claro. Na prática, isso significa não armazenar dados completos de cartão, registrar a base legal para cada tratamento e oferecer mecanismos de exercício de direitos do titular. Além da LGPD, respeite os requisitos de segurança das bandeiras (PCI DSS) — ainda que a tokenização via SDK reduza significativamente o escopo de conformidade. Integrações ignoram esses requisitos por achar que são “só burocracia”, mas uma non-conformidade pode custar muito mais que o próprio processamento.
Métricas para acompanhar após a implementação
Integrar a API é o começo, não o fim. Sem monitoramento contínuo, é impossível saber se a migração trouxe o resultado esperado ou se introduziu regressões silenciosas. Defina um painel com as métricas abaixo e revise semanalmente nos primeiros 90 dias após o go-live.
Taxa de aprovação, chargeback e custo efetivo por transação
A taxa de aprovação é o indicador mais direto de saúde da integração: uma queda súbita após a migração pode indicar problema de roteamento, configuração incorreta de 3DS ou incompatibilidade de dados. O índice de chargeback deve ser monitorado por causa (fraude, não-reconhecimento, produto não entregue), porque cada causa tem uma correção distinta. O custo efetivo por transação combina taxa nominal, custo de antifraude, custo de chargebacks e custo operacional de conciliação — é o número que realmente importa na comparação entre plataformas.
Tempo de integração, disponibilidade da API e impacto no checkout
Tempo de integração e disponibilidade da API são métricas do fornecedor que afetam diretamente sua operação: registre o uptime observado e o tempo médio de resposta das chamadas em produção. O impacto no checkout deve ser medido em conversão: compare a taxa de abandono antes e depois da migração, e monitore o tempo de carregamento do componente de pagamento. Uma API lenta no momento da autorização aumenta o abandono de carrinho de forma mensurável — e essa perda raramente aparece em relatórios financeiros padrão.
Como planejar a migração para uma nova API de subadquirente
Migrar de uma API de pagamento não é um evento, é um processo com fases claras: descoberta, implementação em sandbox, operação em paralelo, corte e pós-corte. O erro mais comum é tratar o corte como um “dia único” sem preparação de rollback — o que transforma qualquer imprevisto em indisponibilidade de vendas. Planeje cada fase com checklist e responsáveis nomeados.
Estratégia de rollback e operação em paralelo durante a transição
A operação em paralelo mantém a solução anterior ativa enquanto a nova API recebe tráfego real, começando por um percentual pequeno de transações e ampliando gradualmente. Essa abordagem, conhecida como canary release, permite detectar problemas de aprovação ou conciliação antes que afetem toda a operação. O rollback deve ser documentado e testado: defina o gatilho (por exemplo, queda de aprovação acima de determinado percentual por 30 minutos) e tenha o processo pronto para reverter sem intervenção manual extensa. Sem essa preparação, a migração vira uma aposta.
Checklist de comunicação com o time financeiro e de operações
O time financeiro precisa ser comunicado sobre novos prazos de repasse, mudanças na estrutura de taxas e o novo formato dos relatórios de conciliação antes da migração — não depois. A equipe de atendimento ao cliente deve saber como responder a dúvidas sobre status de pagamento durante o período de transição. Preparar um checklist que cubra essas frentes evita atritos internos que, embora não técnicos, atrasam a adoção da nova plataforma. Comunicação clara é tão importante quanto a qualidade da integração.
O futuro: pagamentos embedded e agentes de IA na stack financeira
A fronteira dos pagamentos está se deslocando da página de checkout para dentro dos produtos e fluxos que o antecedem. Pagamentos embedded — aqueles que acontecem sem que o usuário saia do ambiente onde está — estão se tornando padrão em marketplaces, SaaS e modelos de recebimento recorrente. Paralelamente, agentes de IA começam a operar não apenas na camada de decisão, mas na gestão completa da stack financeira.
Pagamentos embutidos em marketplaces e modelos de receita recorrente
Em marketplaces, o pagamento precisa ser embutido no fluxo de compra multi-vendedor, com split automático, repasse a lojistas e resolução de disputas — tudo orquestrado pela camada de subadquirente. Em modelos de recebimento recorrente, a challenge está na retenção: dunning inteligente, atualização automática de cartões expirados e recuperação de falhas de cobrança são diferenciais que impactam diretivo a receita. As APIs que suportarem esses fluxos nativamente — sem exigir desenvolvimento customizado pesado — terão vantagem clara na próxima onda de adoção.
IA generativa aplicada a análise de transações e atendimento financeiro
IA generativa já encontra aplicação prática na análise de transações: resumir milhares de registros em relatórios executivos, explicar anomalias de conciliação em linguagem natural e sugerir ações corretivas para o time financeiro. No atendimento, assistentes generativos podem responder dúvidas sobre status de pagamento, prazos de recebimento e políticas de chargeback com base na documentação real da plataforma — reduzindo a carga sobre o suporte humano. À medida que esses agentes se conectam diretamente às APIs de pagamento, a operação financeira passa a operar com autonomia crescente sobre tarefas rotineiras.
Principais aprendizados
- A API pagamento subadquirente adiciona uma camada de controle sobre taxas, repasses e serviços como antifraude e roteamento entre adquirentes.
- O ciclo completo — autorização, captura, liquidação e repasse — exige tratamento correto de webhooks, idempotência e conciliação.
- Plugins prontos são ideais para go-live rápido; operações em escala se beneficiam de integração via API ou SDK com checkout customizado.
- Um SDK de pagamento online deve entregar tokenização, 3D Secure, suporte a web e mobile, documentação clara e integração com antifraude.
- IA na camada de pagamento atua em três frentes: retentativa inteligente, detecção de fraude em tempo real e automação de conciliação.
- A migração deve incluir sandbox com cenários de falha, operação em paralelo, plano de rollback e conformidade com a LGPD.
Conclusão
Uma API de pagamento de subadquirente bem escolhida vai muito além de processar transações: ela define seu custo financeiro, sua autonomia sobre taxas e repasses e a base sobre a qual você aplica inteligência artificial para elevar aprovação e reduzir fraude. Do ciclo de autorização ao uso de SDK e plugins, cada decisão técnica tem impacto direto em conversão, risco e fluxo de caixa — e subestimar qualquer uma delas cobra preço em produção.
Comece mapeando seus requisitos técnicos e comerciais, valide em sandbox com cenários reais de falha, e só então migre — mantendo métricas como taxa de aprovação, chargeback e custo efetivo por transação sob acompanhamento contínuo para ajustar a operação com dados. Se quiser um ponto de partida concreto, avalie plataformas com boa documentação e suporte em português, testando-as em paralelo à solução atual antes de qualquer corte definitivo.
Perguntas frequentes
Qual é a diferença entre subadquirente, adquirente e facilitador de pagamento?
O adquirente é a instituição credenciada pelas bandeiras para capturar e liquidar transações. O subadquirente é um intermediário que usa a infraestrutura de um adquirente parceiro (ou que atua como instituição de pagamento) para oferecer checkout, antecipação e split a lojistas. Já o facilitador apenas aproxima as partes sem processar o fluxo financeiro — e, por isso, costuma ter menos controle sobre prazos de liquidação e disputas de chargeback.
Minha empresa precisa ter certificação PCI-DSS para integrar a API de um subadquirente?
Se a API usar tokenização e o cartão nunca passar pelos seus servidores (fluxo com campos hospedados, SDK ou redirecionamento), a responsabilidade sobre dados de cartão permanece no subadquirente e o escopo do lojista cai para SAQ A ou A-EP. Se você capturar, transmitir ou armazenar o PAN, entra no escopo completo PCI-DSS, com auditoria anual e potencial multa das bandeiras. Vale confirmar no contrato quem detém a certificação e qual SAQ se aplica ao seu caso.
Como funciona o rateio (split) de pagamentos na API de subadquirente?
No split, a transação é autorizada em nome do marketplace e a API distribui os recursos entre seller, plataforma e o próprio subadquirente via parâmetros de destinatários e percentuais (ou valores fixos) enviados junto à autorização. A liquidação pode ser simultânea ou escalonada, e o ideal é que o subadquirente também faça split nos eventos de chargeback e retenção, para que prejuízos não fiquem centralizados no lojista principal. Confirme se o split é feito em conta de pagamento segregada por seller, o que protege o dinheiro de credores do marketplace.
Quem responde legalmente pela liquidação dos recursos e pelo repasse ao lojista?
Depende do modelo: em subadquirência regulada pelo Banco Central, o subadquirente é instituição de pagamento e detém os recursos em conta de pagamento segregada, respondendo pelo repasse. Em modelos de facilitação sem regulação, o dinheiro pode passar pela conta do lojista principal, que passa a ser responsável civil e tributariamente pelo repasse aos sellers. Exija no contrato prazos de liquidação (D+), regras de reserva de segurança e clareza sobre quem absorve o chargeback.
Quais requisitos do Banco Central se aplicam a quem opera como subadquirente no Brasil?
Desde a Resolução BCB nº 80/2021 e a Lei 12.865/2013, arranjos de pagamento que incluam subadquirência exigem autorização do Banco Central como instituição de pagamento (fase inicial ou fase completa, conforme volume), além de controles antifraude, PLD/FT, capital regulatório e relatórios periódicos. Quem integra apenas a API não precisa dessa autorização, mas deve verificar se o fornecedor a possui — usar um parceiro irregular transfere risco reputacional e contratual ao lojista. O registro pode ser conferido no portal do Banco Central e nos sistemas de supervisão.
