In-App Subscriptions

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • In-App Subscriptions

    Hi zusammen,

    der Eine oder Andere von euch hatte bestimmt schon einmal mit In-App Subscriptions zu tun oder? Ich versuche dieses Thema gerade zu verstehen, komme aber an einem Punkt nicht so wirklich weiter. Vielleicht kann mir ein Profi von euch einen Tipp geben.

    Es geht um Folgendes

    In meiner App habe ich einen In-App Kauf bzw. eine Subscription (1 Monat) die der User abschließen kann. Hat er die Subscription abgeschlossen, dann kann er sich in der App registrieren und bekommt damit einen Zugang zu einer Webseite.

    In der App kann ich prüfen, ob die Subscription noch aktiv ist, um so den Datenaustausch von der App zur Webseite gegebenenfalls abzuschalten. Der User kann dann aber immer noch die Webseite nutzen, was ohne Subscription nicht möglich sein soll. Ich suche jetzt nach einem Weg, wie ich innerhalb der Webseite prüfen kann, ob die Subscription noch aktiv ist. Wenn nicht, dann muss der User dort ausgeloggt werden.

    Also habe ich mich auf die Suche gemacht und bisher folgenden Ansatz gefunden:

    1. Bei der Registrierung innerhalb der App wird das Receipt mit an die Webseiten-Datenbank übermittelt und gespeichert.
    2. Per PHP / curl kann ich die Sandbox per "https://sandbox.itunes.apple.com/verifyReceipt" anzapfen und das Receipt auf Gültigkeit überprüfen.

    Was ich jetzt nicht begreife ist, welcher Teil der zurückgegebenen Daten von "https://sandbox.itunes.apple.com/verifyReceipt" sagt mir, dass die Subscription noch aktiv ist? Da steht so unglaublich viel drin. So wie es aussieht sind das auch alle bisher irgendwann mal abgeschlossenen Subscriptions?

    Und die zweite Frage, die ich mir selber noch nicht beantworten konnte ist, ist dieses eine (erste) Receipt, welches ich beim ersten Abschluss der Subscription in der Datenbank speichere, für immer gültig? Was passiert, wenn der 1 Monat rum ist und die Subscription sich automatisch erneuert hat. Kann ich dann immer noch per PHP curl und diesem Receipt prüfen, ob die Subscription noch aktiv ist?

    Das ist anscheint wirklich ein extrem komplexes Thema, vielleicht steh ich auch einfach nur auf dem Schlauch und es ist eigentlich ganz einfach? Ich hoffe auf euren Rat!

    Vielen Dank und LG
    Neu in der IOS-App-Entwicklungswelt - Spannend, ab und an nervenaufreibend, aber am Ende einfach faszinierend. Seid bitte nicht zu streng wenn ich Fragen einmal doppelt stelle, ich lerne noch :saint:
  • Danke für den Link in den unterirdischen Apple Dokus war ich ganz am Anfang. Dann gings weiter über Youtube und hin zu Stackoverflow. Geholfen hat leider nix. Die Fragen bleiben offen :(
    Neu in der IOS-App-Entwicklungswelt - Spannend, ab und an nervenaufreibend, aber am Ende einfach faszinierend. Seid bitte nicht zu streng wenn ich Fragen einmal doppelt stelle, ich lerne noch :saint:
  • nussratte schrieb:

    Ich verstehe dein Problem nicht richtig
    Wie man das validiert steht doch da

    developer.apple.com/library/ar…oc/uid/TP40010573-CH1-SW2

    Dann versteh ich die Dokumentation nicht richtig. Aber damit habe ich mich schon seit Beginn der App-Entwicklung schwer getan. Zu viel Drumherumgeblubber und kein auf den Punkt kommen (zumindest für mich ist das leider so).

    Mein Problem ist, dass ich bei all den zurückgegebenen Infos beim Validieren per Server, nicht herausfinde, welche Info entscheidend ist, damit ich die Tür auf lasse oder schließe. Welcher Parameter sagt mir „Jo der ist noch im Abo“ oder „Nö der hat gekündigt“ :)

    Und der zweite Punkt bzw. die zweite Frage ist, muss ich ein Receipt irgendwie / irgendwann erneuern, also den gesamten String, den ich für die Validierung verwende oder reicht der, der beim 1. Kauf von Apple kommt?

    Sorry ich werde einfach aus dieser Doku nicht schlau und falls du Subscriptions in deinen Apps verwendest, dann wäre es total nett wenn du mir diese zwei Fragen aus deiner Erfahrung heraus beantwortest bzw. mir sagen kannst wie du es machst :thumbsup:
    Neu in der IOS-App-Entwicklungswelt - Spannend, ab und an nervenaufreibend, aber am Ende einfach faszinierend. Seid bitte nicht zu streng wenn ich Fragen einmal doppelt stelle, ich lerne noch :saint:
  • Ich entwickle zwar eine App mit auto-renewable Subscriptions für einen Kunden, allerdings findet die komplette Prüfung etc. serverseitig statt. Ich muss in der App also "nur" die empfangenen Receipts an den Server schicken. Die Info, ob gerade eine Subscription aktiv ist oder nicht erhalte ich dann an anderer Stelle vom Server. Ich bin froh, dass Apple die serverseitige Verwaltung von auto-renewable Subscriptions empfiehlt und ich dies somit nicht in der App erledigen muss. ;)

    Ich habe aber mal eine Blick in die Doku geworfen und dort eine Beschreibung der Receipt Fields gefunden. Dort gibt es auch ein Feld Subscription Expiration Date mit dem Du die Gültigkeit einer aktiven Subscription für das aktuell Datum ermitteln kannst.
  • MCDan schrieb:

    Ich entwickle zwar eine App mit auto-renewable Subscriptions für einen Kunden, allerdings findet die komplette Prüfung etc. serverseitig statt. Ich muss in der App also "nur" die empfangenen Receipts an den Server schicken. Die Info, ob gerade eine Subscription aktiv ist oder nicht erhalte ich dann an anderer Stelle vom Server. Ich bin froh, dass Apple die serverseitige Verwaltung von auto-renewable Subscriptions empfiehlt und ich dies somit nicht in der App erledigen muss. ;)

    Ich habe aber mal eine Blick in die Doku geworfen und dort eine Beschreibung der Receipt Fields gefunden. Dort gibt es auch ein Feld Subscription Expiration Date mit dem Du die Gültigkeit einer aktiven Subscription für das aktuell Datum ermitteln kannst.
    Hey MCDan,

    super! Genau das ist mein Thema! Ich versuche ja gerade die serverseitige Verwaltung hinzubekommen.

    Die Receipt Fields hatte ich mir schon alle angesehen (@'nussratte') , allerdings habe ich kein Subscription Expiration Date in meinem JSON-Rückgabewert :(

    Dann liegt hier wahrscheinlich schon mein Fehler? Eventuell?

    Wie machst du die Validierung auf dem Server?

    Ich rufe per Curl sandbox.itunes.apple.com/verifyReceipt auf und sende das Receipt und SharedSecret mit. Dann bekomme ich eine ellenlange JSON Rückgabe mit diesen Parametern:

    Quellcode

    1. status
    2. environment
    3. receipt => Array
    4. receipt_type =>
    5. adam_id =>
    6. app_item_id =>
    7. bundle_id =>
    8. application_version =>
    9. download_id =>
    10. version_external_identifier =>
    11. receipt_creation_date =>
    12. receipt_creation_date_ms =>
    13. receipt_creation_date_pst =>
    14. request_date =>
    15. request_date_ms =>
    16. request_date_pst =>
    17. original_purchase_date =>
    18. original_purchase_date_ms =>
    19. original_purchase_date_pst =>
    20. original_application_version =>
    21. in_app => Array
    22. 0 => Array
    23. quantity =>
    24. product_id =>
    25. transaction_id =>
    26. original_transaction_id =>
    27. purchase_date =>
    28. purchase_date_ms =>
    29. purchase_date_pst =>
    30. original_purchase_date =>
    31. original_purchase_date_ms =>
    32. original_purchase_date_pst =>
    33. expires_date =>
    34. expires_date_ms =>
    35. expires_date_pst =>
    36. web_order_line_item_id =>
    37. is_trial_period =>
    38. is_in_intro_offer_period =>
    39. ... (weitere 43 InApp Käufe)
    40. latest_receipt_info => Array
    41. 0 => Array
    42. quantity =>
    43. product_id =>
    44. transaction_id =>
    45. original_transaction_id =>
    46. purchase_date =>
    47. purchase_date_ms =>
    48. purchase_date_pst =>
    49. original_purchase_date =>
    50. original_purchase_date_ms =>
    51. original_purchase_date_pst =>
    52. expires_date =>
    53. expires_date_ms =>
    54. expires_date_pst =>
    55. web_order_line_item_id =>
    56. is_trial_period =>
    57. is_in_intro_offer_period =>
    58. ... (weitere 43 InApp Käufe)
    59. latest_receipt =>
    60. pending_renewal_info => Array
    61. 0 => Array
    62. auto_renew_product_id =>
    63. original_transaction_id =>
    64. is_in_billing_retry_period =>
    65. product_id =>
    66. auto_renew_status =>
    67. 1 => Array
    68. expiration_intent =>
    69. auto_renew_product_id =>
    70. original_transaction_id =>
    71. is_in_billing_retry_period =>
    72. product_id =>
    73. auto_renew_status =>
    Alles anzeigen
    Welcher dieser ganzen Parameter sagt mir jetzt das die Subscription noch aktiv ist oder gekündigt wurde? Kannst du mir das verraten bzw. hier helfen?

    Danke dir!
    Neu in der IOS-App-Entwicklungswelt - Spannend, ab und an nervenaufreibend, aber am Ende einfach faszinierend. Seid bitte nicht zu streng wenn ich Fragen einmal doppelt stelle, ich lerne noch :saint:
  • MCDan schrieb:

    Ich entwickle glücklicherweise ja nur die App und nicht den Server. ;)

    Laut Doku heißt das Feld "expires_date" und dieses gibt es in dem JSON Rückgabe ja auch. Damit soll es laut Doku dann möglich sein zu prüfen, ob die Subscription noch aktiv/gültig ist.
    Mist :D

    Danke für den Hinweis! Ich bekomme das einfach nicht gelöst. Ich glaube ich mach das jetzt ganz anders und prüfe einfach in der App den Status und schließe dann den Zugang per Rest-Api-Aufruf. Anders weiß ich mir da nicht zu helfen. Blöd natürlich, wenn der User schlau ist und dann nur die Webseite nutzt und die App zu lässt ||
    Neu in der IOS-App-Entwicklungswelt - Spannend, ab und an nervenaufreibend, aber am Ende einfach faszinierend. Seid bitte nicht zu streng wenn ich Fragen einmal doppelt stelle, ich lerne noch :saint: