Cómo redirigir después de un pago de Stripe a un panel de control restringido con Webflow Cloud

La mayoría de las configuraciones de Stripe Checkout en un sitio de marketing terminan en el recibo. El cliente paga, Stripe lo envía a una URL de éxito y esa URL es una página estática que cualquiera puede marcar y compartir.

La parte que hace que la compra se sienta como un producto (un panel que se abre tras el pago y rechaza a los visitantes sin una cookie válida) necesita código que se ejecute en un servidor: algo tiene que confirmar con Stripe que esta sesión se ha pagado antes de conceder el acceso.

Webflow Cloud ejecuta ese código de servidor. La compilación es una aplicación de Next.js montada bajo tu sitio de Webflow que abre un panel solo después de que Stripe confirme el cargo. Tus páginas de marketing permanecen en el Designer; el botón de compra es un enlace sencillo a la aplicación.

¿Qué necesitas para restringir un panel de control tras un pago de Stripe en Webflow?

Necesitas un entorno de Webflow Cloud compatible, configuraciones actuales de Next.js y Node.js, credenciales de producto de Stripe y un secreto robusto para firmar cookies. Webflow Cloud está disponible desde el plan de sitio Starter gratuito en adelante, y montar una aplicación en un dominio personalizado requiere el plan Premium o superior.

Reúne los requisitos de plataforma, aplicación, pago y firma antes de crear las rutas de Checkout.

Prepara los siguientes requisitos previos:

• Entorno de Webflow Cloud: Utiliza un sitio y un entorno compatibles. Webflow Cloud se ejecuta en Cloudflare Workers; el plan Starter funciona, mientras que el montaje en dominios personalizados requiere Premium o superior.
• Aplicación Next.js: Usa una aplicación de Next.js 15 con el App Router y fija la versión principal. Next.js 16 desaconseja middleware.ts y lo renombra a proxy.ts; la documentación de Next.js dice que "usa el entorno de ejecución de Node.js por defecto" y que "la opción de configuración no está disponible en archivos Proxy", por lo que no puede optar por Edge. Webflow Cloud solo ejecuta middleware de entorno Edge, así que en la versión 16, el filtro del panel de control en el paso 4 deja de funcionar. Astro y Vite también se pueden desplegar, pero esta implementación utiliza Next.js.
• Node.js y npm: Instala una versión actual compatible de Node.js con npm. La documentación de Webflow Cloud enumera a npm como el único gestor de paquetes compatible.
• Cuenta de Stripe y Precio: Crea un producto y un precio en Stripe, y obtén la clave secreta correspondiente. Usa el modo de prueba mientras validas el flujo.
• Secreto para firmar cookies: Genera una cadena larga y aleatoria para firmar la cookie de miembro y protégela exactamente igual que la clave secreta de Stripe.

Estos requisitos previos proporcionan a la aplicación un entorno de ejecución compatible, un precio de Stripe vendible y los secretos necesarios para emitir un acceso verificable.

5 pasos para restringir un panel de control tras un pago de Stripe en Webflow Cloud

Este flujo crea el Checkout en el servidor, valida la sesión devuelta por Stripe, firma una cookie con ámbito, la aplica en el borde (edge) y conecta la aplicación desplegada a Webflow.

Construye el flujo de pago y acceso en el siguiente orden.

1. Instala el SDK de Stripe y configura las variables de entorno de Webflow Cloud

Antes de que la primera ruta llegue al repositorio, el destino de despliegue ya debería contener todos los secretos. En tu proyecto de Next.js, ejecuta npm install stripe.

Mantén las variables de entorno en el destino de despliegue desde el primer commit; tanto las variables secretas como las que no lo son están disponibles para el proceso de compilación y para la aplicación desplegada en tiempo de ejecución, y como los secretos se ocultan en los registros de compilación, no hay razón para almacenarlos en ningún otro lugar.

Añade los valores necesarios como variables de entorno para el entorno de Webflow Cloud en el que realizas el despliegue, y guarda los datos confidenciales como secretos.

Añade estos valores de entorno:

• STRIPE_SECRET_KEY: Usa la clave secreta de Stripe para el modo actual. Márcala como secreta para que nunca aparezca en el registro de compilación.
• STRIPE_PRICE_ID: Establece el price_... identificador del producto. Mantenerlo aquí te permite cambiar el precio sin editar el código, aunque el nuevo valor solo llegará a la aplicación después de un despliegue.
• MEMBER_COOKIE_SECRET: Guarda la cadena aleatoria que firma y verifica la cookie de miembro. Si la cambias, cerrarás la sesión de todos los miembros inmediatamente.
• NEXT_PUBLIC_BASE_PATH: Establece la ruta de montaje de la aplicación, como /app. Webflow Cloud genera la configuración basePath del framework, pero no crea esta variable; debes añadirla tú mismo y las URLs construidas manualmente la leerán.

NEXT_PUBLIC_BASE_PATH no es secreta a propósito, ya que el prefijo NEXT_PUBLIC_ la expone al código del navegador. Nunca pongas una clave de Stripe, el secreto de una cookie u otra credencial en una variable con ese prefijo.

Añade los mismos valores a un archivo .env.local local para el desarrollo, con la clave de Stripe en modo de prueba. Tras guardar y volver a desplegar, process.env.STRIPE_SECRET_KEY se resuelve dentro de un Route Handler en la aplicación desplegada, y la importación del SDK de Stripe se compila sin necesidad de añadir directivas de tiempo de ejecución a ningún archivo.

2. Crea la sesión de Stripe Checkout desde un Route Handler

Crea un Route Handler GET que genere la sesión de Stripe Checkout y apunte su success_url a la ruta de retorno de la aplicación. Stripe reemplazará el marcador de posición {CHECKOUT_SESSION_ID} en success_url con el ID de sesión real cuando redirija al cliente.

La sesión de Checkout creada por el servidor apunta esa URL a la ruta de montaje de la aplicación, proporcionando a la ruta de retorno una sesión para verificar. El manejador responde GET a propósito: el botón de compra en la página de Webflow será un enlace normal, y un enlace no puede realizar un POST sin código personalizado.

Crea el controlador enapp/api/checkout/route.ts

// app/api/checkout/route.ts
import Stripe from 'stripe';
import { NextResponse } from 'next/server';

export async function GET(request: Request) {
  const stripeSecretKey = process.env.STRIPE_SECRET_KEY!;
  const stripe = new Stripe(stripeSecretKey);
  const origin = new URL(request.url).origin;
  const base = process.env.NEXT_PUBLIC_BASE_PATH ?? '';

  const session = await stripe.checkout.sessions.create({
    mode: 'payment',
    customer_creation: 'always',
    line_items: [{ price: process.env.STRIPE_PRICE_ID!, quantity: 1 }],
    success_url: `${origin}${base}/api/checkout/return?session_id={CHECKOUT_SESSION_ID}`,
    cancel_url: `${origin}/pricing`,
  });

  return NextResponse.redirect(session.url!, 303);
}

No se necesita ninguna anulación de httpClient . La versión actual de stripe-node incluye condiciones de exportación worker y workerd , por lo que un paquete de Workers ya se resuelve con el cliente basado en fetch y el proveedor SubtleCrypto; pasarlos explícitamente es un vestigio de versiones anteriores.

La verificación de webhooks es el único lugar donde el tiempo de ejecución sigue siendo visible, porque SubtleCrypto es asíncrono y constructEvent no lo es. El manejador deriva el origin de la solicitud entrante, por lo que la URL de retorno generada sigue el origen que sirve la solicitud sin necesidad de edición.

Esta ruta de pago no está autenticada a propósito y no tiene límites de velocidad ni control contra abusos en la creación de sesiones. Crea sesiones de Checkout, y un atacante podría generar solicitudes y consumir recursos del servicio.

Añade autenticación o un límite de velocidad a nivel de aplicación antes de usarla en un despliegue de mayor riesgo. No se utiliza protección CSRF porque la ruta no actúa con una sesión de navegador autenticada existente, y el estado OAuth no es aplicable porque no hay un flujo OAuth.

Al acceder a /app/api/checkout en un navegador con tu ruta de montaje real, se te redirigirá a una página de Checkout alojada en Stripe que muestra tu producto y precio.

3. Verifica la sesión pagada y establece una cookie de miembro firmada

Crea el asistente de cookies compartidas y la ruta de retorno para que obtengan la sesión de Checkout desde Stripe e inspeccionen su payment_status. Tanto los flujos de pago abandonados como los completados generan IDs de sesión. Solo un valor de pago debería activar una cookie.

La cookie en sí es una carga útil base64url más una firma HMAC-SHA256, generada con Web Crypto para que el mismo código se ejecute en un Route Handler, en el middleware y en local.next dev

El asistente que comparten ambas rutas se encuentra en:lib/member-cookie.ts

// lib/member-cookie.ts
const encoder = new TextEncoder();
const decoder = new TextDecoder();

export type MemberClaims = { customerId: string; exp: number };

function toBase64Url(bytes: ArrayBuffer | Uint8Array): string {
  const view = bytes instanceof Uint8Array ? bytes : new Uint8Array(bytes);
  let binary = '';
  for (const b of view) binary += String.fromCharCode(b);
  return btoa(binary).replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '');
}

function fromBase64Url(value: string): Uint8Array {
  const standard = value.replace(/-/g, '+').replace(/_/g, '/');
  const padded = standard.padEnd(standard.length + ((4 - (standard.length % 4)) % 4), '=');
  return Uint8Array.from(atob(padded), (c) => c.charCodeAt(0));
}

async function hmacKey(secret: string, usage: 'sign' | 'verify') {
  return crypto.subtle.importKey(
    'raw',
    encoder.encode(secret),
    { name: 'HMAC', hash: 'SHA-256' },
    false,
    [usage],
  );
}

export async function signMemberCookie(claims: MemberClaims, secret: string): Promise<string> {
  const body = toBase64Url(encoder.encode(JSON.stringify(claims)));
  const key = await hmacKey(secret, 'sign');
  const signature = await crypto.subtle.sign('HMAC', key, encoder.encode(body));
  return `${body}.${toBase64Url(signature)}`;
}

export async function verifyMemberCookie(
  value: string | undefined,
  secret: string,
): Promise<MemberClaims | null> {
  if (!value) return null;

  try {
    const [body, signature] = value.split('.');
    if (!body || !signature) return null;

    const key = await hmacKey(secret, 'verify');
    const valid = await crypto.subtle.verify(
      'HMAC',
      key,
      fromBase64Url(signature),
      encoder.encode(body),
    );
    if (!valid) return null;

    const claims = JSON.parse(decoder.decode(fromBase64Url(body))) as MemberClaims;
    return claims.exp > Date.now() ? claims : null;
  } catch {
    return null;
  }
}

La verificación utiliza , que compara firmas sin necesidad de una comparación manual de bytes.crypto.subtle.verify

Esa elección resuelve la brecha de tiempo de ejecución: es una extensión de Cloudflare que existe en el entorno de ejecución de Workers desplegado, pero no en el local . Por lo tanto, una comparación de tiempo constante hecha a mano funciona en producción y falla en tu portátil, o viceversa. Dejar que Web Crypto realice la comparación evita este problema.crypto.subtle.timingSafeEqualnext dev

Crea el controlador de retorno en:app/api/checkout/return/route.ts

// app/api/checkout/return/route.ts
import Stripe from 'stripe';
import { NextResponse } from 'next/server';
import { signMemberCookie } from '@/lib/member-cookie';

const THIRTY_DAYS_SECONDS = 60 * 60 * 24 * 30;

export async function GET(request: Request) {
  const stripeSecretKey = process.env.STRIPE_SECRET_KEY!;
  const stripe = new Stripe(stripeSecretKey);
  const url = new URL(request.url);
  const base = process.env.NEXT_PUBLIC_BASE_PATH ?? '';
  const sessionId = url.searchParams.get('session_id');

  if (!sessionId) {
    return NextResponse.redirect(`${url.origin}/pricing`, 303);
  }

  const session = await stripe.checkout.sessions.retrieve(sessionId);
  if (session.payment_status !== 'paid') {
    return NextResponse.redirect(`${url.origin}/pricing?status=unpaid`, 303);
  }

  const customerId =
    typeof session.customer === 'string' ? session.customer : session.customer?.id ?? 'unknown';

  const cookie = await signMemberCookie(
    { customerId, exp: Date.now() + THIRTY_DAYS_SECONDS * 1000 },
    process.env.MEMBER_COOKIE_SECRET!,
  );

  const response = NextResponse.redirect(`${url.origin}${base}/dashboard`, 303);
  response.cookies.set('member', cookie, {
    httpOnly: true,
    secure: true,
    sameSite: 'lax',
    path: base || '/',
    maxAge: THIRTY_DAYS_SECONDS,
  });
  return response;
}

Añade un límite de tasa a nivel de aplicación a la ruta de retorno antes de usarla en un despliegue de mayor riesgo. Los tokens CSRF no solucionan la reutilización del ID del portador y el estado de OAuth no es aplicable. El acceso de alto valor o específico de una cuenta requiere autenticación del comprador, un registro de compra esperada, un solo canje y revocación mediante webhook.

Las llamadas fetch del lado del cliente deben incluir manualmente la ruta base de Webflow Cloud. Aquí, la redirección apunta al panel de control dentro de la aplicación montada, por lo que la URL ensamblada en el Route Handler incluye esa ruta; un simple podría, en cambio, apuntar a la ruta del sitio. Limitar el de la cookie a la ruta de montaje evita que aparezca en cada solicitud de página de marketing./dashboard/dashboardpath

Completar un pago de prueba ahora establece una cookie y redirige a , que aún no existe y devuelve un 404. Ese 404 es la prueba de que la ruta de retorno funcionó: revisa el almacenamiento de cookies del navegador para ver antes de continuar. El panel de control y su protección llegan en el paso 4.member/app/dashboardmember

4. Protege la ruta del panel de control con middleware.ts en el entorno de ejecución edge

Crea en la raíz del proyecto para proteger la ruta del panel de control. Ese nombre de archivo y ubicación son una convención de archivos de Next.js, no una regla de Webflow; la única restricción de Webflow Cloud aquí es el entorno de ejecución.middleware.ts

El middleware se ejecuta en el entorno Edge por defecto y no necesita una exportación . Solo el middleware del entorno Edge funciona en el entorno de ejecución de Workers; el middleware del entorno Node.js no es compatible.runtime

Protege el panel de control en un solo archivo en la raíz del proyecto:

// middleware.ts
import { NextResponse, type NextRequest } from 'next/server';
import { verifyMemberCookie } from '@/lib/member-cookie';

export async function middleware(request: NextRequest) {
  const member = await verifyMemberCookie(
    request.cookies.get('member')?.value,
    process.env.MEMBER_COOKIE_SECRET!,
  );

  if (member) return NextResponse.next();

  const base = process.env.NEXT_PUBLIC_BASE_PATH ?? '';
  const pricing = new URL(`/pricing?next=${encodeURIComponent(`${base}/dashboard`)}`, request.url);
  return NextResponse.redirect(pricing, 303);
}

export const config = {
  matcher: ['/dashboard/:path*'],
};

El comparador apunta a la ruta del panel de control dentro de la aplicación. La redirección para un visitante anónimo va a la página de precios de Webflow y lleva un parámetro que tu botón de compra puede ignorar o aceptar más adelante.next

La página del panel de control vuelve a leer la cookie y deniega el acceso si la verificación falla, por lo que una futura refactorización que mueva o evite el middleware no expondrá el identificador del cliente:

// app/dashboard/page.tsx
import { cookies } from 'next/headers';
import { verifyMemberCookie } from '@/lib/member-cookie';

export default async function Dashboard() {
  const store = await cookies();
  const member = await verifyMemberCookie(
    store.get('member')?.value,
    process.env.MEMBER_COOKIE_SECRET!,
  );

  if (!member) {
    return (
      <main>
        <h1>Access denied</h1>
        <p>A valid member cookie is required.</p>
      </main>
    );
  }

  return (
    <main>
      <h1>Your dashboard</h1>
      <p>Signed in as Stripe customer {member.customerId}</p>
    </main>
  );
}

Tanto el middleware como las comprobaciones de página realizan una verificación HMAC y evitan que una edición del comparador exponga silenciosamente el identificador del cliente. Un pago exitoso y una solicitud en ventana privada confirman ambos comportamientos.

5. Vincula el botón de compra de Webflow a la aplicación y despliega

Configura el botón en el Designer como un enlace simple a después de sustituir tu ruta de montaje. La página de marketing no requiere ni un embed ni una etiqueta de script de Stripe. El Designer sigue siendo dueño del diseño mientras que la aplicación es dueña de la transacción./app/api/checkout

Publica el sitio de Webflow y luego despliega la aplicación en el entorno de Webflow Cloud que contiene las variables requeridas. Antes del despliegue, confirma que la ruta base configurada coincida exactamente con la ruta de montaje de la aplicación.

Ejecuta estas comprobaciones de despliegue:

• Haz clic en Comprar en la página publicada: En el modo de prueba de Stripe, usa una tarjeta de prueba estándar y confirma que Checkout muestra tu producto y precio.
• Completa el pago de prueba: Confirma que Stripe redirige brevemente a /app/api/checkout/return?session_id=cs_test_... antes de que la ruta de retorno verifique el pago y emita la cookie.
• Llega al panel de control: Verifica que la URL sea /app/dashboard y que la página muestre un cus_... ID de cliente de Stripe.
• Abre el panel de control en una ventana privada: Sin la cookie, confirma que la solicitud redirige a /pricing y que el contenido protegido permanece oculto.

Ahora deberías tener un botón de compra publicado que completa el proceso de pago, emite una cookie firmada, abre el panel de control y rechaza el acceso desde un navegador privado si no tiene dicha cookie.

¿Qué hace que la redirección de Stripe falle en Webflow Cloud?

Los fallos suelen deberse a una directiva de tiempo de ejecución no compatible, una puerta de middleware faltante, una ruta de montaje incorrecta o una cookie que la solicitud del panel de control no puede enviar o verificar. Empieza comparando el entorno desplegado, las URL generadas por Stripe, el archivo de middleware y la cookie del navegador con estos síntomas.

El despliegue en Webflow Cloud falla con un error de tiempo de ejecución no compatible

Causa: Esto aparece después de añadir export const runtime = 'edge' a un manejador de rutas. La palabra "edge" significa dos cosas distintas en la documentación de Webflow Cloud, y la misma página usa ambas. Webflow Cloud ejecuta tu aplicación en Cloudflare Workers, que es una plataforma edge.

El objetivo de tiempo de ejecución de Next.js edge , configurado con export const runtime = 'edge', es independiente, y el adaptador OpenNext de Cloudflare que utiliza Webflow Cloud no lo admite. La página bring-your-own-app todavía te indica que añadas la directiva a las rutas de la API, por lo que un desarrollador que sigue la documentación al pie de la letra termina enviando una compilación rota.

Solución: Elimina todas las líneas export const runtime = 'edge' de los manejadores de rutas y páginas, vuelve a desplegar y deja que el adaptador coloque el código. Si una ruta sigue fallando tras la eliminación, busca runtime en los archivos layout.tsx del repositorio, ya que una directiva en un diseño puede aplicarse a las rutas que contiene.

Cualquiera puede abrir /app/dashboard sin una cookie

Causa: Un posible desencadenante es renombrar un archivo de middleware.ts a proxy.ts, a menudo mediante un codemod o una guía de actualización. Las versiones más recientes de Next.js introducen proxy.ts como sucesor de middleware.ts. En Webflow Cloud, solo el middleware de tiempo de ejecución Edge funciona en el entorno de ejecución de Workers, y proxy se ejecuta en el entorno de ejecución de Node sin posibilidad de optar por Edge.

Como resultado, proxy.ts no puede proporcionar la puerta de middleware en Webflow Cloud. Un segundo desencadenante es una página del panel de control que muestra datos protegidos después de que la verificación de la cookie devuelve un valor nulo.

Solución: Renombra el archivo de nuevo a middleware.ts en la raíz del proyecto y mantén la función exportada con el nombre middleware. Mantén la comprobación de nulos a nivel de página para que el componente también falle de forma segura.

Tras volver a desplegar, abre el panel de control en una ventana privada y confirma que redirige a la página de precios. La comprobación de la página evita que se muestre contenido protegido si se omite el middleware.

Stripe devuelve al cliente a la ruta incorrecta de tu dominio después del pago

Causa: El success_url que recibió Stripe omitió la ruta de montaje, o el NEXT_PUBLIC_BASE_PATH en el entorno desplegado difiere de donde está montada la aplicación. El success_url en este flujo apunta a una ruta de retorno dentro de la aplicación montada, por lo que debe construirse con NEXT_PUBLIC_BASE_PATH.

Stripe redirige exactamente a la URL que se le proporcionó, por lo que si falta /app , el cliente es enviado fuera de la ruta de retorno de la aplicación montada. El pago ya se ha procesado en este punto, lo que hace que la redirección incorrecta sea especialmente molesta.

Solución: Abre el panel de control de Stripe, busca la sesión de pago y lee su success_url. Compáralo con la URL a la que responde realmente la ruta de retorno. Establece NEXT_PUBLIC_BASE_PATH en la ruta de montaje exacta con una barra inclinada al principio y sin barra al final, vuelve a desplegar y crea una sesión nueva; las sesiones existentes conservan su URL antigua.

No envíes a los clientes identificadores de sesión sin procesar ni abras manualmente sus sesiones a través de una ruta de retorno no autenticada; recupera el acceso mediante un proceso de soporte autenticado que verifique al comprador y la compra.

El pago se realiza correctamente, pero el panel de control redirige inmediatamente a la página de precios

Causa: La cookie se configuró en la respuesta de retorno y el middleware no la leyó. En Webflow Cloud, las posibles razones son una que no cubre el panel de control, como cuando la ruta real es , un diferente en el entorno donde se ejecuta el middleware que el que firmó la cookie, o en una ejecución local, donde el navegador no almacena la cookie.pathpath: '/dashboard'/app/dashboardMEMBER_COOKIE_SECRETsecure: truehttp://localhost

Otra causa aparece si alguien reemplazó por : esa extensión de Cloudflare existe en el entorno de ejecución de Workers desplegado pero no bajo local, por lo que la verificación falla en un lugar y pasa en el otro.crypto.subtle.verifycrypto.subtle.timingSafeEqualnext dev

Solución: Abre las herramientas de desarrollo del navegador, ve a la pestaña Aplicación e inspecciona la cookie en la solicitud del panel de control. Si no está presente, verifica los encabezados de respuesta en la ruta de retorno para y corrige el a la ruta de montaje.Set-Cookiepath

Si está presente pero la redirección sigue ocurriendo, el secreto difiere entre el firmante y el verificador; establece el mismo valor en cada entorno y vuelve a desplegar ambos. Para pruebas locales, mantén y ejecuta contra , o limita en .secure: truehttpssecureprocess.env.NODE_ENV === 'production'

Lo que puede construir a continuación con Stripe y Webflow

Tus clientes de pago necesitan que el panel de control se abra tan pronto como Stripe confirme el cargo, y esta compilación lo permite en ese momento. La producción puede ampliar este panel con controles de acceso vinculados al comprador y acceso basado en roles una vez que se implemente un proveedor de identidad real.

Explora la integración con Stripe para conectar Stripe y Webflow.

Para una personalización más profunda más allá de lo que maneja de forma nativa la redirección de Checkout, la documentación para desarrolladores de Webflow cubre las variables de entorno y los límites de la plataforma, incluido el tiempo de espera de solicitud fijo de 20 segundos y los 30 segundos de CPU de Worker que se aplican en cada plan.