Si tu plataforma de engagement de clientes no tiene wallet passes nativos, tienes 2 caminos. Conectar una herramienta de pases y mantener 2 sistemas sincronizados, o migrar a una plataforma que emite pases de Apple y Google Wallet sobre el mismo perfil de cliente. El primero es más rápido para arrancar. El segundo es más simple de operar una vez que el wallet forma parte de tus journeys.
Escribimos esto para equipos que usan plataformas como Braze, OneSignal o CleverTap y quieren wallet passes sin desarmar todo. Para una vista por proveedor, revisa la comparación de Wallet passes.
Para startups y scaleups de LATAM, en México, Colombia, Argentina, Chile o Perú, la pregunta suele llegar justo cuando el equipo ya opera push, email y segmentos con un presupuesto ajustado. Por eso vale la pena decidir con números y no por inercia.
Desde dónde partes
El soporte de wallet varía mucho entre plataformas de engagement. Braze agrega wallet a través de partners como PassKit. OneSignal no tiene wallet passes nativos. Revisa la documentación actual de tu propia plataforma antes de planear, porque esto cambia.
Sin soporte nativo, el pase vive en 1 sistema y el cliente en otro. Cada pase que emites, actualizas o segmentas necesita datos de los 2.
Camino A: mantener tu CEP y sumar una herramienta de pases
Mantienes tu plataforma actual para push, email y segmentos, y conectas una herramienta de pases independiente para Apple y Google Wallet.
Así suele funcionar. Tu CEP o tu backend llama a la API de la herramienta de pases para emitirlos, muchas veces a través de webhooks. Si la herramienta de pases expone eventos, estos vuelven a tu CEP para que puedas segmentar a los holders.
La ventaja es real. No migras nada. Tu equipo conserva sus herramientas y journeys, y puedes empezar con 1 caso de uso, como una tarjeta de lealtad.
La desventaja crece con el tiempo. 2 bases de datos que sincronizar, 2 suscripciones, 2 revisiones de seguridad y GDPR. Cada escenario que combina una actualización del pase con un mensaje, como “tus puntos vencen pronto”, se arma entre 2 herramientas.
Piensa en una temporada como el Hot Sale en mayo o el Buen Fin en noviembre. Ahí es cuando el cupón en el wallet, el push y el email tienen que salir del mismo disparador a la misma hora, y cualquier retraso en la sincronización se nota en ventas.
Camino B: migrar a una plataforma con wallet nativo
Llevas tu mensajería a una plataforma que emite wallet passes de forma nativa, sobre el mismo perfil que push, in-app, email y SMS.
Los pases se emiten por User ID dentro de la plataforma. Segmentos, journeys y canales ven al holder del pase como 1 solo cliente. 1 paso del journey emite el pase y el siguiente envía el link.
Obtienes 1 perfil, 1 journey y 1 contrato. Las actualizaciones del pase y los mensajes salen del mismo disparador, y no hay una capa de sincronización que vigilar.
El costo es la migración en sí: cambios de SDK, importación de datos, reconstrucción de journeys y plantillas. Vale la pena cuando el wallet es un canal de largo plazo, no una campaña de una sola vez.
| Camino A: CEP + herramienta de pases | Camino B: wallet nativo | |
|---|---|---|
| Tiempo hasta el primer pase | Rápido | Depende de la migración |
| Sistemas que mantener | 2 más una capa de sincronización | 1 |
| Journeys con actualizaciones de pases | Armados entre 2 herramientas | 1 journey |
| Segmentar a los holders | Con datos sincronizados | Mismo perfil |
| Contratos y evaluaciones de proveedor | 2 | 1 |
| Ideal para | Un solo caso de uso de wallet | Wallet como canal de retención |
Marco de decisión
Califícate con 4 preguntas.
- 1
Alcance
¿El wallet es 1 campaña o un canal que vas a operar durante años? 1 campaña apunta al Camino A.
- 2
Canales
¿Cuántos escenarios combinan un pase con push, email o SMS? Muchos apuntan al Camino B.
- 3
Equipo
¿Tienes desarrolladores para construir y mantener una capa de sincronización? Si no, el Camino A se encarece con el tiempo.
- 4
Residencia de datos
¿Necesitas hosting en la UE y menos encargados de tratamiento para GDPR? Cada proveedor extra es 1 encargado más que revisar.
Si 2 o más de tus respuestas son “largo plazo”, “muchos”, “sin desarrolladores” o “menos encargados”, mira con atención el Camino B. Si ninguna lo es, el Camino A es una opción perfectamente válida, y puedes revisarla en un año.
Cuánto cuestan 2 herramientas
El Camino A parece más barato el primer día, porque nada se mueve. En un año, suma las partes que nunca aparecen en la factura del proveedor de pases: construir la integración, mantener la sincronización, el trabajo duplicado en journeys y una segunda evaluación de proveedor.
El Camino B concentra el costo al inicio: el trabajo de migración y luego 1 sola cuota de plataforma. Compara los 2 en un horizonte de 12 a 24 meses, no de 1.
Para equipos de LATAM que tienen que justificar cada línea del presupuesto, conviene presentar esta comparación con el calendario comercial al lado: Hot Sale, Día de la Madre, CyberMonday, Buen Fin, Black Friday y Navidad. Cada temporada en la que armas el mismo journey en 2 herramientas es un costo que el Camino A repite.
Checklist de migración
Si eliges el Camino B, planea la migración alrededor del cliente, no de la herramienta.
- Audita lo que envías. Haz la lista de campañas de push, email, SMS e in-app, journeys y segmentos que tienen que migrar.
- Mapea tus datos. User IDs, tags, eventos y registros de consentimiento. El User ID es lo que une un pase con un cliente.
- Configura el wallet una vez. Un certificado Pass Type ID de Apple (cuenta de Apple Developer, US$99 al año) y un Issuer ID de Google con la cuenta de servicio de Pushwoosh invitada a tu emisor. En LATAM, donde alrededor del 85% de los usuarios está en Android, el lado de Google no es un detalle.
- Integra el SDK. Reemplaza el SDK anterior en tu app y prueba los push antes de mover el tráfico.
- Reconstruye primero los journeys clave. Bienvenida, carrito abandonado, reactivación y después los nuevos escenarios de wallet.
- Planea el lanzamiento de los pases. Emite pases desde un paso del journey y envía el link por email, SMS o push.
- Opera en paralelo por poco tiempo. Mantén la plataforma anterior durante un breve traslape y después apágala.
Durante la migración, usa la API para emitir pases desde tu propio backend.
Lee también: Cómo emitir wallet passes personalizados por API
Simplifica tu stack con Pushwoosh
Pushwoosh emite pases nativos de Apple y Google Wallet sobre los mismos User ID, segmentos y journeys que push, in-app, email, SMS y WhatsApp. Es 1 sola plataforma, alojada en infraestructura propia en Alemania y Estados Unidos, con cumplimiento de GDPR y SOC 2 Type 2. Mira dónde encaja Pushwoosh entre las opciones de wallet.
Agregar wallet no debería significar sumar 1 herramienta más. Debería significar 1 perfil de cliente sobre el que todos los canales pueden actuar.
FAQ
Artículos relacionados
Ver todo