Hace unos meses me llamó una dueña de negocio, bastante entusiasmada. Acababa de encontrar un procesador de pagos que cobraba casi un punto porcentual menos que el que usaba desde hacía cuatro años. Con su volumen de ventas, eso significaba dinero real cada mes. Ya había firmado los papeles.

Después le hizo una pregunta simple a su nuevo proveedor: "¿Cómo se transfieren las tarjetas guardadas de mis clientes?" La respuesta no fue la que esperaba. No se transfieren. Al menos no automáticamente.

Me llamó confundida y un poco angustiada. Casi 900 clientes tenían tarjetas guardadas para pedidos recurrentes. ¿Estaba a punto de perderlos a todos? No, si lo planificaba bien. Pero esta es exactamente la parte de cambiar de procesador que agarra desprevenidos a los dueños de negocio: a simple vista parece un trámite administrativo. En realidad es un diseño de seguridad, y una vez que se entiende por qué, todo tiene mucho más sentido.

Por qué el número de tarjeta de sus clientes no "se muda" con usted

Acá está la parte que casi nadie sabe: cuando un cliente guarda su tarjeta en su sitio, casi seguro que usted no está guardando el número real de 16 dígitos en ningún sistema propio. Lo está guardando su procesador de pagos.

Lo que su sitio web conserva, en cambio, es un reemplazo: una cadena larga y aleatoria de caracteres llamada token. Cuando se cobra la tarjeta guardada de un cliente, su sistema le envía ese token a su procesador, y el procesador lo compara con el número real de tarjeta que guarda en su propia bóveda segura. Sus sistemas nunca tocan el número real.

Este diseño, llamado tokenización, existe por una buena razón. Guardar números de tarjeta reales es caro y riesgoso: pone a un negocio directamente bajo un conjunto estricto de normas de seguridad llamado PCI DSS (por sus siglas en inglés, el estándar de seguridad de datos de la industria de tarjetas de pago), que regula cómo hay que proteger esos datos. La tokenización le permite a la mayoría de los negocios evitar buena parte de esa carga, porque los datos sensibles quedan del lado del procesador, no del suyo.

El detalle importante: un token solo tiene sentido para el procesador que lo creó. Es como un ticket de guardarropa de un local específico: si se lo entrega a otro guardarropa, nadie sabe de qué se trata. Al cambiar de procesador, los tokens del anterior, en general, no pueden ser leídos ni reutilizados por el nuevo. Los números reales de tarjeta siguen ahí, bien guardados en la bóveda anterior, pero ni el nuevo procesador ni usted pueden verlos.

Esto no es un descuido: es justamente el sentido del modelo de seguridad. De todos modos, le recomiendo consultar temprano con un profesional calificado en pagos o cumplimiento normativo, porque los requisitos de PCI y las políticas de cada procesador cambian, y los detalles importan según su situación.

Sus dos opciones reales para mover las tarjetas de los clientes

Una vez que acepta que los tokens no se transfieren solos, tiene que elegir entre dos caminos.

Opción uno: pedirles a los clientes que vuelvan a cargar su tarjeta. Es la más simple técnicamente, y la más barata al principio. También es la más riesgosa para su negocio, porque cada paso extra que le pide a un cliente es una oportunidad para que no lo haga. Un porcentaje de clientes va a ignorar el correo, olvidarse, o pensar que es un intento de phishing y borrarlo. Para un cliente de compra única, es una molestia menor. Para un cliente con un plan recurrente, puede significar que su suscripción se caiga en silencio, y ahí perdió un cliente que pagaba por una decisión administrativa de la que ni siquiera se enteró.

Opción dos: una migración de tokens. Es un proceso en el que su procesador anterior y el nuevo —a veces directamente, a veces a través de un servicio externo creado para esto— intercambian de forma segura los datos reales de la tarjeta detrás de escena, sin que pasen nunca por sus sistemas ni que sus clientes tengan que hacer nada. Bien hecho, sus clientes no notan absolutamente nada. Su próximo cobro simplemente se procesa, en el nuevo procesador, con un token nuevo que tiene sentido para su nuevo proveedor.

La migración de tokens no está disponible en todas las situaciones: depende de si ambos procesadores la admiten y de los trámites de cumplimiento necesarios para autorizar la transferencia. Tampoco es instantánea; hay que planificarla pensando en semanas reales, no en un fin de semana. Le recomiendo, en serio, pedirle al equipo comercial o de integración de su nuevo procesador que confirme por escrito si la migración de tokens es siquiera una opción, antes de firmar nada.

Mantener la facturación recurrente funcionando durante el cambio

Si su negocio tiene suscripciones, membresías o cualquier tipo de cobro repetido, esta es la parte alrededor de la cual hay que planificar con más cuidado.

El patrón más seguro que he visto funcionar es mantener los dos procesadores activos en paralelo durante un tiempo —la cuenta anterior sigue funcionando, la nueva empieza a tomar negocio nuevo— en lugar de cortar todo de un día para el otro. Si hay una migración de tokens en curso, esta se hace en silencio, en segundo plano, mientras los dos sistemas están activos, y la cuenta anterior se cierra recién cuando se confirma que el próximo cobro de cada cliente recurrente funciona del lado nuevo. Cerrar la cuenta anterior demasiado pronto es, por lejos, la forma más común en que esto sale mal, porque una vez cerrada, cualquier tarjeta que siga atada a los tokens viejos deja simplemente de poder cobrarse.

Si en cambio opta por pedirles a los clientes que vuelvan a cargar su tarjeta, dese tiempo real de anticipación —semanas, no días— y mande varios recordatorios, por correo y, si lo tiene, por mensaje de texto. Trátelo como trataría cualquier campaña en la que necesita que la gente actúe, porque es exactamente eso.

Un ejemplo real, resumido

Un cliente del rubro retail cambió de procesador a mitad de año para conseguir mejores tarifas, con un volumen considerable de clientes recurrentes. Mantuvimos los dos sistemas en paralelo durante unas seis semanas, siguiendo de cerca la tasa de cobros fallidos durante esa ventana de superposición. Un pequeño grupo de tarjetas no se transfirió bien —en su mayoría vencidas, que de todos modos había que actualizar— y a esos clientes se les mandó un correo breve pidiéndoles que volvieran a cargar su tarjeta. Esa ventana de superposición, más que cualquier otra cosa, fue lo que mantuvo la tasa de fallos lo bastante baja como para que casi nadie notara el cambio.

Preguntas para hacer antes de comprometerse a cambiar

Antes de firmar con un nuevo procesador, vale la pena conseguir respuestas claras sobre: si la migración de tokens es compatible entre su procesador anterior y el nuevo, cuánto tiempo suele tomar ese proceso, si ambas cuentas pueden quedar activas en paralelo durante la transición, qué pasa con las tarjetas vencidas o que no se transfieren, y qué documentación o autorización exige su procesador anterior para liberar los datos hacia el nuevo. Un procesador que no puede responder esto con claridad ya le está diciendo algo sobre cómo va a ser el resto de la relación.

Este tipo de transición toca el mismo terreno que aborda mi artículo sobre cómo un motor de conciliación de tarjetas de crédito rastrea las transacciones de punta a punta, y si la facturación recurrente es parte de su negocio, también vale la pena leer lo que el software de facturación por suscripción debe hacer bien. Ambos explican piezas de la infraestructura por la que un cambio de procesador pasa de lleno.

Conseguir mejores tarifas es una buena razón para cambiar de procesador. Solo no deje que el entusiasmo se salte la planificación. Si está evaluando un cambio y quiere una segunda mirada sobre lo que realmente va a implicar, hablemos de su situación.