Rechazo en Google Play
Salvo en unos pocos programas regionales, los bienes digitales que se venden dentro de una app Android tienen que pasar por Google Play Billing. Los bienes físicos y los servicios del mundo real se quedan en Stripe. La mayoría de las apps web empaquetadas rechazadas simplemente muestran dentro de la app su checkout web para una suscripción; aquí tienes las tres formas de solucionarlo, y lo que cambian y lo que no cambian los cambios regionales de 2025 y 2026.
Desde $109 de pago único por plataforma, o deja que nuestro equipo lo haga todo desde $698.
La política de pagos de Google tiene un núcleo sencillo. Si los usuarios pagan por una app o compran cosas digitales dentro de ella (funciones premium, suscripciones, contenido, créditos o moneda virtual, una versión sin anuncios, acceso a software en la nube), la transacción pasa por el sistema de facturación de Google Play, salvo que se aplique una excepción o uno de los programas regionales de Google. Las compras de bienes físicos (alimentación, ropa, electrónica) y de servicios físicos (transporte, comida a domicilio, cuotas de gimnasio, entradas para eventos) están exentas y usan tu propio proveedor de pagos, como Stripe. También están exentas algunas otras categorías, entre ellas los pagos entre particulares, las subastas online y las donaciones exentas de impuestos.
La segunda mitad de la regla trata de la redirección (steering). Dentro de la app no puedes llevar a los usuarios a otra forma de pagar los bienes digitales: nada de enlaces o botones hacia un checkout web, nada de un WebView que abra tu página de Stripe, nada de textos que animen a comprar fuera de la app, salvo que lo permita un programa en el que estés inscrito. Google permite expresamente las apps de solo consumo: los usuarios inician sesión y usan lo que pagaron en otro sitio, siempre que no se pueda comprar nada dentro de la app. Para esas apps, las preguntas frecuentes sobre la política de pagos de Google permiten incluso mencionar otras opciones de compra, siempre que no haya un enlace directo.
La entrada en Estado de las políticas (Policy status) cita la política de pagos y normalmente dice que la app ofrece contenido, funciones o suscripciones digitales mediante un método de pago distinto del sistema de facturación de Google Play, o que enlaza a los usuarios con uno. La captura suele ser tu página de precios, un banner de Upgrade o la página de Stripe Checkout abierta dentro de la app. En una app ya publicada, la incidencia puede llegar como advertencia con un plazo y acabar en una retirada si no se corrige.
| Vendes | Dentro de la app Android | Notas |
|---|---|---|
| Una suscripción a tu app (plan SaaS, nivel Pro) | Google Play Billing, o ninguna compra en la app | El rechazo por pagos más habitual en las apps hechas con vibe coding |
| Créditos de IA, tokens, generaciones | Google Play Billing (producto consumible) | Los créditos comprados en tu web se pueden seguir usando en la app |
| Cursos, plantillas, contenido descargable | Google Play Billing | Contenido digital que se consume en la app |
| Una versión sin anuncios | Google Play Billing | Con la API manual, disableadmob=true desactiva los anuncios después de la compra |
| Productos físicos de tu tienda | Stripe o el checkout de tu tienda | Play Billing no está pensado para bienes físicos |
| Servicios presenciales: reservas, limpieza, trayectos, comida a domicilio, entradas para eventos | Stripe | Los servicios físicos están exentos |
| Donaciones | Depende del destinatario | Las donaciones exentas de impuestos están exentas; revisa la política para tu caso |
Mi WebView de iOS finalmente está aprobada. ¡Gracias!
La regla básica tiene cada vez más excepciones regionales, y es la parte de la política de Play que más cambió en 2025 y 2026:
Lo que esto significa para ti: estos programas son opcionales, conllevan requisitos de inscripción, de interfaz y de declaración, solo se aplican a los usuarios de la región cubierta y no hacen que tu checkout web quede libre de comisiones. Mientras no estés inscrito y cumplas los requisitos, trata la regla básica como obligatoria, y consulta en la Play Console y en el Centro de ayuda las condiciones vigentes antes de construir nada en torno a ellos.
WebViewGold lanza compras de Play desde tu app web: revenuecat://purchase?external_id=…&product=… con RevenueCat, o los enlaces manuales inapppurchase:// e inappsubscription://, más restoreinapppurchases:// y cancelinapppurchase://. Requiere la Extended License; la configuración está en la documentación de compras in-app para Android y en la guía de RevenueCat.
Oculta dentro de la app todas las formas de comprar bienes digitales: la página de precios, los botones de upgrade, las recargas de créditos y el portal de facturación. Los suscriptores que pagaron en tu web inician sesión y lo tienen todo. Es la solución más rápida y no necesita productos nuevos, pero no genera ingresos dentro de la app.
Si la mayoría de tus usuarios están en una región cubierta y las cuentas salen, inscríbete en el programa correspondiente, sigue sus normas de interfaz y de declaración, y ofrece la alternativa solo a los usuarios que cumplen los requisitos. getstorelocation:// guarda el país de Play Store en storeLocation, lo que ayuda con los precios regionales; comprueba cómo define el programa a los usuarios que cumplen los requisitos antes de basar tu lógica en ello.
Si vendes productos físicos o servicios presenciales, conserva Stripe. Asegúrate de que no se venda nada digital, como una membresía premium o descargas, a través del mismo checkout, porque esa parte necesita Play Billing.
Solo consumo lleva una tarde; Play Billing, uno o dos días incluida la configuración de productos.
Páginas de precios, banners de upgrade, paywalls, botones para comprar más créditos, el portal de clientes de Stripe, enlaces en emails que se abren dentro de la app y redirecciones del servidor a Checkout después del registro o cuando termina una prueba. El revisor encontrará el que se te olvide.
Configura USER_AGENT en Config.java con el user agent por defecto más un token como WebViewGoldApp, y compruébalo en el navegador y en el servidor, para poder desactivar tanto las redirecciones como los botones. La guía de Stripe frente a compras in-app muestra el patrón completo.
Productos digitales: Play Billing u ocultos. Productos y servicios físicos: Stripe. Anota la decisión; tu app de iOS necesita la misma lista, y las normas de Apple son distintas (consulta la guía de la Directriz 3.1.1).
El archivo de CSS personalizado del proyecto Android solo se aplica dentro de la app (CSS y JavaScript personalizados), así que puedes ocultar ahí los elementos de precios y de checkout sin tocar tu web, como se muestra abajo. Las redirecciones a Stripe del lado del servidor necesitan la comprobación del user agent.
Crea los productos en la Play Console, conecta RevenueCat o usa los enlaces manuales, dale a las compras una successful_url que desbloquee la cuenta en tu servidor y prueba con testers de licencias antes de enviarla.
Abrir la página de Stripe en Chrome mediante EXTERNAL_LINK_HANDLING_OPTIONS o BROWSER_WHITELIST no ayuda. Un enlace desde la app a un checkout web para bienes digitales sigue siendo redirección, se abra donde se abra.
Dale a la cuenta de revisión de Datos de inicio de sesión el acceso de pago, describe en las instrucciones cómo funciona el pago en la app (Play Billing o solo consumo), sube la nueva versión y responde en Estado de las políticas.
Va en el archivo de CSS personalizado del proyecto Android de WebViewGold. Los selectores son ejemplos; usa las clases e IDs que tu app web usa de verdad.
/* Oculta dentro de la app Android todas las formas de comprar bienes digitales */
.pricing-table,
.upgrade-banner,
.buy-credits-button,
a[href*="checkout.stripe.com"],
a[href*="billing.stripe.com"],
a[href$="/pricing"] {
display: none !important;
}Para la vía de solo consumo. El agente cambia solo lo que ve la app y deja intacto el checkout de tu web.
Mi app web se ejecuta dentro de una app Android creada con WebViewGold. Google Play la rechazó por la política de pagos porque la app vende [nuestra suscripción Pro / créditos de IA] a través de Stripe. La app envía un user agent personalizado que contiene 'WebViewGoldApp'. Cuando una página o una petición viene de la app: - Oculta todas las páginas de precios, botones de upgrade, paywalls, recargas de créditos y enlaces a Stripe Checkout o al portal de clientes de Stripe para productos digitales. - Elimina las redirecciones del lado del servidor a Stripe después del registro o cuando termina una prueba; muestra en su lugar la app normal. - No muestres ningún texto que anime a comprar en la web, ni enlaces a ella. - Deja sin cambios el checkout de productos físicos [enuméralos, o escribe: ninguno]. - Los usuarios que se suscribieron en la web conservan el acceso completo al iniciar sesión. Fuera de la app, no cambies nada. Enumera cada punto de entrada de pago que hayas encontrado y cada archivo que hayas cambiado, para que pueda revisar cada uno en un teléfono.
Sí. Google regula lo que ocurre dentro de la app. Tu web, tus emails y tu marketing pueden vender como quieras, y quienes se suscribieron allí pueden iniciar sesión en la app y usarlo todo.
Para los usuarios de EE. UU., Google ya no exige Play Billing y permite enlaces a ofertas externas, pero lo gestiona a través de sus programas de facturación alternativa y de enlaces a contenido externo para EE. UU., con inscripción, declaraciones y comisiones de servicio. Lee la página de ayuda de Google para EE. UU. e inscríbete antes de mostrar un botón de Stripe a usuarios de EE. UU., y mantenlo fuera del alcance de los usuarios de otros países.
Normalmente porque también se vende algo digital, como una membresía con ventajas en la app, descargas digitales o una suscripción para funciones de la app, o porque las pantallas dan esa impresión. Revisa cada producto al que pueda llegar un revisor en la app.
No. WebViewGold también tiene enlaces manuales para compras únicas y suscripciones. RevenueCat es útil cuando vendes en iOS y Android y quieres un único lugar para los entitlements y los webhooks.
Sí. Usar compras in-app en un producto final requiere la Extended License de WebViewGold, como indica la documentación de compras in-app.
El principio es parecido, pero las normas, las excepciones y los cambios recientes de Apple en EE. UU. difieren en los detalles. Trata cada tienda por separado; la parte del App Store se explica en la guía de la Directriz 3.1.1.
El mismo resultado, con distinta cantidad de trabajo por tu parte. Las tres incluyen la garantía de aprobación y soporte humano 24/7.
$109 por plataforma, pago único
La licencia de WebViewGold: un proyecto de Xcode o Android Studio listo para usar. Pega tu URL, define nombre e icono, activa funciones, compila y envía. Actualizaciones gratuitas para siempre.
Ver planes en la página principal$349 por licencia, complemento de pago único
Sin Mac, sin Xcode, sin Android Studio: configura en el navegador, compilamos ambas apps en la nube y las entregamos a App Store Connect y a Play Console.
Cómo funciona el Cloud Builder Prueba la demo gratuita$698 por plataforma $798
Envíanos tu URL y tu icono. Nuestro equipo configura, compila y entrega tu app en 72 horas, en marca blanca y con los proyectos fuente. Ambas plataformas por $1,158.
Detalles del Full Service Con tecnología de
Precios de la Oferta de invierno válidos hasta el 31 de diciembre de 2026.
Garantía de aprobación en App Store & Google Play – o te devolvemos el dinero en 14 días
¿Prefieres delegarlo? Full Service: configuramos, compilamos y entregamos en 72 horas, desde $698 por plataforma. ¿Preguntas? Chatea con nosotros 24/7.
Los reembolsos se conceden bajo las condiciones indicadas en nuestras FAQ: un rechazo por motivos ajenos al contenido por parte de Apple y/o Google, reclamado dentro de los 14 días posteriores a la compra.