Google Pay por dentro: el equipo de Akua que lo hizo posible

Si gestionas los pagos de un banco o una fintech, conoces bien el momento en que un comprador escribe a mano los dieciséis dígitos de su tarjeta, la fecha de vencimiento y el código de seguridad: cada dato es una oportunidad de error y, con ella, un pago que puede no concretarse.

Ese fue el punto de partida del proyecto. Nuestros clientes buscaban una forma de cobrar más ágil, con menos pasos y menos fricción, con un objetivo concreto: aumentar la cantidad de pagos exitosos. Google Pay resuelve justamente eso, porque la tarjeta ya está guardada en la cuenta de Google o en el dispositivo del comprador, y pagar se reduce a tocar un botón.

“Sabemos que ingresar manualmente los datos de una tarjeta es muy propenso a errores. Cuando la tarjeta ya está guardada en un lugar seguro como Google Pay, ese paso directamente desaparece.”

Detrás de ese botón trabajaron tres especialistas de producto. Luciano Barrera, Product Engineer Backend del equipo de Processor, se encargó de recibir, verificar y descifrar cada pago. Javier Perez, Tech Lead del equipo de Experience, construyó el botón en el checkout y el armado del request que llega al procesador.

Nicolas Carrazcosa, Payments Specialist, coordinó la relación con Google y la habilitación para nuestros clientes. En este artículo, cada uno cuenta su parte del proyecto.

01 · Processor, con Luciano Barrera

Qué pasa cuando alguien toca el botón

Akua procesa Google Pay como gateway registrado ante Google. Eso significa que Google cifra los datos de la tarjeta de manera que solo Akua puede abrirlos. El comercio, a través de la plataforma de nuestro cliente, recibe ese token cifrado y nos lo reenvía sin tocarlo, de modo que nunca ve los datos de la tarjeta ni administra claves.

“Cuando alguien paga con Google Pay, no nos llega la tarjeta: llega un paquete cifrado que solo Akua puede abrir. Primero verificamos que lo haya generado Google, que esté dirigido a nosotros y que no esté vencido. Solo entonces lo abrimos, enviamos el pago a Visa o Mastercard, y el banco de la tarjeta decide si lo aprueba.”

Luciano lleva poco más de un año en el equipo de Processor, el que orquesta cada pago en Akua. Cuando ingresa un cobro, coordina las validaciones con los equipos de Fraude, Comercios y Tarjetas, envía el pago a las redes a través de nuestros rieles y, cuando llega la respuesta, sigue gestionándolo durante todo su ciclo de vida: capturas, anulaciones, devoluciones y conciliación.

Así se ve por fuera un token de Google Pay cuando llega a Akua:

// Token de Google Pay (protocolo ECv2), visto desde afuera
{
  "protocolVersion": "ECv2",
  "signature": "MEUCIQ…",
  "intermediateSigningKey": { "signedKey": "…", "signatures": ["…"] },
  "signedMessage": "{\"encryptedMessage\":\"…\",\"ephemeralPublicKey\":\"…\",\"tag\":\"…\"}"
}

Akua soporta los dos métodos que ofrece Google Pay: la tarjeta guardada en la cuenta de Google y el token del dispositivo, que trae un criptograma de un solo uso para cada compra. Funciona con Visa y Mastercard, y ya hay pagos reales aprobados en las dos redes.

02 · Processor · Seguridad

Cuatro verificaciones antes de leer un solo dato

Antes de descifrar un pago, Akua responde cuatro preguntas, siempre en el mismo orden. Si cualquiera de ellas falla, el pago se rechaza y el token no se abre.

1. ¿Lo firmó Google? Verificamos la cadena de firmas contra las claves públicas de Google.
2. ¿Está dirigido a Akua? El destinatario viaja firmado dentro del token y tiene que ser gateway:akua.
3. ¿Llegó intacto y sigue vigente? Comprobamos que nadie lo haya modificado durante el envío y que no esté vencido.
4. Descifrar. Solo cuando las tres respuestas anteriores son afirmativas, el token se abre con la clave privada de Akua.

Una vez descifrado, el pago sigue el mismo camino que cualquier otra tarjeta en Akua: las mismas validaciones, los mismos controles de fraude y la misma conexión directa con Visa y Mastercard. El procesamiento de Google Pay usa la misma infraestructura que ya existía.

03 · Processor · El desafío técnico

Implementar ECv2 en Go, sin una librería oficial

Google protege cada pago con un protocolo llamado ECv2, que combina firmas digitales y cifrado de curva elíptica. Para implementarlo, Google ofrece su librería de referencia, Tink, pero solo en Java. Nuestra plataforma está construida en Go, y para Go no existe una librería oficial de Google.

Decidimos implementar ECv2 nosotros mismos, en Go, siguiendo la especificación de Google y usando solo la criptografía estándar del lenguaje, sin librerías de terceros. Escribir criptografía propia exige probarla con mucho rigor, así que la validamos en tres capas.

Google como juez

Armamos un programa con la librería oficial de Google en Java para generar tokens auténticos, y nuestro código en Go los descifró igual que Google. También hicimos la prueba inversa: la librería de Google aceptó los tokens que generó nuestro código.

Un generador de pagos propio

Creamos una herramienta que fabrica pagos de Google Pay cifrados a demanda. Con ella probamos el flujo completo sin depender de terceros y simulamos a propósito tokens alterados, vencidos y con la clave caducada. En todos esos casos, Akua los rechazó.

Material real de Google

Validamos con tokens del ambiente de pruebas de Google y con tokens productivos que Google compartió para ese fin. Después llegaron los primeros pagos reales, aprobados.

“Como no existía una librería oficial para nuestro lenguaje, lo implementamos nosotros y lo validamos contra la librería oficial de Google, con la IA acelerando todo el proceso.”

04 · IA en el motor

Qué aportó la IA y qué decidió el equipo

En el equipo de Processor, la IA trabajó a la par de Luciano y sus compañeros durante todo el proyecto, en tareas concretas que aceleraron la construcción y la validación:

• Leyó la especificación de Google y la convirtió en una guía concreta de lo que había que construir.
• Nos permitió trabajar en Java, un lenguaje que el equipo no usa, para armar el programa de validación con la librería de Google.
• Escribió las herramientas de prueba en paralelo al código, incluidos el generador de pagos y los casos de error.
• Ayudó a encontrar problemas antes del lanzamiento. Google no envía el código de seguridad de la tarjeta (CVV) y nuestras propias reglas lo exigían; lo detectamos en pruebas y lo corregimos antes de salir a producción.

Las decisiones de fondo quedaron siempre en manos del equipo: la seguridad, la custodia de claves, el registro con Google y la revisión de cada cambio.

05 · Processor · Diseñado para producción

Decisiones pensadas para operar a escala

La clave que permite descifrar los pagos de Google Pay se genera y se guarda cifrada en un servicio dedicado a custodiarla, y solo el servicio encargado de descifrar los pagos puede pedirla. Alrededor de esa decisión construimos otras que hacen que la solución funcione igual para todos nuestros clientes.

• Rotación de claves sin cortes. Cuando llega un token, Akua prueba primero la clave activa y luego la anterior. Así podemos reemplazarla sin interrumpir el servicio, y ya lo hicimos en producción.
• Continuidad ante una caída de Google. Las claves públicas de Google se descargan y se renuevan solas. Si Google no responde, Akua sigue operando con la última versión vigente.
• Un solo registro para toda la región. Un único registro ante Google atiende a todos los países y clientes donde operamos.
• La misma tarjeta, un solo registro. Si un comprador ya pagó con una tarjeta y vuelve con la misma a través de Google Pay, Akua la reconoce y no duplica el registro.
• Pagos identificados. La consulta de un pago indica que se hizo con Google Pay y con qué método, información útil para reportes y conciliación sin integrar nada adicional.

Además, los datos de la tarjeta nunca se guardan sin cifrar ni aparecen en los registros del sistema, el token cifrado viaja solo entre los servicios internos que lo necesitan, y cada token sirve para un único pago y trae su propio vencimiento.

06 · Habilitación, con Nicolas Carrascosa

Qué cambia para tu operación de pagos

Para quien gestiona los pagos de un banco o una fintech, sumar Google Pay no implica una integración nueva. El pago llega por la misma API que ya usan y Akua se ocupa del resto, sin que tengan que manejar datos de tarjeta ni claves de Google. Una vez procesado, el pago se gestiona como cualquier otro: se puede capturar, anular o devolver, y la consulta de cada pago indica que se hizo con Google Pay, lo que simplifica los reportes y la conciliación.

Hay dos formas de ofrecerlo a los comercios. La primera es nuestro checkout white label y nuestros links de pago, que ya traen el botón de Google Pay integrado. La segunda es la integración vía API, siguiendo los pasos de nuestra documentación. Para el comprador, el resultado es el mismo en los dos casos: paga más rápido porque no tiene que escribir su tarjeta.

“Para tener Google Pay disponible, basta con contactar a nuestro equipo comercial. Una vez hecho el contacto, el cliente puede ofrecerlo a través de nuestro checkout white label o seguir los pasos de nuestra documentación para hacerlo vía API.”

07 · El equipo

Un equipo pequeño, con el problema del cliente en el centro

El proyecto reunió a tres especialistas de tres frentes: Luciano en Processor, a cargo de recibir y descifrar cada pago; Javier en Experience, responsable del botón en el checkout y del armado del request; y Nicolas en la coordinación con Google y la habilitación para clientes. Nicolas resume el proyecto en coordinación, velocidad y ejecución, y destaca el trabajo conjunto con Luciano y Javier. El trabajo con Google fue ágil, y su velocidad de respuesta y ejecución nos permitió implementar el botón de “Pagar con Google Pay” en muy poco tiempo.

“Cuando se arma un pequeño equipo que entiende la necesidad y las expectativas del cliente, los resultados son mejores. Eso es lo que me llevo para el próximo proyecto.”

En resumen

Lo que construyó el equipo detrás del botón

• Akua procesa Google Pay como gateway registrado: Google cifra los datos de la tarjeta para que solo Akua pueda abrirlos, y el comercio nunca ve esos datos ni administra claves.
• Cada token pasa por cuatro verificaciones antes de descifrarse, y cualquier falla implica el rechazo del pago.
• Implementamos ECv2 en Go con la criptografía estándar del lenguaje y lo validamos contra la librería oficial de Google, con tokens de prueba y con pagos reales en Visa y Mastercard.
• La IA aceleró la lectura de la especificación, las pruebas y la detección de problemas; las decisiones de seguridad y custodia de claves quedaron en el equipo.
• Nuestros clientes ofrecen Google Pay por la misma API o con el checkout white label y los links de pago, y cada pago se gestiona igual que cualquier otro.

Próximo paso

Ofrece Google Pay a tus comercios sobre la infraestructura de Akua

Conversemos sobre cómo habilitarlo en tu operación, por API o con nuestro checkout white label.

Agenda una demo Conoce el Checkout

Google Pay es una marca comercial de Google LLC.