Zum Inhalt springen

Android Play Store Review Guidelines für IAP

GitHub

Damit deine Android-App bei Google Play freigegeben wird, musst du die Google-Richtlinien einhalten – besonders bei Apps mit In-App-Käufen und Abonnements. Dieser Guide zeigt dir alles, was du für eine erfolgreiche Review brauchst.

  1. Erstelle ein signiertes Android App Bundle

    Neue Google Play Apps sollten als Android App Bundle hochgeladen werden (.aab), nicht als per Sideload installierte Debug-APK.

    Behalte deinen versionCode bei jedem Upload ansteigen und bewahre deinen Upload-Key sicher auf, falls du Play App Signing nutzt.

    Android App Bundle Workflow

  2. Lege den App-Eintrag in der Play Console an

    Falls du noch kein Developer-Konto hast, beginne mit Play-Console-Registrierung. Gehe dann zu Home > App erstellen, wähle die Sprache, den App-/Spiele-Typ, den Status (kostenlos/kostenpflichtig), die Support-E-Mail und akzeptiere die erforderlichen Erklärungen.

    Choose the free/paid setting carefully. Google lets you change a paid app to free later, but once an app has been offered for free, it cannot be switched to paid.

    App in der Play Console erstellen

  3. App-Inhalte und Store-Eintrag vervollständigen

    Schließe vor der Production-Review die erforderlichen Play Console Erklärungen ab:

    • Datenschutzerklärung
    • Werbung
    • App-Zugriff
    • Zielgruppe und Inhalte
    • Altersfreigabe
    • Datensicherheit
    • Deklarationen sensibler Berechtigungen, falls zutreffend
  4. Einen über Play installierten Test-Track durchlaufen

    Starte mit Internes Testing für schnelle QA. Wenn dein Developer-Account ein persönlicher Account ist, der nach dem 13. November 2023 erstellt wurde, musst du zusätzlich einen geschlossenen Test mit mindestens 12 angemeldeten Testern an 14 aufeinanderfolgenden Tagen, bevor du Produktionszugriff erhältst.

    Internes Testing in der Play Console

  5. Billing End-to-End verifizieren

    Installiere die App über Google Play, nicht über eine lokal exportierte APK. Bestätige dann:

    • Produkte werden korrekt aus Play geladen
    • Das Kauf-Sheet zeigt ein test purchase Banner für Lizenztester
    • Entitlements werden nach dem Kauf freigeschaltet
    • Restore- und Subscription-Management-Flows funktionieren

Google Play Billing-Anforderungen

Abschnitt „Google Play Billing Requirements“

Verpflichtendes Abrechnungssystem

Abschnitt „Verpflichtendes Abrechnungssystem“

Für digitale Güter und Dienste musst nutzt du das Google Play Billing System:

Digitale Güter (Play Billing Pflicht):

  • Abonnements für Premium-Features
  • In-App-Währung oder Credits
  • Digitale Inhalte (E-Books, Musik, Videos)
  • Game-Upgrades und Power-ups
  • App-Freischaltungen und Premium-Stufen

Physische Güter (Play Billing nicht erlaubt):

  • Physische Merchandise-Artikel
  • Echte Dienstleistungen
  • Einmalige Spenden an Non-Profits

:::note Abo-Setup In der Play Console konfigurierst du Android-Abos über das aktuelle Abo -> Basisplan -> Angebot Modell. In native-purchases, übergeben Sie die Base Plan ID mit planIdentifier. :::

import { NativePurchases, PURCHASE_TYPE } from '@capgo/native-purchases';
// Ensure billing is available on the device
const { isBillingSupported } = await NativePurchases.isBillingSupported();
if (!isBillingSupported) throw new Error('Google Play Billing not available');
// Fetch subscription products (Store data is required—never hardcode pricing)
const { products } = await NativePurchases.getProducts({
productIdentifiers: ['premium_monthly', 'premium_yearly'],
productType: PURCHASE_TYPE.SUBS,
});
// Plan identifiers are the Base Plan IDs you create in Google Play Console
const transaction = await NativePurchases.purchaseProduct({
productIdentifier: 'premium_monthly',
planIdentifier: 'monthly-plan', // REQUIRED on Android, ignored on iOS
productType: PURCHASE_TYPE.SUBS,
});
console.log('Purchase token for server validation:', transaction.purchaseToken);

Google Play schreibt eine klare Offenlegung aller Kosten vor dem Kauf vor:

Erforderliche Elemente:

  • Exakter Preis in der lokalen Währung des Nutzers
  • Abrechnungsintervall (monatlich, jährlich, etc.)
  • Was im Abonnement enthalten ist
  • Gesamtkosten für Einführungsangebote
  • Zeitpunkt der Abrechnung

Best Practices für das UI-Design

Beispiel für konforme UI:

function SubscriptionCard({ product }) {
return (
<div className="subscription-card">
<h3>{product.title}</h3>
{/* Show intro offer if available */}
{product.introductoryPrice && (
<div className="intro-offer">
<p className="intro-price">{product.introductoryPriceString}</p>
<p className="intro-period">
for {product.introductoryPricePeriod}
</p>
</div>
)}
{/* Regular price */}
<div className="regular-price">
<p className="price">{product.priceString}</p>
<p className="period">per {product.subscriptionPeriod}</p>
</div>
{/* Clear description */}
<p>{product.description}</p>
{/* Renewal terms */}
<p className="terms">
Renews automatically. Cancel anytime in Google Play.
</p>
<button onClick={() => handlePurchase(product)}>
Subscribe Now
</button>
</div>
);
}

Hinweis zur automatischen Verlängerung

Abschnitt „Hinweis zur automatischen Verlängerung“

Bevor sich ein Abo automatisch verlängert, verlangt Google:

  • Klare Benachrichtigung über die Verlängerung
  • Erinnerung an den Preis
  • Einfacher Kündigungsprozess

Wenn du dasselbe Entitlement auf mehreren Plattformen verkaufst, sollten Produktname, Abrechnungszeitraum, enthaltene Vorteile und die Sprache zur Verlängerung konsistent sein, um Überraschungen für die Nutzer zu vermeiden.

Preise können aufgrund von Steuern, lokaler Währung oder Store-Ökonomie legitim variieren, aber das Purchase-UI darf diese Unterschiede niemals verbergen oder Kosten suggerieren, die von Google Play anders abgerechnet werden.

Anforderungen an die Datenschutzerklärung

Abschnitt „Anforderungen an die Datenschutzerklärung“

Wenn deine App In-App-Käufe enthält, musst du:

  1. Link im Play Store Listing

    • Datenschutz-URL in der Play Console hinterlegen
    • Muss öffentlich zugänglich sein
    • Muss in derselben Sprache wie deine App sein
  2. Link innerhalb der App

    • Datenschutzrichtlinie in den App-Einstellungen anzeigen
    • Vor dem Erheben von Nutzerdaten anzeigen
    • Leicht auffindbar machen

Beispiel-Implementierung:

function SettingsScreen() {
const openPrivacyPolicy = () => {
window.open('https://yourapp.com/privacy', '_blank');
};
const openTerms = () => {
window.open('https://yourapp.com/terms', '_blank');
};
return (
<div>
<h2>Settings</h2>
<button onClick={openPrivacyPolicy}>
Privacy Policy
</button>
<button onClick={openTerms}>
Terms of Service
</button>
<button onClick={() => NativePurchases.manageSubscriptions()}>
Manage Subscriptions
</button>
</div>
);
}

Datensicherheitsbereich

Abschnitt „Datensicherheit“

Google Play erfordert detaillierte Angaben im Bereich Datensicherheit:

Für IAP-Apps müssen folgende Punkte deklariert werden:

  • Erfassung des Kaufverlaufs
  • E-Mail-Adressen (für Belege)
  • Geräte-IDs (zur Betrugsprävention)
  • Verarbeitung von Zahlungsinformationen
  • Erfassung von Analysedaten

Der Bereich Datensicherheit ist rechtlich bindend. Falsche Angaben können zur Entfernung der App führen.

Erklärungen zu App-Inhalten

Abschnitt „App-Inhaltsangaben“

Der Google Play Review umfasst nicht nur das Binary. Vor einem Production-Release müssen die Angaben unter Richtlinien und Programme > App-Inhalte.

Das Minimum, das sorgfältig geprüft werden sollte:

  • Datenschutzerklärung: Öffentliche URL in der Play Console, plus ein In-App-Einstiegspunkt, falls erforderlich
  • Werbung: Angeben, ob die App Werbung enthält
  • App-Zugriff: Gib den Prüfern funktionierende Zugangsdaten oder einen klaren Testpfad, falls ein Screen zugangsbeschränkt ist
  • Zielgruppe und Inhalte: Die tatsächliche Zielgruppe der App korrekt angeben
  • Altersfreigaben: Den IARC-Fragebogen ausfüllen, damit die App nicht als „nicht bewertet“ markiert wird
  • Datensicherheit: Geben Sie Angaben zu Datensammlung, Weitergabe und Sicherheit korrekt an

Warum es fehlschlägt:

  • Kein Google Play Billing für digitale Güter
  • Veraltete Billing-APIs im Einsatz
  • Implementierung eigener Zahlungslösungen für Abonnements

Prävention:

// ✅ Correct: Use native-purchases (uses Google Play Billing)
await NativePurchases.purchaseProduct({
productIdentifier: 'premium_monthly',
planIdentifier: 'monthly-plan',
productType: PURCHASE_TYPE.SUBS,
});
// ❌ Wrong: Custom payment processor for subscriptions
// await CustomPayment.charge(user, 9.99);

2. Unklare Preise oder versteckte Kosten

Abschnitt: „2. Unklare Preise oder versteckte Kosten“

Warum es fehlschlägt:

  • Preis erst nach Klick auf Kauf sichtbar
  • Zusatzgebühren werden nicht vorab angezeigt
  • Vage Abo-Bedingungen

Prävention:

function PurchaseScreen({ product }) {
return (
<div>
{/* Show ALL costs upfront */}
<h2>Premium Subscription</h2>
<div className="pricing">
<p className="price">{product.priceString}/month</p>
<p className="taxes">Taxes may apply based on location</p>
</div>
<div className="features">
<h3>Includes:</h3>
<ul>
<li>Ad-free experience</li>
<li>Unlimited cloud storage</li>
<li>Priority support</li>
</ul>
</div>
<div className="terms">
<p>
Subscription renews automatically unless cancelled at least
24 hours before the end of the current period.
</p>
<p>
Manage or cancel in Google Play Subscriptions.
</p>
</div>
<button onClick={handlePurchase}>
Start Subscription
</button>
</div>
);
}

3. Irreführende Abo-Praktiken

Abschnitt: „3. Irreführende Abo-Muster“

Warum es fehlschlägt:

  • Premium-Optionen vorauswählen
  • Günstigere Alternativen verstecken
  • Kündigungen erschweren
  • Künstliche Verknappung („Nur noch 3 Plätze frei!“)

Best Practices für die Beschreibung

Marketing-Richtlinien

Prävention:

  • Alle Abo-Stufen gleichwertig anzeigen
  • Kündigung klar und leicht zugänglich machen
  • Countdown-Timer oder künstliche Verknappung vermeiden
  • Keine Dark Patterns für teure Optionen nutzen

Warum es fehlschlägt:

  • App stürzt beim Kauf ab
  • Produkte werden nicht geladen
  • Kaufbestätigung wird nicht angezeigt
  • Premium-Features werden nach Kauf nicht freigeschaltet
  • Tests wurden nur mit Sideload-Builds durchgeführt, anstatt über einen Play-installierten Test-Track

Prävention:

import { NativePurchases, PURCHASE_TYPE } from '@capgo/native-purchases';
// Comprehensive testing before submission
async function testPurchaseFlow() {
try {
// 1. Test product loading
const { products } = await NativePurchases.getProducts({
productIdentifiers: ['premium_monthly', 'premium_yearly'],
productType: PURCHASE_TYPE.SUBS,
});
console.log('✓ Products loaded:', products.length);
// 2. Test purchase flow
const transaction = await NativePurchases.purchaseProduct({
productIdentifier: 'premium_monthly',
planIdentifier: 'monthly-plan',
productType: PURCHASE_TYPE.SUBS,
});
console.log('✓ Purchase completed', transaction.transactionId);
// 3. Verify entitlements
const { purchases } = await NativePurchases.getPurchases({
productType: PURCHASE_TYPE.SUBS,
});
if (
purchases.some(
(purchase) =>
purchase.productIdentifier === 'premium_monthly' &&
['PURCHASED', '1'].includes(purchase.purchaseState ?? '') &&
purchase.isAcknowledged,
)
) {
console.log('✓ Premium features unlocked');
}
// 4. Test restore
await NativePurchases.restorePurchases();
console.log('✓ Restore works');
} catch (error) {
console.error('✗ Test failed:', error);
}
}

5. Verstöße gegen die Datenschutzerklärung

Abschnitt „5. Verstöße gegen die Datenschutzrichtlinie“

Warum es fehlschlägt:

  • Kein Link zur Datenschutzerklärung in der App
  • Datenschutzerklärung nicht aufrufbar
  • Datenerhebung nicht offengelegt
  • Abschnitt „Datensicherheit“ ungenau

Prävention:

  • Datenschutzerklärung im Play Store Listing hinzufügen
  • Link in den App-Einstellungen einfügen
  • Abschnitt „Datensicherheit“ korrekt ausfüllen
  • Update der Richtlinien bei neuer Datenerhebung

Alternative Abrechnungsprogramme

Abschnitt „Alternative Abrechnungsprogramme“

Googles alternative Abrechnungsprogramme sind regionsspezifisch und können sich ändern. Falls Sie von der Standard-Google-Play-Abrechnung abweichen möchten, prüfen Sie die genaue Marktzulassung, die benötigten APIs und die Pflichtangaben in der Play Console unmittelbar vor der Implementierung.

Nutzer müssen folgende Optionen haben:

  • Aktive Abos einfach einsehen
  • Ohne Support-Kontakt kündigen
  • Kündigungszeitpunkt verstehen

Implementierung:

import { NativePurchases } from '@capgo/native-purchases';
function ManageSubscriptionButton() {
const openManagement = async () => {
try {
// Opens Google Play subscription management
await NativePurchases.manageSubscriptions();
} catch (error) {
// Fallback to direct URL
const playStoreUrl = 'https://play.google.com/store/account/subscriptions';
window.open(playStoreUrl, '_blank');
}
};
return (
<button onClick={openManagement}>
Manage Subscription in Google Play
</button>
);
}

Erforderliche Informationen:

  • Wann tritt die Kündigung in Kraft?
  • Behalten Nutzer den Zugriff bis zum Ende?
  • Sind Teilrückerstattungen möglich?
function CancellationInfo() {
return (
<div className="cancellation-info">
<h3>Cancellation Policy</h3>
<ul>
<li>Cancel anytime in Google Play</li>
<li>Access continues until end of billing period</li>
<li>No refunds for partial periods</li>
<li>Resubscribe anytime to regain access</li>
</ul>
<button onClick={() => NativePurchases.manageSubscriptions()}>
Manage in Google Play
</button>
</div>
);
}

Checkliste vor dem Einreichen

  1. Billing-Implementierung prüfen

    • Google Play Billing nutzen (via native-purchases)
    • Alle Abo-Produkte in der Play Console erstellt
    • Basispläne und Angebote korrekt konfiguriert
    • Produkte sind aktiviert und veröffentlicht
    • Preise für alle Zielländer festgelegt
  2. Kaufabläufe testen

    • Lizenz-Testkonto erstellen
    • Build über einen Play-Testtrack installieren
    • Jede Abo-Stufe testen
    • Prüfen, ob Produkte korrekt laden
    • Kaufabschluss testen
    • Bestätige das test purchase Banner erscheint
    • Prüfen, ob Premium-Features freigeschaltet werden
    • Abo-Wiederherstellung testen
    • Auf mehreren Geräten testen
  3. Alle Texte prüfen

    • Preise vor dem Kauf klar anzeigen
    • Alle Gebühren vorab offenlegen
    • Abo-Bedingungen sind klar
    • Kündigungsprozess erklärt
    • Keine irreführenden Angaben
  4. App-Inhalte und Datenschutz

    • Datenschutzerklärung in Play Console verlinkt
    • Datenschutzerklärung in der App verfügbar
    • Anzeigen-Erklärung abgeschlossen
    • App-Zugriffsanweisungen hinzugefügt, falls die App einen Login erfordert
    • Abschnitt „Datensicherheit“ korrekt ausgefüllt
    • Berechtigungen begründet und dokumentiert
  5. Altersfreigabe und Zielgruppe

    • Fragebogen zur Altersfreigabe ausfüllen
    • Zielgruppe und Inhalte vervollständigen
    • Altersfreigabe muss zum Inhalt passen
    • In-App-Käufe im Fragebogen angeben
  6. Store-Eintrag vorbereiten

    • App-Beschreibung ist korrekt
    • Kurzbeschreibung unter 80 Zeichen
    • Vollständige Beschreibung unter 4000 Zeichen
    • Mindestens 2 Smartphone-Screenshots hochgeladen
    • 1024x500 Feature-Grafik hochgeladen
    • Screenshots zeigen die aktuelle Version
    • Alle erforderlichen Assets hochgeladen

Produktionszugriff für neue persönliche Accounts: Meist innerhalb von 7 Tagen nach Antragstellung Erster Produktions-Review: Oft mehrere Tage; bei Fragen zu Abrechnung oder Richtlinien auch länger Updates: Meist schneller als das erste Release, wird aber dennoch geprüft Appeals: Plane über mehrere Tage und liefere exakte Fixes sowie Anweisungen für den Reviewer

:::tip Rolling Reviews Im Gegensatz zu Apple prüft Google Apps kontinuierlich. Deine App kann jederzeit während des Review-Zeitraums live gehen, nicht zu einem festen Zeitpunkt. :::

  1. Testkonto hinzufügen:

    • Gehe zur Play Console
    • Einstellungen > Lizenztest
    • Gmail-Konto zum Testen hinzufügen
  2. In der Sandbox testen:

import { NativePurchases, PURCHASE_TYPE } from '@capgo/native-purchases';
// Test purchases with license test account
async function testInSandbox() {
const { isBillingSupported } = await NativePurchases.isBillingSupported();
if (!isBillingSupported) {
console.error('Billing not supported in this environment');
return;
}
// Fetch products (returns test pricing when using a license tester)
const { products } = await NativePurchases.getProducts({
productIdentifiers: ['premium_monthly'],
productType: PURCHASE_TYPE.SUBS,
});
console.log('Test products:', products);
// Make test purchase (no charge)
const transaction = await NativePurchases.purchaseProduct({
productIdentifier: 'premium_monthly',
planIdentifier: 'monthly-plan',
productType: PURCHASE_TYPE.SUBS,
});
console.log('Test purchase complete:', transaction.transactionId);
}
  1. Test-Banner prüfen:
    • Beim Kauf mit dem Testkonto
    • Sollte eine „Testkauf“-Benachrichtigung anzeigen
    • Es entstehen keine echten Kosten

Interne und geschlossene Test-Tracks

Abschnitt „Interne und geschlossene Testtracks“

Vor dem Production-Release:

  1. Erstelle ein Internes Testing Track für schnelles QA oder ein geschlossenen Test hochladen Track für breiteres Testing
  2. Lade ein signiertes Bundle hoch .aab und veröffentliche das Testing-Release
  3. Tester-E-Mail-Adressen hinzufügen und den Opt-in-Link teilen
  4. Tester müssen den Build über Google Play installieren
  5. Prüfen Sie, ob die Purchase-Flows im Play-installierten Build End-to-End funktionieren
  6. Falls Ihr persönlicher Developer-Account nach dem 13. November 2023 erstellt wurde: Halten Sie mindestens 12 Tester für 14 aufeinanderfolgende Tage in einem geschlossenen Test bereit, bevor Sie die Produktion beantragen

Ein per Sideload installierter Debug-Build ist kein Ersatz für einen über Google Play installierten Test-Build, wenn Sie Google Play Billing validieren.

Best Practices für Native Purchases

Abschnitt: „Best Practices für Native Purchases“
import { NativePurchases, PURCHASE_TYPE } from '@capgo/native-purchases';
async function handlePurchase(productId: string, planIdentifier?: string) {
try {
setLoading(true);
const transaction = await NativePurchases.purchaseProduct({
productIdentifier: productId,
planIdentifier,
productType: planIdentifier ? PURCHASE_TYPE.SUBS : PURCHASE_TYPE.INAPP,
});
console.log('Purchase token:', transaction.purchaseToken ?? transaction.receipt);
// Success - check entitlements from the store
const { purchases } = await NativePurchases.getPurchases({
productType: planIdentifier ? PURCHASE_TYPE.SUBS : PURCHASE_TYPE.INAPP,
});
const isOwned = purchases.some(
(purchase) =>
purchase.productIdentifier === productId &&
(purchase.purchaseState === 'PURCHASED' || purchase.purchaseState === '1') &&
purchase.isAcknowledged,
);
if (isOwned) {
unlockPremiumFeatures();
showSuccess('Premium activated!');
}
} catch (error: any) {
// Handle specific error cases
switch (error.code) {
case 'USER_CANCELLED':
// User backed out - no error needed
console.log('Purchase cancelled');
break;
case 'ITEM_ALREADY_OWNED':
// They already own it - restore instead
showInfo('You already own this! Restoring...');
await NativePurchases.restorePurchases();
break;
case 'ITEM_UNAVAILABLE':
showError('This subscription is currently unavailable. Please try again later.');
break;
case 'NETWORK_ERROR':
showError('Network error. Please check your connection and try again.');
break;
default:
showError('Purchase failed. Please try again.');
console.error('Purchase error:', error);
}
} finally {
setLoading(false);
}
}
import { NativePurchases, PURCHASE_TYPE } from '@capgo/native-purchases';
function RestorePurchasesButton() {
const [loading, setLoading] = useState(false);
const handleRestore = async () => {
setLoading(true);
try {
await NativePurchases.restorePurchases();
const { purchases } = await NativePurchases.getPurchases({
productType: PURCHASE_TYPE.SUBS,
});
const hasSubscription = purchases.some(
(purchase) => purchase.productType === 'subs' && purchase.isAcknowledged,
);
if (hasSubscription) {
unlockPremiumFeatures();
showSuccess('Subscriptions restored!');
return;
}
// Check one-time unlocks if needed
const { purchases: iaps } = await NativePurchases.getPurchases({
productType: PURCHASE_TYPE.INAPP,
});
const hasInApp = iaps.some((purchase) => purchase.productIdentifier === 'premium_unlock');
if (hasInApp) {
unlockPremiumFeatures();
showSuccess('Previous purchases restored!');
return;
}
showInfo('No previous purchases found.');
} catch (error) {
showError('Failed to restore purchases. Please try again.');
} finally {
setLoading(false);
}
};
return (
<button onClick={handleRestore} disabled={loading}>
{loading ? 'Restoring...' : 'Restore Purchases'}
</button>
);
}
import { NativePurchases, PURCHASE_TYPE } from '@capgo/native-purchases';
async function checkSubscriptionStatus() {
try {
const { purchases } = await NativePurchases.getPurchases({
productType: PURCHASE_TYPE.SUBS,
});
const subscription = purchases.find(
(purchase) =>
purchase.productIdentifier === 'premium_monthly' &&
(purchase.purchaseState === 'PURCHASED' || purchase.purchaseState === '1') &&
purchase.isAcknowledged,
);
if (!subscription) {
showPaywall();
return;
}
console.log('Subscription active:', {
productId: subscription.productIdentifier,
expiresAt: subscription.expirationDate,
willRenew: subscription.willCancel === false,
purchaseToken: subscription.purchaseToken,
});
unlockPremiumFeatures();
} catch (error) {
console.error('Failed to check subscription:', error);
}
}

Zahlungsrichtlinien:

  • Keine Nutzung von Google Play Billing
  • Irreführende Abo-Bedingungen
  • Versteckte Kosten

Datenschutzrichtlinien:

  • Fehlende Datenschutzerklärung
  • Ungenaue Data-Safety-Erklärungen
  • Übermäßige Berechtigungen
  1. Verstoßmitteilung prüfen

    • Die zitierte Richtlinie lesen
    • Verstehen, was Google beanstandet hat
    • Bereitgestellte Beispiele prüfen
  2. Problem beheben

    • Die Ursache beheben, nicht nur die Symptome
    • Nach dem Fix gründlich testen
    • Alle Änderungen dokumentieren
  3. Einspruch einlegen (falls zutreffend)

    Klärungs- und Einspruchsprozess

    Subject: Policy Violation Appeal - [App Name]
    Dear Google Play Review Team,
    I have received notification that my app violates [Policy X.Y].
    I have made the following changes to comply:
    1. [Specific change made]
    2. [Specific change made]
    3. [Specific change made]
    The updated version [version number] addresses all concerns raised.
    Test account for verification:
    Email: test@example.com
    Password: TestPass123
    Thank you for your consideration.

    Beispiel für Dokumentation anfordern

  4. Erneut einreichen oder aktualisieren

    • Korrigierte Version hochladen
    • Zur Überprüfung erneut einreichen
    • Status in der Play Console überwachen

Der Play Store Review kann komplex sein, besonders wenn Billing-Compliance, App-Content-Deklarationen und die Einrichtung von Test-Tracks zusammenkommen. Wenn du persönliche Unterstützung brauchst:

Beratungstermin mit unserem Team buchen für Hilfe bei:

  • Vollständige Vorbereitung auf den Play Store Review
  • Setup der Test-Tracks und Tester-Recruiting
  • Review der IAP-Implementierung
  • Datensicherheit und Datenschutz-Compliance
  • Fehlerbehebung bei Ablehnungen und Einsprüchen
  • Kompletter App-Submission-Prozess

Unsere Experten haben bereits hunderte Apps erfolgreich durch Play-Store-Einreichungen begleitet und helfen Ihnen, die aktuellen Anforderungen zu meistern.

Brauchen Sie Hilfe bei der Implementierung?

Weiterführende Infos zu den Android Play Store Review Guidelines für IAP

Abschnitt mit dem Titel „Weiterführende Infos zu den Android Play Store Review Guidelines für IAP“

Wenn du es nutzt Android Play Store Review Guidelines für IAP um Sicherheit und Compliance zu planen, verbinden Sie es mit @capgo/native-purchases verwenden für die native Funktionalität bei der Nutzung von @capgo/native-purchases, Verschlüsselung für die Implementierungsdetails in Encryption, Compliance für das Implementierungsdetail in Compliance, Capgo Security-Scanner für den Produkt-Workflow im Capgo Security Scanner, und Capgo Sicherheit für den Produkt-Workflow in Capgo Security.