Pase genérico vs tipos nativos en Google Wallet: cuándo usar cada uno

Usa un tipo nativo de Google Wallet — eventTicket, loyalty y sus pares — cuando tu pase es una de las categorías que Google modela: ganas el layout propio de la categoría y campos con semántica que la plataforma entiende. Usa el genérico cuando tu credencial no encaja en ninguna categoría.

Esa es la regla en una línea. Nosotros operamos ambos en producción — genéricos para credenciales que no son ninguna categoría, nativos para entradas y membresías —, así que lo que sigue es la diferencia real: qué ganas, qué reglas nuevas aceptas y qué pasa con los pases ya emitidos cuando decides migrar.

Qué te da un tipo nativo

Respuesta directa: render y comportamiento de categoría que no tienes que construir.

Un EventTicketObject muestra el nombre del evento, el lugar y la fecha en el encabezado nativo del pase — con el layout que Google diseñó para entradas — porque la clase los declara como lo que son (eventName, venue, dateTime), no como filas de texto que se parecen. Un LoyaltyObject hace lo propio con el programa, el nivel y el saldo del miembro.

La semántica además trabaja para ti hacia adelante: la plataforma sabe que ese pase es una entrada con fecha y lugar, no un rectángulo con textos — y las capacidades que Google construye por categoría aterrizan sobre los tipos nativos, no sobre el genérico.

Qué te da el genérico

Libertad y neutralidad. El genericObject renderiza filas de contenido que tú defines, sin imponer un modelo: sirve igual para un carné estudiantil, una factura de servicios o una cuota inmobiliaria — credenciales que no son ninguna de las categorías de Google y que forzarlas dentro de una sería mentirle al modelo.

Esa neutralidad es el motivo por el que el genérico no es «la opción inferior»: para una credencial que no es una categoría, es la opción correcta. Nuestra regla operativa es exactamente esa: nativo cuando la categoría existe, genérico cuando no — nunca un genérico simulando ser entrada, nunca una credencial embutida en una categoría que no le corresponde.

El costo de los nativos: la Class tiene ciclo de aprobación

Aquí está la letra pequeña operativa. Las clases nativas nacen con un estado de revisión (draft, underReview, approved) y el gate real no es por clase sino por cuenta de emisor: las cuentas nuevas de Google Wallet nacen en demo mode, donde solo puedes emitir pases a usuarios con rol en tu cuenta o registrados como testers. Para emitir al público hay que solicitar publishing access — un proceso de revisión de Google que, según su documentación a agosto de 2026, pide el perfil de negocio completo y al menos una clase creada (las capturas de pantalla de la integración, que el proceso exigía antes, dejaron de ser requisito — la propia página lo declara).

Las clases en underReview las aprueba la plataforma automáticamente —así lo documenta la referencia—; el publishing access no aprueba clases: habilita que cualquier titular guarde el pase. La consecuencia de planeación: si tu go-live tiene fecha, el trámite del emisor va al principio del proyecto, no al final — es de los pocos pasos del canal cuyo tiempo no controla tu equipo.

Migrar: los objetos viejos no se convierten

El punto que más sorprende al planear la adopción: pasarte a tipos nativos no convierte nada. Un pase guardado como genérico sigue siendo genérico — las emisiones nuevas salen nativas y ambas poblaciones conviven en la misma operación, indefinidamente.

Eso tiene dos consecuencias prácticas que ya documentamos por separado:

• El tipo de cada pase se persiste y se respeta. Cada actualización y cada mensaje debe viajar al recurso del tipo real del objeto — el path equivocado responde 404 como si el pase no existiera. Y una re-instalación debe respetar el tipo persistido: re-emitir como nativo un pase que ya existe como genérico crea dos objetos para el mismo pase, y esa doble identidad no se reconcilia sola.
• La migración es un estado permanente, no una ventana. Tu código no «termina» de migrar cuando despliegas los tipos nativos: opera una flota mixta desde ese día en adelante. Diseñar asumiendo flota mixta desde el principio es más barato que descubrirlo con los 404 en producción.

En Apple el dilema existe, con otra forma

Apple no tiene Class ni Object, pero la decisión equivalente existe: el estilo del pase (generic, eventTicket, storeCard, coupon) que se declara en el pass.json. Dos cosas que aprendimos en dispositivo:

• Cada estilo dibuja slots de imagen distintos. El strip (la banda de arte horizontal) solo se renderiza en eventTicket, storeCard y coupon; el thumbnail solo en generic y eventTicket. Empaquetar un arte en un slot que el estilo no dibuja produce bytes muertos: el archivo lo lleva, Wallet jamás lo pinta, y nadie te avisa — lo descubres preguntándote por qué la foto no aparece.
• El estilo se fija en la primera instalación. El contenido del pase se regenera completo en cada descarga, pero cambiar el estilo de un pase ya instalado rompe el render en el dispositivo. Nuestra regla operativa: el estilo queda congelado al primer install, y si una operación necesita otro estilo, el camino es re-emitir el pase e instalarlo de nuevo.

La simetría con Google es imperfecta pero útil para decidir: en ambas plataformas, el «tipo» del pase es la decisión que se toma bien al principio o se paga después — en Google porque los objetos no se convierten, en Apple porque el estilo se congela.

Cómo decidir

Tres preguntas, en orden:

1. ¿Tu pase es una de las categorías que Google modela? Entrada de evento, tarjeta de lealtad, tarjeta de embarque, oferta. Si no lo es — credencial institucional, factura, cuota — la decisión terminó: genérico.
2. ¿Necesitas el comportamiento de categoría o te alcanza el texto? Si la respuesta honesta es que solo quieres que «se vea» como entrada, el nativo te da eso gratis y sin simulaciones.
3. ¿Tu cuenta de emisor ya tiene publishing access? Si no, y el go-live tiene fecha, el trámite entra a la ruta crítica hoy.

Y la meta-regla que cubre a las tres: decide por pase, persiste la decisión junto al pase, y trata la flota como mixta desde el primer día. Todo lo demás de este artículo se deriva de ahí.

Preguntas frecuentes

¿Puedo empezar con el tipo genérico y pasarme a un tipo nativo después?

Sí, para los pases nuevos: las emisiones siguientes salen nativas. Los pases ya guardados como genéricos no se convierten — siguen siendo genéricos y conviven con los nativos, así que tu código debe tratar el tipo de cada pase como un dato persistido, no como una configuración global.

¿Un tipo nativo cuesta más mantener que el genérico?

Tiene más reglas: campos de clase que en la práctica son de nacimiento, y el ciclo de aprobación del emisor para publicar en volumen. A cambio elimina los arreglos de layout que el genérico exige para parecerse a una entrada o a una tarjeta de lealtad. En operaciones reales, el mantenimiento neto suele ser menor.

¿Qué pasa si emito una entrada de evento como pase genérico?

Funciona — nosotros lo hicimos así en su primera versión. El pase muestra los datos como filas de texto, sin el layout de entrada ni la semántica de categoría. La razón para migrar no fue que estuviera roto, sino todo lo que el tipo nativo da gratis y el genérico obliga a simular.

¿La cuota de mensajes cambia según el tipo?

No: el límite de 3 mensajes con notificación visible por objeto cada 24 horas aplica igual a genéricos y nativos. Lo que cambia entre tipos es el render y el comportamiento, no el presupuesto de avisos.