Saltar al contenido principal

Google Play prueba suscripciones por plazas y consumo, con acceso aún limitado

Las plazas de equipo, el crédito por uso y la compra combinada pueden cambiar los planes de una app. Antes conviene verificar el acceso y los derechos.

Portátil cerrado, teléfono con pantalla apagada y grupos de piezas de vidrio sobre una mesa
TechKili · Ilustración generada con IA mediante Cloudflare FLUX
Compartir este artículo:
En este artículo

Google Play está probando formas de vender suscripciones por puesto, por consumo prepago y junto con productos de pago único, pero los desarrolladores no deben dar por disponible todo el conjunto. Google presentó los cambios el 29 de septiembre de 2026 y aclaró que muchas funciones siguen limitadas a socios seleccionados o se están desplegando. Para un equipo de aplicaciones, la decisión inmediata es identificar qué problema de acceso resuelve cada modelo y comprobar su disponibilidad antes de diseñar la compra en torno a él.

Cuatro modelos para necesidades distintas

Multi-Quantity Subscription Purchase está pensado para quien necesita varias plazas en una sola transacción y puede asignarlas a miembros de un equipo o estudiantes. Es una cuestión distinta de elegir una cuota mensual o anual para una persona. Google lo plantea para aplicaciones de productividad, educación e IA que venden acceso colectivo; el anuncio no fija una fecha de lanzamiento general.

Usage-Based Billing se dirige a servicios con costes variables, como la generación mediante IA. Google describe un saldo prepago medido por uso que se recarga automáticamente al bajar de un umbral. Es una propuesta para financiar el consumo, no una prueba de que una aplicación pueda cobrar sin una experiencia de compra clara. Cada equipo tendría que definir qué compra una unidad, cómo ve el usuario el crédito restante y qué ocurre con el acceso cuando se agota el saldo. Son decisiones de implementación, no prestaciones que Google afirme haber resuelto para todas las aplicaciones.

Mixed Carts reuniría una suscripción de renovación automática y un producto de pago único en una sola llamada a la API y una única pantalla de compra. Antes, según Google, esas compras exigían transacciones separadas. Cross-Developer Bundling responde a otro caso: permitiría vender dos o más suscripciones como un paquete del catálogo, incluso entre desarrolladores asociados. Esto exige coordinar derechos de acceso y acuerdos comerciales entre empresas, además de modificar el proceso de compra.

Las suscripciones actuales siguen ofreciendo opciones

La documentación vigente de Play Billing describe planes base, ofertas, planes prepagos y complementos de suscripción. Una recarga prepaga prolonga el derecho de acceso a una suscripción; no debe confundirse con el nuevo saldo medido por consumo y su reposición automática. Google también señala que su API In-App Messaging está disponible para todos los desarrolladores y permite avisar sobre pagos rechazados y cambios de precio. Son opciones concretas que pueden evaluarse mientras se prueban los nuevos modelos.

El anuncio de Google Play del 29 de septiembre indica que muchas funciones nuevas están en un programa de acceso anticipado o se despliegan mediante Play Console. Invita a los desarrolladores que tengan un gestor de socios de Google Play a manifestar su interés conforme se abran los programas. No ofrece una fecha única de disponibilidad, criterios de acceso ni especificaciones de API para producción de cada modelo nuevo.

Diseñar los derechos de acceso antes de prometer resultados

Para un equipo que vende consumo de IA, la primera prueba consiste en averiguar si el crédito prepago representa sus costes y las expectativas del usuario mejor que un derecho fijo y recurrente. En una aplicación colaborativa, la primera pregunta de diseño es quién posee las plazas y qué ocurre al reasignarlas. Una compra mixta podría simplificar el pago, pero la aplicación también tendría que contabilizar por separado los derechos recurrentes y los de pago único. Estas son implicaciones de implementación que TechKili extrae de los modelos descritos por Google, no resultados medidos en despliegues reales.

Google presenta los cambios como herramientas de crecimiento y retención, pero el anuncio no aporta resultados independientes de conversión o abandono para estas funciones. Los desarrolladores pueden definir desde ahora los flujos de acceso y asistencia y, antes de prometer una función a sus clientes, confirmar que está habilitada en su cuenta.

Fuentes