Te llega un ticket: “Agregar un botón de Apple Wallet al email de confirmación.” Suena simple hasta que lo investigas y te topas con las reglas de marca de Apple, un .pkpass firmado y la pregunta de a dónde apunta realmente el botón. El botón en sí es la parte fácil; conectarlo a un pase real y ubicarlo bien es donde la gente se traba.
Esta es la versión corta para quien tenga que publicar ese botón: dónde va en email, web y app, las reglas que exigen Apple y Google, y cómo conectarlo a un link de instalación que realmente guarde un pase. Bien hecho, el botón sube tu tasa de instalación en vez de quedar sin usar en una plantilla.
Dónde va realmente el botón (email, web, in-app)
El botón funciona en tres lugares, y cada uno tiene un lugar natural ligado al momento en que el pase tiene valor.
En email, va en el mensaje de confirmación u oferta: un comprobante de compra, la confirmación de una entrada, el alta a un programa de fidelización. Un detalle importante: el cliente puede abrir el email en una laptop, donde el botón no funciona, así que suma una línea como “abre este email desde tu celular para agregar el pase”.
En la web, va en páginas de confirmación y de oferta, cerca de lo que se está guardando: justo después del pago, en una confirmación de reserva, en una página de cupón dedicada. Para una tienda que vende también en marketplaces como MercadoLibre, el lugar más natural sigue siendo tu propio checkout o la página de confirmación del pedido, no el marketplace en sí.
En la app, va donde ya aparece la información del pase, justo después de la acción que lo genera: una compra, un alta, la emisión de una entrada. Las apps nativas usan el control de botón propio de Apple en vez de una imagen.
Las reglas oficiales de Apple para el botón
Apple trata el badge como una pieza de marca registrada, así que las reglas son estrictas y vale la pena seguirlas para evitar un rechazo en la revisión de la app o un botón que se vea roto.
Usa el SVG descargable de Apple para web y email, y la versión EPS para materiales impresos con un código QR. No crees tu propia versión, y no recolorees, rotes, animes ni agregues sombras al badge. En apps nativas, usa el control PKAddPassButton, que renderiza el look y el idioma correctos automáticamente.
En cuanto al layout, deja un espacio libre mínimo alrededor del badge equivalente a una décima parte de su altura, y colócalo sobre fondo blanco o claro. Para fondos oscuros, Apple ofrece una versión en outline. El badge debe quedar secundario frente a tu contenido principal, no dominar el layout.
En el naming, escribe “Apple Wallet” en la primera mención y “Wallet” después, e incluye la línea de crédito de marca de Apple en cualquier texto legal que muestres. Estas reglas de naming son parte de lo que Apple revisa.
Algunos errores hacen que el botón se rechace o falle en silencio. Un badge diseñado a mano en vez del oficial no pasa la revisión, y un badge escondido donde no se entiende su función queda ignorado.
Un link a un pase sin firmar o mal armado no hace nada cuando lo tocas, y un naming inconsistente como “guardar en el wallet del iPhone” rompe las reglas de marca. Todo esto se evita usando el material oficial y un pase correctamente firmado.
Botón Add to Google Wallet: la misma función, reglas distintas
Si soportas ambos wallets, y la mayoría de los negocios de consumo en la región deberían, vas a poner un botón de Google junto al de Apple. La función es idéntica; los detalles cambian.
El botón de Google viene en XML para Android, SVG y PNG, solo en negro, con variantes primaria y condensada. El espacio libre es fijo, 8dp en todos los lados, y el botón necesita una altura mínima de 48dp. Una regla fácil de pasar por alto: si hay otros botones en la misma página, el botón Add to Google Wallet debe ser igual o más grande que ellos, nunca más chico.
El botón tiene que llamar a un flujo de la API de Google Wallet, que abre la app de Google Wallet para que el usuario guarde el pase en su dispositivo Android y su cuenta de Google. Para el naming, escribe “Google Wallet” con G y W mayúsculas, y usa el texto localizado que provee Google en vez de uno propio.
Así que son dos botones y dos sets de reglas en un mismo lugar de tu plantilla. Arma el pase para ambos estándares, coloca los dos badges uno junto al otro, y el dispositivo del cliente se encarga del resto. Con el mercado dominado por Android en LATAM, el botón de Google Wallet no es un extra: para buena parte de tu audiencia es el único que van a tocar.
Conectando el botón a un link de instalación real
Un badge es solo una imagen hasta que apunta a un pase real y firmado. Tres cosas lo conectan con algo que un cliente puede realmente guardar.
-
Genera el link de instalación por usuario
El botón enlaza a una URL de instalación que resuelve en un pase firmado. Puedes producir ese pase de dos formas: construirlo tú mismo con el framework PassKit de Apple, lo que implica generar y firmar el .pkpass y correr un servicio que aloje el link, o usar una plataforma de pases que se encarga de firmar y alojar por ti. La primera da control total y le sirve a equipos con recursos de backend; la segunda es más rápida para la mayoría de los equipos de marketing y producto. Para un pase compartido, como un cupón genérico, un solo link sirve para todos. Para un pase personalizado, como una tarjeta de fidelización con los puntos de un cliente específico, generas un link único por usuario para que el pase guardado lleve sus datos. Con una plataforma como Pushwoosh Wallet passes, armas el pase una sola vez y generas ese link de instalación sin manejar la firma del .pkpass tú mismo.
-
Coloca el botón en tu plantilla de email
En tu plataforma de email, coloca el badge SVG de Apple (y el botón de Google, si soportas ambos) y configura su link hacia la URL de instalación. Para un pase por usuario, la mayoría de las plataformas de email te dejan insertar el link único como variable de personalización, así el botón de cada destinatario apunta a su propio pase. Suma la nota de "ábrelo desde tu iPhone", y mantén el badge sobre fondo claro según las reglas de Apple. Dado que la mayoría de tu audiencia en la región abre el email desde un Android, no des por hecho que el badge de Apple es el que más se va a usar: prueba primero el flujo de Google Wallet de punta a punta.
-
Mide guardados, no solo clics
Un clic en el badge no es un guardado; el cliente todavía tiene que confirmar que agrega el pase. Registra el guardado real como su propio evento para medir tasa de instalación, no solo click-through. Ese número te dice si la ubicación y la oferta están funcionando, y es la métrica que hay que optimizar, porque un pase guardado es el que se queda en el celular.
Un solo link, todos los canales
Generar un link de instalación único por usuario y pegarlo a mano en cada canal no escala más allá de un puñado de campañas. El link es el mismo activo ya sea que viaje en un email, un push o un SMS, así que lo eficiente es generarlo una vez y reutilizarlo en todos lados.
Con Pushwoosh Wallet passes, armas el pase, generas el link de instalación y lo distribuyes por push, email y SMS desde un solo lugar. Los botones de Apple y Google apuntan al mismo pase, y manejas guardados y actualizaciones sin tocar un archivo .pkpass.
Sube tu tasa de instalación de wallet passes con Pushwoosh
Publica el botón una sola vez y reutiliza el link en todos lados. Pushwoosh Wallet passes genera el link de instalación para Apple y Google Wallet y lo distribuye por push, email y SMS desde un solo panel.
