Ablehnung bei Google Play
Außerhalb einiger regionaler Programme müssen digitale Güter, die in einer Android-App verkauft werden, über Google Play Billing laufen. Physische Waren und Dienstleistungen in der realen Welt bleiben bei Stripe. Die meisten abgelehnten Web-Wrapper-Apps zeigen in der App schlicht ihren Web-Checkout für ein Abo; hier sind die drei Wege, das zu beheben, und was die regionalen Änderungen von 2025 und 2026 ändern und was nicht.
Ab $109 einmalig pro Plattform, oder unser Team erledigt alles ab $698.
Googles Zahlungsrichtlinie hat einen einfachen Kern. Bezahlen Nutzer für eine App oder kaufen sie darin digitale Dinge (Premium-Funktionen, Abos, Inhalte, Credits oder virtuelle Währung, eine werbefreie Version, Zugang zu Cloud-Software), läuft die Transaktion über das Abrechnungssystem von Google Play, sofern keine Ausnahme und keines der regionalen Programme von Google greift. Käufe physischer Waren (Lebensmittel, Kleidung, Elektronik) und physischer Dienstleistungen (Beförderung, Essenslieferung, Fitnessstudio-Mitgliedschaften, Veranstaltungstickets) sind ausgenommen und laufen über deinen eigenen Zahlungsanbieter, etwa Stripe. Einige weitere Kategorien sind ebenfalls ausgenommen, darunter Peer-to-Peer-Zahlungen, Online-Auktionen und steuerbefreite Spenden.
Die zweite Hälfte der Regel betrifft das Umlenken (Steering). In der App darfst du Nutzer nicht zu einem anderen Zahlungsweg für digitale Güter führen: keine Links oder Buttons zu einem Web-Checkout, keine WebView, die deine Stripe-Seite öffnet, keine Formulierungen, die zum Kauf außerhalb der App ermuntern, es sei denn, ein Programm, an dem du teilnimmst, erlaubt es. Google erlaubt ausdrücklich reine Nutzungs-Apps (consumption-only): Nutzer melden sich an und nutzen, wofür sie anderswo bezahlt haben, solange sich in der App nichts kaufen lässt. Für diese Apps erlauben Googles FAQ zur Zahlungsrichtlinie sogar, andere Kaufmöglichkeiten zu erwähnen, solange es keinen direkten Link gibt.
Der Eintrag im Richtlinienstatus zitiert die Zahlungsrichtlinie und sagt meist, dass die App digitale Inhalte, Funktionen oder Abos über eine andere Zahlungsmethode als das Abrechnungssystem von Google Play anbietet oder Nutzer zu einer solchen verlinkt. Der Screenshot zeigt typischerweise deine Preisseite, ein Upgrade-Banner oder die in der App geöffnete Stripe-Checkout-Seite. Bei einer Live-App kann das Problem als Warnung mit Frist kommen und bis zur Entfernung eskalieren, wenn es nicht behoben wird.
| Du verkaufst | In der Android-App | Hinweise |
|---|---|---|
| Ein Abo für deine App (SaaS-Plan, Pro-Stufe) | Google Play Billing oder gar kein Kauf in der App | Die häufigste Ablehnung nach der Zahlungsrichtlinie bei Vibe-Coding-Apps |
| KI-Credits, Tokens, Generierungen | Google Play Billing (Verbrauchsprodukt) | Auf deiner Website gekaufte Credits können weiterhin in der App genutzt werden |
| Kurse, Vorlagen, herunterladbare Inhalte | Google Play Billing | Digitale Inhalte, die in der App genutzt werden |
| Eine werbefreie Version | Google Play Billing | Mit der manuellen API schaltet disableadmob=true die Werbung nach dem Kauf ab |
| Physische Produkte aus deinem Shop | Stripe oder dein Shop-Checkout | Play Billing ist nicht für physische Waren gedacht |
| Dienstleistungen vor Ort: Buchungen, Reinigung, Fahrten, Essenslieferung, Veranstaltungstickets | Stripe | Physische Dienstleistungen sind ausgenommen |
| Spenden | Hängt vom Empfänger ab | Steuerbefreite Spenden sind ausgenommen; prüf die Richtlinie für deinen Fall |
Mein iOS WebView wurde endlich genehmigt. Danke!!
Die Kernregel hat eine wachsende Zahl regionaler Ausnahmen, und dieser Teil der Play-Richtlinien hat sich 2025 und 2026 am stärksten verändert:
Was das für dich bedeutet: Diese Programme sind freiwillig, bringen Anforderungen an Teilnahme, Benutzeroberfläche und Meldungen mit, gelten nur für Nutzer in der jeweiligen Region und machen deinen Web-Checkout nicht gebührenfrei. Solange du nicht teilnimmst und alle Auflagen erfüllst, betrachte die Kernregel als verbindlich, und prüf in der Play Console und in der Hilfe die aktuellen Bedingungen, bevor du irgendetwas darauf aufbaust.
WebViewGold löst Play-Käufe aus deiner Web-App aus: revenuecat://purchase?external_id=…&product=… mit RevenueCat oder die manuellen Links inapppurchase:// und inappsubscription://, dazu restoreinapppurchases:// und cancelinapppurchase://. Das setzt die Extended License voraus; die Einrichtung steht in der Android-Doku zu In-App-Käufen und im RevenueCat-Guide.
Blende in der App jede Möglichkeit aus, digitale Güter zu kaufen: die Preisseite, Upgrade-Buttons, Credit-Aufladungen, das Abrechnungsportal. Abonnenten, die auf deiner Website bezahlt haben, melden sich an und bekommen alles. Das ist die schnellste Lösung und braucht keine neuen Produkte, bringt in der App aber keinen Umsatz.
Sind die meisten deiner Nutzer in einer abgedeckten Region und gehen die Zahlen auf, nimm am passenden Programm teil, halte dich an seine Regeln für Benutzeroberfläche und Meldungen und biete die Alternative nur berechtigten Nutzern an. getstorelocation:// schreibt das Play-Store-Land in storeLocation, was bei regionalen Preisen hilft; prüf, wie das Programm berechtigte Nutzer definiert, bevor du danach verzweigst.
Verkaufst du physische Produkte oder Dienstleistungen vor Ort, behalte Stripe. Achte darauf, dass über denselben Checkout nichts Digitales verkauft wird, etwa eine Premium-Mitgliedschaft oder Downloads, denn dieser Teil braucht Play Billing.
Reine Nutzung dauert einen Nachmittag; Play Billing einen oder zwei Tage inklusive Produkteinrichtung.
Preisseiten, Upgrade-Banner, Paywalls, Buttons zum Nachkaufen von Credits, das Stripe-Kundenportal, Links in E-Mails, die sich in der App öffnen, und Server-Weiterleitungen zum Checkout nach der Registrierung oder am Ende einer Testphase. Der Reviewer findet genau den, den du vergisst.
Setze USER_AGENT in Config.java auf den Standard-User-Agent plus ein Token wie WebViewGoldApp und prüf es im Browser und auf dem Server, damit du Weiterleitungen genauso abschalten kannst wie Buttons. Der Guide Stripe vs. In-App-Kauf zeigt das vollständige Muster.
Digitale Produkte: Play Billing oder ausgeblendet. Physische Produkte und Dienstleistungen: Stripe. Schreib die Entscheidung auf; deine iOS-App braucht dieselbe Liste, und Apples Regeln weichen ab (siehe den Guide zu Guideline 3.1.1).
Die Custom-CSS-Datei des Android-Projekts gilt nur in der App (Custom CSS und JavaScript), daher kannst du dort Preis- und Checkout-Elemente ausblenden, ohne deine Website anzufassen, wie unten gezeigt. Serverseitige Weiterleitungen zu Stripe brauchen die User-Agent-Prüfung.
Lege die Produkte in der Play Console an, verbinde RevenueCat oder nutze die manuellen Links, gib Käufen eine successful_url, die das Konto auf deinem Server freischaltet, und teste vor der Einreichung mit Lizenztestern.
Die Stripe-Seite über EXTERNAL_LINK_HANDLING_OPTIONS oder BROWSER_WHITELIST in Chrome zu öffnen, hilft nicht. Ein Link aus der App zu einem Web-Checkout für digitale Güter bleibt Umlenkung, egal wo er sich öffnet.
Schalte für den Review-Account in den Anmeldedaten (Sign-in details) den bezahlten Zugang frei, beschreibe in der Anleitung, wie Bezahlen in der App funktioniert (Play Billing oder reine Nutzung), lade die neue Version hoch und antworte im Richtlinienstatus.
Gehört in die Custom-CSS-Datei des WebViewGold-Android-Projekts. Die Selektoren sind Beispiele; nutze die Klassen und IDs, die deine Web-App wirklich verwendet.
/* Jede Möglichkeit ausblenden, in der Android-App digitale Güter zu kaufen */
.pricing-table,
.upgrade-banner,
.buy-credits-button,
a[href*="checkout.stripe.com"],
a[href*="billing.stripe.com"],
a[href$="/pricing"] {
display: none !important;
}Für den Weg der reinen Nutzung. Der Agent ändert nur, was die App sieht, und lässt den Checkout deiner Website in Ruhe.
Meine Web-App läuft in einer Android-App, die mit WebViewGold gebaut ist. Google Play hat sie nach der Zahlungsrichtlinie (Payments policy) abgelehnt, weil die App [unser Pro-Abo / KI-Credits] über Stripe verkauft. Die App sendet einen eigenen User-Agent, der 'WebViewGoldApp' enthält. Wenn eine Seite oder Anfrage aus der App kommt: - Blende jede Preisseite, jeden Upgrade-Button, jede Paywall, jede Credit-Aufladung und jeden Link zu Stripe Checkout oder zum Stripe-Kundenportal für digitale Produkte aus. - Entferne serverseitige Weiterleitungen zu Stripe nach der Registrierung oder am Ende einer Testphase; zeig stattdessen die normale App. - Zeig keinen Text, der zum Kauf auf der Website ermuntert, und keine Links dorthin. - Lass den Checkout für physische Produkte [liste sie auf oder schreib: keine] unverändert. - Nutzer, die im Web abonniert haben, behalten nach dem Login vollen Zugriff. Außerhalb der App änderst du nichts. Liste jeden gefundenen Einstiegspunkt für Zahlungen und jede geänderte Datei auf, damit ich alles auf einem Smartphone prüfen kann.
Ja. Google regelt, was in der App passiert. Deine Website, deine E-Mails und dein Marketing dürfen verkaufen, wie du willst, und wer dort abonniert hat, kann sich in der App anmelden und alles nutzen.
Für Nutzer in den USA verlangt Google kein Play Billing mehr und erlaubt Links zu externen Angeboten, regelt das aber über seine US-Programme für alternative Abrechnung und für Links zu externen Inhalten, mit Teilnahme, Meldepflichten und Servicegebühren. Lies Googles Hilfeseite für die USA und melde dich an, bevor du US-Nutzern einen Stripe-Button zeigst, und halte ihn von Nutzern in anderen Ländern fern.
Meist, weil auch etwas Digitales verkauft wird, etwa eine Mitgliedschaft mit App-Vorteilen, digitale Downloads oder ein Abo für App-Funktionen, oder weil die Screens danach aussehen. Prüf jedes Produkt, das ein Reviewer in der App erreichen kann.
Nein. WebViewGold hat auch manuelle Links für Einmalkäufe und Abos. RevenueCat ist nützlich, wenn du auf iOS und Android verkaufst und Entitlements und Webhooks an einem Ort haben willst.
Ja. Für In-App-Käufe in einem Endprodukt ist die WebViewGold Extended License erforderlich, wie die Doku zu In-App-Käufen angibt.
Das Prinzip ist ähnlich, aber Apples Regeln, Ausnahmen und die jüngsten Änderungen in den USA unterscheiden sich im Detail. Behandle jeden Store separat; die App-Store-Seite behandelt der Guide zu Guideline 3.1.1.
Gleiches Ergebnis, unterschiedlich viel Arbeit auf deiner Seite. Alle drei kommen mit Genehmigungsgarantie und 24/7 Support von echten Menschen.
$109 pro Plattform, einmalig
Die WebViewGold-Lizenz: ein fertiges Xcode- oder Android-Studio-Projekt. URL einfügen, Name und Icon setzen, Features einschalten, bauen und einreichen. Kostenlose Updates für immer.
Pakete auf der Hauptseite ansehen$349 pro Lizenz, einmaliges Add-on
Kein Mac, kein Xcode, kein Android Studio: Du konfigurierst im Browser, wir bauen beide Apps in der Cloud und übergeben sie an App Store Connect und die Play Console.
So funktioniert der Cloud Builder Kostenlose Demo ausprobieren$698 pro Plattform $798
Schick uns deine URL und dein Icon. Unser Team konfiguriert, baut und liefert deine App innerhalb von 72 Stunden, White-Label, inklusive Quellprojekten. Beide Plattformen für $1,158.
Full-Service-Details Powered by
Winter-Sale-Preise gültig bis 31. Dezember 2026.
App Store & Google Play Genehmigungsgarantie – oder Geld zurück innerhalb von 14 Tagen
Lieber abgeben? Full Service: Wir konfigurieren, bauen und liefern innerhalb von 72 Stunden, ab $698 pro Plattform. Fragen? Chatte mit uns – 24/7.
Erstattungen erfolgen zu den in unseren FAQ genannten Bedingungen: eine nicht inhaltsbedingte Ablehnung durch Apple und/oder Google, geltend gemacht innerhalb von 14 Tagen nach dem Kauf.