Documentación de Rivya AI

Guía de pago y checkout en Rivya

Entiende el checkout de planes y packs de credits en Rivya, redirecciones de Stripe, el puente /payment, webhooks, actualizaciones de facturación y comprobaciones de compra.

Última revisión el 2026/04/28

Usa esta guía de pago y checkout cuando necesites entender qué ocurre después de comprar un plan o un pack de credits en Rivya.

Lo que la gente suele malinterpretar sobre el pago en Rivya es esto:

Que Stripe complete el pago no es el último paso. El producto todavía tiene que ponerse al día y reflejar correctamente ese cambio.

Por eso el flujo de checkout no termina en Stripe, y tampoco termina en el momento en que el navegador vuelve.

El flujo de pago tiene tres etapas reales

Ahora mismo, el checkout es más fácil de entender si lo separas en tres etapas:

  1. Rivya crea la sesión de checkout
  2. el usuario completa Stripe Checkout
  3. Rivya espera a que el estado del producto vuelva a ser confiable

Esa tercera etapa es exactamente la razón por la que existe /payment.

Dónde puede empezar el checkout

El checkout empieza actualmente desde lugares que ya coinciden con la intención del usuario:

  • Precios
  • /settings/billing
  • /settings/credits

Y las dos formas principales de compra son:

  • checkout de plan de suscripción
  • checkout de pack de credits de una sola vez

Son decisiones comerciales distintas, pero convergen en la misma ruta de confirmación.

Checkout de plan y checkout de pack de credits son parecidos, pero no iguales

El checkout de plan tiene forma de suscripción.

El checkout de pack de credits tiene forma de recarga única de wallet.

Esa diferencia importa porque, después del pago, Rivya necesita saber si debe refrescar:

  • el estado de la suscripción
  • o el estado de la wallet

Por eso el mismo momento de éxito en Stripe puede enviarte después de vuelta a superficies de producto distintas.

Por qué existe /payment

/payment no es una página de recibo en el sentido habitual.

Es un puente de procesamiento.

Su trabajo es:

  • leer el session_id de Stripe
  • comprobar si el registro de pago del lado del producto ya se asentó
  • seguir consultando durante un periodo corto si es necesario
  • solo entonces redirigirte de vuelta a la parte correcta de la app

Eso la hace más parecida a una página de sincronización de estado que a una página de contenido.

Cuándo está "realmente hecho" un pago desde la perspectiva del producto

Desde el punto de vista del usuario, el pago parece completo cuando Stripe dice que funcionó.

Desde el punto de vista del producto, el pago solo está realmente completo cuando el estado de la cuenta se ve actualizado en Rivya.

Eso normalmente significa:

  • el registro de pago está marcado como paid o completed
  • los efectos de suscripción o wallet son visibles
  • puedes volver con seguridad a facturación o credits sin ver un estado obsoleto

Esta es la razón real por la que el producto espera en /payment en lugar de devolver inmediatamente al usuario a la app.

Por qué los webhooks siguen importando aunque /payment haga polling

/payment no reemplaza los webhooks de Stripe.

Los webhooks siguen siendo lo que actualiza el estado backend duradero.

La página /payment existe para que la experiencia pueda esperar hasta que ese estado esté reflejado lo suficiente como para confiar en él antes de redirigir.

Esa es la diferencia entre:

  • "Stripe procesó algo"
  • y "Rivya ahora refleja claramente ese cambio"

A dónde vas después del pago

La ruta de regreso está atada intencionalmente a lo que cambió.

Si la compra estaba relacionada con una suscripción, generalmente se te devuelve hacia billing.

Si la compra fue un pack de credits, generalmente se te devuelve hacia credits.

No es una ruta cosmética. Coincide con la pregunta que los usuarios suelen tener justo después de pagar:

  • ¿se actualizó mi plan?
  • ¿o se actualizó mi wallet?

Qué significa realmente un timeout o fallo

Si /payment agota el tiempo o falla, eso no significa automáticamente que el pago desapareció.

Más a menudo significa una de estas cosas:

  • el registro de pago del lado del producto aún no se asentó
  • la redirección está esperando un estado que todavía se está poniendo al día
  • la página de cuenta aún se vería obsoleta si se redirigiera al usuario demasiado pronto

Por eso un estado de timeout es mejor que un falso estado de éxito. Le dice al usuario que la confirmación del producto es la parte que sigue incompleta.

La mejor forma de comprobar si el pago llegó realmente

Después del checkout, la ruta de verificación más limpia es:

  1. deja que /payment termine su flujo
  2. revisa /settings/billing si la compra fue un plan
  3. revisa /settings/credits si la compra fue un pack
  4. revisa Centro de notificaciones si la cuenta todavía parece desincronizada

Esto suele ser mejor que refrescar páginas al azar y adivinar.

El pago también se convierte en memoria de cuenta

El pago no es solo una acción de checkout. También se vuelve parte del historial de cuenta mediante eventos duraderos como:

  • suscripción iniciada
  • suscripción renovada
  • pago fallido
  • paquete de credits añadido

Por eso las notificaciones también importan aquí. Cerrar la pestaña de Stripe no es el final de la historia de la cuenta.

Un modelo mental mejor

La forma más simple de pensar en el checkout de Rivya es:

  • Stripe maneja el movimiento de dinero
  • /payment maneja el reingreso del lado del producto

Si mantienes separados esos dos roles, todo el flujo se vuelve más fácil de razonar.

Leer a continuación

Lista de revisión del estado de checkout

Cuando una compra parezca incompleta o confusa, comprueba:

  • Confirma dónde empezó Checkout: precios públicos, configuración de billing o configuración de credits.
  • Comprueba si Stripe completó el pago y devolvió al usuario a /payment.
  • Espera a que Rivya refresque suscripción, pack, invoice y estado de wallet antes de iniciar otra tarea pagada.
  • Usa páginas de billing para suscripciones y páginas de credits para packs o historial de wallet.
  • No trates una redirección del navegador como prueba de que webhook y estado de cuenta ya se asentaron.

Revisa antes de reintentar el pago

Revisa antes de reintentar si el usuario ve un plan obsoleto, credits faltantes, ventanas de Checkout duplicadas, pago fallido o un recibo exitoso de Stripe que todavía no se refleja en Rivya.

Tabla de contenido