Ejecuta el corte de Stripe como un despliegue controlado

Confirma primero que la operación necesita dos cuentas. Registra los identificadores de cuenta, la entidad y el país; pide a Stripe la copia de clientes y métodos de pago aptos. Su documentación indica que no se copian suscripciones, facturas, planes, cupones, eventos ni registros. Clasifica por separado métodos no admitidos y clientes compartidos.

Haz un inventario de productos, precios, moneda, intervalo, cantidad, prueba, ancla, descuento, impuesto, método de cobro, estado y próxima factura. Añade las dependencias de aplicación: claves, identificadores en la base de datos, webhooks, portal, gestión de impagos, analítica y permisos. Cada elemento debe tener un responsable del lado comprador.

Reproduce en Sandbox las formas sencillas y difíciles: mensual, anual, múltiples partidas, pruebas, calendarios, facturación por factura, atrasos, descuentos e impuestos. Stripe recomienda probar el modelo de precios y recuerda que los identificadores de prueba y producción deben mapearse por separado.

Valida idempotencia, pero no la confundas con corrección comercial. Una clave idempotente puede evitar crear dos veces la misma solicitud; no demuestra que importe, fecha o precio fueran adecuados. Guarda el resultado y concilia cada fila con el manifiesto.

Prueba los webhooks sin asumir orden. Verifica firma con el secreto nuevo, procesa duplicados de forma segura y recupera el objeto de Stripe cuando falte contexto. Simula también un pago fallido y una autenticación requerida para comprobar que el producto no concede ni retira acceso por un único evento aislado.

Si utilizas el kit de migración de Stripe, consulta sus reglas vigentes antes de cargar el CSV. La documentación actual define requisitos para fechas futuras, validación, creación de calendarios y ventanas operativas. Registra en el plan las horas que muestre el Dashboard, en lugar de confiar en una memoria antigua.

Toma una instantánea final de origen y destino. A partir de ella, cualquier alta, cambio de plan, cancelación, descuento o actualización de pago debe quedar congelado o incorporarse mediante un procedimiento para registrar los cambios posteriores. Inspecciona facturas abiertas y borradores, partidas pendientes, uso medido, cancelaciones programadas y renovaciones alrededor de T0.

Publica un tablero de lanzamiento con criterios binarios: cuenta, recuento, datos de pago, mapeos, fechas, desactivación, aplicación y soporte. Si un control obligatorio no es verde, no se interpreta como una advertencia menor; se aplaza o se excluye la cohorte afectada.

Restringe cambios, repite la validación y registra la aprobación. Crea o programa en destino y conserva el identificador resultante. Verifica cliente, precio, cantidad, fecha siguiente, prueba, descuento, impuesto, método de cobro y metadatos. Solo entonces completa la acción de origen acordada antes de que ambas cuentas puedan cobrar el mismo periodo.

Despliega la configuración del comprador: claves, identificadores, endpoint de webhook y secreto de firma, portal, analítica, gestión de impagos y lógica de acceso. Ejecuta pruebas sintéticas de lectura, actualización y recepción de eventos. Mantén disponibles a los responsables de ambas cuentas durante la ventana.

Revisa errores, facturas, eventos, autenticaciones y acceso durante las primeras horas. En los días siguientes, compara las cohortes de renovación con el importe y la fecha esperados. Una suscripción activa puede tener una factura sin pagar; una factura pagada no demuestra que el producto procese correctamente el evento.

La reversibilidad cambia durante el corte. Antes de crear puede aplazarse. Después de crear pero antes de cobrar, algunas acciones pueden cancelarse o corregirse según el flujo. Tras facturas, pagos, cancelaciones o comunicaciones, «volver atrás» puede generar nuevos efectos. Define una reparación hacia delante y consulta a Stripe para los casos ambiguos.

Al final de la observación, entrega el informe, resuelve excepciones y revoca claves temporales. Conserva el acceso histórico que exijan obligaciones y disputas. Un corte se considera aceptado cuando los criterios medibles están cumplidos, no cuando termina la videollamada.