Forma de pago con token
Descripción general
Una forma de pago con tokens es un tipo de integración de pago en la plataforma de pagos. Para que un usuario realice un pago con esta forma de pago, Google y el integrador de pagos deben intercambiar por única vez las credenciales de identidad de la cuenta. Esto, a su vez, pasa por el flujo de establecimiento de un token, que representa esa forma de pago para ese usuario en particular. Este token se puede usar para realizar pagos continuos. Actualmente, existen 2 versiones de estas APIs. La versión 2 es compatible con operadores de telefonía celular y proveedores de números de referencia. Todos los demás proveedores de FOP con tokens deben implementar la versión 1. El resto de este documento se centra en la versión 1.
Google usa dos flujos para establecer la identidad y crear este token:
- Flujo de autenticación: Identifica y verifica (autentica) al usuario.
- Flujo de asociación: Establece un token para un usuario (nuevo o previamente identificado y autenticado). Este token representa una forma de pago específica de un usuario en particular. El token se puede usar en compras futuras.
Una vez que se establece el token, Google lo usa durante el flujo de compra para brindar una experiencia de confirmación de la compra rápida y sin problemas al usuario. Google usa este token para representar una instancia de una forma de pago de un cliente. También se denomina instrumento. Un cliente de Google puede tener más de un instrumento para pagar bienes y servicios.
Por último, todo movimiento de dinero entre el banco del integrador y el banco de Google se realiza en el flujo de remesa.
|
|
|
|
|
En este diagrama, se muestra una descripción general de los flujos:
Descripción general de las FOP con tokens
En términos generales, agregar tu servicio como forma de pago a los productos de Google implica los siguientes flujos:
Estos flujos se describen con más detalle en las siguientes secciones y con mayor detalle en la sección de guías.
Conceptos y terminología
Símbolos & Convenciones
Las palabras clave “DEBEN”, "NO DEBE", "OBLIGATORIO", "SHALL", "NO DEBERÁ", "DEBERÍA", «NO DEBERÍAS», "RECOMENDADO", "MAYO", y "OPTIONAL" en estos documentos se deben interpretar como se describe en RFC 2119.
Marcas de tiempo
Todas las marcas de tiempo se representan como milisegundos desde el tiempo Unix (1 de enero de 1970) en UTC.
Por ejemplo:
- 23 de abril de 2019, 8:23:25 p.m. (GMT = 1556051005000 milisegundos)
- 16 de agosto de 2018 12:28:35 p.m. GMT = 1534422515000 milisegundos
Importes
Los valores monetarios en esta API están en un formato llamado "micros", un estándar en Google. Los micros son un formato de precisión fija basado en números enteros. Para representar un valor monetario en micros, multiplica el valor de la moneda estándar por 1,000,000.
Por ejemplo:
- USD 1.23 = 1230000 micro USD
- USD 0.01 = 10,000 microUSD
Idempotencia
Todas las llamadas a métodos dentro de esta API deben tener un comportamiento idempotente. Google volverá a intentar las solicitudes de manera esporádica para asegurarse de que las transacciones estén en el mismo estado en ambos lados. Los integradores no deben intentar volver a procesar ninguna solicitud que ya se haya procesado correctamente. En su lugar, se debe informar la respuesta del procesamiento correcto. Todos los métodos tienen un RequestHeader común que contiene un requestId. Este requestId es la clave de idempotencia para todas las llamadas.
Cualquier respuesta que no sea terminal (no HTTP 200-success) no debe procesarse de forma idempotente. Por lo tanto, una solicitud que previamente obtuvo un 400 (solicitud incorrecta/condición previa con errores), cuando se llamó por segunda vez, no debe mostrar 400 de forma idempotente, se debe volver a evaluar. En la reevaluación, podría mostrar un error 400 o procesarse correctamente.
Para obtener más información sobre la idempotencia, consulta esta guía detallada.
Integrador
Una empresa que usa la plataforma de pagos de Google para su negocio. Podría ser una empresa interna (propia), como YouTube o AdWords, o una empresa externa (de terceros) que desea integrar su servicio para funcionar con el ecosistema de Google.
Forma de pago
Forma de pago. Esto es más general que un instrumento. Visa, Mastercard y PayPal son formas de pago.
Instrumento
Es una instancia particular de una forma de pago realizada por un cliente específico. Por ejemplo, la tarjeta de crédito de un usuario o su cuenta de PayPal. Una FOP con tokens asignados a un cliente en particular también es un instrumento porque es una instancia de una forma de pago para ese cliente que se almacena de forma segura en nuestro sistema.
Token
Es una representación, en el sistema de Google, de la forma de pago de un usuario específico. Debido a que contiene toda la información necesaria para realizar una compra, un token también es un instrumento. Esto puede incluir información como el número de cuenta que un usuario tiene con su integrador.
Flujos clave
Flujo de autenticación
La autenticación es el primer flujo que se debe llevar a cabo. El propósito del flujo de autenticación es identificar y autenticar al usuario en el integrador. La autenticación puede ocurrir de varias maneras. Las FOP con tokens admiten dos formas de identificar y autenticar al usuario:
- Autenticación de OTP de SMS-MT (se cerró el SMS para dispositivos móviles, contraseña de un solo uso)
- Autenticación de redireccionamiento
Durante la integración, los integradores trabajan con Google para elegir los mecanismos de autenticación que mejor se adapten a su producto.
Los flujos de autenticación se pueden usar en dos contextos: en primer lugar, para identificar a un cliente nuevo con el fin de hacer una asociación y, en segundo lugar, para desafiar a un usuario por las credenciales de un instrumento existente. El resultado del flujo de autenticación se puede usar como entrada para varios flujos, como el flujo de asociación, el flujo de token de actualización, el flujo de compra con problemas, etcétera. Además, el flujo de autenticación se puede usar en modo independiente, no vinculado a ningún flujo posterior.
Autenticación de OTP de SMS-MT
En este mecanismo de autenticación, el usuario ingresa un número de teléfono en una IU de Google. Google envía este número de teléfono al integrador (a través del método sendOtp). El integrador envía una contraseña de un solo uso al usuario. El usuario ingresa la contraseña en la IU de Google, que la envía al integrador. Esto activa una respuesta exitosa por parte del integrador de pagos.
Cuando se usa la autenticación de OTP por SMS-MT en modo independiente, el valor de la OTP se envía al integrador con el método verifyOtp. Este método verifica que la OTP proporcionada sea la que se envió.
Autenticación de redireccionamiento
La autenticación por redireccionamiento ocurre cuando Google redirecciona al usuario a una aplicación propiedad del integrador. Esa aplicación puede ser una aplicación web o para Android.
Los redireccionamientos de Android y Web se comportan de manera similar. Google redirecciona al usuario a la app del integrador. El integrador identifica y autentica al usuario de la forma que sea más natural para él. Una vez autenticado, el integrador redirecciona al usuario de vuelta a la IU de Google para finalizar la asociación. Después del redireccionamiento, Google proporciona un requestId para identificar esta sesión de autenticación. Luego, ese identificador se usa como prueba de identidad para la autenticación durante la asociación.
Los integradores que eligen este flujo deben proporcionar una URL de autenticación web, ya que este es el denominador más común en todas las plataformas (computadoras de escritorio o dispositivos móviles). Sin embargo, se recomienda la autenticación de Android, ya que proporciona la mejor experiencia del usuario en dispositivos móviles.
Según el contexto del dispositivo y las apps instaladas, las IU de Google elegirán el redireccionamiento de la app para Android o la Web.
Este mecanismo de autenticación le proporciona al integrador más libertad. Hay muchas formas de identificar y autenticar a un usuario. El nombre de usuario y la contraseña, o la información biométrica y las preguntas de seguridad, son soluciones viables. Google no pretende dictar cómo un integrador verifica a un usuario. El integrador se encarga de autenticar al usuario. De esta manera, Google pretende aprovechar las diversas interfaces de usuario del integrador para autenticar al usuario y simplemente proporcionarle una prueba de autenticación.
Para obtener más información sobre la autenticación, consulta esta guía detallada.
Flujo de asociación
Después del flujo de autenticación a través de uno de los mecanismos mencionados anteriormente, el usuario avanza por el flujo de asociación. El propósito del flujo de asociación es establecer un token de Google Payments (GPT) para crear un instrumento. Este flujo hace lo siguiente:
- Negocia una identidad llamada token para representar a este usuario.
- Proporciona información de la cuenta para informar al motor de riesgos de Google.
- Recopila la información necesaria de la configuración inicial para crear y establecer el
GPT.
El resultado es que Google y el integrador acuerdan el GPT establecido.
Dos usuarios de Google pueden compartir la misma cuenta de usuario con el integrador. En este caso, cada usuario tendría un instrumento diferente. Para cada instrumento hay un flujo de asociación independiente y, por lo tanto, un GPT único.
En esta ilustración, se muestra una FOP con tokens falsos llamada InvisiCash. Esto demuestra los pasos que debe seguir un usuario para el flujo de autenticación y el flujo de asociación.
Descripción general del flujo de la asociación
- Un usuario de Google con la dirección de correo electrónico sf@gmail.com quiere agregar su cuenta de InvisiCash a Google Play Store para poder usarla para hacer compras.
- Google Play Store abre la app de InvisiCash para la autenticación.
El usuario accede a su cuenta de InvisiCash con la dirección de correo electrónico sally@otheremail.com. Es posible que use su dirección de correo electrónico de Gmail para ambas opciones si esa es la información de acceso de su cuenta de InvisiCash.
La app de InvisiCash envía el ID de autenticación a Google Play Store.
Google Play Store envía el ID de autenticación a los servidores de Google.
El servidor de Google envía un mensaje al servidor InvisiCash para asociar la cuenta. Esta asociación incluye un ID de autenticación,
GPT(token de Google Payments) y un ID de asociación.Los servidores de InvisiCash almacenan el token de Google Payments (
GPT) y el ID de la asociación. Ambos ahora están asociados a la cuenta InvisiCash de Sally.InvisiCash aprueba esta asociación. Luego, los servidores de Google crean un instrumento que se puede usar para compras futuras.