> ## Documentation Index > Fetch the complete documentation index at: https://docs.cakto.com.br/llms.txt > Use this file to discover all available pages before exploring further. # Redirect pós-pagamento > Leve o comprador de volta ao seu sistema depois da aprovação, com um identificador daquela compra na URL. ## Por que isso existe A **Página de Obrigado** resolve "para onde o comprador vai depois de pagar". Ela não resolve "**qual** compra é esta": a URL é a mesma para todo mundo, então o seu sistema recebe a visita sem saber a qual sessão ela pertence. O redirect pós-pagamento resolve esse segundo problema. Você cadastra a URL **uma vez, no produto**, com um espaço reservado; em cada link de checkout você manda um identificador seu; e o comprador volta para a URL já com aquele identificador no lugar. ``` seu sistema Cakto seu sistema │ │ │ 1. cria a sessão e um token │ │ 2. manda o comprador para │ │ pay.cakto.com.br/?callback= │ │ ──────────────▶ │ │ pagamento aprovado │ │ │ │ │ tela de aprovação (5s) │ │ │ │ │ └──────────────────────▶│ │ https://seusite.com/cb/│ │ │ │◀─────────── webhook purchase_approved, com "callback": "" ─┘ ``` > [!NOTE] > > O **token é seu**. A Cakto não o interpreta e não o valida — ela grava o valor no pedido e o > devolve, na URL do redirect e no webhook. Quem decide o que ele significa é o seu sistema. > [!WARNING] > > **Não ponha dado pessoal no token.** Ele é gravado no pedido, aparece na URL do navegador do > comprador, viaja no `Referer` para o seu servidor e fica no payload do webhook. Use um > identificador opaco — um id de sessão, um UUID —, nunca e-mail, CPF ou nome. O charset aceito > (letras, números e `. _ ~ -`) já torna endereço de e-mail inválido, mas a regra vale para > qualquer dado que identifique uma pessoa. ## Como configurar No painel, em **Produto → Configurações → Checkout**, no campo **Redirecionar após o pagamento**: ``` https://seusite.com.br/sistema/{{callback}} ``` > [!WARNING] > > `{{callback}}` é **substituído**, não acrescentado no fim. O trecho desaparece e o token entra no > lugar dele — então ele pode estar no caminho (`/sistema/{{callback}}`) ou na query > (`/sistema?token={{callback}}`), onde você precisar. > > Escreva exatamente `{{callback}}`. Variações como `{{parametro}}`, `{callback}` ou > `{{ callback }}` são **recusadas ao salvar**: elas passariam despercebidas e virariam uma URL que > nunca recebe o token. Regras do campo: | Regra | Valor | | - | - | | Protocolo | `https` obrigatório — o token viaja na URL | | Formato | URL absoluta, com domínio, sem usuário ou senha embutidos | | Tamanho | até 2048 caracteres | | Placeholder | `{{callback}}`, no máximo uma vez (opcional) | ## Como mandar o token Acrescente `?callback=` ao link do checkout: ``` https://pay.cakto.com.br/32f9yzc?callback=8f31c9e7 ``` O token aceita letras, números e `. _ ~ -`, até 255 caracteres. Um valor fora desse conjunto é **descartado** — o que estiver fora dele (barras, `@`, espaços) poderia reescrever o caminho do destino, e por isso não passa. > [!NOTE] > > **Sem `?callback=` no link, não há redirecionamento.** Se o seu template tem `{{callback}}` e a > compra chegou sem token, o comprador fica na tela de aprovação normal. É deliberado: mandá-lo > para `https://seusite.com.br/sistema/` sem identificador levaria o seu sistema a uma visita que > ele não tem como associar a nada. > > Se você quiser um destino fixo, cadastre a URL **sem** o placeholder — aí o redirect acontece > sempre. ## O que o comprador vê A tela de aprovação continua aparecendo. Depois dela, uma contagem de **5 segundos** e um botão **Ir agora** para quem não quiser esperar. > [!WARNING] > > **Produto com upsell tem precedência.** Se o produto tem uma página de upsell configurada, o > comprador vai para o upsell e o redirect pós-pagamento não roda. Os dois disputam o mesmo momento, > e o upsell vem primeiro. ## Não dependa só do redirect O redirect acontece **no navegador do comprador**. Ele não acontece se a aba for fechada antes dos 5 segundos, nem se o Pix for pago em outro aparelho — casos normais, não falhas. Por isso o mesmo token é entregue no **webhook**, que é servidor a servidor e independe do navegador. Todo evento de pedido traz o campo `callback`: ```json theme={null} { "event": "purchase_approved", "data": { "refId": "4852F91", "status": "paid", "callback": "8f31c9e7", "checkoutUrl": "https://pay.cakto.com.br/32f9yzc?callback=8f31c9e7" } } ``` > [!TIP] > > A divisão que funciona: o **webhook** confirma a compra e libera o acesso; o **redirect** devolve > a pessoa à tela certa. Se você tratar o redirect como confirmação de pagamento, vai perder as > compras em que ele não acontece — e vai confiar num sinal que vem pelo navegador. > > Ver [Guia de Webhooks](/conceitos/webhooks.md). ## Como pedir acesso > [!WARNING] > > O recurso é liberado **caso a caso, após análise do Compliance da Cakto**. Ele não aparece no > painel antes da liberação. Envie um e-mail para **`compliance@cakto.com.br`** com o assunto exato: ``` Post Payment Redirect - Liberar Acesso ``` No corpo, informe: **1. A URL que será utilizada** O endereço completo, no formato que você vai cadastrar, incluindo o `{{callback}}` se for usar — por exemplo `https://seusite.com.br/sistema/{{callback}}`. **2. Como o recurso será utilizado** O que o seu sistema faz quando o comprador chega nessa URL, e por que precisa do identificador da compra. > [!NOTE] > > **A URL precisa estar no ar e funcional no momento da análise.** A liberação é avaliada sobre um > endereço que responde, não sobre um que ainda será construído — o e-mail tem que apresentar uma > URL válida, e não apenas descrevê-la. ## Perguntas frequentes > **Posso usar um valor diferente por comprador?** > > Sim — é exatamente para isso. O token vai no link do checkout, então ele pode ser diferente a > cada visita. Gere um por sessão e guarde a associação do seu lado. > **Funciona com Pix e com cartão?** > > Com os dois, e também com as carteiras. A URL final é montada no servidor da Cakto a partir do > que foi gravado no pedido, e não a partir do endereço que está no navegador — por isso funciona > no Pix, que é aprovado por consulta, e no retorno das carteiras, que chega em outra URL. > **Posso ter uma URL diferente por oferta?** > > Não. O campo é **por produto**. Ofertas do mesmo produto compartilham a mesma URL — use o token > se precisar distinguir a origem. > **E se eu perder o acesso ao recurso?** > > O redirect deixa de acontecer na compra seguinte, e o valor cadastrado no produto é preservado. > O webhook continua entregando o `callback` normalmente. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.