Para migrar cobros recurrentes, confirma qué credenciales pueden utilizarse en el destino, conserva la identidad de cada suscripción y mantén un único ejecutor autorizado por ciclo. Separa la transferencia de datos del cambio de ruta y resuelve los cobros pendientes antes de repetir comandos. Realiza la transición por grupos verificables, con conciliación, criterios de reversión y comunicación. Cambiar el endpoint no hace portátiles los tokens ni garantiza la continuidad del cobro.
El objetivo es reducir las interrupciones y controlar las excepciones, no prometer una migración sin riesgo. Algunas suscripciones podrán cambiar de ruta; otras tendrán que permanecer temporalmente en el origen o actualizar la forma de pago. El plan debe reconocer estas diferencias antes de modificar el planificador que cobra a toda la cartera.
Esta guía presenta una propuesta de arquitectura y operación con una cartera ficticia de mil suscripciones. Las referencias se consultaron el 22 de octubre de 2026. No se exponen procesos internos, credenciales ni clientes de AZPay, ni se presupone que la plataforma ofrezca ninguna de las modalidades de portabilidad descritas.
¿Qué se migra además de la API de pagos?
Una operación recurrente combina relación comercial, calendario, forma de pago, credencial externa, comandos y movimientos financieros. El proyecto debe definir qué partes cambian. Migrar solo las nuevas ventas es distinto de transferir una cartera activa; cambiar la captura de tarjeta es distinto de migrar la ejecución de los cobros anteriores.
La guía de recurrencia y card-on-file separa suscripción, ciclo e intento. Conserva estas identidades durante la transición. El cliente no debería adquirir una segunda suscripción comercial solo porque la empresa pase a ejecutar el mismo ciclo en otro procesador.
Incluye también las operaciones posteriores: consulta de cobros antiguos, captura cuando proceda, cancelación, reembolso, disputa e informes. Un PSP puede dejar de recibir nuevas autorizaciones y seguir siendo necesario para administrar el historial. Cerrar ese acceso demasiado pronto compromete la atención al cliente y el cierre financiero.
Redacta una declaración de alcance con los medios, países, monedas, modelos comerciales y cohortes elegibles. Registra lo que permanece en el origen y quién responde por cada excepción. Esta declaración permite hablar de continuidad a partir de la cartera real, en lugar de definir la finalización como el cambio de una URL.
¿Cómo inventariar credenciales sin presuponer portabilidad?
Para cada grupo de suscripciones, identifica quién emite el token, qué servicio puede resolverlo, en qué rutas puede utilizarse y cómo se sigue su ciclo de vida. Registra capacidades, no datos primarios de tarjeta en una hoja de proyecto. Las referencias operativas también deben seguir los controles internos de acceso.
Un token de vault puede ser únicamente un identificador del proveedor de origen. El destino no adquiere la capacidad de utilizarlo por recibir una cadena con el mismo valor. La documentación de Adyen para importar desde otro proveedor (se abre en una pestaña nueva ↗) muestra una migración coordinada, con referencias de cliente, formatos y transferencia acordados entre los participantes. Este proceso no demuestra una portabilidad universal.
Los tokens de red exigen otro análisis. La guía de referencia de EMV Payment Tokenisation (se abre en una pestaña nueva ↗) describe controles que restringen cómo y dónde pueden utilizarse los tokens. Por eso, confirma la compatibilidad del destino, el dominio de uso y los datos necesarios para procesar, sin tratar un token de red como una credencial sin restricciones.
El inventario también debe distinguir las credenciales que se migrarán, las que seguirán siendo accesibles únicamente en el origen y las situaciones que exigen una nueva interacción del cliente. La explicación de PAN, vault y tokens de red proporciona el contexto; el proyecto debe obtener una respuesta concreta de los participantes contratados.
¿Qué pruebas deben existir antes de la transferencia?
Confirma que origen y destino aceptan el proceso, qué responsabilidades asumen y cómo se acreditarán el envío, la recepción y el resultado. Define la identidad que relacionará el registro anterior con el nuevo, además del tratamiento de los rechazos. Confirmar la recepción de un archivo no equivale a confirmar que todas las credenciales se pueden utilizar.
La documentación de resultados de importación de Adyen (se abre en una pestaña nueva ↗) muestra la devolución de un resultado de migración. Utiliza este tipo de evidencia para comprobar correspondencias y cuestiones pendientes, sin copiar el formato del proveedor como si fuera un estándar del mercado ni implementar transferencias manuales de datos sensibles.
El PCI SSC, FAQ 1092 (se abre en una pestaña nueva ↗), aclara que externalizar el procesamiento no elimina la responsabilidad del comercio de proteger los datos y supervisar al prestador. El proyecto debe involucrar a los equipos responsables del alcance y los controles aplicables, incluido el canal de transferencia definido por los proveedores.
No incluyas PAN, CVV ni archivos de credenciales en herramientas de atención, repositorios, registros o mensajes del proyecto. La FAQ 1318 del PCI SSC (se abre en una pestaña nueva ↗) distingue la retención de datos necesarios de la prohibición de almacenar datos sensibles de autenticación después de la autorización. El manual operativo editorial debe mantenerse en el nivel de responsabilidades, referencias y evidencias, sin enseñar exportaciones informales.
¿Cómo mapear estados y operaciones entre los PSP?
Construye una correspondencia semántica antes de convertir los nombres. Un estado llamado éxito puede significar autorización en una API y otra etapa en otro servicio. Compara los eventos que permiten cobrar, entregar, cancelar y devolver. Cuando no exista equivalencia, conserva la particularidad en lugar de forzar un estado común engañoso.
Para cada operación, documenta la condición previa, la referencia externa, el resultado concluyente, la situación pendiente y el mecanismo de consulta. Incluye la regla de idempotencia y su ventana cuando esté disponible. Enviar la misma clave a dos PSP no constituye una garantía compartida de ejecución única.
Una propuesta consiste en mantener suscripción y ciclo como identidades internas estables, con intentos externos independientes. Cada intento conserva proveedor, referencia y resultado. La ruta elegida para ejecutar un ciclo debe ser un dato explícito, no una inferencia a partir del último token encontrado en el registro del cliente.
La guía de idempotencia en las API de pagos desarrolla los controles por comando. En la migración, añade un control de propiedad del ciclo: qué ejecutor puede iniciar la siguiente acción y qué evidencia permite transferir esa responsabilidad a otro.
¿Cómo impedir que dos planificadores cobren el mismo periodo?
Ejecutar dos integraciones durante la transición puede ser necesario; ejecutar el mismo ciclo financiero en ambas no debe ser una consecuencia accidental. La aplicación debe decidir qué ruta es la propietaria antes de enviar el comando. Una regla de exclusión transaccional por suscripción y periodo puede proteger esa decisión, según el modelo de negocio.
Utiliza una versión de enrutamiento o un mecanismo equivalente para invalidar decisiones antiguas. No basta con cambiar un campo PSP en el registro si una tarea ya ha puesto un cobro en la cola del origen. El consumidor debe comprobar si sigue autorizado para ejecutarlo y si ese ciclo ya tiene un intento en curso o una finalización registrada.
Cuando exista un resultado indeterminado en el origen, mantén el ciclo en investigación. El token del destino puede estar listo, pero eso no demuestra que un nuevo cobro sea seguro. Consulta el intento, correlaciona los eventos y concilia. La política de failover en pagos aplica el mismo principio al cambio de ruta ante un fallo.
Coordina también los comandos manuales. Atención al cliente, panel operativo y tareas deben consultar la misma identidad de obligación. Un bloqueo únicamente en el planificador automático deja abierta la posibilidad de que soporte inicie un segundo cobro mientras intenta ayudar al cliente.
Caso ficticio: ¿cómo dividir mil suscripciones?
Considera una cartera sintética de 1.000 suscripciones mensuales, sin precios ni datos reales. El inventario identifica 600 con una correspondencia de credencial validada para el destino, 250 que siguen dependiendo del origen y 150 que requieren que el cliente actualice su forma de pago. Los grupos suman 1.000 y no deben mezclarse en una única decisión de transición.
Entre las 600 mapeadas, 50 aún tienen un cobro en estado indeterminado en el origen. Por tanto, en ese momento solo 550 son candidatas a la transición operativa. La clasificación completa es: 550 candidatas, 50 en investigación, 250 mantenidas en el origen y 150 a la espera de una nueva credencial. La suma sigue siendo 1.000.
Estas cantidades no son previsiones ni criterios universales de elegibilidad. Muestran cómo evitar confundir una credencial migrada con una suscripción lista para cobrar en el destino. Los 50 casos pendientes solo pueden cambiar de grupo cuando sus resultados y su siguiente periodo estén claros.
Elige un piloto entre las 550 candidatas con criterios definidos antes de la ejecución: capacidad del destino, variedad necesaria para ejercitar el flujo e impacto operativo aceptable. Un piloto seleccionado únicamente entre los casos más sencillos valida el camino básico, pero no demuestra que toda la cartera se comportará igual.
Las 250 mantenidas en el origen necesitan calendario y responsable propios. Para las 150 que deben actualizarse, ofrece un proceso legítimo de obtención de la nueva credencial, explica la acción necesaria y sigue el abandono y la confirmación. No anuncies una migración completada porque las 550 candidatas se hayan procesado correctamente mientras el resto queda sin plan.
¿Cómo estructurar la preparación, el piloto y la transición?
En la preparación, valida la integración de destino y los mapeos sin iniciar cobros duplicados en producción. Prueba la emisión de comandos, los webhooks, las consultas y las operaciones posteriores con datos y entornos adecuados. Demuestra que el sistema distingue entre pruebas, preparación y ejecución financiera real.
En el piloto, habilita solo el grupo autorizado y mantén límites de exposición y criterios de interrupción. Observa el ciclo completo relevante: no solo la respuesta de autorización, sino también la actualización comercial, la captura cuando proceda, la conciliación y la capacidad de atención. Una migración puede parecer saludable hasta el primer reembolso o cierre.
Para la transición, registra qué ciclos pertenecen a cada ruta, la versión de la decisión y la hora de activación. Reevalúa las colas antiguas y los comandos reservados antes de liberar la ejecución en el destino. Un mensaje creado antes del cambio no puede decidir por sí solo que sigue autorizado a cobrar después.
Después, amplía la población a partir de evidencias. Una nueva cohorte debe poder explicarse mediante el inventario y los resultados, no por la presión de terminar el proyecto en una fecha arbitraria. El plazo comercial puede orientar la planificación; no convierte las credenciales incompatibles ni los resultados indeterminados en casos seguros.
¿Qué debe provocar una interrupción o reversión?
Define las condiciones antes del piloto: duplicidad confirmada, incapacidad para correlacionar ingresos, comandos sin propietario, aumento relevante de errores o imposibilidad de ejecutar operaciones posteriores críticas. Los límites cuantitativos deben proceder de la operación y de su tolerancia aprobada; esta guía no inventa porcentajes adecuados para cualquier empresa.
Interrumpir la ampliación es distinto de devolver toda la cartera al origen. Primero, bloquea los comandos nuevos del grupo afectado, conserva los resultados e identifica qué ciclos aún no se han ejecutado. Una reversión de configuración no deshace una autorización, una captura ni un pago ya realizados.
Permite una nueva ejecución en el origen únicamente cuando este aún pueda procesar la credencial, la obligación no esté satisfecha y el resultado del intento en destino esté suficientemente resuelto. Si falta alguna condición, la acción adecuada puede ser mantener el cobro pendiente e investigar, en lugar de intentar recuperar disponibilidad mediante una duplicidad.
El plan de vuelta atrás debe incluir la propia posibilidad de regresar. Si la credencial antigua se ha desactivado o el contrato ha terminado, la ruta anterior puede haber dejado de existir. Por eso, la reversibilidad debe demostrarse antes de utilizarse como argumento para acelerar la transición.
Registra también quién decide interrumpir, quién ejecuta el cambio y qué evidencias se conservan. Durante un incidente, una decisión sin responsable puede crear versiones de ruta contrapuestas en paneles y colas. Una única fuente de decisión operativa reduce ese riesgo, siempre que todos los consumidores respeten su versión.
¿Cómo mantener los webhooks y el historial durante la coexistencia?
Origen y destino pueden seguir produciendo eventos legítimos sobre objetos distintos. Valida cada emisor mediante el mecanismo documentado y conserva el contexto del proveedor en la identidad externa. Dos referencias iguales en servicios diferentes no deben colisionar en el procesamiento interno.
Un evento tardío del origen puede completar un cobro anterior a la transición. Debe actualizar ese intento y ese periodo, sin volver a cambiar el PSP preferido de todas las suscripciones. Del mismo modo, un evento del destino no debe sobrescribir el historial de un reembolso que aún se administra en el origen.
Conserva las referencias que vinculan cliente, suscripción, ciclo, intento y movimiento financiero. Si hay un identificador nuevo para la credencial, mantén la correspondencia con el anterior al nivel necesario para investigar y conforme a la política de acceso y retención. El token es una referencia de forma de pago, no toda la identidad del cliente.
Prepara la recuperación de mensajes perdidos. Las consultas y rutinas de verificación deben conocer ambos proveedores mientras existan obligaciones operativas en los dos. Cerrar el consumidor antiguo el día del cambio puede hacer que una migración técnicamente exitosa produzca pendientes que solo aparezcan en el cierre.
¿Qué debe conciliarse antes de cerrar el origen?
Concilia el resultado de la migración de credenciales con el inventario comercial: ¿cuántas se aceptaron, rechazaron, sustituyeron o siguen esperando una acción? Después, compara los ciclos previstos con los comandos ejecutados. Cada periodo debe tener una explicación de por qué está pagado, pendiente, cancelado o fuera de alcance.
En la capa financiera, conserva capturas, tarifas, reembolsos, disputas, derechos de cobro y transferencias según los métodos y contratos. El destino no pasa a conocer automáticamente esos hechos antiguos. La conciliación entre venta, captura y liquidación ayuda a definir las fuentes y las diferencias de calendario.
El cierre debe funcionar en ambas direcciones. Desde una suscripción, encuentra sus cobros en cada PSP; desde una línea financiera, encuentra el ciclo y la obligación correspondientes. Cualquier movimiento huérfano debe clasificarse y tratarse, en lugar de descartarse por pertenecer a la integración que se desactivará.
Antes de cerrar contratos o accesos, confirma cómo continuarán las consultas y operaciones posteriores y durante cuánto tiempo serán necesarias. Esta decisión depende de obligaciones, productos y contratos reales. Mantén solo los accesos y datos necesarios, pero no elimines la capacidad operativa que el historial todavía exige.
¿Cómo comunicar la transición al suscriptor?
Explica la acción concreta esperada cuando sea necesario actualizar el medio de pago. Indica el canal legítimo para hacerlo y mantén al equipo de atención capaz de diferenciar una actualización de credencial, un cobro pendiente y la cancelación de una suscripción. Evita mensajes que induzcan a un pago manual sin verificar un intento en procesamiento.
No prometas que el cliente nunca percibirá un cambio. El nombre que aparece en el extracto, la exigencia de autenticación, el proceso de actualización y las condiciones de cobro pueden depender de los participantes. Anticipa las diferencias confirmadas y valida los textos con quienes responden por la experiencia comercial.
Si la nueva credencial no se confirma a tiempo, aplica la política de producto prevista para continuidad o periodo de gracia. Un problema de migración no debe clasificarse automáticamente como desinterés del cliente. Medir el origen del fallo ayuda a evitar comunicaciones incorrectas y decisiones de acceso difíciles de explicar.
¿Cómo probar la concurrencia y la recuperación antes de la transición?
Ejecuta una prueba en la que dos tareas reserven simultáneamente el mismo periodo, una con la versión antigua y otra con la nueva. El resultado esperado es una única autorización de ejecución; la que no la obtenga debe reconocer el estado existente y registrar la decisión. Esta prueba verifica una propiedad que no aparece cuando cada integración se prueba de forma aislada.
Después, interrumpe el proceso tras el envío al origen y antes de guardar la respuesta. Activa la transición mientras el intento está indeterminado. El nuevo ejecutor debe mantener el bloqueo sobre esa obligación, consultar o esperar evidencias y evitar crear otro cobro en el destino. El éxito de la prueba consiste en preservar el resultado desconocido hasta resolverlo.
Reenvía un webhook antiguo después de actualizar una credencial. Debe encontrar el intento original, sin cambiar el token actual del cliente ni habilitar de nuevo el mismo periodo. Simula también una cancelación comercial mientras hay una instrucción preparada: la decisión debe tener en cuenta la operación financiera que ya puede estar en curso.
Por último, prueba un fallo del destino durante el piloto. La operación debe poder bloquear la ampliación, listar los ciclos afectados e identificar cuáles pueden volver al origen. Comprueba este conjunto de forma individual: algunos pagos ya tendrán un resultado confirmado y otros estarán pendientes. Una lista única de suscripciones afectadas no basta para decidir reintentos seguros.
¿El plan sirve para Pix, boleto y otros medios?
La disciplina de identidad, propietario del ciclo y conciliación es común; la migración de la credencial no lo es. La tarjeta puede implicar un vault y un token. Otros medios pueden depender de un cobro emitido, un permiso, una entidad o un contrato distinto. Inventaría estas dependencias por separado y no intentes convertir todos los métodos en una columna llamada token.
Para la recurrencia Pix, la guía de Pix Automático y cancelación distingue autorización, instrucción y suscripción comercial. Verifica con los participantes cómo afecta el cambio de servicio a ese vínculo y si hace falta un nuevo proceso. La relación comercial existente no demuestra, por sí sola, que el destino pueda iniciar los mismos pagos.
¿Qué lista de comprobación hace ejecutable el plan?
Antes del piloto, confirma el inventario por tipo de credencial, la compatibilidad y autorización del proceso entre proveedores, el mapeo de estados, las identidades comerciales estables y la correspondencia de los registros migrados. Cada punto debe tener evidencia y responsable. Una lista marcada únicamente como debatida aún no demuestra capacidad de ejecución.
Antes de la transición, confirma un propietario único por ciclo, las colas antiguas evaluadas, los intentos indeterminados aislados, los webhooks de ambas rutas activos cuando sean necesarios y la rutina de consulta y conciliación preparada. Registra el conjunto de suscripciones habilitado y la versión de la decisión para permitir una auditoría posterior.
Antes de ampliar, verifica los resultados del piloto, las discrepancias abiertas, la preparación de soporte, el mecanismo de interrupción probado y la viabilidad real del retorno. Incluye pruebas de respuesta perdida, evento tardío, tarea duplicada y cambio de credencial durante la transición. La aceptación consiste en controlar los efectos, no solo en obtener una respuesta HTTP satisfactoria.
Antes de cerrar, explica el destino de todas las cohortes, la responsabilidad de las operaciones históricas y el cierre de los importes. La cartera puede haberse migrado correctamente de forma parcial; en ese caso, describe la parte restante y su plan, sin ocultarla en un porcentaje agregado de éxito.
El resultado esperado es una transición cuya siguiente acción pueda elegirse a partir de evidencias: cobrar en el destino, mantener en el origen, esperar una resolución o solicitar una actualización. Para evaluar una integración de AZPay, consulta la Dev Central y confirma capacidades y contratos. La continuidad nace de coordinar credenciales, ciclos y dinero, no de suponer que todos los tokens cambian de proveedor conservando el mismo significado.