Comparar / Checkout

Checkout alojado vs construir o seu

Todo o comerciante que recebe online responde a isto uma vez: a página que recolhe os dados do cartão é sua ou do seu fornecedor? A resposta define o seu âmbito PCI, a rapidez com que adiciona um método de pagamento e quem é chamado quando chega uma imposição dos esquemas de cartões. É menos uma escolha de tecnologia do que uma decisão sobre em que a sua equipa deve gastar o ano.

Opção vs opção

Sete perguntas que decidem

Dimension
Checkout alojado
Checkout próprio
Âmbito PCI
Mínimo. A página que recolhe os dados do cartão é do fornecedor, por isso os seus servidores veem um token e nunca um número de cartão — normalmente a autoavaliação mais leve possível.
Seu. Tratar dados de cartão diretamente coloca os seus sistemas no âmbito, com o desenho, a avaliação e a recertificação anual que daí decorrem.
Tempo até ao primeiro pagamento
Dias. Cria uma encomenda, redireciona, trata um webhook — grande parte do trabalho é decidir o que acontece depois de o pagamento ser bem-sucedido.
Meses, e a cauda longa é a parte difícil: 3-D Secure, janelas de wallets, estados de erro, novas tentativas e os casos limite de cada método.
Adicionar um método de pagamento
Configuração. Os novos métodos chegam com a plataforma e ativam-se; a página adapta-se sem uma release do seu lado.
Um projeto de cada vez — integração, certificação, trabalho de UI e um compromisso permanente de manutenção por método.
Controlo da experiência
Elevado, mas limitado: marca, opções de layout, domínio próprio e campos embebidos quando precisa do pagamento dentro da sua página — dentro do que o fornecedor expõe.
Total. Se o seu checkout precisa de fazer algo verdadeiramente invulgar, não se aplicam restrições de ninguém.
Trabalho de conversão
Herdado. A ordenação dos métodos, a localização, o suporte a wallets e o comportamento de novas tentativas melhoram com a plataforma, sem que faça as experiências.
Conquista-se. Pode otimizar melhor do que uma página genérica para o seu funil específico — se tiver o tráfego e as pessoas para o fazer bem.
Manter-se atualizado
Problema do fornecedor. Imposições dos esquemas, alterações de SCA, atualizações de browsers e wallets chegam como atualizações da plataforma.
Uma linha permanente no seu roadmap, sem fim — o trabalho nunca acaba e raramente é priorizado até algo falhar.
Custo real
Economia por transação, visível e proporcional ao volume.
Salários de engenharia mais certificação, gastos antes do primeiro pagamento e todos os anos depois — normalmente subestimados por uma ordem de grandeza.
01

Quando o checkout alojado ganha

Para a maioria das empresas, na maior parte das vezes. Se os pagamentos são a forma de receber e não aquilo que vende, a página de checkout não é onde está a sua vantagem — e o custo de a ter é pago da forma menos visível: uma fatia permanente da capacidade de engenharia dedicada a imposições dos esquemas e integrações de métodos em vez de ao seu produto. Uma página alojada também resolve a questão PCI, o maior custo oculto de fazer por conta própria.

  1. 01Os pagamentos são um meio para a receita, não o produto
  2. 02Quer os dados de cartão fora do âmbito, e não só tratados com cuidado
  3. 03Os novos métodos devem chegar sem uma release do seu lado
  4. 04Os seus engenheiros valem mais naquilo que os clientes compram
02

Quando construir o seu ganha

Quando o checkout é mesmo o produto. Plataformas que processam para terceiros, empresas com um fluxo que nenhuma página alojada consegue exprimir, e equipas com um volume em que uma fração de ponto percentual de conversão pesa mais do que o salário de uma equipa de pagamentos — esses casos existem e justificam construir. Tal como uma posição regulatória que exija a superfície de tratamento de cartões dentro do seu perímetro. Abaixo dessa escala, construir costuma significar redescobrir, a custo elevado, por que existem os checkouts alojados.

  1. 01Os pagamentos são o produto — processa por conta de terceiros
  2. 02O volume é suficiente para a conversão marginal superar o custo de uma equipa
  3. 03Um regulador ou comité de risco exige a superfície no seu perímetro
  4. 04O seu fluxo é verdadeiramente invulgar e nenhuma página alojada o exprime
03

Onde entra a Protocore

O Protocore Gateway é a resposta alojada, com as saídas habituais incluídas e não vendidas à parte: execute a página no nosso domínio ou no seu, embuta os campos de pagamento no seu layout quando o fluxo o exigir, ou apresente o mesmo checkout nativamente na sua app. Cartões, wallets, transferência bancária e USDC numa só página, liquidados num único valor em euros com uma só referência de encomenda. E se a resposta honesta para si for a terceira opção — quer ser o fornecedor e não o comerciante — a mesma plataforma está disponível em whitelabel, o que costuma compensar mais do que construir um gateway de raiz.

  1. 01Página alojada, domínio próprio, campos embebidos ou in-app — a mesma integração
  2. 02Cartões, wallets, transferência e USDC numa só página, liquidados em EUR
  3. 03Uma só referência de encomenda, do checkout ao recibo e à linha do extrato
  4. 04Disponível em whitelabel quando quer ser o fornecedor, não o comerciante

Não sabe de que lado está?

Diga-nos o volume, os métodos e em que andam a trabalhar os seus engenheiros. Dizemos-lhe com franqueza o que a sua situação pede — incluindo quando é construir por conta própria.