La respuesta directa
El comprador de un SaaS debe tratar la facturación Stripe como una línea de trabajo del cierre, con criterios de aceptación explícitos. Antes de que el vendedor desactive nada, necesita comprobar clientes y suscripciones en destino, obtener todas las correspondencias de identificadores, desplegar cambios de webhooks y base de datos, asignar excepciones, conciliar resultados y preparar la vigilancia del primer ciclo de renovación.
Revisado el 24 de julio de 2026 por el equipo de producto de MoveMRR.
Incluye la aceptación de cobros en la lista de cierre
El acuerdo debe indicar qué clientes y suscripciones se transfieren, qué cuenta será autoritativa, quién solicita la copia de datos, cómo se tratan las altas durante el cambio y qué pruebas permiten al vendedor desactivar las suscripciones antiguas.
Exige control operativo, no solo cifras iguales
El mismo número de suscripciones puede ocultar precios, fechas, descuentos, métodos, impuestos, metadatos o identificadores incorrectos. La aceptación debe muestrear las formas de facturación reales y probar que los eventos del destino actualizan permisos e informes.
- Valida fecha, importe, divisa, estado, cantidad, descuentos e impuestos.
- Actualiza los identificadores guardados de clientes, productos, precios y suscripciones.
- Rota los secretos de webhook y confirma un procesamiento idempotente.
- Vigila las primeras renovaciones y los cobros fallidos en destino.
Mantén un responsable de excepciones tras el cierre
Métodos ausentes, precios heredados, renovaciones cercanas, impagos y desajustes de aplicación requieren responsables y plazos. El acuerdo debe aclarar qué resuelve vendedor, comprador o proveedor.
Pruebas de aceptación para el comprador
| Control | Prueba débil | Prueba sólida |
|---|---|---|
| Alcance | Un total de suscripciones | Inventario firmado con identificadores antiguos y nuevos |
| Continuidad | Las suscripciones existen | Fechas, importes, métodos, descuentos y estados concilian |
| Aplicación | El código se desplegó | La prueba webhook-permiso funciona en destino |
| Cierre en origen | El vendedor dice que terminó | Solo lo aceptado tiene el estado acordado |
Un proceso controlado
- 1
Define la aceptación
Adjunta alcance, correspondencias, renovaciones, pruebas y responsables al plan.
- 2
Revisa la preparación del destino
Comprueba cuenta, catálogo, clientes y webhooks.
- 3
Aprueba el ensayo
Revisa cada acción y excepción antes de cambiar cobros reales.
- 4
Acepta el destino
Concilia objetos y prueba la aplicación con eventos de la cuenta nueva.
- 5
Vigila el primer ciclo
Sigue fallos de pago, permisos, soporte y contabilidad.
Límites que debes verificar antes de migrar
- MoveMRR no sustituye la diligencia legal, fiscal, financiera, de privacidad ni de código.
- Facturas, eventos y registros históricos siguen separados de los objetos nuevos.
- Stripe controla qué datos de pago se pueden copiar.
- El comprador debe desplegar y validar sus propios cambios de aplicación.
Preguntas frecuentes
¿Qué debe recibir el comprador después de migrar Stripe?
Como mínimo: alcance firmado, correspondencias de objetos, excepciones, resultados de origen y destino, auditoría, registro de cambios de la aplicación, plan de vigilancia y responsables.
¿Se deben cancelar las suscripciones antiguas antes de probar?
No. Primero deben validarse las suscripciones y el comportamiento de la aplicación en destino; después puede autorizarse la desactivación configurada.
¿Se puede trasladar intacto todo el historial de Stripe?
No. La copia de clientes y la recreación de suscripciones no clonan facturas, eventos, registros, disputas y liquidaciones. Su conservación exige un plan aparte.