Cambio planificado de PSP: migrar suscripciones y cerrar las obligaciones antiguas

Una migración de PSP rara vez termina el día del lanzamiento. El nuevo botón de pago ya funciona. Marketing anunció que el cambio está completo. Al día siguiente, un comprador pide el reembolso de un pedido del mes pasado y el equipo financiero espera la última liquidación del PSP anterior. La mudanza solo estaba lista para las ventas nuevas. Las obligaciones antiguas se quedaron en la dirección de siempre.

Cambiar de proveedor de pagos implica varias transiciones: la nueva aceptación de pagos, la atención de las operaciones anteriores, el traslado de los datos permitidos, la gestión de suscripciones y el cierre de las liquidaciones. Conviene gestionarlas como flujos separados, cada uno con sus propios criterios de finalización. Un solo día de cambio en la interfaz no cierra los cinco.

Primero, trace un mapa de lo que queda

Antes de mover el tráfico, exporte un registro autorizado de las obligaciones abiertas: operaciones no finalizadas, reembolsos disponibles, disputas, reservas, liquidaciones pendientes y suscripciones. Use los campos mínimos necesarios y un almacenamiento protegido. Para cada categoría, asigne un responsable, una fuente de estado y una condición de cierre. Un importe de «saldo en el panel» sin desglose no muestra qué obligaciones sobrevivirán al contrato.

El principio de enrutamiento propuesto es sencillo: cada nueva acción la atiende el proceso al que realmente pertenece. El reembolso de un pago antiguo no se puede enviar automáticamente al nuevo PSP con el identificador anterior. Confirme la vía admitida con las partes y conserve el acceso necesario para las operaciones acordadas. Si el contrato anterior termina, acuerde por separado la atención posterior y sus posibles limitaciones.

En soporte, la búsqueda debe empezar por el número de pedido y después mostrar el proveedor de ese pago concreto. El comprador no tiene por qué recordar la fecha de su mudanza técnica. Si en la interfaz solo queda el sistema nuevo, el personal empezará a armar una hoja paralela de pedidos antiguos y a crear un riesgo adicional de errores.

Trasladar datos no traslada la suscripción

El token de pago, los datos de la tarjeta, el perfil del cliente y el calendario de cobros son objetos distintos. Que en la exportación haya una fila token no prueba que pueda usarse con el nuevo proveedor. Stripe describe procesos específicos de migración de datos de pago con participación de su equipo. Resumen de migraciones de Stripe. La disponibilidad y las condiciones se comprueban para cada método y cada parte.

Adyen, tras importar los datos de pagos recurrentes, entrega un archivo con el resultado de la migración. Procedimiento de importación de Adyen. La conclusión operativa: se necesita un puente verificable entre los identificadores anteriores y los nuevos, incluidos los registros que no se lograron trasladar. No considere la ausencia de errores en el proceso como prueba de que se trasladó a cada cliente.

Transmita los datos sensibles de tarjetas solo mediante el proceso seguro acordado entre los proveedores y con las autorizaciones necesarias. Una hoja de cálculo en una carpeta compartida o un correo al gestor no se vuelven un medio de envío aceptable porque el proyecto sea urgente. Para los clientes que no se puedan trasladar, prepare de antemano una vía clara y admitida para actualizar sus datos de pago.

Una factura debe tener un solo ejecutor

Imaginemos una suscripción de 30 euros con la próxima renovación el día 15. Durante la mudanza, el planificador antiguo sigue activo y el sistema nuevo ya recibió al cliente y la fecha de renovación. Ambos pueden ejecutar correctamente sus instrucciones y generar dos cobros. La idempotencia dentro de cada PSP no resuelve esa colisión entre sistemas independientes.

Antes de activar el nuevo calendario, deje establecido qué sistema es dueño de cada periodo de facturación concreto. Concilie el último periodo pagado, la próxima factura, el periodo de prueba, los descuentos y los cambios previstos. Después compruebe que el sistema antiguo ya no tiene permiso para iniciar ese mismo periodo. El orden del cambio depende de los productos y debe ensayarse antes con datos sintéticos.

En el simulacro, añada una cancelación del cliente entre la exportación y el cambio. Una instantánea de datos del lunes no refleja una decisión tomada el martes. Hace falta un proceso para trasladar los cambios o una ventana de congelación limitada que el producto admita. Congelar la configuración interna no debe privar al comprador de la vía que le corresponde para cancelar el servicio.

Verifique el traslado por grupos

Empiece por un segmento limitado y acordado, con criterios de ampliación: importes correctos, estados esperados, soporte funcionando y una conciliación que cuadra. Evalúe por separado a los clientes nuevos y a los que ya pagaban: los motivos de rechazo y las acciones necesarias pueden ser distintos. Elija su orden según el modelo de negocio real, no según la comodidad de una sola tarjeta de prueba.

Para cada grupo, guarde su composición original. Así se nota si falta un cliente en el sistema nuevo y la comparación de la conversión no mezcla compradores distintos. El rollback también necesita reglas: ¿qué operaciones nuevas pueden volver a la ruta anterior y cuáles deben terminar donde empezaron? Los pagos ya procesados no se anulan con un simple rollback de la versión del sitio.

La mudanza termina cuando las ventas nuevas funcionan, las obligaciones antiguas se atienden según el proceso acordado, todos los saldos están explicados y el acceso innecesario se revoca tras cerrar las dependencias. Este último punto se ejecuta con una lista verificada; de lo contrario, el ahorro en la cuenta antigua se convertirá en la imposibilidad de atender el siguiente reembolso.