Separa los dos usos de Stripe
La facturación de las suscripciones a Reylin no es la conexión de analítica de clientes. Una cuenta comercial compartida puede contener servicios ajenos. Elige un alcance de productos seleccionados, o elige explícitamente la analítica de toda la cuenta solo si toda ella corresponde a ese proyecto. Ningún metadato del cliente puede determinar la elegibilidad de un producto.
La política de lanzamiento exclusiva para el propietario no es facturable y actualmente solo permite analítica de clientes en modo de prueba. La recogida en producción sigue requiriendo aceptación y autorización separadas.
Lista de comprobación de la conexión
- Usa un espacio de trabajo de propietario verificado y un origen de sitio aprobado, no la demo sintética compartida.
- Confirma la cuenta del proveedor y el modo de prueba o producción con credenciales autorizadas antes de guardar una conexión.
- Elige el alcance inmutable de productos del proyecto antes de incorporar pagos. Cambiarlo requiere un proyecto separado, no reescribir cobros antiguos.
- Configura el endpoint exacto del webhook y el secreto de firma mediante un flujo seguro y aprobado de credenciales. Nunca pegues claves en una guía, artículo, consola del navegador o chat.
- Confirma la verificación de firma sobre el cuerpo sin procesar y la entrega; después, comprueba por separado el éxito del pago y el de la atribución.
Decisiones para productos seleccionados
Las líneas de Checkout o la asignación canónica de pagos de facturas proporcionan pruebas autorizadas del producto. Cada línea incluida debe poder resolverse y pertenecer al conjunto de productos elegido. Un pago totalmente ajeno se excluye; las pruebas mixtas, ambiguas, ausentes o no admitidas se ponen en cuarentena. No se inventa una distribución proporcional de ingresos.
El importe del cobro sigue siendo el importe pagado confirmado por el proveedor, incluidos los pagos de facturas con descuentos o parciales admitidos. No se sustituye por una suma de líneas. Las comprobaciones de pruebas incluyen cuenta, modo, identidad y moneda.
Reembolsos e ingresos recurrentes
La elegibilidad del pago aceptado queda fijada. La eliminación posterior de un producto no invalida un reembolso parcial válido. Un reembolso anterior al pago puede conservar la decisión verificada del pago principal sin restar cobros netos hasta que llegue dicho pago. Solo el estado de reembolso completado resta dinero.
El descubrimiento y la actualización de suscripciones aplican la misma política de productos. El MRR contractual es bruto, antes de descuentos e impuestos, y está separado por moneda; no es una previsión de caja ni un modelo completo de facturación escalonada o por consumo. Los estados no admitidos u obsoletos no se cuentan como ingresos válidos.
Límites históricos y aceptación en producción
La recuperación limitada de eventos del proveedor no puede recrear visitantes que nunca se rastrearon, y el historial disponible del proveedor es finito. Los eventos excluidos hacen avanzar la cobertura del importador sin contarse como pagos importados. Las pruebas sin resolver siguen pendientes.
Las pruebas sintéticas locales cubren eventos duplicados, exclusiones por alcance, productos mixtos, reembolsos parciales, renovaciones por factura y aislamiento de monedas. No demuestran permisos reales de claves restringidas, aceptación de la versión de API, entrega de webhooks ni recuperación operativa. Completa estas comprobaciones antes de conectar datos de producción.
Esta documentación describe el código y sus límites; no confirma una conexión activa. Los ejemplos técnicos mantienen sus identificadores originales.