Google Wallet: de demo mode a publishing access, el trámite completo en la ruta crítica del go-live

Toda cuenta de emisor de Google Wallet nace en demo mode: puedes crear clases y objetos, pero solo emitir pases a usuarios con rol Admin o Developer en tu cuenta, o registrados como cuentas de prueba, y los pases salen con la anotación [TEST ONLY]. Para emitir al público hay que pedir publishing access en la consola de Google Pay y Wallet, cumplidos dos prerrequisitos —perfil de negocio completo y al menos una clase creada—; el equipo de Google Wallet revisa y notifica, sin plazo publicado. En la ruta crítica de un go-live, ese trámite va primero.

Así está documentado a agosto de 2026, y así lo operamos. Pase genérico vs tipos nativos lo toca en una sección; este artículo es el trámite completo, clic por clic, con lo que la documentación no dice y lo que sí dice sobre el ciclo de revisión de las clases.

Qué es demo mode y qué no te deja hacer

La página de onboarding del emisor lo declara al final del alta: «todas las cuentas nuevas están en demo mode. En demo mode puedes crear pases, pero no tendrás publishing access. Esto significa que los pases que crees solo pueden emitirse a usuarios que tengan el rol Admin o Developer, o que hayan sido agregados como cuenta de prueba a tu cuenta de emisor». La página de publishing access lo repite con una consecuencia visible: «cuando se te concede publishing access, la anotación [TEST ONLY] también se retira de tus pases».

En la práctica, demo mode es suficiente para construir toda la integración —clases, objetos, el botón de «Agregar a Google Wallet», las actualizaciones, los mensajes— y probarla en los teléfonos de tu equipo. Lo que no puedes hacer es lo único que importa el día del lanzamiento: que un titular cualquiera guarde el pase.

Los dos prerrequisitos

Antes de que aparezca el botón de solicitud hay que cumplir dos cosas, y la documentación viva las enumera así:

1. Perfil de negocio completo. «Tu perfil de negocio le da al equipo de Google Wallet información básica sobre tu negocio y ayuda a verificar que tu cuenta de emisor pertenece a un negocio, organización o persona real.» Completarlo implica «proveer la información de tu negocio y configurar un perfil de pagos o seleccionar uno existente para identificar tu negocio». Se hace en la consola, entrada Business Profile.
2. Al menos una clase de pase creada. «Casi todos los tipos de pase requieren una clase para emitir pases a usuarios de Google Wallet. Antes de que puedas ser aprobado para publishing access, se requiere que hayas creado al menos una clase.» Si llegas con la integración construida, esto ya está hecho.

Y lo que ya no se pide: la misma página anota que «las capturas de pantalla ya no son un requisito para solicitar acceso de producción». Es un cambio de la propia documentación —la nota está en la página a agosto de 2026— y conviene saberlo porque hay resúmenes automáticos —incluido el que la propia página muestra arriba del cuerpo— que todavía hablan de capturas. El cuerpo manda.

El trámite, clic por clic

Con los prerrequisitos cumplidos, según la página viva:

1. Entra a la consola de Google Pay y Wallet.
2. Haz clic en Google Wallet API.
3. Si completaste los prerrequisitos, verás un botón Request publishing access en el recuadro Get publishing access. Según la página, el botón aparece solo con los prerrequisitos cumplidos: si no lo ves, revisa esos dos puntos antes de sospechar de la consola.
4. Haz clic en Request publishing access.
5. «El equipo de Google Wallet revisará tu cuenta de emisor y te notificará cuando tu solicitud de publishing access sea aprobada.»

La lista de verificación de lanzamiento añade el matiz que la página de solicitud omite: el equipo «revisará y probará tu integración, y o bien te notificará que el acceso fue concedido, o detallará los problemas que deben resolverse antes de concederlo». Es decir, puede volver con observaciones. Una vez aprobado, «cualquier clase y objeto nuevos que crees estarán en vivo y listos para emitir pases a tus usuarios».

Cuánto tarda, y por qué va primero

Ninguna de las páginas vivas del trámite publica un plazo: ni días hábiles, ni rango, ni SLA. Lo que está escrito es que hay revisión humana, que puede volver con cosas que corregir y que te notifican al aprobar.

Nosotros no vamos a inventar un número; lo que sí decimos, de operar go-lives con fecha, es que este es de los pocos pasos del canal cuyo tiempo no controla tu equipo, y el único que puede volver con tarea. Por eso entra a la ruta crítica el primer día del proyecto, no la semana del lanzamiento — y por eso conviene que el perfil de negocio lo complete alguien con la información legal y de pagos a mano, no el desarrollador que está creando la primera clase.

Mientras tanto, nada se detiene: demo mode permite terminar la integración completa y probarla en los dispositivos del equipo registrados como cuentas de prueba.

Qué pasa con las clases nativas: reviewStatus

Aquí la documentación es más precisa de lo que suele creerse. Las clases nativas —EventTicketClass, LoyaltyClass y compañía— llevan un campo obligatorio reviewStatus, y la referencia describe su ciclo de vida completo:

• «Este campo puede ponerse en draft o underReview con las llamadas insert, patch o update. Una vez que el estado de revisión cambia desde draft, no puede volver a draft.»
• «Deberías mantener este campo en draft mientras la clase está en desarrollo. Una clase en draft no puede usarse para crear ningún objeto.»
• «Deberías poner este campo en underReview cuando creas que la clase está lista para usarse. La plataforma lo pondrá automáticamente en approved y la clase podrá usarse de inmediato para crear o migrar objetos.»
• «Al actualizar una clase ya aprobada, deberías seguir enviando este campo en underReview.»

A agosto de 2026 los valores canónicos del enum son UNDER_REVIEW, APPROVED, REJECTED y DRAFT; las variantes en minúscula (underReview, approved…) siguen aceptadas como alias heredados, marcados como obsoletos en la referencia del enum — en este artículo usamos el alias porque es el que la descripción del campo reviewStatus sigue escribiendo en prosa. Y hay un campo review que guarda «los comentarios fijados por la plataforma cuando una clase se marca aprobada o rechazada».

Tres consecuencias operativas, las tres aprendidas en producción:

• No crees clases en draft si vas a emitir pronto. Un draft no crea objetos, y salir de draft es irreversible. Nosotros creamos toda clase nativa directamente en underReview, y nunca dejamos que el código de la vertical decida ese campo: lo fija una sola pieza para que nadie lo olvide.
• El PATCH a una clase aprobada lleva reviewStatus otra vez. Es lo que la referencia pide y lo que vimos: una actualización de clase sin el campo se rechaza; con underReview pasa y la plataforma la vuelve a aprobar. Como el PATCH de clase se propaga a todos los objetos de esa clase, esta es la palanca para corregir un dato de evento en toda la flota de una sola vez — sin consumir cuota de mensajes.
• No hay botón de aprobar por clase, y tampoco hace falta. La aprobación de la clase la hace la plataforma; el gate para emitir al público es el publishing access de la cuenta. La lista de pruebas previas al lanzamiento de Google incluye, como ítem esperado, «las clases tienen un reviewStatus de Approved» — y la clase genérica (GenericClass) no tiene este campo en absoluto.

Una confusión que conviene desarmar: demo mode es estado de la cuenta de emisor; draft/underReview/approved es estado de cada clase. Los dos estados son independientes: el publishing access no aprueba clases, y una clase aprobada no te da publishing access.

Un emisor por operación

Si cada institución que opera contigo emite bajo su propia cuenta de emisor —el modelo que usamos cuando la marca y la relación con Google deben ser de la operación, como en varias sedes, un solo panel—, cada cuenta pasa por su propio trámite de publishing access, con su propio perfil de negocio y su propia revisión. Es lo que hace del trámite un ítem de checklist por cliente, y no un hito único de la plataforma.

Checklist del go-live

Además de la solicitud, las páginas de pruebas previas y de lanzamiento de Google proponen un recorrido que en nuestra experiencia ahorra una ida y vuelta con el revisor:

• Pruebas requeridas: el botón y el enlace de «Agregar a Google Wallet» (funcionan, abren el pase correcto, respetan las guías de marca).
• Pruebas recomendadas: funcionalidad general, clases y objetos (incluido el reviewStatus en Approved), interfaz, y pruebas en tienda si el pase se presenta en caja.
• Al menos una clase y un objeto creados antes de solicitar el acceso.
• Tras la aprobación: la anotación [TEST ONLY] desaparece de los pases de la cuenta, y todo lo nuevo nace en vivo.

Preguntas frecuentes

¿Qué puedo hacer en demo mode?

Crear clases y objetos y emitir pases, pero solo a usuarios de Google Wallet cuyas cuentas tengan rol Admin o Developer en tu cuenta de emisor, o que hayas agregado como cuentas de prueba en la consola. Los pases salen con la anotación [TEST ONLY], que Google retira al conceder publishing access.

¿Qué pide Google para conceder publishing access?

Dos prerrequisitos, según su documentación viva: completar el perfil de negocio en la consola de Google Pay y Wallet —datos del negocio y un perfil de pagos— y haber creado al menos una clase de pase. Las capturas de pantalla de la integración, que antes se pedían, dejaron de ser requisito; la propia página lo declara.

¿Cuánto tarda la revisión?

Google no publica tiempos ni SLA: dice que el equipo de Google Wallet revisa la cuenta y te notifica cuando aprueba, o te detalla lo que hay que corregir antes. Por eso el trámite va al principio del proyecto: es de los pocos pasos del canal cuyo tiempo no controla tu equipo, y puede requerir una ida y vuelta.

¿Tengo que pedir aprobación por cada clase nativa?

No. El gate de emisión al público es por cuenta de emisor, no por clase. Las clases nativas se crean en underReview y, según la referencia de Google, la plataforma las pasa a approved automáticamente y quedan listas para crear objetos; al actualizar una clase ya aprobada hay que volver a enviar underReview. Lo que no existe es un botón de aprobar por clase — el detalle de Class y Object explica qué vive en cada nivel.