2013-07-11 6 views
5

Ich entwickle eine App mit automatisch erneuernden Quittungen, und speichern sie auf dem Server, die alle gut funktioniert, bis der Benutzer ihre Einkäufe wiederherstellt - das verursacht Duplikate.Speichern/Wiederherstellen automatisch erneuernden Quittungen ohne Duplikate

Das Feld transaction_id ist für den gleichen Empfang mit jeder Wiederherstellung unterschiedlich, und die original_transaction_id ist natürlich die gleiche über jeden Lauf der Erneuerungen, so dass ich das nicht verwenden kann. Das Feld unique_identifier ist auch das gleiche (ich verstehe nicht, wie es einzigartig ist). Ich hatte das web_order_line_item_id Feld verwendet und es schien gut, aber ich habe es gerade mit einem komplett neuen Konto getestet, und endete mit einem Duplikat, so dass es auch nutzlos ist.

Ich vermisse etwas wirklich offensichtlich hier? Es muss ein Feld geben, das für jeden Beleg eindeutig ist, aber nicht jedes Mal geändert wird, wenn es wiederhergestellt wird?

+0

Da Sie die Quittung auf Ihrem Server speichern, warum holen Sie die Quittung nicht einfach vom Server ab? – rocky

+0

Ich mache für die meisten Anwendungsszenarien, aber ich muss Benutzern erlauben, Käufe auf einem neuen oder wiederhergestellten Gerät wiederherzustellen. –

+0

Ich gehe davon aus, dass Sie eine Art Login für Ihr Abonnement haben, das automatisch verlängert wird. Und ich gehe auch davon aus, dass Sie die Anmeldung mit der Quittung verbinden, die Sie auf Ihrem Server speichern. In diesem Zusammenhang spielt es keine Rolle, ob ein Gerät neu oder wiederhergestellt ist. Wenn sich der Benutzer anmeldet, können Sie den Server nach dem Beleg abfragen und ihn zurücksenden. Sind meine Annahmen falsch? – rocky

Antwort

3

Anscheinend original_transaction_id und purchase_date sind die einzigen zwei eindeutigen Werte, die nach dem Wiederherstellen der Käufe nicht geändert werden. Sie können sich auch auf latest_receipt_info -> web_order_line_item_id verlassen, da es zwischen den Wiederherstellungen nicht wechselt (im Gegensatz zu latest_receipt_info -> transaction_id). Durch die Überprüfung latest_receipt_info können Sie herausfinden, expiration_date des Abonnements, die offenbar Apple glaubt, sollte genug für Sie sein.