
O checkout transparente, em que o cliente paga sem sair do site, faz sentido para lojas que querem controlar a experiência, oferecer cartão salvo e reduzir etapas, desde que tenham equipe para manter a integração e cuidar da segurança. O checkout redirecionado, em que o cliente conclui o pagamento numa página do provedor, é o caminho mais rápido e com menor responsabilidade sobre dados de cartão, ao custo de menos controle visual. O link de pagamento serve para vendas sem carrinho, como as fechadas pelo WhatsApp, por telefone ou por um vendedor. A decisão importa porque o abandono é alto: a Baymard Institute calcula que 70,22% dos carrinhos on-line são abandonados, e 17% dos compradores dizem ter desistido por um checkout longo ou complicado. Muitas empresas acabam combinando os três modelos.
Este artigo explica como cada modelo funciona, o que os dados de abandono dizem, o que muda na segurança e quanto custa integrar cada opção.
Os três modelos de checkout, em linguagem simples
Checkout é a etapa final da compra, em que o cliente informa como vai pagar e confirma o pedido. A forma de montar essa etapa define quem controla a tela, quem recebe os dados do cartão e quanto trabalho de desenvolvimento a empresa terá.
Checkout transparente
No checkout transparente, o formulário de pagamento fica dentro do site ou do aplicativo da empresa. O cliente não percebe a troca de ambiente. Por trás, o sistema da loja conversa com a API do provedor de pagamento para criar a cobrança.
A documentação do Checkout Transparente do Mercado Pago resume a proposta: integrar o pagamento ao próprio site e personalizar toda a experiência. Hoje, a maioria dos provedores oferece componentes prontos que capturam o cartão num campo seguro hospedado por eles, embutido na página da loja. Isso permite a aparência de checkout próprio sem que o número do cartão passe pelos servidores da empresa.
Checkout redirecionado
No checkout redirecionado, o cliente monta o carrinho no site da loja e, na hora de pagar, é levado a uma página do provedor. Depois do pagamento, volta à loja. A visão geral do Checkout Pro do Mercado Pago descreve esse fluxo: o comprador “paga no ambiente seguro do Mercado Pago e retorna à sua loja ou ao destino configurado”.
O Checkout PagBank segue a mesma lógica: direciona o cliente a uma página exclusiva do PagBank e, depois da transação, o redireciona para a página indicada pela loja. A Stripe chama esse modelo de página completa e o marca como recomendado na sua documentação de pagamentos on-line.
Link de pagamento
O link de pagamento é um endereço gerado para uma cobrança específica. A empresa envia o link por WhatsApp, e-mail ou SMS, e o cliente abre uma página do provedor para pagar. Não há carrinho nem site obrigatório.
A Stripe descreve os Payment Links como forma de “aceitar pagamentos sem um site”. O Asaas, o PagBank e outros provedores oferecem recurso equivalente. Quando o sistema da empresa gera o link pela API, a baixa do pagamento pode ser automática, sem conferência manual.
O que os dados de abandono de carrinho mostram
A Baymard Institute, centro de pesquisa em usabilidade de comércio eletrônico, mantém uma média calculada a partir de 50 estudos diferentes. Na versão atualizada em setembro de 2025, a taxa média de abandono de carrinho é de 70,22%. Ou seja, de cada dez pessoas que colocam algo no carrinho, sete saem sem comprar.
Parte desse abandono não tem relação com o checkout. Na pesquisa citada pela Baymard, 42% dos compradores on-line dos Estados Unidos disseram que estavam só olhando. Mas, entre os demais motivos, vários estão diretamente ligados à etapa de pagamento.
| Motivo de abandono durante o checkout | Compradores que citaram |
|---|---|
| Custos extras altos (frete, impostos, taxas) | 40% |
| Entrega muito lenta | 20% |
| Não confiou no site para informar o cartão | 19% |
| O site exigiu criar conta | 18% |
| Checkout longo ou complicado | 17% |
| O site apresentou erro ou travou | 17% |
| Política de devolução insatisfatória | 13% |
| Não conseguiu ver o custo total antes | 12% |
| Cartão recusado | 10% |
| Poucas formas de pagamento | 9% |
Fonte: Baymard Institute, lista de estatísticas de abandono de carrinho, pesquisa com compradores on-line dos Estados Unidos.
Os dados são de compradores americanos, mas os motivos se repetem no Brasil. O Relatório do Varejo 2026 da Adyen, citado pelo Finsiders, aponta que 60% dos consumidores brasileiros abandonam a compra quando não conseguem pagar da forma que preferem. Num país em que Pix e cartão parcelado convivem, oferecer os dois é condição básica.
Quanto o checkout pode melhorar a conversão
A Baymard estima que um site de comércio eletrônico grande pode ter aumento de 35,26% na taxa de conversão apenas resolvendo problemas de usabilidade no checkout. Na pesquisa de usabilidade de checkout, feita com 344 sites de maior faturamento dos Estados Unidos e da Europa, 65% tiveram desempenho “medíocre” ou pior, e só 2% foram avaliados como “bons”.
A mesma lista informa que o checkout médio nos Estados Unidos exibe 23,48 elementos de formulário, ou 14,88 campos quando se contam só os campos a preencher. Cada campo a mais é uma chance de desistência. Esse dado ajuda a entender por que o modelo de checkout, sozinho, não resolve: um checkout transparente mal desenhado pode converter pior que uma boa página redirecionada.
Comparativo dos três modelos
A tabela resume as diferenças práticas. É uma comparação qualitativa, para orientar a decisão.
| Critério | Checkout transparente | Checkout redirecionado | Link de pagamento |
|---|---|---|---|
| Onde o cliente paga | No site ou app da loja | Na página do provedor | Na página do provedor |
| Controle visual | Total | Limitado ao que o provedor permite | Baixo |
| Esforço de integração | Alto | Baixo a médio | Baixo |
| Escopo de segurança de cartão | Menor com campos seguros do provedor; maior se o servidor recebe o cartão | Menor | Menor |
| Cartão salvo para próximas compras | Sim, com tokenização | Depende do provedor | Depende do provedor |
| Uso típico | Lojas com volume e equipe técnica | Lojas iniciando ou com equipe enxuta | Venda consultiva, WhatsApp, cobrança avulsa |
| Dependência do provedor | Média, se houver camada intermediária | Alta | Alta |
Não há dado público que comprove, de forma geral, que um modelo converte mais que o outro. O que os estudos mostram é que confiança, número de etapas, formas de pagamento e erros pesam no abandono. Um checkout redirecionado de um provedor conhecido pode passar mais confiança a um cliente novo. Um checkout transparente bem feito reduz etapas e permite oferecer cartão salvo a quem já comprou.

Como o Pix muda o desenho do checkout
O Pix tem peso grande no comércio eletrônico brasileiro. Uma pesquisa da Visa com 1.521 brasileiros, feita em dezembro de 2025 e divulgada pelo Let’s Money, aponta que o Pix já representa 45% das transações no e-commerce, contra 47% do cartão. O Global Payments Report, também citado pelo Let’s Money, chega a 38% das transações de e-commerce em 2025. As metodologias são diferentes, mas as duas apontam o Pix como meio central.
No Pix, o checkout não captura dados sensíveis. Ele exibe um QR Code ou um código “copia e cola”, e o cliente paga no aplicativo do banco. Isso muda três coisas no desenho:
- No celular, o cliente sai do site para abrir o app do banco. A documentação de Pix da Stripe observa que o app do banco não redireciona o cliente de volta, então a página precisa continuar aberta e atualizar sozinha quando o pagamento for confirmado.
- A confirmação chega por webhook, o aviso automático do provedor. O sistema deve liberar o pedido assim que o aviso chega, sem exigir que o cliente clique em “já paguei”.
- O QR Code tem validade. A loja precisa definir o prazo e tratar pedidos com Pix expirado, liberando o estoque reservado.
Esses detalhes valem para os três modelos. No redirecionado e no link, o provedor cuida da tela; no transparente, a loja precisa desenhar a espera.
Cartão de crédito: parcelamento, autenticação e cartão salvo
O cartão segue relevante, sobretudo nas compras de valor maior e parceladas. Dados da Abecs publicados pelo Let’s Money mostram que as compras não presenciais com cartão somaram R$ 633 bilhões no primeiro semestre de 2026, alta de 18%.
Autenticação 3DS
O 3DS (EMV 3-D Secure) é o protocolo que permite ao banco emissor confirmar que quem está comprando é o dono do cartão. Segundo a EMVCo, entidade que mantém o padrão, em muitas transações o cliente apenas clica em comprar e o pagamento é aprovado, porque o banco analisa os dados enviados pela loja. Em transações de maior risco, o banco pode pedir uma verificação extra, como senha de uso único ou biometria.
Para o checkout, o 3DS é uma etapa que pode aparecer ou não. No modelo redirecionado, o provedor cuida disso. No transparente, a loja precisa exibir o desafio do banco quando ele vier, sem quebrar o fluxo. Em débito on-line, a autenticação costuma ser obrigatória: o manual da API E-commerce Cielo informa que todas as transações de débito devem ser autenticadas com EMV 3DS 2.2, por exigência dos emissores e das bandeiras.
Cartão salvo
Guardar o cartão para a próxima compra reduz etapas e abandono em clientes recorrentes. Isso é feito por tokenização: o provedor guarda o cartão e devolve um código (token) que a loja usa nas próximas cobranças. O número real nunca fica no sistema da empresa. Esse recurso é mais simples no checkout transparente e nas assinaturas.
Segurança e PCI DSS: o que muda em cada modelo
O PCI DSS é o padrão de segurança exigido pelas bandeiras de cartão de qualquer empresa que aceite cartão. O tamanho da obrigação depende de como o cartão é capturado.
Segundo a guia de segurança de integração da Stripe, uma empresa que recebe o número do cartão nos próprios servidores pode precisar cumprir mais de 300 controles de segurança, com software dedicado e auditoria externa anual. Quem usa as integrações de baixo risco do provedor, em que o cartão vai direto ao provedor, reduz bastante essas obrigações.
O formulário de autoavaliação mais simples do PCI DSS é o SAQ A. Segundo a documentação da Adyen sobre elegibilidade ao SAQ A, a versão atualizada entrou em vigor em 31 de março de 2025 e retirou do SAQ A dois requisitos sobre scripts da página de pagamento. Em troca, a empresa precisa confirmar que todos os elementos da página de pagamento vêm diretamente de um provedor em conformidade com o PCI DSS e que o site está protegido contra ataques por scripts.
Na prática, isso significa:
| Modelo | Situação típica de segurança |
|---|---|
| Link de pagamento | Cartão digitado na página do provedor; obrigação da loja é a menor |
| Checkout redirecionado | Cartão digitado na página do provedor; loja protege o site e o redirecionamento |
| Transparente com campos seguros do provedor | Cartão capturado por componente do provedor; loja precisa controlar os scripts da página |
| Transparente com captura própria do cartão | Cartão passa pelo servidor da loja; obrigações do PCI DSS são muito maiores |
A validação exata depende do provedor e do adquirente. O enquadramento deve ser confirmado com eles e, quando for o caso, com um auditor qualificado. O guia de segurança no desenvolvimento com o OWASP Top 10 cobre as falhas web que mais aparecem em páginas de pagamento.
Modelos intermediários: o melhor dos dois lados
A fronteira entre transparente e redirecionado ficou menos rígida. Os provedores oferecem opções intermediárias:
- formulário embutido: a página de pagamento do provedor aparece dentro do site da loja, numa moldura;
- componentes prontos: blocos de pagamento, como os Bricks do Mercado Pago e o Payment Element da Stripe, que a loja posiciona e estiliza dentro do próprio checkout;
- checkout em aplicativo: kits de desenvolvimento para iOS e Android que exibem o pagamento dentro do app.
A documentação da Stripe recomenda a API de sessões de checkout para a maioria das integrações e alerta que construir o fluxo do zero exige reimplementar descontos, impostos, frete e assinaturas no código da loja. Esse alerta vale para qualquer provedor: quanto mais o checkout é construído do zero, mais código a empresa terá de manter.

Quando usar cada modelo
Use checkout redirecionado quando
- a loja está começando e precisa vender logo;
- não há equipe técnica para manter a integração de pagamento;
- a marca ainda é pouco conhecida e o selo do provedor ajuda a passar confiança;
- o volume ainda não justifica o investimento num checkout próprio.
Use checkout transparente quando
- o volume de vendas torna relevante cada ponto de conversão;
- há clientes recorrentes que se beneficiam de cartão salvo;
- a loja precisa de regras próprias, como frete calculado na mesma tela, cupons e assinaturas;
- a empresa quer poder trocar de provedor sem mudar a experiência do cliente.
Use link de pagamento quando
- a venda acontece em conversa, pelo WhatsApp, por telefone ou com um vendedor;
- a cobrança é avulsa, como sinal de reserva, orçamento aprovado ou serviço prestado;
- a empresa não tem loja virtual ou precisa cobrar algo que não está no catálogo.
O link de pagamento combina bem com automação de atendimento. O guia de WhatsApp Business API para automação mostra como gerar e enviar cobranças dentro da conversa.
Roteiro para escolher o checkout
Os passos abaixo ajudam a sair da discussão genérica e chegar a uma decisão para o seu caso.
- Meça o funil atual: quantos carrinhos chegam ao pagamento e quantos concluem a compra.
- Identifique onde o cliente desiste: no frete, no cadastro, na escolha do meio de pagamento ou na recusa do cartão.
- Liste os meios de pagamento que precisam estar no checkout, com Pix e cartão parcelado como base.
- Avalie a equipe disponível para manter a integração e responder a incidentes.
- Confirme com o provedor qual será o enquadramento no PCI DSS em cada modelo.
- Comece pelo modelo mais simples que resolva o problema principal e evolua com base nos números.
- Mantenha a integração isolada num módulo próprio, para mudar de modelo ou de provedor sem refazer a loja.
O artigo sobre como medir o ROI de projetos de tecnologia ajuda a calcular se o ganho de conversão paga o investimento num checkout próprio.
Quanto custa integrar cada modelo
O custo varia com o provedor, os meios de pagamento e o estado do sistema atual. A tabela traz a estimativa de referência da Mind Group para integrar cada modelo a uma loja ou sistema web já existente.
| Modelo de checkout | Horas estimadas | Faixa em reais |
|---|---|---|
| Link de pagamento gerado pelo sistema, com baixa automática | 20 a 60 | R$ 2,2 mil a R$ 11,4 mil |
| Checkout redirecionado com retorno à loja e webhooks | 40 a 100 | R$ 4,4 mil a R$ 19 mil |
| Checkout transparente com Pix, cartão e boleto, usando campos seguros do provedor | 120 a 280 | R$ 13,2 mil a R$ 53,2 mil |
| Adicional de 3DS, cartão salvo e regras antifraude no transparente | 60 a 140 | R$ 6,6 mil a R$ 26,6 mil |
| Checkout dentro de aplicativo iOS e Android | 80 a 200 | R$ 8,8 mil a R$ 38 mil |
Metodologia: estimativa de referência da Mind Group para 2026, calculada como horas estimadas × valor-hora de R$ 110 a R$ 190, conforme a senioridade do time. O piso usa o menor número de horas a R$ 110, e o teto usa o maior número de horas a R$ 190. O valor final depende do escopo, do provedor e do sistema atual. Não inclui as tarifas do provedor de pagamento.
Quando a loja ou o aplicativo ainda não existem, o checkout faz parte de um projeto maior. Os artigos sobre quanto custa desenvolver um sistema web e quanto custa desenvolver um app para iOS e Android detalham essas faixas. A escolha do provedor em si é tratada no comparativo de gateways de pagamento no Brasil.
Erros que derrubam a conversão em qualquer modelo
Alguns problemas aparecem tanto no checkout transparente quanto no redirecionado:
- mostrar o frete só na última etapa, quando a Baymard aponta custos extras como o principal motivo de abandono;
- exigir criação de conta antes do pagamento, citado por 18% dos compradores na pesquisa da Baymard;
- tratar recusa de cartão sem oferecer outra forma de pagamento na mesma tela;
- deixar a página de Pix parada, sem atualizar quando o pagamento é confirmado;
- carregar scripts de terceiros desnecessários na página de pagamento, o que pesa na velocidade e na segurança.
Como a Mind Group pode ajudar
A Mind Group é uma software house brasileira, fundada em 2016, que desenvolve sistemas, aplicativos e soluções de inteligência artificial sob medida para empresas de todo o Brasil. Tem mais de 60 desenvolvedores próprios, mais de 500 produtos digitais lançados, nota 5,0 no Clutch com 17 avaliações verificadas de clientes, entrega o código-fonte ao cliente e mantém uma frente de cibersegurança dedicada à correção de vulnerabilidades e à resposta a incidentes.
A Mind não vende checkout nem processa pagamentos. O trabalho é desenvolver e integrar o checkout escolhido, transparente, redirecionado ou por link, ao sistema, à loja ou ao aplicativo da empresa, usando o provedor que ela contratar. A frente de cibersegurança revisa scripts da página de pagamento, validação de webhooks e proteção de credenciais, pontos que afetam o enquadramento no PCI DSS.
As entregas são quinzenais, com versão para testar, e o código-fonte fica com a empresa. A página de desenvolvimento de sistemas explica como a Mind conduz projetos sob medida.
Atualizado em novembro de 2026.
Perguntas frequentes
O que é checkout transparente?
É o modelo em que o cliente paga dentro do site ou do aplicativo da loja, sem ser levado a outra página. Por trás, o sistema da loja usa a API do provedor de pagamento. Hoje, a maioria dos provedores oferece campos seguros que capturam o cartão sem que ele passe pelos servidores da loja.
Checkout transparente converte mais que o redirecionado?
Não há dado público que comprove isso de forma geral. Os estudos da Baymard mostram que número de etapas, confiança, formas de pagamento e erros pesam mais no abandono. Um checkout transparente bem desenhado tende a reduzir etapas, mas um redirecionado de provedor conhecido pode passar mais confiança a clientes novos.
Qual é a taxa média de abandono de carrinho?
A Baymard Institute calcula média de 70,22%, com base em 50 estudos, na versão atualizada em setembro de 2025. Parte do abandono vem de pessoas que estavam só pesquisando, mas custos extras, checkout complicado e falta de confiança também aparecem entre os motivos.
Link de pagamento é seguro?
Quando gerado por um provedor de pagamento confiável, o cliente digita os dados numa página do próprio provedor, o que reduz a exposição da empresa. O risco maior é de golpe: criminosos podem enviar links falsos em nome da loja. Por isso, vale usar domínio reconhecível e orientar o cliente a conferir o recebedor antes de pagar.
Preciso de certificação PCI DSS para ter checkout transparente?
Toda empresa que aceita cartão precisa cumprir o PCI DSS em algum grau. Com campos seguros do provedor, o escopo é bem menor do que quando o servidor da loja recebe o número do cartão. O enquadramento exato deve ser confirmado com o provedor e o adquirente.
Dá para usar mais de um modelo ao mesmo tempo?
Sim, e é comum. Uma loja pode ter checkout transparente no site, link de pagamento para vendas pelo WhatsApp e checkout redirecionado como alternativa em caso de falha. O importante é que todos alimentem o mesmo sistema de pedidos e conciliação.
Quanto custa desenvolver um checkout transparente?
Pela estimativa de referência da Mind Group, a integração de checkout transparente com Pix, cartão e boleto a uma loja existente fica entre 120 e 280 horas, ou R$ 13,2 mil a R$ 53,2 mil. Recursos como 3DS, cartão salvo e regras antifraude somam de 60 a 140 horas.
Fontes: Cart Abandonment Rate Statistics (Baymard Institute) · Checkout UX Research (Baymard Institute) · Varejo enfrenta dilema entre barrar fraudes e perder clientes, com dados da Adyen (Finsiders) · Pix alcança 45% das compras online, segundo pesquisa da Visa (Let’s Money) · Pix chega a 38% das transações de e-commerce em 2025, segundo o Global Payments Report (Let’s Money) · Balanço da Abecs sobre cartões no 1º semestre de 2026 (Let’s Money) · Checkout Transparente (Mercado Pago Developers) · Checkout Pro (Mercado Pago Developers) · APIs PagBank · Online payments (Stripe Docs) · Pix payments (Stripe Docs) · Integration security guide (Stripe Docs) · SAQ A eligibility (Adyen Docs) · EMV 3-D Secure (EMVCo) · Manual da API E-commerce Cielo
