Skip to main content

Criar um fluxo de checkout da Stripe

Entregue ao Devin uma especificação de checkout com suas chaves de sandbox da Stripe e obtenha um fluxo de pagamento funcional — página de preços, sessão de checkout, handler de webhook e página de confirmação — validado no navegador.
AuthorCognition
CategoryDesenvolvimento de funcionalidades
1

(Opcional) Defina o escopo da base de código com o Ask Devin

Se você não tiver certeza de como seu app lida com pagamentos hoje — ou de quais arquivos e padrões você deve referenciar na sua spec — use o Ask Devin para investigar primeiro:Use as respostas para preencher sua spec — faça referência a arquivos específicos, nomes de tabelas e padrões, para que o Devin construa algo que se integre naturalmente à sua base de código. Você também pode iniciar uma sessão do Devin diretamente pelo Ask Devin, e ele levará tudo o que aprendeu como contexto.
2

Adicionar chaves de teste da Stripe

Devin precisa de chaves do Stripe em modo de teste para criar sessões de checkout e verificar o manipulador de webhook. Sempre use credenciais de sandbox — nunca forneça chaves do Stripe de produção para o Devin.A abordagem mais simples é armazená-las como segredos da organização antes de iniciar a sessão:
  1. Vá para Settings > Secrets e adicione:
  2. Devin acessa esses valores como variáveis de ambiente, portanto eles nunca ficam gravados diretamente no seu código-fonte.
Os segredos da organização devem ser adicionados antes de iniciar a sessão — eles são injetados no início da sessão. Alternativamente, você pode fornecer segredos durante a sessão usando o chat, e o Devin também solicitará proativamente qualquer credencial de que precisar quando encontrar variáveis de ambiente ausentes.
3

Entregue sua especificação de checkout

Cole sua especificação — de um PRD, um ticket do Linear ou uma mensagem detalhada no Slack — diretamente no Devin. Uma boa especificação de checkout cobre os planos de preços, o fluxo de pagamento e o que acontece após um pagamento bem-sucedido. Quanto mais estruturada, melhor.Uma boa especificação para o Devin inclui três coisas: o que construir (planos de preços, fluxo de checkout, handler de webhook), onde isso fica (rotas, tabelas, arquivos) e como isso se encaixa (padrões existentes a seguir). Você não precisa especificar todos os detalhes de implementação — o Devin investiga sua base de código para preencher as lacunas.
4

Devin constrói e valida no navegador

Devin lê sua especificação, explora a base de código em busca de padrões correspondentes e então implementa na stack completa. Antes de abrir um PR, ele executa seu app localmente e abre seu navegador integrado para verificar se o fluxo de checkout funciona de ponta a ponta.Veja como isso funciona no exemplo de checkout da Stripe:
  1. Cria a migração — Adiciona a tabela subscriptions com colunas para user_id, stripe_subscription_id, plan, status e current_period_end
  2. Constrói a página de preços — Cria os cards de preço em três níveis em /pricing, cada um com um botão “Subscribe” que faz POST para a API de checkout
  3. Implementa a criação da sessão de checkout — Implementa POST /api/checkout/sessions, que cria uma sessão do Stripe Checkout com o ID de preço correto, e-mail do cliente e URLs de redirecionamento
  4. Adiciona o handler de webhook — Implementa POST /api/webhooks/stripe com verificação de assinatura, tratamento do evento checkout.session.completed e atualizações no banco de dados
  5. Constrói a página de sucesso — Cria /checkout/success, que busca a sessão do Stripe, exibe o nome do plano, o valor cobrado e um link “Go to Dashboard”
  6. Escreve testes — Testes para verificação de assinatura do webhook (válida, inválida, ausente), criação de sessão de checkout e lógica de atualização de plano no banco de dados
  7. Abre o navegador — Inicia o servidor de desenvolvimento, navega até /pricing, clica em “Subscribe” no plano Pro, verifica se o redirecionamento do Stripe Checkout funciona e checa se a página de sucesso renderiza corretamente após um pagamento de teste
  8. Abre um PR — Entrega todas as alterações com um resumo do que foi implementado e como foi verificado
A etapa de verificação no navegador captura problemas que testes de unidade não cobrem — um card de preços que não dispara o checkout, uma URL de redirecionamento que retorna 404 ou uma página de sucesso que falha ao carregar os detalhes da sessão. Se você definiu uma skill de testes local, Devin segue essas etapas automaticamente para cada funcionalidade que implementa.
5

Iterar com base no PR

Depois que o PR for aberto, envie prompts de acompanhamento na mesma sessão para estender ou ajustar o fluxo de checkout.
6

Revise o PR com o Devin Review

Assim que o Devin abrir a PR, use o Devin Review para revisar as alterações. O Devin Review tem contexto completo da sua base de código e consegue identificar bugs, problemas de segurança e inconsistências de estilo no diff. Você pode fazer perguntas adicionais no chat de revisão — por exemplo, “O handler do webhook valida o tipo de evento antes de processar?” — e o Devin responderá com base no código real.