Por que tantas lojas Shopify Brasil usam dois apps de cotação de frete (e como resolver isso)

Se você opera uma loja Shopify Brasil há mais de seis meses, provavelmente já passou por isso: tem um app para mostrar frete na Página de Produto e outro app para devolver as tarifas no checkout. Duas instalações, duas configurações, duas faturas.

Quem chega novo na operação acha estranho. Quem já está há um tempo já desistiu de achar estranho — porque parece que é simplesmente assim que funciona na Shopify Brasil.

Não é. Mas dá pra entender por que virou padrão.

Como o stack de dois apps virou comum

Os apps de cotação de frete brasileiros se dividem em dois grupos:

Grupo “PDP-first”: nasceram para resolver o widget de frete na Página de Produto e no carrinho. Fazem isso bem. Não cobrem checkout porque a Shopify exige Carrier Service (CCS) homologado para entregar tarifas oficiais ao checkout, e esses apps não têm essa homologação.

Grupo “checkout-first”: nasceram com Carrier Service homologado e entregam frete no checkout. Mas não tinham — ou tinham mal — o widget na PDP, porque foi uma adição posterior, fora da arquitetura original.

O resultado natural: lojista que queria cotação antes do checkout (para reduzir abandono) instalava um app do grupo “PDP-first”. Lojista que queria tarifa no checkout instalava um do grupo “checkout-first”. Quando ele queria as duas coisas, instalava os dois.

Não era preguiça nem ignorância. Era a forma viável de cobrir os dois pontos.

O custo escondido de manter dois apps

Quem só configurou uma vez não vê o problema. Quem opera no dia a dia, vê.

Duas configurações em paralelo

Você cadastra origem de envio em dois lugares. Cadastra dimensões e regras em dois lugares. Quando muda CEP de origem (mudou o galpão, contratou um centro de distribuição), atualiza em dois lugares — e quase sempre esquece um dos dois. O cliente percebe primeiro.

Dois pontos de falha

Cada app tem sua própria estabilidade de API, seu próprio tempo de resposta, seu próprio histórico de incidentes. Se o app de PDP cai, o cliente vê “frete indisponível” e desiste. Se o app de checkout cai, o cliente chega até o fim do funil e abandona. A probabilidade de um dos dois falhar é maior do que a probabilidade de cada um isoladamente.

Duas faturas, dois suportes

Você paga dois aplicativos. Quando algo dá errado, abre ticket no que parece o culpado — e às vezes os dois tickets vão de Pôncio Pilatos a Heródes, cada um apontando para o outro.

Inconsistência no que o cliente vê

E o pior: a tarifa que aparece na Página de Produto não é, necessariamente, a mesma que aparece no checkout. Cada app cota a sua maneira. Quando diverge — e diverge — o cliente desconfia.

Por que isso não é um problema técnico inevitável

Não há limitação técnica que justifique manter os dois pontos separados. Carrier Service homologado é uma chancela da Shopify; widget de PDP é HTML+JS+API que qualquer app pode implementar. Os dois cabem no mesmo aplicativo.

O que faltava era um app que tivesse os dois bem feitos:

• Carrier Service homologado para cobrir o checkout
• Widget de PDP e carrinho de qualidade, com cache, validação de CEP, mensagens customizáveis
• Mesma fonte de tarifa para os três pontos — para que o cliente veja o mesmo valor da PDP ao pagamento

O que olhar quando avaliar um app único

Se você está com dois apps hoje e considera consolidar, alguns critérios práticos:

1. Carrier Service homologado pela Shopify. Sem isso, o app não entrega no checkout. Confira no admin: em Configurações → Envio e entrega, o app precisa aparecer na lista de tarifas com a etiqueta “Tarifas fornecidas pelo app”.

2. Widget na PDP e no carrinho — não só no checkout. Apps que prometem “extensão de PDP” mas entregam algo travado, sem mensagens customizáveis ou sem validação de CEP, voltam ao mesmo problema do stack duplicado.

3. Mesma tarifa nos três pontos. Pergunte explicitamente: o número que aparece na PDP é o mesmo que aparece no checkout? Se a resposta for evasiva, é porque não é.

4. Suporte direto, em português, da equipe que desenvolve o app. Saiba quem responde quando algo der errado. Apps com atendimento terceirizado tendem a ter respostas genéricas para problemas específicos.

5. BYOC sem amarração. Você usa o contrato que negociou com a transportadora — o app é só o canal técnico, não negocia tarifa em seu nome nem cobra por pedido cotado.

6. Cache automático e monitoramento. O que acontece se a API da transportadora cair em horário de pico? Apps maduros têm cache que segura cotações recentes e monitoramento ativo que alerta quando alguma transportadora começa a falhar.

Por que escrevemos sobre isso

Não é objetivo de blog post. O Cota Frete nasceu exatamente desse problema.

Um dos sócios operava uma loja Shopify específica com esse stack duplicado — um app na PDP/carrinho, outro no checkout. Os dois davam dor. Quando o app do checkout caía, ele ficava sabendo pelo cliente. Quando precisava ajustar dimensão de produto, era em dois lugares. Quando subiu o volume e precisou negociar contrato com transportadora, descobriu que cada app tratava o contrato de um jeito diferente.

A decisão foi parar de aceitar isso como inevitável e construir um app único que resolvesse os três pontos do funil — PDP, carrinho e checkout — com Carrier Service homologado, contrato próprio do lojista e suporte direto em português.

Se você está nesse stack hoje e quer testar o Cota Frete, o plano Starter é gratuito com Correios. Instale pela Shopify App Store ou fale com a gente se quiser entender melhor antes.

Resumo

• O stack “dois apps de cotação” virou comum porque os apps brasileiros se especializaram em PDP ou em checkout, raramente nos dois.
• O custo é invisível para quem só configurou uma vez, mas alto para quem opera: duas configurações em paralelo, dois pontos de falha, faturas separadas, tarifa potencialmente inconsistente.
• Não há razão técnica para manter os dois separados — só razão histórica de mercado.
• Ao avaliar um app único, conferir os 6 critérios acima evita trocar um stack ruim por outro stack ruim.

Última atualização: maio de 2026