FOP con token
Descripción general
Una FOP (forma de pago) con asignación de token es un tipo de integración de pagos 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 las credenciales de identidad de la cuenta por única vez. Esto, a su vez, atraviesa el flujo de establecimiento de un token que representa esa forma de pago para ese usuario en particular. Puedes utilizar este token para realizar pagos una y otra vez. Actualmente, hay 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 realizada por un usuario específico. Luego, el token se podrá usar en compras futuras.
Una vez que se establece el token, Google lo usará durante el flujo de compra para ofrecer al usuario una experiencia de pago rápida y fluida. Google usa este token para representar una instancia de una forma de pago realizada por un cliente. Esto también se conoce como instrumento. Los clientes de Google pueden tener más de un instrumento para pagar bienes y servicios.
Por último, todo el movimiento de dinero entre el banco del integrador y el de Google se realiza en el flujo de remesa.
|
|
|
|
|
En este diagrama, se ilustra una descripción general general de los flujos:
Descripción general de las FOP con token
En términos generales, agregar un 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 más detalle en la sección de guías.
Conceptos y terminología
Símbolos y convenciones
Las palabras clave "DEBE", "NO DEBE", "OBLIGATORIO", "DEBERÍA", "NO DEBERÁ", "DEBERÍA", "NO DEBERÁ", "RECOMENDADO", "PUEDE" y "OPCIONAL" de 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 de esta API están en un formato llamado "micros", un estándar de 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 = 1230,000 microUSD
- USD 0.01 = 10,000 microUSD
Idempotencia
Todas las llamadas de método dentro de esta API deben tener un comportamiento idempotente. Google reintentará las solicitudes de forma 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 solicitudes que ya se procesaron 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 sin terminal (una respuesta correcta que no sea HTTP 200), no se debe procesar de forma idempotente. Por lo tanto, una solicitud que anteriormente obtuvo un 400 (solicitud incorrecta o condición previa fallida), cuando se la llamó por segunda vez, no debe mostrar 400 de forma idempotente, debe volver a evaluarse. En la reevaluación, podría mostrar un 400 o procesarse correctamente.
Para obtener más información sobre la idempotencia, consulta esta guía detallada.
Integrador
Ser una empresa que usa la plataforma de pagos de Google en su negocio. Pueden ser internos, como YouTube o AdWords, o empresas externas que desean integrar su servicio para que funcione con el ecosistema de Google.
forma de pago
Forma de pago. Esto es más general que un instrumento. Visa, Mastercard y PayPal son todas formas de pago.
Instrumento
Una instancia en particular de una forma de pago por parte de un cliente específico. Por ejemplo, la tarjeta de crédito de un usuario o su cuenta de PayPal. Una FOP con token para un cliente en particular también es un instrumento, ya que es una instancia de una forma de pago para ese cliente, almacenada de forma segura en nuestro sistema.
Token
Representación en el sistema de Google de la forma de pago de un usuario específico. Como 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 de claves
Flujo de autenticación
La autenticación es el primer flujo que debe producirse. 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 token admiten dos formas de identificar y autenticar al usuario:
- Autenticación de OTP de SMS-MT (se canceló 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 adaptan a su producto.
Los flujos de autenticación se pueden usar en dos contextos: primero, para identificar a un cliente nuevo a fin de establecer una asociación, y en segundo lugar, para solicitar a un usuario las credenciales de un instrumento existente. El resultado del flujo de autenticación se puede usar como entrada en varios flujos, como el flujo de asociación, el flujo de tokens de actualización, el flujo de compra con verificación, 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 (mediante el 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 del integrador de pagos.
Cuando se usa la autenticación con OTP de SMS-MT en modo independiente, el valor de la OTP se envía al integrador mediante el método verifyOtp. Este método verifica que la OTP proporcionada sea la que se envió.
Autenticación de redireccionamiento
La autenticación de redireccionamiento ocurre cuando Google redirecciona al usuario a una aplicación que pertenece a un 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 ese integrador. 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 autenticación de identidad durante la asociación.
Los integradores que elijan este flujo deben proporcionar una URL de autenticación web, ya que 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 para proporcionar 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 a la Web o a la app para Android.
Este mecanismo de autenticación le brinda mayor libertad al integrador. Existen muchas formas de identificar y autenticar a un usuario. El nombre de usuario y la contraseña, o las preguntas sobre información biométrica y seguridad, son dos soluciones viables. Google no tiene la intención de determinar 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 pasa por el flujo de asociación. El propósito del flujo de asociación es establecer un token de Google Payment (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 configuración inicial necesaria 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 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 forma de pago tokenizada falsa llamada InvisiCash. Esto demuestra los pasos que deberá seguir un usuario para el flujo de autenticación y el flujo de asociación.
Descripción general del flujo de asociación
- Una usuaria 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 abrirá la app de InvisiCash para realizar la autenticación.
La usuaria accede a su cuenta de InvisiCash con la dirección de correo electrónico sally@otheremail.com. Es posible que se deba a que usa su dirección de Gmail para ambos casos si ese es el 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 de InvisiCash para asociar la cuenta. Esta asociación incluye un ID de autenticación, un
GPT(token de Google Payment) y un ID de asociación.Los servidores de InvisiCash almacenan el token de pago de Google (
GPT) y el ID de asociación. Ahora ambos están asociados a la cuenta de InvisiCash de Sally.InvisiCash aprueba esta asociación. Luego, los servidores de Google crean un instrumento que puede usarse para compras futuras.