Skip to main content
1

(Opcional) Delimita el alcance de la base de código con Ask Devin

Si no tienes claro cómo gestiona actualmente tu app los pagos, o qué archivos y patrones debes incluir en tu especificación, usa Ask Devin para investigar primero:Utiliza las respuestas para completar tu especificación; menciona archivos concretos, nombres de tablas y patrones para que Devin implemente algo que se integre de forma natural en tu base de código. También puedes iniciar una sesión de Devin directamente desde Ask Devin, y se conservará todo lo que haya aprendido como contexto.
2

Agregar claves de prueba de Stripe

Devin necesita claves de Stripe en modo de prueba para crear sesiones de checkout y verificar el controlador del webhook. Usa siempre credenciales de sandbox; nunca le des a Devin claves de Stripe de producción.El enfoque más sencillo es almacenarlas como secretos de organización antes de iniciar la sesión:
  1. Ve a Settings > Secrets y agrega:
  2. Devin accede a estas como variables de entorno, por lo que nunca terminan incluidas directamente en tu código fuente.
Los secretos de organización deben agregarse antes de iniciar la sesión; se inyectan al inicio de la sesión. Alternativamente, puedes proporcionar secretos durante la sesión usando el chat, y Devin también te pedirá de forma proactiva cualquier credencial que necesite cuando detecte variables de entorno faltantes.
3

Pasa tu especificación de checkout

Pega tu especificación — ya sea desde un PRD, un ticket de Linear o un mensaje detallado de Slack — directamente en Devin. Una buena especificación de checkout cubre los niveles de precios, el flujo de pago y lo que ocurre después de un pago exitoso. Cuanto más estructurada, mejor.A good spec for Devin includes three things: what to build (pricing tiers, checkout flow, webhook handler), where it lives (routes, tables, files), and how it fits in (existing patterns to follow). You don’t need to specify every implementation detail — Devin investigates your codebase to fill in the gaps.
4

Devin builds and verifies in the browser

Devin reads your spec, explores the codebase for matching patterns, then implements across the full stack. Before opening a PR, it runs your app locally and opens its built-in browser to verify the checkout flow works end-to-end.Here’s what that looks like for the Stripe checkout example:
  1. Creates the migration — Adds the subscriptions table with columns for user_id, stripe_subscription_id, plan, status, and current_period_end
  2. Builds the pricing page — Creates the three-tier pricing cards at /pricing, each with a “Subscribe” button that posts to the checkout API
  3. Implements checkout session creation — Builds POST /api/checkout/sessions that creates a Stripe Checkout session with the correct price ID, customer email, and redirect URLs
  4. Adds the webhook handler — Implements POST /api/webhooks/stripe with signature verification, checkout.session.completed event handling, and database updates
  5. Builds the success page — Creates /checkout/success that fetches the Stripe session, displays the plan name, amount charged, and a “Go to Dashboard” link
  6. Writes tests — Tests for webhook signature verification (valid, invalid, missing), checkout session creation, and the plan-update database logic
  7. Opens the browser — Starts the dev server, navigates to /pricing, clicks “Subscribe” on the Pro tier, verifies the Stripe Checkout redirect works, and checks that the success page renders correctly after a test payment
  8. Opens a PR — Delivers all changes with a summary of what was implemented and how it was verified
El paso de verificación en el navegador detecta problemas que las pruebas unitarias no cubren: una tarjeta de precios que no dispara el checkout, una URL de redirección que responde con 404 o una página de éxito que no logra cargar los detalles de la sesión. Si has definido una skill de pruebas locales, Devin sigue esos pasos automáticamente para cada funcionalidad que construye.
5

Iterate from the PR

Once the PR is open, send follow-up prompts in the same session to extend or adjust the checkout flow.
6

Review the PR with Devin Review

Once Devin opens the PR, use Devin Review to review the changes. Devin Review has full context of your codebase and can catch bugs, security issues, and style inconsistencies across the diff. You can ask follow-up questions in the review chat — for instance, “Does the webhook handler validate the event type before processing?” — and Devin will answer grounded in the actual code.