Iniciar el flujo de redireccionamiento

Descripción general

El propósito del flujo para iniciar el redireccionamiento es redireccionar al usuario al integrador de pagos con información suficiente para completar un pago. A su vez, el integrador redirecciona al usuario a la interfaz web de una entidad emisora y reenvía la información que proporciona Google. El usuario puede seguir las instrucciones proporcionadas por la entidad emisora para completar un pago. Esto activará el flujo de redireccionamiento completo.

Cómo funciona el flujo

El usuario puede seleccionar la entidad emisora que usará como forma de pago (FOP) de dos maneras.

  1. El usuario selecciona al emisor en la interfaz de usuario (IU) de Google.
  2. El usuario selecciona el integrador en la IU de Google y la entidad emisora en la IU del integrador.

El usuario selecciona al emisor en la IU de Google

En este caso, el usuario selecciona una entidad emisora durante la selección de una FOP en la IU de Google, por lo que el campo issuerId del objeto formOfPayment en RedirectRequest contendrá un identificador único generado por Google que representa a una entidad emisora. Ten en cuenta que, si el integrador de pagos y la entidad emisora son la misma entidad, Google generará un issuerId para el integrador de pagos. La solicitud de redireccionamiento usa un método GET de HTTPS, con parámetros codificados en la URL.

Iniciar el flujo de redireccionamiento (se seleccionó a la entidad emisora)

En el siguiente diagrama de secuencias, se muestra la interacción entre el navegador del usuario, Google, el integrador y la entidad emisora cuando el usuario selecciona una entidad emisora en la IU de Google:

Inicia el flujo de redireccionamiento con la entidad emisora seleccionada

A continuación, se muestra la lista de objetos del diagrama anterior:

  • Usuario: Es la persona que desea realizar un pago.
  • IU de Google: Es la interfaz web o de la app de Google, donde el cliente inicia un pago.
  • Servidor de Google: Es el servidor de backend de Google que crea una solicitud de redireccionamiento.
  • Integrador de pagos: Es el integrador que reenvía al usuario y la solicitud de redireccionamiento a la entidad emisora.
  • Emisor: Es la entidad emisora a la que el usuario tiene una cuenta.

En el caso del flujo para iniciar el redireccionamiento, ya suponemos que el usuario está en la propiedad de Google (IU de Google) y elige una forma de pago. Aquí es donde todo comienza.

  1. El usuario selecciona la entidad emisora específica que desea utilizar para realizar un pago. Esto es lo que activa el flujo Comenzar redireccionamiento.
  2. La IU de Google llama al servidor de Google (backend) para crear una nueva solicitud de redireccionamiento.
  3. El servidor de Google crea una solicitud de redireccionamiento.
  4. La solicitud de redireccionamiento se envía a la IU de Google.
  5. La IU de Google redirecciona al usuario al servidor del integrador.
  6. El integrador procesa la solicitud de redireccionamiento de Google y genera una solicitud de redireccionamiento específica de la entidad emisora.
  7. El integrador redirecciona al usuario a la interfaz web de la entidad emisora.
  8. El usuario se autentica en la interfaz web de la entidad emisora.
  9. El usuario sigue las instrucciones en pantalla para completar el pago.

El usuario selecciona el integrador en la IU de Google

En este caso, el usuario selecciona el integrador en la IU de Google, por lo que el campo formOfPayment de RedirectRequest se establecerá en noneChosen, ya que solo las entidades emisoras se consideran FOP válidas. El integrador debe proporcionar una IU que permita al usuario seleccionar una de las entidades emisoras aprobadas por Google. La solicitud de redireccionamiento usa un método GET de HTTPS, con parámetros codificados en la URL.

Iniciar el flujo de redireccionamiento (integrador seleccionado)

En el siguiente diagrama de secuencias, se muestra la interacción entre el navegador del usuario, Google, el integrador y la entidad emisora cuando el usuario selecciona un integrador en la IU de Google:

Inicia el flujo de redireccionamiento con el integrador seleccionado

A continuación, se muestra la lista de objetos del diagrama anterior:

  • Usuario: Es la persona que desea realizar un pago.
  • IU de Google: Es la interfaz web o de la app de Google, donde el cliente inicia un pago.
  • Servidor de Google: Es el servidor de backend de Google que crea una solicitud de redireccionamiento.
  • Integrador de pagos: Es el integrador en el que el usuario selecciona una entidad emisora.
  • Emisor: Es la entidad emisora a la que el usuario tiene una cuenta.

En el caso del flujo para iniciar el redireccionamiento, ya suponemos que el usuario está en la propiedad de Google (IU de Google) y elige una forma de pago. Aquí es donde todo comienza.

  1. El usuario selecciona un integrador (no una entidad emisora específica) para realizar el pago. Esto es lo que activa el flujo Comenzar redireccionamiento.
  2. La IU de Google llama al servidor de Google (backend) para crear una nueva solicitud de redireccionamiento.
  3. El servidor de Google crea una solicitud de redireccionamiento.
  4. La solicitud de redireccionamiento se envía a la IU de Google.
  5. La IU de Google redirecciona al usuario a la interfaz web del integrador.
  6. El integrador procesa la solicitud de redireccionamiento de Google.
  7. El integrador le muestra al usuario los emisores disponibles.
  8. El usuario selecciona la entidad emisora específica que desea utilizar para realizar un pago.
  9. El integrador genera una solicitud de redireccionamiento específica de la entidad emisora.
  10. El integrador redirecciona al usuario a la interfaz web de la entidad emisora.
  11. El usuario se autentica en la interfaz web de la entidad emisora.
  12. El usuario sigue las instrucciones en pantalla para completar el pago.

Prácticas recomendadas y otras consideraciones

Medidas de seguridad

La URL de solicitud de redireccionamiento incluirá un campo callbackUrl sin encriptar y un campo redirectRequest encriptados. Ambos campos contendrán el requestId de la transacción actual. El proveedor debe validar que requestId sea idéntico en callbackUrl y en la carga útil encriptada para verificar que estén relacionados.