Entwicklernutzlast

Die Entwicklernutzlast wurde in der Vergangenheit für verschiedene Zwecke verwendet, darunter die Betrugsprävention und die Zuordnung von Käufen zum richtigen Nutzer. Ab Version 2.2 der Google Play Billing Library werden Anwendungsfälle, für die zuvor die Entwicklernutzlast erforderlich war, jetzt vollständig in anderen Teilen der Bibliothek unterstützt.

Mit dieser Unterstützung haben wir die Entwicklernutzlast ab Version 2.2 der Google Play Billing Library eingestellt. Methoden, die mit der Entwicklernutzlast verknüpft sind, wurden in Version 2.2 verworfen und in Version 3.0 entfernt. Deine App kann weiterhin die Entwicklernutzlast für Käufe abrufen, die mit früheren Versionen der Bibliothek oder AIDL getätigt wurden.

Eine detaillierte Liste der Änderungen findest du in den Versionshinweisen zur Google Play Billing Library 2.2 und den Versionshinweisen zur Google Play Billing Library 3.0.

Bestätigung von Käufen

Damit Käufe authentisch sind und nicht gefälscht oder wiederholt werden, empfiehlt Google, das Kauf-Token (das du über die Methode getPurchaseToken() im Objekt Purchase erhältst) zusammen mit den Google Play Developer APIs zu verwenden, um die Authentizität von Käufen zu überprüfen. Weitere Informationen finden Sie unter Betrug und Missbrauch bekämpfen.

Kaufattribution

Bei vielen Apps, insbesondere Spielen, muss sichergestellt werden, dass ein Kauf dem In-Game-Charakter oder -Avatar oder dem In-App-Nutzerprofil, der bzw. das den Kauf initiiert hat, korrekt zugeordnet wird. Ab der Google Play Billing Library 2.2 kann Ihre App beim Starten des Kaufdialogs verschleierte Konto- und Profil-IDs an Google übergeben und diese beim Abrufen eines Kaufs zurückgeben lassen.

Verwenden Sie die Parameter setObfuscatedAccountId() und setObfuscatedProfileId() in BillingFlowParams und rufen Sie sie mit der Methode getAccountIdentifiers() im Objekt Purchase ab.

Metadaten mit einem Kauf verknüpfen

Google empfiehlt, Metadaten zu einem Kauf auf einem sicheren Backend-Server zu speichern, den Sie selbst verwalten. Diese Kaufmetadaten sollten mit dem Kauf-Token verknüpft sein, das mit getPurchaseToken im Objekt Purchase abgerufen wurde. Diese Daten können beibehalten werden, indem das Kaufftoken und die Metadaten an dein Backend übergeben werden, wenn dein PurchasesUpdatedListener nach einem erfolgreichen Kauf aufgerufen wird.

Damit die Metadaten auch dann verknüpft werden, wenn der Kaufvorgang unterbrochen wird, speichere sie vor dem Starten des Kaufdialogs auf deinem Backend-Server mit der Konto-ID, der SKU und dem Zeitstempel des Nutzers.

Wenn der Kaufvorgang unterbrochen wird, bevor PurchasesUpdatedListener aufgerufen wird, erkennt deine App den Kauf, sobald sie fortgesetzt wird und BillingClient.queryPurchasesAsync() aufruft. Anschließend kannst du die Werte, die du über die Methoden getPurchaseTime(), getSku() und getPurchaseToken() des Purchase-Objekts abgerufen hast, an deinen Backend-Server senden, um Metadaten abzurufen, die Metadaten mit dem Kauf-Token zu verknüpfen und den Kauf weiter zu verarbeiten. Beachten Sie, dass der ursprünglich gespeicherte Zeitstempel nicht genau mit dem Wert von getPurchaseTime() des Purchase-Objekts übereinstimmt. Sie müssen sie daher ungefähr vergleichen. Sie können beispielsweise prüfen, ob die Werte innerhalb eines bestimmten Zeitraums voneinander abweichen.