Migrar suscripciones de Stripe sin acción del cliente
Última actualización:
Respuesta directa: Muchas migraciones entre cuentas de Stripe pueden copiar en segundo plano datos aptos de clientes y medios de pago guardados. Así, los clientes no tienen que crear otra cuenta ni volver a introducir una tarjeta durante el cambio. No es una garantía universal: medios no compatibles, métodos predeterminados ausentes, rechazos del emisor y Strong Customer Authentication pueden exigir que algunos clientes actúen.
El objetivo correcto es minimizar la acción del cliente y preparar una vía de corrección , no prometer que nadie tendrá que autenticarse jamás.
Qué puede copiar Stripe en segundo plano
La documentación actual de Stripe sobre copia entre cuentas enumera:
- nombre, correo, teléfono, dirección, medio predeterminado y metadatos del cliente;
- tarjetas como objetos Card, Source o PaymentMethod;
- cuentas ACH como objetos bancarios o PaymentMethod;
- objetos SEPA PaymentMethod.
Stripe indica que los Customers copiados conservan sus Customer IDs, mientras que cambian los identificadores de los medios de pago. Tampoco informa al cliente cuando se realiza la copia.
Quedan excluidos cargos, facturas, planes, suscripciones, cupones, eventos, registros, objetos SEPA Source, Bacs PaymentMethods, cuentas conectadas e invitados. El origen conserva los datos porque se copian, no se mueven.
Fuente primaria: Stripe: datos que pueden copiarse entre cuentas.
Tabla de decisión sobre acción del cliente
| Condición | Experiencia probable | Preparación necesaria |
|---|---|---|
| Tarjeta o PaymentMethod bancaria compatible se copia y sigue predeterminada | Sin registro ni nueva entrada durante la migración | Verificar el medio predeterminado del Customer de destino |
| Hay métodos copiados, pero no un predeterminado válido | El cobro automático futuro puede fallar | Elegir el método correcto solo con consentimiento o conducta de pago que lo respalde |
| SEPA guardado como Source antigua | Stripe documenta que no se copia | Obtener un mandato compatible o planificar comunicación |
| Bacs PaymentMethod | Stripe documenta que no se copia entre cuentas | Crear un plan de corrección separado para Bacs |
| El emisor acepta la exención de pago recurrente sin presencia | La renovación puede completarse sin sesión | Vigilar webhooks de pagos y facturas |
| El emisor rechaza la exención o exige 3DS | Se requiere acción del cliente | Enviar el flujo alojado de autenticación y seguir su finalización |
| Tarjeta caducada, sustituida o rechazada | El cliente debe actualizar el pago | Usar recobro y mensajes de actualización en destino |
«Probable» es intencionado: el banco y la red participan en la autorización final.
Por qué SCA impide una promesa absoluta
Para pagos recurrentes sin presencia, Stripe puede solicitar una exención de transacción iniciada por el comercio cuando el medio se configuró correctamente. El emisor decide si la acepta. Si la rechaza, el cliente debe volver a una sesión y autenticarse.
Por tanto, tu aplicación debe gestionar:
- gestionar
invoice.payment_action_required; - gestionar
invoice.payment_failed; - gestionar PaymentIntents con
requires_actionorequires_payment_method; - ofrecer una página segura de destino para autenticar o sustituir el medio.
Fuentes primarias:
Requisitos para una migración con poca fricción
Realiza estas comprobaciones antes de recrear suscripciones:
- Clasifica los medios: separa los compatibles de Bacs, SEPA Source antiguas, medios ausentes y tarjetas caducadas.
- Verifica predeterminados en destino: Billing Migration Toolkit requiere uno para el cobro automático.
- Confirma la autorización recurrente: conserva consentimientos y revisa si cambia el comercio o sus condiciones.
- Alinea la presentación: prepara descriptor, correo de soporte, recibos y Customer Portal de destino.
- Configura la recuperación: recobro, correos de fallo y vía de autenticación antes de la primera renovación.
- Ensaya casos representativos: tarjeta normal, predeterminado ausente, prueba, fallo y cada método bancario relevante.
MoveMRR puede mostrar problemas de medios y correspondencias; el comprador sigue siendo responsable del consentimiento, los ajustes de Stripe y la comunicación.
Secuencia de cambio
Para clientes aptos, una secuencia controlada es:
- completar la copia de clientes y pagos de Stripe;
- conciliar Customers copiados y medios predeterminados;
- relacionar Prices y configuración del origen con objetos de destino;
- hacer un ensayo y separar casos automáticos de corrección manual;
- crear suscripciones de destino con el calendario futuro acordado;
- aplicar la estrategia elegida de desactivación del origen;
- vigilar primeras renovaciones y eventos que exigen acción;
- contactar solo con los clientes que necesitan corrección.
Esta secuencia evita pedir a todos que actualicen su tarjeta únicamente porque cambió la cuenta.
Qué comunicar a los clientes
Avisar a todos es una decisión empresarial y jurídica. Incluso sin acción prevista, un aviso puede reducir disputas si cambian el nombre del comercio o el descriptor.
Un mensaje preciso explica:
- el servicio y el ritmo de renovación no cambian;
- cambia la entidad de facturación o el descriptor;
- la mayoría no tiene que hacer nada;
- Stripe o la empresa puede contactar a quien necesite autenticarse o actualizar el medio;
- dónde verificar una solicitud legítima de actualización.
Evita afirmar que la tarjeta funcionará con certeza o que nunca habrá que volver a autorizar.
Qué hace y qué no hace MoveMRR
MoveMRR coordina la parte de suscripciones: preparación, correspondencias, ensayos, creación en destino, desactivación configurable, conciliación y exportación de IDs. Stripe copia las credenciales aptas; MoveMRR no recibe números de tarjeta.
MoveMRR no puede anular:
- la aptitud de copia decidida por Stripe;
- las decisiones de autorización bancaria;
- SCA o las reglas de las redes;
- la ausencia de consentimiento;
- los medios no compatibles;
- un recobro o integración de autenticación incompletos del comprador.