Inscripción en el programa de lealtad del usuario y actualizaciones de pases

La función de inscripción y acceso al programa de lealtad permite a los usuarios buscar tu programa de lealtad y unirse a su cuenta o acceder a ella directamente desde la Billetera de Google. Se dirigirá a los usuarios a tu sitio web apto para dispositivos móviles para completar el proceso, después del cual podrán agregar su tarjeta oficial a la Billetera de Google.

La implementación de esta función es un requisito previo para convertir los pases "estáticos" agregados por el usuario en pases "dinámicos" vinculados a la API. En esta guía, se proporciona una descripción general de los beneficios y los pasos de implementación necesarios para habilitar tu programa de lealtad para el registro, el acceso y las actualizaciones de pases.

Descripción general

Para comenzar, asegúrate de haber configurado tu proyecto y tener acceso a la API de Google Wallet.

Debes seguir estos cuatro pasos para implementar la función:

  1. Configura una clase de prueba: Configura la Billetera de Google para probar tus flujos.
  2. Desarrolla páginas: Crea páginas de inscripción o acceso con SharedDataType de la Billetera de Google.
  3. Implementar la devolución: Envía la tarjeta de lealtad a la Billetera de Google después de la acción.
  4. Solicita la verificación: Envía la solicitud para su revisión y solicita la activación de la actualización.

¿Por qué implementar la inscripción en el programa de lealtad?

Para comprender el valor de esta integración, es importante distinguir entre los dos tipos de pases que existen en la Billetera de Google: L1 (agregado por el usuario) y L2 (emitido por el socio).

Diferencia entre L1 y L2

Función Pase L1 (agregado por el usuario) Aprobación de L2 (emitida por el socio)
Origen Se crea cuando un usuario escanea manualmente una tarjeta física o escribe un número. Se crea y se envía con la API de Wallet después de que un usuario se registra o accede con tu flujo.
Control Estática: El socio no tiene visibilidad ni control sobre este pase. Dinámico: El socio tiene control total con la API.
Funcionalidad Imagen estática de un código de barras. No se puede actualizar. Puede actualizar los saldos de puntos y el estado de nivel, mostrar ofertas personalizadas y recibir notificaciones.

Las rutas de actualización: el "puente" hacia tu programa

Cuando compilas el flujo de inscripción en el programa de lealtad (el "destino"), permites que Google cree un "puente" que actualice a los usuarios de los pases L1 estáticos a tus pases L2 oficiales. Existen dos activadores principales de actualización:

  1. Actualizaciones de pases de L1 a L2: Si un usuario agregó manualmente tu tarjeta (L1) anteriormente, la Billetera de Google puede solicitarle que visite tu nuevo flujo de acceso para actualizarla al pase dinámico oficial (L2).
  2. Actualizaciones de pases importados de Gmail: Si la Billetera de Google detecta una tarjeta de lealtad que usa el Gmail de un usuario, puede solicitarle que visite tu flujo y se autentique para recibir el pase oficial de nivel 2.

Paso 1: Configura una clase de prueba en la Billetera de Google

Determina las URLs de inscripción y acceso, el logotipo de tu programa y los campos de usuario elegidos. Luego, usa los campos anidados discoverableProgram en loyaltyclass para establecer los valores adecuados.

Establece los valores en discoverableProgram para crear una versión preliminar de tu programa de lealtad habilitado para la inscripción o el acceso. Para asegurarte de que los verificadores puedan ver esta información, verifica que tengan acceso a la consola de Google Pay y la Billetera. Para obtener detalles sobre cómo compartir el acceso a Google Pay y a Wallet Console con otras personas, consulta Más información sobre la página Usuarios.

Para completar la verificación de la funcionalidad de tu implementación durante el proceso de desarrollo, comunícate con nosotros a través del widget de asistencia al cliente en la consola de Google Pay y la Billetera. Mientras estás en la consola, selecciona API de Google Wallet en el tema y Acceso o inscripción en el programa de lealtad en el subtema.

Paso 2: Desarrolla páginas de inscripción y acceso

Cuando un usuario elige acceder a tu programa de lealtad o inscribirse en él, se lo dirige a una página personalizada de tu sitio web para que complete el proceso de inscripción o acceso. Si un usuario decide inscribirse, la Billetera de Google le pedirá que apruebe compartir sus datos de usuario contigo.

Debes proporcionar una de las dos páginas, o ambas, que permitan a los usuarios completar estas acciones:

  1. Una URL de acceso en la que un usuario puede acceder a una cuenta existente.
  2. Es una URL de inscripción en la que un usuario puede crear una cuenta nueva.

Tus páginas de acceso y de inscripción deben cumplir con los siguientes requisitos:

  • Brinda una experiencia del usuario apta para dispositivos móviles.
  • Minimiza la cantidad de campos obligatorios durante el proceso de inscripción.
  • Permite que el usuario complete el acceso o la inscripción en una sola página.
  • Usa el cifrado HTTPS con un certificado válido para garantizar que los datos del usuario se transmitan de forma segura.
  • Asegúrate de que tus páginas de acceso y registro tengan un tiempo de actividad de al menos el 99.9%.

Además de estos requisitos, te recomendamos que permitas que los usuarios se inscriban en tu programa de lealtad sin completar ningún formulario o que mantengas la página solo para la aceptación de tus condiciones del servicio.

  • Si aprovechas los datos del usuario que se proporcionan en SharedDataType, puedes crear una cuenta y enviar de inmediato su tarjeta de lealtad.
  • Posteriormente, puedes enviarle al usuario por correo electrónico una contraseña de un solo uso o un vínculo para configurar su contraseña y los detalles opcionales de la cuenta.
  • Esto reduce la probabilidad de que los usuarios abandonen el proceso de inscripción, ya que cada paso adicional puede generar más abandonos.

Cuando se presenta la página de acceso o inscripción, la Billetera de Google crea un WebView de Android y se realiza una solicitud POST a la URL que proporcionaste. Los datos del usuario se proporcionan en el parámetro SharedDataType, que se incluye en la solicitud POST con una codificación Content-Type de application/x-www-form-urlencoded y UTF-8. El valor del parámetro SharedDataType es un objeto JSON codificado en Base64.

Según la acción que elija el usuario y los campos que hayas especificado para solicitarle, el objeto JSON puede contener los siguientes campos.

Campo Inscripción
correo electrónico
firstName
lastName
addressLine [1-3]
city
state
zipcode
country
teléfono

Consulta lo siguiente para ver un ejemplo decodificado de un objeto JSON que se incluye en SharedDataType.

Recurso

{
  "firstName": "Jane",
  "lastName": "Doe",
  "addressLine1": "1600 Amphitheatre Pkwy",
  "addressLine2": "Apt 123",
  "addressLine3": "Attn:Jane",
  "city": "Mountain View",
  "state": "CA",
  "zipcode": "94043",
  "country": "US",
  "email": "jane.doe@example.com",
  "phone": "555-555-5555"
}

Paso 3: Implementa el rechazo inmediato en la Billetera de Google

Una vez que se autentique (acceso) o después de la creación de la cuenta (inscripción), tu página debe enviar inmediatamente la tarjeta de lealtad del usuario a la Billetera de Google.

Puedes volver a enviar la tarjeta de lealtad a la Billetera de Google redireccionando a un vínculo que siga la siguiente estructura.

https://pay.google.com/gp/v/save/{jwt_generated}

La longitud segura para una URL es de 2,000 caracteres. Tus vínculos no deben superar este límite. Los objetos codificados en JWT deben ser pequeños y contener solo datos específicos del usuario. Intenta mantener la mayoría de los datos en la clase del objeto y créala antes de generar el JWT. En el caso de los objetos más grandes que no cumplen con el límite, considera crear primero el objeto en la API de la Billetera de Google y enviar solo el ID del objeto en el JWT.

Flujo de comunicación típico

En la siguiente imagen, se ilustra el flujo de comunicación para un usuario que completa el registro o el acceso. Es tu responsabilidad implementar todas las acciones entre "Tu servidor".

Flujos de acceso a la inscripción

Paso 4: Solicita la verificación y la activación

Después de completar el trabajo de desarrollo y probar los flujos de inscripción y acceso, debes enviar una solicitud para que se revise y active por completo tu implementación.

  1. Navega a la consola de Google Pay y la Billetera.
  2. Usa el widget Comunicarse con el equipo de asistencia.
  3. Informa al equipo de asistencia al cliente que completaste la integración de la inscripción en el programa de lealtad.

Después de una revisión completa de tu implementación que confirme la funcionalidad correcta en combinación con la app de la Billetera de Google, se lanzará públicamente la función de inscripción o acceso al programa de lealtad.

Para garantizar una experiencia del usuario óptima, se realizarán verificaciones periódicas de la implementación del registro o acceso para garantizar el cumplimiento continuo de los requisitos de la función. Recibirás una notificación en caso de que haya discrepancias, y es posible que se inhabilite la función de acceso o inscripción hasta que se resuelva el problema.

Preguntas frecuentes

  • ¿Hay requisitos para las imágenes que se usan en mi programa de lealtad? Sí, tus imágenes deben estar alojadas en una ubicación HTTPS, ya que, de lo contrario, no se verán en la Billetera de Google.

  • ¿Existen herramientas que simplifiquen la implementación y la depuración de los JWT? Sí, las plataformas como www.jwt.io te permiten decodificar y depurar tus tokens durante el proceso de desarrollo, lo que te permite verificar el contenido que envías. Ten en cuenta que Google no está afiliado a ninguno de estos terceros y no recomienda específicamente a ninguno de ellos.

  • ¿Cómo controlamos correctamente los datos de SharedDataType codificados en Base64? Asegúrate de usar la codificación UTF-8 durante todo el proceso. Primero, la cadena JSON se codifica en UTF-8 y, luego, se codifica con android.util.Base64 con las opciones NO_WRAP y URL_SAFE. Esto se corresponde con la sección 4 del RFC 3548.