Como escolher uma empresa de pagamentos para seu e-commerce: 20 critérios além da taxa

A escolha de uma empresa de pagamentos costuma começar por uma tabela de taxas. Essa é uma maneira compreensível de comparar propostas, mas é também uma das formas mais perigosas de tomar a decisão. O fornecedor de pagamentos ocupa o ponto em que intenção de compra vira receita, e o custo de uma infraestrutura inadequada pode aparecer em lugares que não estão na proposta comercial: vendas recusadas, checkout lento, indisponibilidade, horas de desenvolvimento, chargebacks, conciliação manual, suporte demorado e dependência tecnológica.

Para um e-commerce pequeno, a simplicidade de contratação pode ser o principal fator. Para uma empresa que cresce, surgem perguntas diferentes: a plataforma suporta mais volume? consigo adicionar Pix, cartão e recorrência pela mesma API? terei dados para entender recusas? como migro se precisar? como funciona o suporte em incidentes? qual é o papel regulatório de cada participante? existe flexibilidade para múltiplas rotas? o financeiro consegue fechar a operação sem planilhas?

Este artigo propõe uma maneira mais madura de escolher um parceiro de pagamentos: comparar o custo total e a capacidade de gerar receita, reduzir risco e sustentar crescimento. O objetivo não é encontrar um “melhor provedor universal”, porque ele não existe. É encontrar a combinação adequada para seu modelo de negócio, estágio e arquitetura.

Comece pelo problema de negócio, não pelo fornecedor

Antes de pedir propostas, escreva o que precisa resolver. Quantas transações a empresa processa? Qual é o ticket médio? Qual percentual é mobile? Há recorrência? Marketplace? Múltiplos sellers? Produtos digitais? Alto valor? Vendas internacionais? Pix é relevante? A empresa precisa de boleto? Qual é o prazo de recebimento desejado?

Depois liste as dores atuais. Recusas elevadas? dificuldade de conciliar? API antiga? falta de tokenização? chargeback? indisponibilidade? suporte? custo? ausência de split? Essa lista será a base de um RFP ou scorecard.

Sem isso, o fornecedor com a apresentação mais bonita tende a vencer, mesmo que resolva o problema errado.

1. Entenda exatamente qual papel o fornecedor exerce

O mercado usa termos como gateway, PSP, adquirente, subadquirente, plataforma e orquestrador. Essas palavras não são equivalentes e, em alguns casos, são utilizadas comercialmente com sentidos amplos.

O Banco Central define instituição de pagamento, arranjo, credenciador e subcredenciador dentro do sistema regulatório aplicável. Um gateway, por outro lado, é principalmente uma camada tecnológica. Uma mesma empresa pode combinar serviços, mas é importante perguntar quem faz o quê.

Peça um desenho simples: seu e-commerce contrata quem? Quem processa? Quem habilita o estabelecimento? Quem liquida? Quem armazena a credencial? Quem responde por antifraude? Quem envia os webhooks? Quem aparece na conciliação?

Clareza evita surpresa contratual e operacional.

2. Confirme o enquadramento e os participantes aplicáveis

Quando o serviço depende de instituição autorizada, consulte as fontes oficiais. O Banco Central disponibiliza ferramenta para verificar instituições, arranjos e sistemas autorizados. Isso não significa que todo fornecedor de tecnologia precise ser uma instituição de pagamento; significa que a empresa deve saber quais participantes regulados sustentam o produto contratado quando isso for necessário.

Não baseie due diligence apenas em logotipos na página comercial. Peça contratos, termos, evidências e descrição de responsabilidades.

Para empresas maiores, jurídico e compliance devem participar da seleção antes da assinatura, não depois.

3. Meça aprovação com metodologia

Taxa de aprovação pode ser mais relevante que uma pequena diferença de preço, mas números de fornecedores não são automaticamente comparáveis. Um pode calcular aprovação sobre todas as tentativas; outro excluir erros; outro medir apenas clientes de determinado perfil.

Pergunte: qual é o denominador? há segmentação por bandeira, emissor, ticket e recorrência? erros técnicos entram? retentativas contam separadamente? o número é mediana da base ou resultado de um segmento?

Melhor ainda: faça piloto com tráfego comparável. Se for possível, roteie uma amostra controlada e compare pedidos pagos, não apenas autorizações.

4. Compare custo total, não apenas MDR

O preço de pagamentos pode incluir MDR, tarifa de gateway, antifraude, autenticação, boleto, Pix, chargeback, antecipação, saque, split, tokenização, mensalidade e serviços adicionais.

Também existem custos internos: tempo de engenharia, manutenção, operação financeira, atendimento e incidentes. Um provedor R$ 0,02 mais barato por transação pode ser mais caro se exige duas pessoas conciliando manualmente.

Crie uma planilha de total cost of ownership para 12 e 24 meses. Use seu mix real de pagamento e três cenários de crescimento.

5. Avalie prazo e previsibilidade de recebimento

Preço sem fluxo de caixa é comparação incompleta. Entenda datas de liquidação, antecipação, finais de semana, feriados, regras para parcelas e possíveis reservas conforme o produto.

No Brasil, recebíveis de cartões possuem estrutura regulatória específica. O Banco Central define agendas e unidades de recebíveis e mantém regras para registro e negociação desses ativos.

Seu financeiro precisa saber o que receberá e quando, antes de depender do novo fornecedor.

6. API é produto, não detalhe técnico

Uma API ruim cobra juros durante anos. Documentação incompleta, mensagens de erro genéricas, ausência de idempotência e SDKs abandonados tornam toda evolução mais cara.

Peça acesso ao sandbox antes do contrato. Solicite que um desenvolvedor independente da negociação comercial tente criar uma cobrança, estornar, consultar e processar um webhook. Meça quanto tempo leva para entender a documentação.

Verifique versionamento, changelog e política de depreciação. Um parceiro deve evoluir sem quebrar sua produção inesperadamente.

7. Idempotência e tratamento de falhas são obrigatórios

Pergunte como a API evita cobranças duplicadas. O RFC 9110 define o conceito de idempotência e ressalta os cuidados ao repetir operações não idempotentes. Em pagamentos, APIs normalmente adicionam mecanismos próprios para que uma intenção possa ser reenviada após falha de comunicação sem criar um novo efeito financeiro.

Simule timeout depois do envio. O sistema consegue consultar a mesma intenção? Há uma chave idempotente? Como o fornecedor documenta estado desconhecido?

Uma demo que só mostra o caminho feliz não é avaliação técnica.

8. Webhooks precisam ser confiáveis

Você dependerá de eventos para confirmar Pix, estorno, disputa e outros estados. Pergunte como o webhook é autenticado, quantas vezes é repetido, como funciona retry e se existe replay manual.

Seu sistema deve tolerar duplicidade e eventos fora de ordem. O fornecedor precisa fornecer IDs e documentação suficientes.

Se o portal não mostra histórico de entregas e respostas HTTP, investigar um incidente pode virar troca de e-mails.

9. Segurança e PCI DSS

O PCI DSS foi criado para estabelecer requisitos técnicos e operacionais de proteção de dados de contas de pagamento. O PCI Security Standards Council informa que o padrão se aplica a entidades que armazenam, processam ou transmitem dados de cartão ou podem impactar a segurança do ambiente.

Pergunte qual é o escopo do serviço, como ocorre tokenização, quem armazena credenciais e quais evidências de conformidade estão disponíveis. PCI não é apenas um selo; o desenho da integração muda seu próprio escopo.

Avalie também segurança de API. A OWASP mantém um Top 10 específico com riscos como autorização quebrada, autenticação quebrada, consumo irrestrito de recursos e má configuração.

10. Tokenização e portabilidade

Credenciais salvas aumentam recompra e são importantes para assinatura, mas podem criar dependência do provedor. Entenda que tipo de token é usado e se existe processo seguro de migração quando tecnicamente possível.

Pergunte quem controla o vault, como funciona cartão atualizado, token de rede quando aplicável e em quais rotas o token pode ser usado.

Portabilidade não deve ser descoberta apenas no momento de sair.

11. Antifraude e falso positivo

Não compare antifraude apenas por quantidade de regras. Pergunte como decisões são explicadas, se existem scores, revisão, listas, dispositivo, autenticação e integração com seu histórico.

Meça fraude e falso positivo. Um motor que bloqueia tudo pode apresentar baixa fraude e péssima receita. O objetivo é maximizar aprovação saudável.

Também verifique se é possível utilizar um antifraude externo ou combinar ferramentas. Flexibilidade importa para operações sofisticadas.

12. Chargeback e disputa

Pergunte como notificações chegam, quais dados são disponibilizados, qual é o prazo operacional, se há portal, API ou webhook, como evidências são enviadas e como resultados são consultados.

Visa e Mastercard mantêm processos formais de disputa e publicam guias para comerciantes. A Mastercard também referencia programas relacionados a chargeback excessivo e fraude excessiva.

Seu provedor deve ajudar a tornar esses eventos visíveis. A responsabilidade do comerciante por prevenção, documentação e atendimento continua relevante.

13. Conciliação financeira

Peça um arquivo real ou layout de conciliação. O financeiro consegue relacionar pedido, transação, taxa, parcela, estorno, chargeback e liquidação?

Há API? export CSV? filtros por seller? identificação de antecipação? agenda de recebíveis? Se a resposta é “você vê o total no dashboard”, isso é insuficiente para uma operação em escala.

Inclua o time financeiro no piloto.

14. Suporte e gestão de incidentes

Pergunte o que acontece às 22h de uma sexta-feira quando a autorização começa a falhar. Existe canal de incidente? SLA por severidade? plantão? status page? executivo de conta? time técnico?

Suporte comercial bom não é o mesmo que suporte operacional. Durante a venda, todo fornecedor responde rápido. Simule um cenário crítico na due diligence e pergunte quem seria acionado.

Solicite exemplos de post-mortem ou processo de comunicação, respeitando confidencialidade.

15. SLA e disponibilidade

“99,9%” parece alto, mas representa potencialmente dezenas de minutos de indisponibilidade em um mês, dependendo da metodologia. Pergunte o que entra no cálculo, quais endpoints são medidos e se indisponibilidade de parceiros externos é excluída.

Veja histórico, não apenas promessa. Pergunte por p95 e p99 de latência, janelas de manutenção e arquitetura de redundância.

Seu negócio pode exigir múltiplos provedores se a tolerância a falha for menor que a capacidade de qualquer fornecedor único.

16. Performance e latência

Checkout é experiência. O web.dev publicou estudos relacionando performance de páginas e conversão. Em um estudo de caso de 2026, a Nuvemshop relatou melhora de Core Web Vitals e aumento de conversão na coorte analisada após otimizações de performance.

A autorização depende de vários participantes e o provedor não controla tudo, mas deve minimizar sua própria latência e fornecer métricas.

Teste em produção controlada. Uma chamada no Postman em horário vazio não representa Black Friday.

17. Escalabilidade e picos

Pergunte sobre rate limit, burst, filas, capacidade e proteção contra noisy neighbor. Se sua campanha viralizar, o sistema aceita o pico?

Simule carga no sandbox ou em ambiente acordado. Testes precisam respeitar limites do fornecedor; não realize stress test sem autorização.

Analise também seu próprio lado. A infraestrutura de pagamento mais escalável não resolve uma aplicação que serializa todas as requisições em um banco saturado.

18. Multiadquirência e orquestração

Para algumas empresas, uma rota é suficiente. Para outras, múltiplos parceiros permitem redundância, cobertura e otimização. Pergunte se a plataforma suporta diferentes rotas e como decide elegibilidade.

Smart routing deve considerar contrato, seller, bandeira, disponibilidade, custo e performance. Algoritmo não pode ignorar restrições de credenciamento.

Se multiadquirência faz parte do roadmap, escolha uma arquitetura que não exija refazer o checkout a cada parceiro.

19. Dados e observabilidade

Você deve conseguir pesquisar uma transação por ID do pedido, payment ID, seller, referência externa e outros campos relevantes. O portal precisa mostrar histórico de estados e erros.

Para operação avançada, pergunte por API de relatórios, exportação e acesso a métricas. Seus dados de pagamento são insumo de negócio.

Evite contratos ou arquiteturas que impeçam exportação básica do histórico.

20. Roadmap e alinhamento estratégico

Escolher pagamentos é uma decisão de anos. Conheça o roadmap: novos meios, moedas, adquirentes, recorrência, split, observabilidade, integrações e segurança.

Não compre promessas sem prazo, mas use a direção estratégica como critério. Se sua empresa pretende virar marketplace e o fornecedor não planeja suportar recebedores, vocês podem se afastar rapidamente.

A melhor parceria é aquela em que a infraestrutura consegue acompanhar a próxima fase da empresa.

Crie uma matriz de decisão ponderada

Depois da due diligence, transforme opiniões em score. Um exemplo:

Os pesos devem refletir seu negócio. Uma empresa de assinatura pode aumentar tokenização e recorrência. Marketplace aumenta split, recebedores e compliance. Varejo de baixo risco pode dar mais peso a custo.

Faça prova de conceito com casos reais

A POC deve usar um catálogo de cenários, não apenas uma compra aprovada. Teste cartão aprovado, recusado, Pix pago, Pix expirado, estorno parcial, timeout, duplicidade, webhook repetido, consulta, falha de autenticação e exportação financeira.

Registre tempo do desenvolvedor, bugs encontrados, dúvidas e qualidade do suporte. A experiência da integração é um dado.

Se possível, faça um piloto em produção com volume limitado e critérios de rollback.

Compare com base na margem incremental

Suponha que o fornecedor A seja mais barato, mas o B melhora pedidos pagos, reduz falha técnica e economiza horas de operação. O que importa é a margem incremental líquida.

Crie uma conta com receita adicional estimada, custo de processamento, fraude, chargeback, operação e custo financeiro. Não atribua causalidade sem teste, mas tente capturar o valor completo.

Pagamentos é uma linha de custo e uma alavanca de receita ao mesmo tempo.

Cuidado com lock-in invisível

Lock-in não é apenas contrato longo. Pode estar em tokens não portáveis, API proprietária espalhada pelo código, relatórios sem exportação, regras de negócio configuradas apenas no portal ou dependência de um único meio.

Crie uma camada interna de pagamentos e mantenha IDs próprios. Isso não elimina dependência, mas reduz custo de mudança.

Negocie cláusulas de exportação e transição antes da assinatura.

Quando usar um único provedor?

Uma solução única pode ser ótima para empresas que valorizam simplicidade, possuem volume moderado e não precisam de contingência sofisticada. Menos integrações significam menos operação.

Não adote multi-provider por moda. Cada rota adiciona reconciliação, contratos, monitoramento e complexidade.

O desenho deve corresponder ao risco e escala reais.

Quando considerar múltiplos provedores?

Faz sentido quando indisponibilidade possui impacto alto, existem diferenças de cobertura, contratos específicos, sellers elegíveis em rotas distintas ou oportunidade comprovada de otimização.

O passo seguinte é uma camada de orquestração que mantenha regras centralizadas e dados normalizados.

Mesmo nesse cenário, evite enviar a mesma transação simultaneamente para duas rotas sem um desenho específico, pois pode gerar cobranças duplicadas.

Checklist executivo para a reunião comercial

Leve estas perguntas:

1. Qual o papel exato de cada empresa no fluxo?
2. Quais meios estão disponíveis hoje?
3. Como a taxa de aprovação é calculada?
4. Quais são todos os custos?
5. Como funciona liquidação e antecipação?
6. Qual evidência PCI se aplica?
7. Como funciona tokenização e migração?
8. Existe idempotência?
9. Como funcionam webhooks e replay?
10. Qual o SLA e histórico de disponibilidade?
11. Como são tratados incidentes críticos?
12. Quais relatórios de conciliação existem?
13. Como são notificadas disputas?
14. Posso usar antifraude externo?
15. Há suporte a múltiplas rotas?
16. Quais limites de API e volume?
17. Como funciona sandbox?
18. Qual política de versionamento?
19. Como exporto meus dados?
20. Qual é o roadmap dos próximos 12 meses?

Como a IOPAY pode ajudar

A IOPAY pode ser incluída em uma avaliação estruturada de parceiros de pagamento por empresas que buscam centralizar integração, checkout e operação em uma arquitetura que possa evoluir conforme o negócio cresce.

A melhor forma de avaliar não é aceitar uma promessa comercial. É mapear seus requisitos e testar a infraestrutura contra eles. Volume, aprovação, risco, conciliação, meios, segurança e roadmap devem formar um score único.

Está comparando provedores de pagamento? Converse com a equipe IOPAY e use seu cenário real para avaliar arquitetura, integração e operação antes de decidir.

FAQ - como escolher empresa de pagamentos

Qual é o melhor gateway de pagamento?

Não existe um melhor universal. A escolha depende de volume, modelo de negócio, meios de pagamento, requisitos técnicos, risco, custo e necessidade de escala. Compare fornecedores com uma matriz ponderada.

Devo escolher o provedor com menor taxa?

Não necessariamente. Avalie custo total, aprovação, indisponibilidade, integração, chargeback, conciliação e operação. Uma pequena economia de tarifa pode ser superada por perda de receita ou custo manual.

Como comparar taxa de aprovação entre empresas?

Peça a metodologia e, idealmente, faça um teste controlado com tráfego comparável. Números de apresentações comerciais podem ter denominadores diferentes.

Preciso de multiadquirência?

Depende. Ela pode trazer redundância e flexibilidade, mas adiciona complexidade. Faça a conta do benefício esperado e garanta conciliação e roteamento adequados.

O que devo verificar sobre PCI DSS?

Entenda qual serviço está coberto, quais dados passam por seu ambiente, como funciona tokenização e qual evidência de conformidade é aplicável. O desenho da integração afeta seu próprio escopo.

Por que conciliação deve entrar na escolha?

Porque uma venda só está operacionalmente encerrada quando valores, taxas e eventos conseguem ser explicados. Relatórios ruins aumentam custo financeiro e risco de divergências.

Vale fazer POC antes de contratar?

Sim, principalmente em operações relevantes. Teste cenários reais, inclusive falhas. A POC revela qualidade de documentação, API e suporte.

Como saber se o fornecedor é adequado para crescer?

Analise capacidade, SLA, multi-provider, dados, versionamento, suporte, roadmap e referências de clientes com complexidade semelhante à sua.

Referências

1. Banco Central do Brasil - Instituições de Pagamento: https://www.bcb.gov.br/estabilidadefinanceira/instituicaopagamento
2. Banco Central do Brasil - instituições, arranjos e sistemas autorizados: https://www.bcb.gov.br/meubc/faqs/p/instituicoes-arranjos-e-sistemas-autorizados-pelo-bc
3. Banco Central do Brasil - Arranjos de Pagamento: https://www.bcb.gov.br/estabilidadefinanceira/arranjospagamento/
4. Banco Central do Brasil - Operações com recebíveis: https://www.bcb.gov.br/meubc/faqs/s/operacao-com-recebiveis
5. PCI Security Standards Council - PCI DSS: https://www.pcisecuritystandards.org/pt/standards/pci-dss/
6. PCI SSC - Biblioteca de Documentos e PCI DSS v4.0.1: https://www.pcisecuritystandards.org/pt/document_library/
7. OWASP API Security Top 10: https://owasp.org/API-Security/
8. RFC 9110 - HTTP Semantics: https://www.rfc-editor.org/rfc/rfc9110.html
9. Visa - Dispute Resolution: https://www.visa.com/en-us/support/business/dispute-resolution
10. Mastercard - Regras e programas de conformidade: https://www.mastercard.com/br/pt/business/support/rules.html
11. web.dev - Caso Nuvemshop sobre performance e conversão: https://web.dev/case-studies/nuvemshop?hl=pt-br

Como transformar os 20 critérios em uma decisão objetiva

Depois de mapear os critérios, o passo mais importante é tirar a comparação do campo da percepção e transformá-la em uma matriz de decisão. Uma forma simples é separar os requisitos em três grupos: eliminatórios, relevantes e desejáveis. Um requisito eliminatório é aquele que torna o fornecedor inviável para a operação, como ausência de determinado meio de pagamento, incompatibilidade técnica, restrição de volume, impossibilidade de atender sellers específicos ou falta de uma condição de segurança necessária. Critérios relevantes diferenciam economicamente ou operacionalmente as propostas. Já os desejáveis agregam valor, mas não justificam sozinhos uma troca de fornecedor.

Também vale atribuir pesos diferentes a conversão, disponibilidade, custo, velocidade de integração, conciliação, risco e suporte. Em um e-commerce de grande volume, por exemplo, um ponto percentual de aprovação pode valer muito mais do que uma pequena diferença de preço por transação. Em outro negócio, prazo de recebimento e previsibilidade de caixa podem ser decisivos. O importante é não usar uma tabela universal: a matriz precisa refletir a economia e os gargalos do próprio merchant.

Por fim, a decisão não deveria terminar na assinatura do contrato. Defina indicadores para os primeiros 30, 60 e 90 dias, incluindo aprovação, latência, incidentes, divergências de conciliação, tempo de suporte e impacto sobre a conversão. Dessa forma, a empresa compara promessa comercial com resultado operacional e cria evidências para expandir, renegociar ou ajustar a arquitetura de pagamentos.