Implantar Checkout.com en un e-commerce legacy sin interrumpir el servicio

Esta semana hemos finalizado la implantación de Checkout.com en el e-commerce de uno de nuestros clientes. El resultado ha sido óptimo: cero interrupciones del servicio y una única incidencia menor durante el lanzamiento, resuelta con agilidad y sin impacto significativo para los usuarios.

Dicho así, podría parecer simplemente otra integración de una nueva pasarela de pagos. La realidad fue bastante más compleja.

El reto no estaba tanto en conectar Checkout.com como en hacerlo sobre una plataforma con más de diez años de evolución, altamente personalizada, con una cantidad considerable de código legacy y prácticamente sin documentación técnica sobre muchas de las decisiones acumuladas durante todos esos años.

Además, la implantación debía funcionar en cinco mercados diferentes (tres actualmente activos y otros dos en preparación), con distintos medios de pago, aplicaciones móviles, pagos recurrentes y sistemas preexistentes que debían seguir conviviendo con la nueva plataforma.

En un escenario así, integrar una API es solo una pequeña parte del proyecto.

El problema no era instalar una pasarela de pagos

En un proyecto nuevo, incorporar un proveedor como Checkout.com puede ser un proceso relativamente acotado. Existen SDK, documentación, integraciones de referencia e incluso plugins para muchas plataformas.

Aquí ninguna de esas comodidades resolvía el problema.

La plataforma lleva más de una década evolucionando y contiene una importante capa de personalización construida alrededor de los procesos reales del negocio.

Los pagos no son una pieza aislada. Intervienen en la creación y confirmación de pedidos, las suscripciones, las devoluciones, las aplicaciones móviles, las operaciones de Atención al Cliente y numerosos procesos internos.

Por eso, sustituir la infraestructura de pagos no consistía simplemente en cambiar unas llamadas a una API por otras.

Había que entender primero qué hacía realmente el sistema.

Y en software legacy existe con frecuencia una diferencia importante entre cómo se supone que funciona una aplicación y cómo funciona después de diez años de evolución.

Cinco mercados y múltiples medios de pago

A la complejidad tecnológica se añadía la internacionalización.

La plataforma opera actualmente en tres países y está preparando otros dos mercados. Cada uno presenta requisitos y métodos de pago diferentes.

Checkout.com debía incorporar:

• pagos con Visa y Mastercard;
• Bizum en España;
• Apple Pay;
• Google Pay.

Pero esos métodos no sustituían completamente al ecosistema anterior.

Debían convivir con:

• American Express, que continúa procesándose mediante Redsys;
• Klarna;
• PayPal;
• transferencia bancaria.

El resultado es mucho más parecido a una matriz de pagos que a una única pasarela:

mercado × método de pago × dispositivo × estado del pedido × comportamiento del proveedor.

Cada combinación puede presentar particularidades distintas.

Y cada particularidad debe funcionar no solamente en el caso ideal, sino también cuando un banco rechaza una operación, un usuario abandona un flujo, una autenticación falla o una confirmación llega de forma asíncrona.

Migrar desde Redsys sin romper lo que ya funcionaba

Otro elemento especialmente delicado era la convivencia con Redsys.

Una migración de pagos rara vez permite tratar el sistema anterior como si dejara de existir de un día para otro. Hay datos, comportamientos históricos y funcionalidades construidas alrededor de él que deben seguir funcionando durante la transición.

En nuestro caso existía, además, un requisito particularmente sensible: los pagos recurrentes. La plataforma dispone de clientes con suscripciones y, por tanto, de tarjetas tokenizadas utilizadas posteriormente para realizar cargos.

Cambiar el proveedor de pagos exige resolver qué sucede con esas credenciales y con los clientes cuyas tarjetas todavía no se encuentran preparadas para operar con el nuevo sistema.

Para ello, además de la migración de los tokens preexistentes, hemos desarrollado también un mecanismo que permite renovar las tarjetas pendientes de tokenización mediante una operación de 0 €.

El sistema identifica con antelación las tarjetas que necesitan ser actualizadas y avisa automáticamente al cliente antes de que llegue el momento de efectuar el siguiente cobro.

Así conseguimos que buena parte de esas tarjetas se actualicen antes del siguiente cobro, en lugar de descubrir el problema cuando una renovación ya ha fallado.

Anticiparse es más importante que reaccionar

Una de las claves del éxito ha sido el acompañamiento del Account Manager de Checkout.com.

Su papel ha ido bastante más allá de responder consultas puntuales. Nos ha ayudado a anticipar posibles problemas, coordinar las verificaciones necesarias y mantener actualizado el roadmap de validaciones hasta el momento de lanzamiento.

En proyectos que afectan a un proceso tan crítico como el pago, esta colaboración entre proveedor y equipo técnico resulta especialmente valiosa.

Buena parte del valor de ese acompañamiento estuvo precisamente en detectar riesgos antes de que llegaran a producción.

Una integración de pagos es también un proyecto de coordinación

Otro factor fundamental ha sido la coordinación entre equipos.

El checkout no termina en la web. La compañía dispone también de aplicaciones móviles para iOS y Android, mantenidas por otro proveedor, y el comportamiento del nuevo sistema debía ser coherente independientemente del canal utilizado por el cliente.

A ello se sumaban las diferentes áreas internas afectadas por el cambio. Tecnología, negocio, Atención al Cliente y proveedores externos debían entender qué cambiaba, cuándo cambiaba y qué dependencias existían entre unos equipos y otros.

En la práctica, buena parte de la dificultad no estuvo en la API de Checkout.com, sino en coordinar los cambios entre web, aplicaciones móviles, proveedor de pagos y equipos internos.

Una integración puede estar perfectamente implementada y fracasar igualmente si un equipo desconoce una dependencia, una aplicación no está preparada para el cambio o una incidencia llega a una persona que no sabe cómo interpretarla.

QA como parte de la arquitectura del lanzamiento

Probablemente una de las áreas en las que hemos sido más meticulosos ha sido QA.

Diseñamos y ejecutamos planes específicos de pruebas sobre dos escenarios diferenciados de QA, además de validar los flujos correspondientes en las aplicaciones de iOS y Android.

Pero en un sistema de pagos existe un límite evidente para cualquier entorno de pruebas. Un sandbox puede reproducir muchos comportamientos, pero no puede reproducir completamente el ecosistema real compuesto por bancos, tarjetas, autenticaciones, wallets, configuraciones de producción y comportamiento de usuarios.

Por ese motivo realizamos también pruebas controladas contra producción desde nuestros entornos de stage. No queríamos que el día del lanzamiento fuese el momento en el que determinados flujos se ejecutasen por primera vez contra sistemas reales.

Cuando llegó ese día, muchas de las situaciones críticas ya habían ocurrido previamente de forma deliberada y controlada. Llegamos al lanzamiento con los principales escenarios ya validados, incluidos aquellos que sólo podían comprobarse de forma fiable contra producción.

Preparar también lo que ocurre cuando algo falla

Hay una parte de este proyecto que consideramos especialmente importante y que, sin embargo, suele recibir mucha menos atención que el código.

Antes del lanzamiento preparamos un Plan de Acción específico para Atención al Cliente. Porque implantar correctamente una plataforma de pagos no significa asumir que nunca habrá pagos rechazados, autenticaciones fallidas, tarjetas caducadas, operaciones pendientes o discrepancias que necesiten revisión.

Todas esas situaciones forman parte de la operativa normal de cualquier sistema de pagos real. La diferencia está en si la organización está preparada para ellas.

El objetivo del plan era que Atención al Cliente pudiera reconocer las situaciones previsibles, saber qué información solicitar, qué respuesta proporcionar al usuario y cuándo debía escalar el caso al equipo técnico.

De esta forma evitamos que la primera aparición de una situación conocida obligue al equipo a improvisar una respuesta.

Para nosotros, este punto resume buena parte de la filosofía del proyecto:

Una migración no termina cuando el nuevo sistema cobra correctamente. Termina cuando la organización sabe qué hacer también cuando algo no sale como estaba previsto.

El lanzamiento

La implantación afecta a cinco mercados, tres de ellos actualmente operativos y dos en preparación, y comprende web, aplicaciones móviles, múltiples métodos de pago y procesos de tokenización y recurrencia.

El lanzamiento se realizó con:

• cero interrupciones del servicio;
• una única incidencia menor, resuelta rápidamente;
• funcionamiento coordinado en web, iOS y Android;
• convivencia con los medios de pago preexistentes;
• procedimientos preparados para los principales escenarios operativos posteriores al lanzamiento.

No se trataba, por tanto, de evitar la complejidad, sino de identificarla previamente y ser proactivos.

La integración es la parte fácil

Después de proyectos como este resulta tentador atribuir el éxito a una arquitectura concreta, una API o una decisión técnica determinada. Naturalmente, la calidad de la implementación importa. Pero los factores que realmente reducen el riesgo son otros: entender el sistema existente, identificar las dependencias, coordinar a todas las partes, probar los escenarios reales y preparar a la organización para operar el nuevo sistema.

Especialmente cuando trabajamos con plataformas legacy. Hay mucho software crítico funcionando sobre sistemas que llevan diez, quince o veinte años evolucionando. Reemplazarlos por completo no siempre es razonable ni necesario.

En muchas ocasiones, el verdadero trabajo de ingeniería consiste precisamente en hacer evolucionar esos sistemas sin detener el negocio que depende de ellos. Eso es lo que hemos hecho en este proyecto.

El 20 de agosto activamos Checkout.com en producción. La plataforma siguió operando con normalidad, los medios de pago anteriores continuaron conviviendo con los nuevos y la única incidencia detectada fue menor y se resolvió sin interrupción del servicio. En un sistema con más de diez años de historia, cinco mercados y varios canales de venta, ese era exactamente el resultado que buscábamos.