Stripe Checkout vs Billing Portal: qué hace cada uno en 2026

Stripe Checkout y el portal de clientes de Stripe Billing son dos páginas alojadas por Stripe que parten en dos un mismo trabajo. Checkout cobra el primer pago e inicia la suscripción. El portal de clientes deja que un cliente existente gestione esa suscripción después. No compiten. Son la puerta de entrada y la sala de control del mismo sistema de facturación, y la decisión que de verdad lía a los equipos es dónde trazar la línea entre ambos.

Si vendes una suscripción SaaS, necesitas los dos. Checkout es donde un desconocido se vuelve cliente que paga. El portal es donde ese cliente actualiza la tarjeta, descarga una factura, cambia de plan o cancela, sin escribir a tu bandeja de soporte. Conéctalos bien y la facturación se gestiona sola en los casos comunes. Conéctalos mal y acabas reconstruyendo piezas que Stripe ya te da gratis.

En breve: cuál usar

Usa Checkout al inicio de la relación: de la página de precios al pago, único o recurrente. Usa el portal de clientes para todo lo que viene tras el primer cobro: cambios de tarjeta, cambios de plan, facturas, cancelaciones. La mayoría de los productos SaaS llaman a Checkout una vez por alta y enlazan al portal desde un único botón "Gestionar facturación" en los ajustes de la cuenta.

Stripe Checkout y el portal de clientes de un vistazo

Dónde encaja Stripe Checkout

Checkout es una página de pago prehecha a la que envías a quien compra, o que incrustas en tu dominio, para cobrar el primer pago. Cubre tarjeta, wallets, impuestos, códigos promocionales y pruebas, y puede crear un cobro único o abrir una suscripción. Creas una Checkout Session de corta duración en el servidor, rediriges al cliente a su URL y Stripe gestiona la parte sensible para PCI.

Importan dos variantes. La versión alojada redirige a una página en stripe.com. La versión incrustada mantiene a quien compra en tu dominio. Ambas cobran al estándar 2,9% más 30 céntimos sin coste añadido, y los Payment Links, el hermano no-code, van con el mismo tarifario. Si tus precios son fijos y quieres cero código, los Payment Links llegan al mismo resultado. Si necesitas líneas de pedido dinámicas, las Checkout Session te dan el control. Comparamos las capas de billing en Stripe Billing vs RevenueCat.

Dónde encaja el portal de clientes

El portal de clientes es una página alojada por Stripe donde un cliente existente gestiona su propia facturación: actualiza el método de pago, ve y descarga facturas, cambia de plan, pausa y cancela. La cancelación está activa por defecto, y puedes recoger un motivo de cancelación o intentar retenerlo con un cupón de retención.

El detalle decisivo: el portal no autentica a nadie por ti. La guía de Stripe es autenticar primero al cliente en tu lado y luego crear una sesión del portal para su customer ID con un return_url. Esa sesión es una URL de corta duración. Caduca si no se usa, lo que impide que un cliente comparta un enlace que expone los controles de facturación. Pones un botón "Gestionar facturación" tras tu propio login, creas la sesión al hacer clic y rediriges.

También puedes saltarte el menú. Un flow es un deep link directo a una sola acción, por ejemplo la página de cancelación o la actualización del método de pago, con la navegación oculta, para que el cliente aterrice justo en la tarea a la que lo enviaste.

Lo que el portal, a propósito, no puede hacer

Aquí es donde la mayoría de los artículos de "usa ambos" se detiene, y es la parte que decide tu arquitectura. El portal es configuración, no código. Tienes la marca y una serie de interruptores en el Dashboard, y ese es el techo.

• Sin UI a medida. No puedes reestructurar las páginas ni meter tus propios componentes. Si tu flujo de cancelación necesita una encuesta a medida o una oferta de salvamento que el portal no expresa, lo construyes vía API.
• El cambio de plan se topa en 10 productos. Cuando dejas cambiar de plan en el portal, puedes exponer como máximo 10 productos. Un catálogo grande se queda corto.
• No adquiere clientes. En el portal no hay alta. Los clientes nuevos siempre pasan antes por Checkout.
• Presupone suscripciones estándar. Vistas previas de prorrateo complejas, presupuestos, add-ons o cambios de consumo medido más allá de lo básico suelen necesitar pantallas a medida sobre la API de Subscriptions.

La regla que usamos: deja que el portal se quede con el 80% estándar del autoservicio de facturación, y construye UI a medida solo para los casos que no puede expresar. Rehacer a mano el cambio de tarjeta o el histórico de facturas es trabajo tirado.

Cómo conectamos los dos

El patrón es el mismo en cada SaaS que enviamos. En el alta creas una Checkout Session, y te aseguras de que cree o reutilice un customer de Stripe, para que la suscripción se enganche a un ID estable. Guardas ese customer ID en el registro del usuario. A partir de ahí, un único botón "Gestionar facturación" en los ajustes de la cuenta crea una sesión del portal para ese ID y redirige.

Trata los webhooks de Stripe como fuente de verdad, no el redirect. Cuando un cliente cambia de plan o cancela en el portal, te enteras por customer.subscription.updated y customer.subscription.deleted, no por el navegador que vuelve a tu return_url. El return URL es un detalle de UX. El webhook es el cambio de estado, y salta aunque el cliente cierre la pestaña. Para el coste y los plazos completos de esta integración, mira Coste y plazos de la integración de Stripe.

Cómo se ve en la práctica

Un cliente en tu plan de 29 dólares quiere el de 99 a mitad de ciclo. Abre el portal desde los ajustes de la cuenta, elige el plan más alto y confirma. Stripe prorratea la diferencia, la cobra y dispara customer.subscription.updated. Tu manejador de webhooks lee el nuevo price ID, actualiza el plan en tu base de datos y desbloquea las funciones de 99 dólares. De esa pantalla de facturación no escribiste nada. Escribiste una rama de webhook.

La cancelación va igual. El cliente cancela en el portal, Stripe puede mostrarle antes un cupón de retención y, al confirmar, recibes customer.subscription.deleted, o un update con cancel_at_period_end puesto. Bajas el acceso en ese evento, no cuando el navegador vuelve. Si el cliente nunca aterriza de nuevo en tu return_url, tu estado sigue siendo correcto.

Hecho así, Checkout y el portal cubren todo el ciclo de vida de la suscripción con dos páginas alojadas y un manejador de webhooks. Escribes casi nada de UI de facturación, y lo que sí escribes es justo lo que Stripe dejó abierto a propósito.