Pasos para la integración de la entidad emisora para los tickets de Motics en la Billetera de Google

En este documento, se analizan los pasos que deben seguir un operador de transporte público (PTO) y su integrador de sistemas, que en adelante se denomina entidad emisora, para proporcionar una implementación de Motics en la Billetera de Google.

1. Completa los requisitos previos

  • Firmar un acuerdo de confidencialidad (NDA) con Google. El equipo de desarrollo empresarial (BD) de Google comparte este formulario en línea, que se puede aceptar con un clic.
  • Realiza la integración con la API estándar de la Billetera de Google para códigos QR:
    • La entidad emisora usa la API de la Billetera de Google para aprovisionar pases y agregarlos a la app de la Billetera de Google de un usuario. Revisa la documentación sobre Códigos QR de transporte público y completa los requisitos previos necesarios para integrarlos en la API.
  • Regístrate en el servicio de boletos electrónicos de VDV para obtener un ownerId (orgId) y los detalles de PKI relevantes requeridos para Motics.

2. Implementación técnica

El paso 2 contiene los detalles técnicos principales de la implementación, que se deben desarrollar en paralelo.

Actualiza la implementación de la API de Google Wallet.

En la página Detalles técnicos, se describen los métodos y parámetros que la entidad emisora debe usar y actualizar para la integración de Motics. Específicamente, la entidad emisora debe llamar a los siguientes métodos de la API de la Billetera de Google con parámetros adicionales relacionados con Motics:

Implementar el extremo de activación

El servidor de Google llama al extremo de activación alojado por la entidad emisora. Esto activa la generación de datos de derechos estáticos (sigSTB) en el servidor de la entidad emisora. Consulta la sección del extremo de activación para obtener más detalles.

Para brindar una buena experiencia del usuario, un usuario debe poder mover su ticket de Motics de un dispositivo a otro dentro de ciertos límites definidos por la entidad emisora. Para ello, la entidad emisora debe implementar el flujo de transferencia y desvinculación.

Envía un correo electrónico de confirmación cuando se guarde el boleto

Google requiere que la entidad emisora envíe un correo electrónico de confirmación a los usuarios cuando guarden un ticket de Motics en la Billetera de Google. El correo electrónico de confirmación debe contener (como mínimo) lo siguiente:

  • Vínculos útiles para que los usuarios administren sus tickets (suscripción)
  • Instrucciones para comunicarse con el servicio de asistencia al cliente de la entidad emisora.

3. Realiza pruebas de integración de extremo a extremo en STAGING

Crea una transitClass de prueba de la Billetera de Google para usar en el desarrollo y, una vez que se complete el trabajo de integración, la solución se debe validar y probar de extremo a extremo con este transitClass de desarrollo. En transitObject:Insert, configura cert_environment como STAGING. Todos los casos de uso deben probarse por completo y todos los casos de prueba deben tener un resultado exitoso.

4. Realiza pruebas de extremo a extremo en PRODUCCIÓN

Una vez que la solución se haya probado correctamente con el entorno STAGING, crea un nuevo transitClass de producción. Esta vez, configura cert_environment como PRODUCTION cuando insertes transitObject. Sigue y completa todos los casos de prueba y las instrucciones de la sección Pruebas.

5. Sigue el proceso de lanzamiento y obtén aprobaciones

Antes de lanzar o iniciar una prueba piloto pública, Google debe haber otorgado la aprobación completa para el lanzamiento. La aprobación depende del resultado de las distintas fases de prueba y de otros factores, como los siguientes, que Google debe revisar y aprobar:

  • Plan y alcance general del lanzamiento
    • En el caso de una prueba piloto, el plan de lanzamiento debe incluir criterios de salida y cronogramas claros para continuar con un lanzamiento completo.
  • Actividades de marketing planificadas
  • Inicia las comunicaciones
  • Fecha de lanzamiento
  • Cronogramas del día de lanzamiento, proceso de derivación y contactos
  • Procesos de asistencia para usuarios finales