¿Qué es Google Pay?

Google Pay es la cartera digital de Google, que se usa para pagar con una tarjeta bancaria guardada en teléfonos Android, relojes Wear OS y dentro de Chrome en la web. Empezó como Android Pay en 2015, pasó a llamarse Google Pay en 2018 y se fusionó con Google Wallet en 2022: en Estados Unidos la marca ahora es Google Wallet, mientras que en el Reino Unido y la mayoría de los demás mercados la cartera en sí sigue llamándose Google Pay. Entre bastidores usa tokenización: el número de tarjeta real se cambia por un Número de Cuenta del Dispositivo, de modo que lo que recibe el comercio no puede reutilizarlo nadie más. La autenticación se gestiona en el dispositivo mediante huella, cara o PIN, lo que significa que Google Pay satisface la Autenticación Reforzada de Cliente bajo PSD2.

Google Pay (que algunos documentos antiguos todavía llaman Android Pay, y rebautizado como Google Wallet en EE. UU.) hace dos tareas distintas que a menudo se confunden. En una tienda, es una cartera contactless por NFC: desbloquea el teléfono, lo acercas al terminal y el chip de emulación de tarjeta envía un pago tokenizado exactamente igual que lo haría una tarjeta sin contacto. En la web y en las apps, es un botón de pago de un solo toque que saca una tarjeta guardada de tu cuenta de Google y la pasa por la Payment Request API o el SDK de JavaScript de Google Pay. La experiencia que ve el cliente parece la misma; la fontanería de debajo es completamente distinta.

El lío de los nombres: Android Pay, Google Pay, Google Wallet

Si tienes dudas sobre cómo llamarlo, es porque Google ha cambiado el nombre tres veces en ocho años. Android Pay se lanzó en septiembre de 2015 como la mitad contactless. Google Wallet, que existía desde 2011 como producto de pagos entre particulares, era la mitad de almacenamiento. En enero de 2018 Google los fusionó en una sola marca llamada Google Pay. Luego, en 2022, los volvió a separar, pero solo en EE. UU., donde la cartera contactless pasó a llamarse Google Wallet y "Google Pay" se convirtió en el término paraguas que cubre la cartera más otras funciones de pago de Google.

En el Reino Unido, la UE y la mayor parte del resto del mundo, la cartera en el lenguaje cotidiano sigue llamándose Google Pay, y la propia documentación de Google usa ambos nombres según en qué página caigas. Para los comercios que integran el botón de pago, el SDK sigue llamándose Google Pay API en cualquier región. Usaremos "Google Pay" a lo largo de esta entrada porque es lo que ve el cliente británico en el botón.

Cómo funciona Google Pay de verdad

Cuando añades una tarjeta a Google Pay, Google no guarda el número de tarjeta en tu teléfono. Entrega el número a la red de tarjetas —Visa, Mastercard, Amex— que devuelve un Número de Cuenta del Dispositivo, a veces llamado PAN del dispositivo. Ese token es lo que vive en tu teléfono. Cada vez que acercas el teléfono para pagar, tu dispositivo envía el PAN del dispositivo más un criptograma de un solo uso, único para esa transacción. El banco adquirente devuelve el criptograma a la red, que lo des-tokeniza y le dice al banco emisor que autorice el pago contra tu tarjeta real.

Si te roban el teléfono, el PAN del dispositivo puede anularse sin cancelar tu tarjeta real. Por eso la mayoría de los bancos tratan Google Pay como un riesgo de fraude menor que una tarjeta tecleada a mano: el comercio nunca ve el PAN real, y el criptograma no se puede repetir.

El criptograma en lenguaje llano

El criptograma es un breve fragmento de datos criptográficos que demuestra tres cosas a la vez: que el pago vino de un token real de Google Pay, que el token se autenticó en el dispositivo (huella, cara o PIN), y que el token no se ha usado antes. La red comprueba el criptograma contra las claves que compartió con el dispositivo cuando se aprovisionó la tarjeta. Si algo no cuadra —clave equivocada, valor repetido, ausencia del indicador de autenticación— la transacción se rechaza a nivel de red, antes incluso de llegar al banco emisor.

Es el mismo modelo de criptograma EMV que usan las tarjetas contactless físicas, solo que generado por software en el teléfono en lugar de por el chip de la tarjeta. Desde la perspectiva del emisor, el mensaje entrante parece una transacción con chip y PIN, y por eso los pagos con Google Pay obtienen el nivel de intercambio más bajo y el reparto de responsabilidad por fraude más favorable al comercio.

Lo que el teléfono envía realmente al terminal

La carga NFC que va del teléfono al terminal contiene el PAN del dispositivo, una fecha de caducidad del token (que es más corta que la caducidad real de la tarjeta, porque Google rota los PAN del dispositivo periódicamente), el criptograma, un contador de transacciones de la aplicación y un indicador que dice que el usuario se autenticó en el dispositivo. El terminal lo trata exactamente igual que una transacción con tarjeta contactless. La mayoría de los terminales modernos ni siquiera saben que es un teléfono: solo ven datos EMV contactless y los pasan por la cadena de adquirencia.

Google Pay en la web

Google Pay en la web funciona a través de una API de JavaScript y la Payment Request API estándar del navegador. El comercio añade el botón de Google Pay a su proceso de pago, y cuando el cliente lo pulsa, el navegador muestra una hoja con las tarjetas guardadas en la cuenta de Google de ese cliente. El cliente elige una, y Google devuelve una carga de pago tokenizada al procesador de pagos del comercio. El procesador desempaqueta el token y ejecuta la transacción.

La mayoría de los grandes adquirentes del Reino Unido —Stripe, Adyen, Worldpay, Braintree— admiten Google Pay de forma nativa, así que para un comercio que integra en una de esas pasarelas, activarlo suele ser cuestión de un parámetro de configuración y no de un proyecto de desarrollo. Lo más complicado son los requisitos para el comercio: un dominio verificado, un procesador de pagos con Google Pay habilitado y un proceso de pago que llame correctamente a la Google Pay API.

Dos formatos de datos de pago: ECv2 y tokens directos de pasarela

La Google Pay API devuelve los datos de la tarjeta en uno de dos formatos según cómo haya integrado el comercio. Con la integración de pasarela, el token se cifra con la clave pública del procesador de pagos y el procesador lo desempaqueta en su propia infraestructura: Stripe, Adyen y los demás lo hacen así. El comercio nunca tiene nada que pueda convertirse de nuevo en un número de tarjeta, así que la integración se sitúa dentro del alcance de SAQ A.

Con la integración directa, el comercio toma él mismo el token cifrado, lo descifra usando sus propias claves emitidas por la red y reenvía el PAN descifrado a su adquirente. Esto es raro en el Reino Unido porque mete al comercio en un alcance de PCI mucho mayor (SAQ D), y la única razón real para usarlo es que uno mismo sea un proveedor de servicios de pago. Para el 99 % de los comercios del Reino Unido, la integración de pasarela es la respuesta correcta.

Compatibilidad de navegadores y la Payment Request API

Google Pay en la web funciona en Chrome, Edge, Safari (en macOS e iOS), Firefox y Samsung Internet. Chrome y Edge usan la Payment Request API de forma nativa. Safari recurre a un flujo basado en JavaScript porque Apple reserva la Payment Request API para Apple Pay. El botón se ve idéntico para el cliente, pero por debajo Safari carga el SDK de JS de Google Pay directamente en lugar de pasar por la hoja de pago del navegador.

Esto importa en un caso concreto: si un cliente está en Safari de iPhone, verá los botones de Apple Pay y de Google Pay si has activado ambos. Algunos comercios ocultan el botón de Google Pay en Safari de iOS porque la tasa de conversión con Apple Pay es mayor en ese segmento. Si hacerlo o no es una decisión de optimización de conversión, no una limitación técnica.

Google Pay por teléfono: donde no funciona

Este es el hueco que pilla por sorpresa a muchos comercios. Google Pay está pensado para el pago presencial sin contacto, el pago en apps y el pago en la web. No hay una variante telefónica. Si un cliente llama a su centro de contacto y quiere pagar, no puede pedirle que "use Google Pay" en ningún sentido práctico: la cartera no tiene canal de audio, ni ruta DTMF, ni una llamada de API que su agente pueda lanzar desde un CRM.

Lo más parecido que puede hacer es enviar al cliente un enlace de pago por SMS o correo electrónico que abra una página de pago alojada con un botón de Google Pay. El cliente pulsa el enlace, toca Google Pay, se autentica con su huella y el pago se completa. El agente sigue en la llamada mientras ocurre. Este es el modelo que sigue la función Pay-By-Link de Paytia para los clientes que quieren pagar durante una llamada sin teclear los dígitos de la tarjeta.

Para los clientes que sí quieren teclear el número de tarjeta en el teclado del teléfono, Google Pay no interviene: eso es captura DTMF con los dígitos suprimidos antes de que lleguen al agente. Los dos métodos conviven en la mayoría de los centros de contacto, porque no todo el que llama tiene Google Pay configurado, y no toda transacción funciona a través de un enlace web.

Dónde encaja Google Pay con PCI DSS

Como las cargas de Google Pay se tokenizan antes de llegar al comercio, aceptar Google Pay reduce la cantidad de datos de tarjeta que tocan sus sistemas. Eso no le exime de PCI —el token sigue tratándose como dato de cuenta y la integración alrededor sigue necesitando controles de PCI— pero sí estrecha el entorno de datos del titular de la tarjeta frente a tomar un número de tarjeta tecleado a mano. Para un comercio en SAQ A que ya solo recibe pagos tokenizados a través de una página alojada, añadir Google Pay suele encajar dentro del alcance existente.

Detalles concretos de PCI DSS v4.0.1

Bajo el estándar actual (v4.0.1, en vigor desde marzo de 2024), la integración de Google Pay en la web se trata como un canal de pago de comercio electrónico externalizado siempre que el comercio use la integración de pasarela. El comercio tiene que conservar pruebas de que el SDK de JS de Google Pay se carga desde el dominio de Google (no una copia alojada en el propio servidor del comercio), de que están en su sitio los controles de integridad de scripts a nivel de página del Requisito 6.4.3, y de que los requisitos de detección de cambios del 11.6.1 cubren la página de pago. Esos son los mismos controles que un comercio ya necesita para cualquier formulario de tarjeta alojado, así que para los comercios en SAQ A la carga marginal de cumplimiento de añadir Google Pay es pequeña.

Para el caso de NFC en la app, PCI no se aplica al propio dispositivo del consumidor —el teléfono es del cliente, no del comercio— pero el lado de la adquirencia sigue teniendo que cumplir PCI. Ese es el problema del adquirente, no del comercio.

Reglas de las redes y reparto de responsabilidad

Visa y Mastercard clasifican las transacciones de Google Pay como con tarjeta presente cuando el pago ocurre por NFC en un terminal físico, y con tarjeta no presente (con criptograma de token) cuando ocurre en la web o en una app. El tratamiento de tarjeta presente es el importante: un toque de Google Pay en un terminal obtiene el mismo reparto de responsabilidad que una transacción con chip y PIN, lo que significa que el emisor asume el riesgo de fraude si el criptograma se autenticó correctamente. Para el comercio electrónico, el criptograma cuenta como el factor de SCA, lo que significa que el comercio no necesita añadir 3-D Secure por encima.

Autenticación Reforzada de Cliente y Google Pay

Bajo PSD2 (Reino Unido y UE), la mayoría de los pagos con tarjeta online necesitan dos de: algo que el cliente sabe, algo que tiene y algo que es. Google Pay se encarga de todo esto en el dispositivo: la posesión es el propio teléfono, el factor de inherencia es la huella o el escaneo facial, y el factor de conocimiento (el PIN) está disponible como alternativa. El criptograma que el dispositivo envía al comercio demuestra que la autenticación en el dispositivo se produjo, así que el banco puede marcar el pago como cumplidor de SCA sin lanzar un desafío 3-D Secure aparte.

Para los comercios, esto significa que los procesos de pago con Google Pay tienen tasas de finalización notablemente más altas que los procesos de pago con tarjeta y 3DS, porque el cliente nunca ve una redirección a su banco. El flujo es: toca el botón, huella, listo. Hemos visto a comercios de comercio electrónico del Reino Unido obtener un aumento de conversión del 6-10 % por la vía de Google Pay frente a introducir una tarjeta y pasar por un desafío 3DS.

Lo que Google Pay no hará

Google Pay es una cartera, no un procesador de pagos. No adquiere transacciones, no liquida fondos y no asume el fraude. Lo único que hace es presentar una tarjeta guardada a un comercio en una forma tokenizada y autenticada por SCA: el resto del recorrido del pago pasa por los mismos bancos y redes que un pago normal con tarjeta. Tampoco hay comisión del emisor en el Reino Unido ni en la mayoría de los demás mercados. El cliente paga lo mismo que pagaría con la tarjeta subyacente, y el comercio paga las mismas comisiones de intercambio y de red que pagaría por una transacción contactless o con tarjeta no presente, respectivamente.

Una limitación real: Google Pay solo funciona con tarjetas de emisores admitidos. La mayoría de los bancos tradicionales y los neobancos del Reino Unido lo admiten, pero un puñado de tarjetas corporativas y de prepago todavía no. Si está implantando Google Pay como opción de pago, la respuesta práctica es dejar la introducción de tarjeta con tarjeta no presente como alternativa para los clientes cuya tarjeta no esté registrada.

Casos límite y modos de fallo

Algunas cosas que prever si va a añadir Google Pay al proceso de pago. PAN del dispositivo rotados: Google puede reemitir el token en el dispositivo en cualquier momento, lo que significa que un flujo de tarjeta guardada para más adelante tiene que usar el token de red de la red de tarjetas (que conserva el adquirente) en lugar de cachear el PAN del dispositivo. Viajes y cambios de SIM: Google Pay funciona en cualquier país en el que la tarjeta subyacente esté habilitada, pero a veces los clientes se encuentran con la cartera bloqueada tras un cambio de SIM hasta que se vuelven a autenticar, lo que puede romper una transacción a mitad del proceso. Reembolsos: los reembolsos vuelven a la tarjeta real subyacente, no al PAN del dispositivo, así que el cliente ve el abono en su extracto con la identidad de la tarjeta original. Eso está bien para la mayoría de los casos de uso, pero hace tropezar a la lógica de conciliación que espera identificadores de token simétricos en la fase del reembolso.

El fallo más común que vemos en producción es un dominio sin verificar. Google Pay se niega a mostrar el botón en cualquier dominio que no esté preregistrado en la Google Pay Business Console. Los comercios que añaden un subdominio nuevo (checkout.example.com después de lanzar en www.example.com) y olvidan registrarlo se encuentran con un fallo silencioso sin botón mostrado: el SDK de JS simplemente no se inicializa. Compruebe siempre el registro del dominio primero cuando el botón deje de aparecer.

Comparación de Google Pay con otras opciones de cartera

La otra gran cartera móvil del mercado del Reino Unido es Apple Pay, que funciona con los mismos principios de tokenización EMV pero solo en dispositivos Apple. La mayoría de los comercios activan ambas, porque las audiencias apenas se solapan: los clientes con iPhone usan Apple Pay, los de Android usan Google Pay, y el coste de añadir el segundo botón una vez integrado el primero es casi nulo en todas las grandes pasarelas del Reino Unido.

También hay carteras específicas de bancos (Samsung Wallet, los pagos desde la app de Barclays, el pago por tarjeta de Monzo Plus) que funcionan con una fontanería parecida pero con una adopción mucho menor. Para un proceso de pago de comercio electrónico, admitir Apple Pay y Google Pay cubre alrededor del 95 % del mercado de carteras en el Reino Unido; añadir más botones de cartera rara vez justifica el recargo visual del proceso de pago.

Luego está la categoría más amplia de las transferencias bancarias: los flujos de pago por banco de Open Banking que esquivan por completo los rieles de tarjeta. Esos son una decisión aparte de si añadir o no Google Pay; tienden a encajar en pagos B2B de mayor valor donde importa el ahorro en intercambio, mientras que Google Pay tiende a ganar en el comercio electrónico de consumo, donde importan más la rapidez y el cumplimiento de SCA.

Lo que le cuesta al comercio

Google no cobra al comercio una comisión por transacción por Google Pay. El procesador sí, pero a la misma tarifa que cobraría por la tarjeta subyacente. Una tarjeta de débito Visa con Google Pay le cuesta al comercio lo mismo que una tarjeta de débito Visa tecleada a mano, salvo por las reservas de fraude más bajas que un procesador podría aplicar gracias a la tokenización y a la prueba de SCA. Algunos procesadores incluso cobran las transacciones de Google Pay algo más baratas que los pagos equivalentes con tarjeta no presente, porque el criptograma cuenta como prueba de SCA y reduce su riesgo de suscripción.

El coste de integración suele ser unas pocas horas de trabajo de front-end para añadir el botón y llamar a la API, más las pruebas. No hay ningún proceso de certificación que el comercio tenga que pasar más allá de la verificación del dominio en la Google Pay Business Console.

Cómo usa Paytia Google Pay

Paytia es una plataforma de pago para centros de contacto, no un botón de pago, así que no mostramos la hoja de Google Pay en el sitio web de un comercio. Donde Google Pay encaja en nuestro mundo es en la vía de Pay-By-Link: cuando un cliente llama y prefiere no teclear los dígitos de la tarjeta por teléfono, nuestros agentes pueden enviar un enlace de un solo toque a una página de pago alojada por Paytia. Esa página muestra Google Pay (y Apple Pay) como opciones, el cliente se autentica en el dispositivo y el pago aterriza directamente en la pasarela del comercio. El agente sigue en la llamada, el comercio nunca ve el número de tarjeta y la transacción se completa con prueba completa de SCA. Para quienes llaman y prefieren teclear su tarjeta en el teclado, nuestra captura con enmascaramiento DTMF funciona en paralelo: los dos métodos cubren a toda la audiencia de pagos del centro de llamadas.

Preguntas frecuentes

¿Es Google Pay lo mismo que Google Wallet?

En EE. UU., Google Wallet es la aplicación de la cartera y Google Pay es la marca de pagos más amplia. En el resto del mundo, la cartera sigue llamándose Google Pay. La tecnología subyacente es idéntica: la misma tokenización con PAN del dispositivo, el mismo modelo de criptograma, el mismo tratamiento de SCA.

¿Reduce Google Pay mi alcance de PCI?

Puede hacerlo. Si ya está en SAQ A usando un proceso de pago alojado, Google Pay se sitúa dentro de ese mismo alcance y no lo amplía. Si actualmente toma números de tarjeta directamente en sus propios sistemas, añadir Google Pay al lado no reduce su alcance: tendría que mover también la vía de entrada de tarjeta a un formulario alojado.

¿Necesito 3-D Secure por encima de Google Pay?

No. El criptograma que Google Pay envía ya contiene una prueba de SCA, y los emisores del Reino Unido y la UE la aceptan como cumplimiento de los requisitos de PSD2 sin un desafío 3DS aparte. Algunos adquirentes todavía hacen una comprobación 3DS suave en transacciones de alto valor como control de fraude, pero no muestra al cliente una pantalla de desafío.

¿Puedo cobrar con Google Pay por teléfono?

No directamente: no hay canal de audio ni DTMF para Google Pay. El apaño es enviar un enlace de pago por SMS o correo electrónico durante la llamada. El cliente pulsa el enlace, completa Google Pay en su navegador y el agente sigue en la línea hasta que el pago se confirma.

¿Por qué no aparece el botón de Google Pay en mi proceso de pago?

La causa más común es que el dominio no está registrado en la Google Pay Business Console. La segunda más común es que el dispositivo o el navegador del cliente no tiene ninguna tarjeta guardada: el botón solo se muestra cuando hay al menos una tarjeta admitida disponible. Menos común: a veces los bloqueadores de anuncios bloquean el SDK de JS de Google Pay en el CDN del comercio.

¿Los reembolsos vuelven a Google Pay o a la tarjeta original?

Los reembolsos se liquidan en la tarjeta real subyacente, no en el PAN del dispositivo. El cliente ve el abono en el mismo extracto de tarjeta que vería para cualquier otro reembolso. A efectos de conciliación, el identificador del reembolso se vincula a la transacción original de Google Pay a través de la pasarela, no a través del token.

¿Qué pasa con una transacción de Google Pay si el teléfono del cliente está sin conexión?

Para el NFC en tienda, Google Pay puede completar un pequeño número de transacciones sin conexión porque el criptograma se genera en el dispositivo y se valida después. Para los pagos en la web y en la app, el dispositivo necesita estar conectado, tanto para obtener las tarjetas guardadas del usuario como para enviar la carga a los servidores de Google. No hay opción de pago sin conexión para Google Pay en comercio electrónico.

¿Funciona Google Pay para pagos recurrentes o de suscripción?

Sí, a través del token de red en lugar del PAN del dispositivo. Cuando el cliente hace el primer pago con Google Pay, el adquirente puede pedir a la red que emita un token de red estable a lo largo de los recobros. Los cargos posteriores pasan por ese token sin necesidad de que Google Pay se vuelva a autenticar cada vez, aunque el cliente puede revocar el token desde su cuenta de Google si quiere cancelar la suscripción.