La migración no termina al crear las suscripciones de destino

Busca cada lugar donde el producto guarda o utiliza un identificador Stripe: cuenta, cliente, suscripción, producto, precio, método de pago, factura, calendario, cupón, portal o Connect si corresponde. Incluye bases de datos, variables de entorno, tareas programadas, paneles internos, soporte y almacenes analíticos.

Después, haz un inventario del comportamiento: creación y actualización de clientes, altas, cambios de plan, cancelaciones, facturas, gestión de impagos, impuestos, portal de clientes y concesión de acceso. Asigna un responsable y una prueba a cada integración. No dependas solo de una búsqueda textual; algunos identificadores pueden estar en datos o configuraciones externas.

Según la documentación de Stripe, la copia de clientes puede conservar actualmente el identificador del objeto Customer, mientras que los métodos de pago cambian de identificador. Las nuevas suscripciones siempre tienen identificadores de destino. No extrapoles una regla de un tipo de objeto a otro ni codifiques un supuesto sin conciliar el resultado real.

Crea una tabla que relacione origen y destino y conserve estado, hora, lote y excepción. Asegura unicidad y cobertura: una fila de origen no debería apuntar accidentalmente a dos destinos ni quedar sin clasificación. Las decisiones sobre clientes compartidos necesitan una regla explícita.

Prueba consultas, actualizaciones y permisos con los identificadores de destino antes del corte. Mantén el mapa del modo de prueba separado del de producción, porque los objetos de ambos modos son diferentes.

Las claves usadas para la migración no deben convertirse en las claves permanentes de la aplicación. Crea credenciales de producción específicas para el comprador, con alcance apropiado, almacén de secretos, propietarios y rotación. Elimina del código, registros y procesos cualquier secreto del vendedor.

Despliega mediante un cambio controlado y verificable. Comprueba el `acct_…` devuelto por la API, no solo que una solicitud responda. Restringe temporalmente operaciones de escritura que puedan dirigirse a la cuenta equivocada y define cómo detener el despliegue.

Los endpoints de webhook y sus secretos de firma pertenecen a la cuenta. Configura en destino los eventos necesarios y guarda el nuevo secreto. Verifica la firma sobre el cuerpo sin modificar y responde con rapidez; procesa la lógica pesada de forma asíncrona cuando corresponda.

Stripe no garantiza el orden de los eventos y puede reenviarlos. Haz el consumidor idempotente, guarda los identificadores procesados y recupera el objeto actual cuando el estado dependa de eventos anteriores. Durante el corte, observa tanto origen como destino para detectar tráfico inesperado.

Prueba un pago correcto, un pago fallido, una autenticación requerida, un cambio de suscripción, una cancelación y un reembolso. La lista exacta depende del producto; suscribirse a todos los eventos sin una razón puede aumentar el ruido y los permisos.

Define el acceso del usuario mediante un estado de negocio y no por la llegada de un único webhook. Una suscripción `active` no asegura que toda factura esté pagada; un evento retrasado tampoco debe revocar acceso incorrectamente. Documenta periodos de gracia y recuperación.

Antes de desactivar el origen, compara población, configuración y estado. Después, vigila las primeras renovaciones y concilia importe, moneda, fecha, factura, pago y acceso. Los errores deben quedar en una cola con propietario; no se ocultan como «éxitos parciales».

La aplicación solo se considera entregada cuando el comprador puede operar altas, cambios, bajas, portal, soporte y recobro desde su cuenta y cuando la evidencia confirma que el origen ya no interviene fuera del alcance histórico acordado.