La respuesta directa
Las suscripciones por uso requieren revisión manual porque crear la suscripción en destino no traslada automáticamente el consumo acumulado, los eventos del medidor, las ventanas de agregación ni el estado de informes de la aplicación. Relaciona la configuración recurrente, fija una frontera exacta, dirige los eventos nuevos al destino y concilia el uso de origen que aún deba facturarse.
Revisado el 24 de julio de 2026 por el equipo de producto de MoveMRR.
Cómo se comporta facturación stripe por consumo o uso durante la migración
MoveMRR puede inventariar y relacionar las dependencias recurrentes, pero la facturación por uso une Stripe con un flujo de eventos y una ventana de acumulación. La unidad segura incluye el último evento aceptado en origen, el primero en destino, el periodo, los conceptos pendientes y el comportamiento de reintento y eliminación de duplicados.
Qué debe comprobar la revisión de preparación
La compatibilidad se determina a partir de los objetos Stripe reales, no del título de una página. El proyecto debe mostrar cualquier correspondencia ausente, campo no admitido, estado ambiguo o requisito de destino antes de ejecutar con datos reales.
- La semántica del precio medido o del medidor coincide en origen y destino.
- Hay una marca temporal de cambio y un conmutador de enrutamiento definidos.
- El uso pendiente y los intervalos de factura tienen una regla de liquidación.
- Los identificadores de eventos y reintentos no pueden duplicar el consumo entre cuentas.
El principal fallo que hay que evitar
Enviar el mismo consumo a las dos cuentas duplica el cobro; no enviarlo a ninguna pierde ingresos. Copiar solo la suscripción deja una diferencia de conciliación oculta.
Facturación Stripe por consumo o uso: controles entre origen y destino
| Control | Prueba necesaria | Si no se cumple |
|---|---|---|
| Definición del medidor | Agregación y dimensiones coinciden | Rediseñar el medidor de destino |
| Frontera de cambio | Último evento de origen y primero de destino registrados | No activar en producción |
| Uso pendiente | Política de factura o traspaso aprobada | Mantener abierto el origen |
| Idempotencia | La repetición no duplica eventos | Añadir deduplicación por evento |
Un proceso controlado
- 1
Haz un inventario del origen
Captura estado, campos, objetos relacionados, fechas y configuración de cuenta.
- 2
Prepara las dependencias del destino
Crea o relaciona todo el catálogo, impuestos, descuentos y pagos necesarios.
- 3
Prueba ejemplos representativos
Incluye los registros difíciles, no solo el camino ideal.
- 4
Revisa las acciones previstas
Resuelve o excluye de forma explícita cada aviso antes de ejecutar.
- 5
Concilia tras la creación
Compara el destino con el estado aprobado y vigila el siguiente evento.
Límites que debes verificar antes de migrar
- No se presupone que los eventos acumulados se trasladen con la suscripción.
- Los flujos propios y almacenes de datos necesitan ingeniería del cliente.
- Las suscripciones con elementos fijos y medidos exigen revisión completa.
- Esta forma no debe aprobarse solo porque el catálogo tenga correspondencias.
Preguntas frecuentes
¿La migración traslada el consumo acumulado?
No debe presuponerse. Los eventos, la agregación y las facturas pendientes necesitan su propio plan de cambio y conciliación.
¿Puede recrearse la suscripción medida?
La configuración recurrente puede relacionarse si el modelo de precios de destino está listo, pero el flujo de uso se valida aparte.
¿Cómo evito cobrar dos veces el mismo uso?
Define una frontera exacta, cambia el enrutamiento de forma atómica, conserva los identificadores de los eventos y concilia los últimos periodos de ambas cuentas.