Blog

Escolher gateway não é “só plugar pagamento”. A escolha define UX, taxa de aprovação, risco de fraude, conciliação financeira e até se o app passa (ou não) pela aprovação das lojas.

Este artigo é para quem quer tomar uma decisão prática, sem jargões e sem “virar refém” de um provedor. Você vai sair com um checklist claro, entender as opções de integração e ter um comparativo de provedores para conversar com seu time (ou com seu fornecedor) com segurança.

O que você vai ver aqui

• Primeiro filtro: o que você vende no app (e quando precisa usar o pagamento da própria loja).
• Checklist de decisão: perguntas que evitam retrabalho.
• Modelos de integração (checkout pronto, API, link) com prós e contras.
• Como comparar taxas sem cair em armadilhas.
• Comparativo de opções comuns (Brasil e multi-país), com observações reais de projeto.
• Sandbox/homologação: como testar com segurança.
• “Pagou / não pagou”: como validar corretamente (para Pix, boleto e cartão).

---

1) Antes de escolher qualquer gateway: o que você vende no app?

Este é o ponto que mais gera reprovação nas lojas e retrabalho técnico.

Se o seu app vende conteúdo digital consumido dentro do app (ex.: assinatura de conteúdo, funcionalidades premium, moedas virtuais, itens digitais, etc.), a regra geral é:

• iOS (Apple): precisa usar Compra Dentro do App (In‑App Purchase).
• Android (Google Play): precisa usar Google Play Billing para compras no app de bens/serviços digitais.

Se você tentar vender o digital “por fora” usando um gateway tradicional, o app pode ser rejeitado ou obrigado a mudar o fluxo.

Por outro lado, se você vende bens físicos ou serviços consumidos fora do app (ex.: entrega, transporte, eventos presenciais, assinatura de um serviço físico), normalmente você pode usar gateways tradicionais.

Regra simples para leigos:

• Digital dentro do app → pagamento da loja.
• Físico / serviço fora do app → gateway “normal”.

---

2) Glossário rápido (sem complicação)

Você vai ouvir alguns termos. Aqui vai uma tradução direta:

• Gateway/PSP (Payment Service Provider): a plataforma que processa o pagamento e te entrega APIs, checkout, webhooks, relatórios, etc. (muitas vezes ela já faz “tudo junto”).
• Adquirente (acquirer): a “maquininha do mundo online” — quem conecta a transação às bandeiras/emissores. Alguns provedores são adquirentes, outros usam adquirentes por baixo.
• Antifraude: camada que ajuda a reduzir fraude e chargeback (pode ser do próprio provedor ou de terceiros).
• Split/Marketplace: funcionalidade para dividir o pagamento (comissões e repasses) entre mais de um recebedor.
• Sandbox/Homologação: ambiente de teste (sem dinheiro real), para validar integração e fluxos.

Se você não lembrar desses nomes, tudo bem: o que importa é entender o efeito prático de cada um na sua operação.

---

3) Checklist de decisão (as perguntas certas)

Use este checklist antes de “escolher pelo nome” (ou pelo preço).

Pergunta	Por que importa	Exemplos de resposta
Você vende digital consumido no app?	Pode obrigar pagamento via loja	“Assinatura premium no app”
O app é Brasil ou multi-país?	Define Pix/boleto e suporte a moedas	“Só Brasil” / “LatAm” / “Global”
Quais meios são obrigatórios?	Impacta conversão	“Cartão + Pix + boleto”
Você precisa de parcelamento?	Muda UX, conciliação e chargeback	“Parcelar em 3–12x”
Há recorrência (assinatura)?	Troca toda a arquitetura de cobrança	“Mensal/anual”
Há marketplace/split?	Define subcontas, repasse e KYC	“Vários vendedores”
Quem precisa receber primeiro?	Define split automático vs manual	“Plataforma retém comissão”
Precisa de antifraude?	Reduz chargeback e perdas	“Sim, ticket alto”
Precisa de reembolso/cancelamento simples?	Suporte e reputação	“Reembolso em 7 dias”
Como será a conciliação?	Evita “faltou repasse”	“Fechamento mensal”
Checkout pronto ou personalizado?	Prazo vs controle de UX	“Quero rápido” / “Quero UX próprio”
O time domina webhooks e status?	Evita bug de pagamento	“Sim / Não”

Dica de ouro: se você não consegue responder essas perguntas em uma reunião de 30 minutos, você ainda não está “comprando gateway” — você está comprando risco.

---

4) Modelos de integração (e como isso afeta prazo e risco)

Existem três caminhos comuns. Eles não são “melhor/pior”; são escolhas com trade-offs.

4.1 Checkout pronto (hosted / redirecionamento / modal)

Você usa a interface do provedor (uma tela pronta), e só recebe o resultado.

Vantagens:

• Mais rápido de implementar.
• Menos responsabilidade com dados sensíveis.
• Geralmente já vem com melhorias de conversão “de fábrica”.

Desvantagens:

• Menos controle de UX e layout.
• Pode ter “quebras” de experiência (redireciona/abre webview).

4.2 Checkout no seu app (API + UI própria)

Você cria o fluxo/UX e usa a API do provedor para processar o pagamento.

Vantagens:

• Total controle do UX.
• Dá para otimizar conversão e funil de compra.

Desvantagens:

• Integração mais complexa.
• Exige mais cuidado com segurança e validação (principalmente via backend).
• Normalmente aumenta o custo de manutenção.

4.3 Link de pagamento (fluxo mais simples)

Você gera um link (pelo provedor) e o usuário paga numa página pronta.

Vantagens:

• Excelente para MVP, vendas assistidas, suporte e casos “fora do app”.
• Quase zero desenvolvimento.

Desvantagens:

• Menos integrado ao funil do app.
• Depende mais de operação manual.

---

5) Taxas e custos: como comparar sem cair em armadilhas

Muita gente escolhe gateway olhando só “a taxa do cartão”. Isso é insuficiente.

Os custos reais costumam vir de um pacote de decisões:

• cartão (aprovação, chargeback, parcelamento);
• Pix (conversão e confirmação);
• boleto (tempo de confirmação e abandono);
• recorrência (inadimplência, retentativas);
• split/marketplace (repasses, KYC, subcontas);
• antifraude (custo vs redução de perda).

Checklist do que comparar (sem números):

Item	O que perguntar (prático)	Por que muda tudo
Cartão (crédito/débito)	Tem captura/autoriza? tokenização? 3DS?	Afeta aprovação e risco
Pix	Confirma em tempo real? QR dinâmico?	Afeta conversão e UX
Boleto	Prazo de compensação e expiração	Afeta abandono e suporte
Parcelamento	Quem assume juros? como concilia?	Afeta repasse e “faltou dinheiro”
Chargeback	Processo e custos de disputa	Afeta margem e suporte
Reembolso	Total/parcial? como notifica?	Afeta reputação do app
Recorrência	Retentativa automática? dunning?	Afeta churn e inadimplência
Marketplace/split	Precisa conta de cada vendedor? KYC?	Afeta onboarding de sellers
Relatórios	Extrato, repasse, conciliação	Evita planilha e disputa

Dica para clientes: peça para o fornecedor te mandar uma proposta com cenários (ex.: venda simples vs assinatura vs marketplace). Um gateway pode ser ótimo para um cenário e ruim para outro.

---

6) Comparativo de provedores (Brasil e multi-país)

A tabela abaixo não é “ranking”. Ela é um mapa para você escolher por cenário.

Importante: recursos podem variar por contrato, país e modelo de conta. Use como orientação e valide com seu fornecedor antes de assinar.

6.1 Plataformas comuns no Brasil (Pix + boleto + cartão)

Provedor	Onde costuma encaixar bem	Pix/Boleto	Recorrência	Split/Marketplace	Antifraude	Observação prática
Mercado Pago	B2C e B2B com checkout pronto ou API	Sim	Depende do produto	Sim	Camadas do provedor	Bom para começar rápido com checkout pronto e webhooks
PagBank (PagSeguro)	E-commerce/app com variedade de meios	Sim	Sim	Sim	Sim (proteção antifraude)	Split pode exigir contas dos envolvidos
Pagar.me (Stone)	Plataformas/marketplaces com regras de split	Sim	Sim	Sim (Pix e recorrência)	Integra com estratégia do cliente	Bom quando precisa controlar regras e eventos via webhooks
iugu	Cobrança recorrente e integrações B2B	Sim (Pix Cobrança)	Sim	Sim	Depende do cenário	Forte em recorrência e automações; exige bom desenho de status
Asaas	Cobrança, assinaturas e automações financeiras	Sim	Sim	Sim	Depende do produto	Muito usado quando o “financeiro” é parte do produto
Efí Pay (Gerencianet)	Pix/boleto/cartão com split	Sim	Depende do produto	Sim	Depende do produto	Split costuma ser entre contas Efí

6.2 PSPs globais e cross-border (quando você tem mais de um país)

Provedor	Melhor para	Brasil (Pix/Boleto)	Marketplace/Split	Antifraude	Observação prática
Stripe	Produtos digitais/físicos multi-país; APIs maduras	Suporta Pix e boleto (conforme região/conta)	Stripe Connect	Stripe Radar	Forte em APIs, webhooks e ecossistema; bom para produto global
Adyen	Operação maior/enterprise; múltiplos métodos locais	Sim (Pix e boleto)	Plataformas (split)	RevenueProtect	Bom para consolidar pagamentos e operar risco/disputas
EBANX	Empresas vendendo para LatAm (cross-border)	Sim (Pix e boleto)	Depende do modelo	Depende do produto	Focado em meios locais e conversão na América Latina
dLocal	Cross-border com meios locais na LatAm	Sim (Pix e boleto)	Depende do modelo	Depende do produto	Útil quando o “local payments” é uma dor no país
PayPal / Braintree	Carteira PayPal, cartões e meios locais em um contrato	Depende do país	Depende do modelo	Ferramentas do provedor	Bom para público internacional e UX “PayPal”
Verifone 2Checkout	Internacional vendendo para Brasil com boleto/pix	Sim (Boleto/Pix)	Depende do modelo	Depende do produto	Opção para e‑commerce internacional com meios brasileiros

6.3 Adquirentes e APIs transacionais (quando você tem estrutura mais “enterprise”)

Provedor	Quando faz sentido	O que entrega	O que você precisa ter “do seu lado”
Cielo (API e-commerce)	Volume maior, operação Brasil, necessidade de módulos	Cartão, Pix, boleto, e-wallets; tokenização; antifraude integrável	Time para operar antifraude, conciliação e regras
Stone Online	Quando você quer “camada transacional” e já tem stack	Autorizar/capturar/cancelar/consultar transações	Antifraude, multimeios, recorrência e UX normalmente ficam com você
Getnet	E-commerce/marketplace com foco em adquirência e APIs	Checkouts/APIs; marketplace API; notificações	Governança de pagamentos e repasses
Rede	Operação Brasil com adquirência e integrações	APIs e autenticação (OAuth)	Estrutura para operar o restante do stack

---

7) Prós e contras (resumo rápido por provedor)

Use esta parte para “bater o martelo” quando você já sabe seu cenário.

Mercado Pago

Prós:

• bom para começar rápido (checkout pronto + API);
• forte para Pix/boleto/cartão no Brasil;
• webhooks bem conhecidos no mercado.

Contras:

• dependendo do modelo, pode ter menos controle fino de UX;
• recursos de marketplace/split exigem desenho cuidadoso de repasse.

PagBank (PagSeguro)

Prós:

• variedade de meios (cartão, Pix, boleto) e recursos complementares;
• split e recorrência aparecem como opções no ecossistema.

Contras:

• split tende a exigir onboarding/contas dos envolvidos;
• como todo provedor, detalhes variam por contrato.

Pagar.me (Stone)

Prós:

• forte quando você precisa de eventos, webhooks e regras de split;
• boa escolha para plataformas e recorrência.

Contras:

• integração costuma exigir mais disciplina técnica (status, eventos, idempotência).

iugu

Prós:

• muito usada para cobrança recorrente, boletos/Pix e automações financeiras;
• boa para modelos B2B e cobrança.

Contras:

• exige bom desenho de status e conciliação (especialmente com Pix/boleto).

Asaas

Prós:

• foco em cobrança e automação (assinaturas, cobranças, gestão);
• bom para cenários em que o financeiro faz parte do produto.

Contras:

• nem sempre é a melhor escolha se o seu foco é “cartão com máxima performance” (depende do seu caso).

Efí Pay (Gerencianet)

Prós:

• boa alternativa para Pix/boleto/cartão, incluindo split.

Contras:

• split normalmente depende de contas Efí para os recebedores.

Stripe

Prós:

• APIs e documentação muito maduras;
• excelente para produto multi-país;
• tem soluções para marketplace (Connect) e antifraude (Radar).

Contras:

• exige um mínimo de maturidade de engenharia;
• disponibilidade de métodos e recursos pode variar por país/conta.

Adyen

Prós:

• forte para operação grande/enterprise;
• muitos métodos locais, split e ferramentas de risco/disputa.

Contras:

• onboarding e negociação costumam ser mais “corporativos” (nem sempre ideal para MVP).

EBANX / dLocal (cross-border)

Prós:

• bons quando você precisa vender em países onde operar meios locais é difícil;
• costumam focar bastante em conversão com meios locais.

Contras:

• podem ser “grandes demais” para operação pequena;
• dependem do seu modelo (doméstico vs cross-border).

PayPal / Braintree

Prós:

• PayPal é conhecido mundialmente;
• Braintree costuma reunir cartões, carteiras e meios locais em uma integração.

Contras:

• para Brasil, verifique se atende Pix/boleto no seu modelo (nem sempre é o foco principal).

Verifone 2Checkout

Prós:

• alternativa para vendedor internacional que precisa aceitar boleto/pix do Brasil.

Contras:

• geralmente faz mais sentido para cross-border do que para empresa 100% Brasil.

Cielo / Stone Online / Getnet / Rede (adquirência)

Prós:

• podem fazer sentido para operações maiores no Brasil, com necessidade de módulos e controle.

Contras:

• você normalmente precisa de mais “stack” ao redor (antifraude, split, reconciliação, UX);
• a implantação tende a ser mais trabalhosa do que um PSP “tudo em um”.

---

8) O que o cliente precisa abrir/contratar (checklist)

Aqui vai um checklist que reduz trocas e acelera implantação. Você pode copiar e colar em e-mail para o time financeiro/jurídico.

Item	Quem geralmente resolve	Observação
Conta PJ no provedor (CNPJ)	Financeiro/Jurídico	Normalmente exige KYC (documentos da empresa)
Conta bancária de recebimento	Financeiro	Confirmar titularidade
Definir modelo: venda simples vs marketplace	Produto/Financeiro	Marketplace costuma exigir subcontas e regras de split
Definir meios: cartão, Pix, boleto, parcelamento	Produto	Afeta UX e conciliação
Definir política de reembolso/cancelamento	Produto/Suporte	Importante para reputação e disputas
Definir responsável por acompanhar relatórios	Financeiro	“Quem confere se caiu?”
Aprovação de orçamento recorrente	Diretoria/Financeiro	Taxas variam com volume, chargeback e antecipação
Compartilhar credenciais de integração de forma segura	TI/Produto	Ideal: usuário dedicado + permissões mínimas necessárias

---

9) Sandbox/homologação: como testar sem medo (antes do lançamento)

Boas integrações de pagamento falham não por “bug”, mas por falta de teste de cenário.

Checklist de testes mínimos:

• pagamento aprovado (cartão);
• pagamento negado (cartão);
• reembolso total e parcial;
• Pix pago imediatamente e Pix pago com atraso;
• boleto gerado e pago depois (status pendente → pago);
• webhook fora de ordem (chega duplicado / chega depois);
• tentativa de “pagar duas vezes” (idempotência);
• conciliação: o que aparece no painel vs no seu sistema.

Regras simples para evitar dor:

• trate o sandbox como ambiente real: webhook + backend + banco;
• nunca valide pagamento “só no app”;
• registre logs de eventos (para auditoria e suporte).

---

10) “Pagou / não pagou”: como validar corretamente (e evitar fraude e bugs)

Esta é a parte mais importante do artigo.

Em projetos reais, os maiores problemas vêm de duas situações:

1. Pix/boleto são assíncronos (podem demorar para confirmar).
2. O usuário pode fechar o app no meio do fluxo — e mesmo assim o pagamento acontecer.

A arquitetura recomendada é sempre esta:

Fluxo recomendado (passo a passo)

1. O app cria um pedido no backend (ex.: “Pedido #123”).
2. O backend chama o provedor e cria a cobrança (cartão/pix/boleto).
3. O backend salva o pagamento como pendente.
4. O provedor envia webhook confirmando mudança de status (pago/negado/estornado).
5. O backend valida a assinatura do webhook e atualiza o status no banco.
6. O app apenas consulta e exibe o status (ex.: “aguardando pagamento” → “aprovado”).

Regra de ouro: quem decide se pagou é o backend. O app só mostra.

Status típicos (para você conversar com o time sem confusão)

Status (exemplo)	O que significa	Ação no app
Pendente	Aguardando pagamento (Pix/boleto)	Mostrar “aguardando”
Autorizado	Cartão autorizado (ainda pode capturar)	“Processando”
Pago / Capturado	Pagamento confirmado	Liberar acesso/entrega
Negado / Falhou	Não pagou	Mostrar erro e permitir tentar de novo
Estornado / Reembolsado	Pagamento devolvido	Ajustar acesso e notificar
Chargeback / Disputa	Contestação do cartão	Abrir fluxo de suporte

---

11) Erros comuns (que viram retrabalho e discussão)

• Escolher gateway antes de decidir: Pix/boleto, recorrência, split e país.
• Confiar no app para marcar “pago” (isso abre brecha de fraude e gera inconsistência).
• Não configurar webhooks (ou não tratar duplicidade e reentrega).
• Ignorar que boleto pode levar horas/dias para confirmar.
• Não planejar conciliação (quando o financeiro começa a cobrar, vira crise).
• Começar marketplace sem split automático (vira planilha + disputa de repasse).
• Não prever reembolso/cancelamento desde o início.

---

12) Um caminho simples para decidir (sem travar o projeto)

Se você quer um “atalho” prático:

1. Venda digital no app?
   Use pagamento da loja (iOS/Android). Não discuta gateway agora.
2. Venda fora do app e só Brasil?
   Priorize um provedor com Pix + boleto + cartão + webhooks bem documentados.
3. Vai ter marketplace?
   Escolha um provedor com split/subcontas e defina as regras de repasse antes de lançar.
4. Vai vender em mais de um país?
   Considere PSP global ou um provedor cross-border com meios locais.

Se você fizer esse roteiro, o resto vira execução — e não “troca infinita de opinião”.

---

Se você quiser, podemos transformar seu cenário em uma decisão objetiva em uma call curta, usando o checklist deste artigo: país, meios, recorrência, split, antifraude e o modelo de integração (checkout pronto vs API).