De dos cuentas Stripe a una entrega controlada

Antes de crear un proyecto, pregunta a Stripe si la operación puede mantener la cuenta existente mediante un cambio permitido de titularidad o si necesita una cuenta distinta. Migrar no es siempre la mejor opción. Una transferencia de control conserva los objetos y el historial, pero solo encaja cuando Stripe confirma que la entidad, el país, las obligaciones y la cuenta pueden permanecer unidos al negocio adquirido.

Si el comprador necesita su propia cuenta, asigna una persona administradora a cada lado, habilita autenticación en dos pasos y registra el identificador de la cuenta de destino. Elige una ventana sin cambios de precios, cupones, clientes o suscripciones. Para aprender el recorrido utiliza un proyecto Sandbox conectado a datos de prueba; reserva un proyecto Live para el corte real.

Crea claves restringidas distintas para origen y destino. La clave de origen suele necesitar lectura de los objetos incluidos; la de destino necesita los permisos de escritura correspondientes a las funciones elegidas. MoveMRR valida modo, cuenta y capacidades antes de guardar la configuración. No reutilices la clave de migración en la aplicación del SaaS y revócala al terminar el periodo de observación.

Las credenciales de prueba y las de producción no son intercambiables. Una validación correcta demuestra que la clave responde y dispone de los permisos comprobados, no que la cuenta esté jurídicamente autorizada para la operación ni que todos los métodos de pago puedan copiarse. Conserva los secretos únicamente en el gestor previsto y nunca en hojas de cálculo, incidencias o mensajes.

Stripe puede copiar clientes aptos y determinados métodos de pago guardados entre cuentas. Su documentación aclara que no copia suscripciones, facturas, planes, cupones, eventos ni registros. Concilia el resultado real: comprueba clientes de destino, métodos predeterminados y una lista separada de métodos no admitidos o ausentes. No des por hecho que toda la población podrá renovarse sin intervención.

Después mapea los objetos específicos de la cuenta. Cada producto y precio de origen debe apuntar a un objeto de destino con el mismo significado comercial: importe, moneda, intervalo, cantidad, tratamiento fiscal y comportamiento de cobro. Añade reglas para cupones, pruebas, múltiples partidas, calendarios y metadatos. Un identificador parecido no demuestra equivalencia.

La configuración decide cómo se reproducen fechas de facturación, fin de prueba, método de cobro, metadatos y estado de origen. Revisa la siguiente fecha de cargo y el periodo ya pagado, no solo `billing_cycle_anchor`. Define también qué pasará con suscripciones vencidas, impagadas, anuales o muy próximas a renovar.

Ejecuta una simulación sin escritura contra el último estado conocido. El informe debe comparar recuentos, mapeos, fechas, importes y acciones previstas. Un ensayo satisfactorio reduce incertidumbre, pero no garantiza una autorización bancaria futura. El pase a producción requiere una aprobación explícita de comprador y vendedor y condiciones de no ejecución claramente documentadas.

En el momento acordado, congela cambios, vuelve a validar la instantánea final y crea o programa las suscripciones de destino. Verifica su configuración antes de completar la desactivación prevista en origen. La frontera debe asignar cada periodo de renovación a una sola cuenta; crear en destino sin controlar el origen deja abierta la posibilidad de cobro duplicado.

El comprador despliega sus claves de cuenta, mapeos de clientes y suscripciones, endpoints de webhook y secretos de firma, enlaces del portal y reglas de acceso. Después concilia cada fila y vigila las primeras cohortes de renovación. Un estado `active` no prueba por sí solo que la factura se haya pagado ni que la aplicación haya concedido el acceso correcto.