Abos über Stripe und In-App-Käufe kombinieren

Wer in der App nichts verkauft, braucht keinen In-App-Kauf

Schaltet eine iOS-App Funktionen gegen Bezahlung frei, muss sie Apples In-App-Kauf nutzen (Richtlinie 3.1.1). Eine kostenlose Begleit-App zu einem bezahlten Web-Dienst kommt dagegen ohne ihn aus, solange sie weder selbst verkauft noch auf einen Kauf außerhalb hinweist (Richtlinie 3.1.3(f)).

Diesen einfacheren Weg gehen BKF Manager und Tactio. Er passt, wenn Kunden ohnehin im Browser buchen, was bei Software für Unternehmen oft der Fall ist. Wer Privatkunden direkt in der App gewinnen will, braucht in der Regel den In-App-Kauf.

LeasePilot hat beides: Die Tarife Plus und Pro gibt es im Web über Stripe und in der iPhone-App über den App Store. Abos aus dem Web darf die App freischalten, weil es sie auch als In-App-Kauf gibt (Richtlinie 3.1.3(b)). Zwei Kassen also, aber ein Konto.

Ein Konto, zwei Bezahlwege

Im Backend hat jedes Abo einen Kanal (App Store oder Stripe), einen Tarif (Plus oder Pro), einen Status und ein Ablaufdatum. Nach jedem Kauf, jeder Verlängerung und jedem Ablauf berechnet das Backend den Tarif des Kontos neu: Es zählt das höchste gültige Abo, egal aus welchem Kanal.

Gültig bleibt ein Abo auch, solange Stripe eine fehlgeschlagene Zahlung (invoice.payment_failed) erneut versucht. Limits wie die Zahl der Fahrzeuge prüft die API gegen die Datenbank, nicht gegen das Login-Token. Ein neuer Tarif gilt deshalb sofort, ohne neue Anmeldung.

Die App kauft, das Backend entscheidet

Mit StoreKit 2 ist jede Transaktion von Apple signiert. Die App schickt sie ans Backend, das die Signatur prüft und den Kauf dem Konto zuordnet. Abgeschlossen wird erst danach:

func buy(_ product: Product) async throws {
    guard case .success(let result) = try await product.purchase(),
          case .verified(let transaction) = result else { return }
    try await backend.confirm(signedTransaction: result.jwsRepresentation)
    await transaction.finish()  // erst nach der Bestätigung durch das Backend
}

Bis dahin liefert StoreKit die offene Transaktion beim nächsten Start erneut, laut Apple nur einmal, gleich nach dem Start. Der Listener auf Transaction.updates gehört deshalb an den App-Start.

Von Verlängerungen und Kündigungen erfährt das Backend direkt, über App Store Server Notifications (Version 2) und Stripe-Webhooks. Einen Status setzt es erst, wenn die Signatur stimmt. Apples Benachrichtigungen findet es über die originalTransactionId, deshalb meldet die angemeldete App den Erstkauf, und ein Kauf gehört genau einem Konto. Im Web übernimmt die Konto-ID in den Metadaten von Stripe Checkout diese Rolle.

Auf die Bezahlseite gehören Links, keine Web-Preise

Bei Abos prüft Apple vor allem, ob Kunden vor dem Abschluss wissen, was sie bekommen. Eine LeasePilot-Version fiel genau da durch: Auf der Bezahlseite fehlte der Link zu den Nutzungsbedingungen (Richtlinie 3.1.2(c)). Seitdem verlinkt sie AGB und Datenschutz.

Die Preise dürfen abweichen, und von Käufen im Store behält Apple eine Provision ein. LeasePilot schreibt deshalb auf die Preisseite: „Preise im Apple App Store können abweichen.“ In der App stehen nur die Preise aus StoreKit.

Auf günstigere Web-Preise hinweisen darf eine App nur im US-Store und in der EU unter Apples gesonderten Bedingungen, auch dort mit Provision. Unsere Apps verzichten darauf.

Was wir mitnehmen

Freigeschaltet wird im Backend. Die App kauft und meldet, das Backend rechnet. Google Play Billing wäre dort ein weiterer Kanal nach demselben Muster.

Den einfacheren Weg zuerst prüfen. Verkauft die App selbst nichts, entfällt der In-App-Kauf samt zweiter Kasse. Was Apple bei unseren Einreichungen sonst beanstandet hat, steht in Eine App in App Store und Google Play bringen.