Por definir: Agrega una breve descripción de la billetera electrónica (igual que se hace con el dinero electrónico).
Por definir: Mira una demostración del flujo de billetera electrónica después de integrar tu FoP en las entidades de Google.
A continuación, se describen los flujos clave de Google Standard Payments involucrados en una transacción con billetera electrónica.
Flujo de la asociación
Google Standard Payments permite a los integradores crear un flujo de creación de instrumentos y un flujo de compra para brindar una experiencia de confirmación de la compra rápida y fluida a sus usuarios.
Un cliente de Google tiene uno o más instrumentos. Un instrumento es una forma de pagar por servicios y bienes en los diversos ecosistemas y mercados de Google. Para agregar un instrumento, el usuario debe vincular un instrumento con credenciales externas y autenticarlas. Un buen ejemplo es una tarjeta de crédito. Una tarjeta de crédito tiene un número de tarjeta (PAN) que Google almacena y un número de verificación de tarjeta (CVN) que se usa para la autenticación. El usuario agrega un instrumento ingresando el PAN y el CVN en una IU de Google. Google almacena el PAN de forma segura después de que el procesador de la tarjeta de crédito verifica los números PAN y de CVN. De manera similar, en esta especificación, vincularemos la prueba de autenticación con un instrumento del lado de Google. A esta vinculación de la cuenta a un instrumento lo llamamos flujo de asociación.
El resultado del flujo de asociación es el intercambio del token de pago de Google (GPT) que aceptan Google y el integrador. Durante la captura, la etiqueta GPT se pasa al integrador de pagos (que mantiene la cuenta de usuario) para identificar la cuenta de usuario a la que se facturará.
Existen muchas formas de autenticar a un usuario para demostrar la propiedad de una cuenta. Los nombres de usuario y las contraseñas son unidireccionales, pero las OTP, la información biométrica y las preguntas de seguridad también son soluciones viables. Google no pretende dictar cómo un integrador de pagos verifica a un usuario. Creemos que el integrador de pagos hace esto de la mejor manera. Por lo tanto, como parte de esta especificación, Google quiere aprovechar las diversas interfaces de usuario del integrador de pagos para autenticar al usuario y simplemente proporcionar a Google una prueba de autenticación. A esto lo llamamos flujo de autenticación.
El resultado del flujo de autenticación es la prueba de autenticación.
El flujo de asociación requiere que Google proporcione una prueba de autenticación por parte del integrador de pagos. Antes del flujo de asociación, Google invoca el flujo de autenticación para obtener esta prueba.
En el siguiente ejemplo, se muestran los pasos que realizará un usuario para el flujo de autenticación y el de asociación. En el siguiente ejemplo, se muestra una billetera electrónica falsa llamada InvisiCash.
Notas sobre este diagrama:
- En los pasos 1 y 3, ten en cuenta que la identidad del usuario (correo electrónico) es diferente entre InvisiCash y Google.
sf@gmail.comysally@otheremail.com, respectivamente. Esto está bien y se espera. - Entre los pasos 3 y 4, la app de InvisiCash (o la IU web si el usuario no la tiene instalada) puede hacer lo necesario para autenticar al usuario, incluida la comunicación con el servidor de InvisiCash.
Flujo de compra
Una vez que finalice la asociación y el usuario tenga un instrumento nuevo, puede usarlo para comprar bienes y servicios a través de Google. En el momento de la compra, el usuario puede o no estar en la sesión. Todo depende del contexto de la compra. Por ejemplo, para una compra basada en una suscripción, es probable que el usuario no esté en la sesión. En el momento de la compra, Google presentará la GPT al integrador de pago. El integrador de pagos usará esta GPT para identificar la cuenta correcta a debitar. Esto se denomina flujo de compra.
El siguiente ejemplo continúa después de que el usuario sf@gmail.com realice la asociación y se cree un instrumento. El usuario ahora quiere comprar bienes.
En ocasiones, es posible que tanto el integrador de pagos como Google requieran que el usuario se autentique antes de realizar una compra. Hay varios motivos para esto. Por ejemplo:
- El motor de riesgos de Google determina que un pago parece sospechoso
- Los requisitos reglamentarios exigen una OTP en cada compra
En esos casos, Google vinculará el flujo de autenticación con el de compra. Se enviará al usuario a la IU del integrador para su autenticación. El resultado del flujo de autenticación es la prueba de la identidad y la autenticación del usuario. Esta prueba se envía junto con la información de la compra durante el flujo de compra.
En el siguiente ejemplo, el usuario sf@gmail.com realizó la asociación y se creó un instrumento. Durante el flujo de compra, el servidor de Google desea desafiar a este usuario para brindar protección contra fraudes:
Flujo de tokens de actualización
Durante el flujo de asociación, el integrador de pagos puede indicarle a Google que esta GPT vence en X meses. Si bien Google prefiere los tokens que no venzan, reconoce que este no siempre puede ser así y, por lo tanto, admite el vencimiento de tokens. Cuando un token está por vencer, Google envía al usuario a través de un flujo de autenticación. Se envía al usuario a la IU del integrador para su autenticación. El resultado del flujo de autenticación es la prueba de la identidad y la autenticación del usuario. Luego, estas pruebas se envían al integrador para extender la fecha de vencimiento de la GPT. Esto se llama flujo de refreshToken.
El siguiente ejemplo continúa después de que el usuario sf@gmail.com realice la asociación y se cree un instrumento. El token del usuario vencerá pronto, por lo que Google le solicita al usuario que actualice el instrumento:
El flujo de autenticación se usa de dos modalidades diferentes. La primera es cuando se intenta autenticar a un usuario durante el tiempo de asociación. En este momento, se desconoce la identidad del usuario y depende del usuario ingresarla. La identidad puede ser un nombre de usuario, una dirección de correo electrónico o un número de teléfono. La segunda modalidad es intentar autenticar que el usuario conoce las credenciales de un instrumento existente. En esta situación, el usuario ya agregó el instrumento y asoció la cuenta de su integrador de pagos. En esta modalidad, queremos verificar que la persona tenga credenciales para una identidad de usuario en particular. El usuario no debe poder cambiar la identidad de la cuenta que se verifica. Para ello, le enviamos al integrador de pagos un ID de asociación en el momento de la asociación. En el momento de la autenticación, Google envía el mismo ID de asociación al integrador. El integrador usa el ID de asociación para buscar la cuenta que se debe autenticar.
Flujo de remesas
Google es el sistema contable de registro y se encarga de las transferencias de remesas. Todos los días, Google envía un resumen de remesas al integrador de pago. En el resumen, se proporciona un resumen del importe que el integrador de pago le debe a Google, junto con las instrucciones para pagarle a Google. Para que el integrador de pagos se concilie, puede consultar a Google sobre los detalles a nivel de la transacción que conforman la declaración de remesa.
A continuación, se muestra el flujo de ejemplo: 