Refus Google Play
En dehors de quelques programmes régionaux, les biens numériques vendus dans une app Android doivent passer par Google Play Billing. Les biens physiques et les services du monde réel restent sur Stripe. La plupart des apps web encapsulées refusées affichent simplement dans l'app leur checkout web pour un abonnement ; voici les trois façons de corriger cela, et ce que les changements régionaux de 2025 et 2026 changent ou ne changent pas.
Dès $109 en paiement unique par plateforme, ou notre équipe s'occupe de tout dès $698.
Le règlement de Google sur les paiements repose sur un principe simple. Si les utilisateurs paient une app ou y achètent des choses numériques (fonctionnalités premium, abonnements, contenus, crédits ou monnaie virtuelle, version sans publicité, accès à un logiciel dans le cloud), la transaction passe par le système de facturation de Google Play, sauf si une exception ou l'un des programmes régionaux de Google s'applique. Les achats de biens physiques (courses, vêtements, électronique) et de services physiques (transport, livraison de repas, abonnements de salle de sport, billets d'événements) en sont exemptés et utilisent votre propre prestataire de paiement, comme Stripe. Quelques autres catégories sont aussi exemptées, dont les paiements entre particuliers, les enchères en ligne et les dons défiscalisés.
La seconde moitié de la règle porte sur l'incitation (steering). Dans l'app, vous ne pouvez pas orienter les utilisateurs vers un autre moyen de payer des biens numériques : pas de liens ni de boutons vers un checkout web, pas de WebView qui ouvre votre page Stripe, pas de formulation qui encourage à acheter hors de l'app, sauf si un programme auquel vous êtes inscrit l'autorise. Google autorise explicitement les apps de consultation seule (consumption-only) : les utilisateurs se connectent et utilisent ce qu'ils ont payé ailleurs, tant que rien ne peut être acheté dans l'app. Pour ces apps, la FAQ de Google sur le règlement sur les paiements permet même de mentionner d'autres options d'achat, tant qu'il n'y a pas de lien direct.
L'entrée dans État des règles cite le règlement sur les paiements et indique généralement que l'app propose des contenus, fonctionnalités ou abonnements numériques via un moyen de paiement autre que le système de facturation de Google Play, ou qu'elle y renvoie les utilisateurs. La capture d'écran montre typiquement votre page de tarifs, une bannière Passer à Pro ou la page Stripe Checkout ouverte dans l'app. Pour une app en ligne, le problème peut arriver sous forme d'avertissement avec une échéance et aboutir à un retrait s'il n'est pas corrigé.
| Vous vendez | Dans l'app Android | Remarques |
|---|---|---|
| Un abonnement à votre app (offre SaaS, formule Pro) | Google Play Billing, ou aucun achat dans l'app | Le refus pour paiements le plus fréquent dans les apps en vibe coding |
| Crédits IA, jetons, générations | Google Play Billing (produit consommable) | Les crédits achetés sur votre site web restent utilisables dans l'app |
| Cours, modèles, contenus téléchargeables | Google Play Billing | Contenu numérique consommé dans l'app |
| Une version sans publicité | Google Play Billing | Avec l'API manuelle, disableadmob=true désactive les annonces après l'achat |
| Des produits physiques de votre boutique | Stripe ou le checkout de votre boutique | Play Billing n'est pas prévu pour les biens physiques |
| Services en personne : réservations, ménage, trajets, livraison de repas, billets d'événements | Stripe | Les services physiques sont exemptés |
| Dons | Selon le bénéficiaire | Les dons défiscalisés sont exemptés ; vérifiez le règlement pour votre cas |
Mon WebView iOS est enfin approuvé. Merci !!
La règle de base compte de plus en plus d'exceptions régionales, et c'est la partie des règles Play qui a le plus changé en 2025 et 2026 :
Ce que cela signifie pour vous : ces programmes se font sur inscription, s'accompagnent d'exigences d'inscription, d'interface et de déclaration, ne s'appliquent qu'aux utilisateurs de la région couverte et ne rendent pas votre checkout web exempt de frais. Tant que vous n'êtes pas inscrit et conforme, considérez la règle de base comme contraignante, et vérifiez les conditions actuelles dans la Play Console et le Centre d'aide avant de construire quoi que ce soit autour.
WebViewGold déclenche les achats Play depuis votre app web : revenuecat://purchase?external_id=…&product=… avec RevenueCat, ou les liens manuels inapppurchase:// et inappsubscription://, plus restoreinapppurchases:// et cancelinapppurchase://. Cela nécessite l'Extended License ; la configuration est décrite dans la documentation sur les achats in-app pour Android et le guide RevenueCat.
Masquez dans l'app tout moyen d'acheter des biens numériques : la page de tarifs, les boutons de mise à niveau, les recharges de crédits, le portail de facturation. Les abonnés qui ont payé sur votre site web se connectent et ont accès à tout. C'est la correction la plus rapide et elle ne demande aucun nouveau produit, mais elle ne rapporte rien dans l'app.
Si la plupart de vos utilisateurs se trouvent dans une région couverte et que les chiffres s'y prêtent, inscrivez-vous au programme correspondant, respectez ses règles d'interface et de déclaration, et ne proposez l'alternative qu'aux utilisateurs éligibles. getstorelocation:// place le pays du Play Store dans storeLocation, ce qui aide pour les prix régionaux ; vérifiez comment le programme définit les utilisateurs éligibles avant de vous baser dessus.
Si vous vendez des produits physiques ou des services en personne, gardez Stripe. Assurez-vous que rien de numérique, comme une adhésion premium ou des téléchargements, n'est vendu par le même checkout, car cette partie exige Play Billing.
La consultation seule prend un après-midi ; Play Billing prend un ou deux jours, configuration des produits comprise.
Pages de tarifs, bannières de mise à niveau, paywalls, boutons pour acheter plus de crédits, portail client Stripe, liens dans les e-mails qui s'ouvrent dans l'app, et redirections serveur vers Checkout après l'inscription ou à la fin d'un essai. L'examinateur trouvera celui que vous avez oublié.
Réglez USER_AGENT dans Config.java sur le user agent par défaut plus un jeton comme WebViewGoldApp, et testez-le dans le navigateur et sur le serveur, pour pouvoir désactiver les redirections aussi bien que les boutons. Le guide Stripe ou achat in-app montre le modèle complet.
Produits numériques : Play Billing ou masqués. Produits et services physiques : Stripe. Notez la décision ; votre app iOS a besoin de la même liste, et les règles d'Apple diffèrent (voir le guide sur la guideline 3.1.1).
Le fichier CSS personnalisé du projet Android ne s'applique que dans l'app (CSS et JavaScript personnalisés), vous pouvez donc y masquer les éléments de tarifs et de checkout sans toucher à votre site web, comme ci-dessous. Les redirections côté serveur vers Stripe nécessitent le test du user agent.
Créez les produits dans la Play Console, connectez RevenueCat ou utilisez les liens manuels, donnez aux achats une successful_url qui débloque le compte sur votre serveur, et testez avec des testeurs de licence avant de soumettre.
Ouvrir la page Stripe dans Chrome via EXTERNAL_LINK_HANDLING_OPTIONS ou BROWSER_WHITELIST n'aide pas. Un lien de l'app vers un checkout web pour des biens numériques reste une incitation, quel que soit l'endroit où il s'ouvre.
Donnez au compte d'examen dans Identifiants de connexion (Sign-in details) le droit payant, décrivez dans les instructions comment se passe le paiement dans l'app (Play Billing ou consultation seule), importez la nouvelle version et répondez dans État des règles.
À placer dans le fichier CSS personnalisé du projet Android WebViewGold. Les sélecteurs sont des exemples ; utilisez les classes et ID que votre app web utilise réellement.
/* Masquer dans l'app Android tout moyen d'acheter des biens numériques */
.pricing-table,
.upgrade-banner,
.buy-credits-button,
a[href*="checkout.stripe.com"],
a[href*="billing.stripe.com"],
a[href$="/pricing"] {
display: none !important;
}Pour la voie de la consultation seule. L'agent ne modifie que ce que voit l'app et laisse le checkout de votre site web tranquille.
Mon app web tourne dans une app Android créée avec WebViewGold. Google Play l'a refusée au titre du règlement sur les paiements (Payments policy), car l'app vend [notre abonnement Pro / des crédits IA] via Stripe. L'app envoie un user agent personnalisé qui contient 'WebViewGoldApp'. Quand une page ou une requête vient de l'app : - Masque chaque page de tarifs, bouton de mise à niveau, paywall, recharge de crédits et lien vers Stripe Checkout ou le portail client Stripe pour les produits numériques. - Supprime les redirections côté serveur vers Stripe après l'inscription ou à la fin d'un essai ; affiche plutôt l'app normale. - N'affiche aucun texte qui encourage à acheter sur le site web, et aucun lien vers celui-ci. - Laisse inchangé le checkout des produits physiques [liste-les, ou écris : aucun]. - Les utilisateurs abonnés sur le web gardent un accès complet après connexion. En dehors de l'app, ne change rien. Liste chaque point d'entrée de paiement que tu as trouvé et chaque fichier que tu as modifié, pour que je puisse les vérifier un par un sur un téléphone.
Oui. Google réglemente ce qui se passe dans l'app. Votre site web, vos e-mails et votre marketing peuvent vendre comme bon vous semble, et les personnes qui s'y sont abonnées peuvent se connecter à l'app et tout utiliser.
Pour les utilisateurs américains, Google n'exige plus Play Billing et autorise les liens vers des offres extérieures, mais il gère cela via ses programmes américains de facturation alternative et de liens vers du contenu externe, avec inscription, déclarations et frais de service. Lisez la page d'aide de Google pour les États-Unis et inscrivez-vous avant de livrer un bouton Stripe aux utilisateurs américains, et tenez-le à l'écart des utilisateurs des autres pays.
En général parce que quelque chose de numérique est aussi en vente, comme une adhésion avec des avantages dans l'app, des téléchargements numériques ou un abonnement pour des fonctionnalités de l'app, ou parce que les écrans le laissent croire. Vérifiez chaque produit qu'un examinateur peut atteindre dans l'app.
Non. WebViewGold propose aussi des liens manuels pour les achats uniques et les abonnements. RevenueCat est utile quand vous vendez sur iOS et Android et voulez un seul endroit pour les droits d'accès et les webhooks.
Oui. Utiliser les achats in-app dans un produit final nécessite l'Extended License de WebViewGold, comme l'indique la documentation sur les achats in-app.
Le principe est similaire, mais les règles d'Apple, ses exceptions et ses récents changements aux États-Unis diffèrent dans le détail. Traitez chaque store séparément ; le côté App Store est couvert dans le guide sur la guideline 3.1.1.
Même résultat, charge de travail différente de votre côté. Les trois formules incluent la garantie d'approbation et le support humain 24/7.
$109 par plateforme, paiement unique
La licence WebViewGold : un projet Xcode ou Android Studio prêt à l'emploi. Collez votre URL, définissez le nom et l'icône, activez les fonctionnalités, compilez et soumettez. Mises à jour gratuites à vie.
Voir les offres sur la page principale$349 par licence, extension en paiement unique
Ni Mac, ni Xcode, ni Android Studio : configurez dans le navigateur, nous compilons les deux apps dans le cloud et les transmettons à App Store Connect et à la Play Console.
Comment fonctionne le Cloud Builder Essayer la démo gratuite$698 par plateforme $798
Envoyez-nous votre URL et votre icône. Notre équipe configure, compile et livre votre app sous 72 heures, en marque blanche, projets sources inclus. Les deux plateformes pour $1,158.
Détails du Full Service Propulsé par
Prix Soldes d'hiver valables jusqu'au 31 décembre 2026.
Garantie d'approbation App Store & Google Play – ou remboursement sous 14 jours
Vous préférez déléguer ? Full Service : nous configurons, compilons et livrons sous 72 heures, dès $698 par plateforme. Des questions ? Chattez avec nous 24/7.
Les remboursements sont accordés aux conditions indiquées dans notre FAQ : un refus non lié au contenu par Apple et/ou Google, demandé dans les 14 jours suivant l'achat.