Mehr Flexibilität für Abonnements ermöglichen

Verwenden Sie den flexiblen Abrechnungsmodus, um erweiterte Funktionen zu erhalten und auf zusätzliche Funktionen zuzugreifen.

Der flexible Abrechnungsmodus bietet ein genaues und vorhersehbares Abrechnungsverhalten und zusätzliche Funktionen für die Verwaltung von Abonnements. Die Einstellung billing_mode=flexible für ein Abonnement ändert das Verhalten von Abonnement Objekten während ihres Lebenszyklus und als Reaktion auf Upgrades, Downgrades und Kündigungen.

Der flexible Abrechnungsmodus bietet andere Funktionen für die Verwaltung von Abonnements als der klassische Abrechnungsmodus. Siehe Unterschiede zwischen dem klassischen und flexiblen Abrechnungsmodus für weitere Einzelheiten.

Um den flexiblen Abrechnungsmodus zu nutzen, muss Ihre Integration auf der Stripe API Version 2025-06-30.basil oder höher sein. Erfahren Sie, wie Sie Ihre API-Version aktualisieren. Sie können nicht vom flexiblen Abrechnungsmodus auf den klassischen Abrechnungsmodus zurückwechseln.

Beschränkungen

Der flexible Abrechnungsmodus ist nicht mit allen Funktionen von Stripe Billing kompatibel. Die folgenden Funktionen sind nicht kompatibel und zeigen einen 400 status code an, wenn Sie ein Abonnement mit aktiviertem flexiblen Abrechnungsmodus erstellen und aktualisieren:

Kostenpflichtige Testversionen
Ältere nutzungsbasierte Abrechnung
Vorabrechnung Private Vorschau
Die Verwendung des alten max_occurrences Parameters

Abrechnungsmodus konfigurieren

Neues Abonnement mit flexiblem Abrechnungsmodus erstellen

Sie können Abonnements mit einem flexiblen Abrechnungsmodus im Dashboard erstellen und aktualisieren, unabhängig von der API-Version Ihrer Integration. Um diese Abonnements in der Stripe-API vollständig zu ändern, muss Ihre Integration auf 2025-06-30.basil oder höher aktualisiert sein. Um zu sehen, welche Version Sie verwenden, gehen Sie zur Workbench-Übersicht und sehen Sie im Abschnitt API-Versionen nach. Klicken Sie dort auf Upgrade, um auf eine neuere Version zu aktualisieren.

Gehen Sie im Dashboard zur Seite Abonnements.
Wählen Sie +Abonnement erstellen aus.
Scrollen Sie herunter zum Abschnitt Erweiterte Einstellungen.
Legen Sie Abrechnungsmodus auf Flexibel fest.

Bestehende Abonnements zum flexiblen Abrechnungsmodus migrieren

Sie können Ihre bestehenden Abonnements in den flexiblen Abrechnungsmodus migrieren. Die flexiblen Verhaltensweisen gelten für alle neuen Aktivitäten im Abonnement nach der Migration. Stripe berechnet jedoch keine Ressourcen neu, die vor der Migration erstellt wurden, einschließlich ausstehender anteilmäßig verrechneter Invoice Items.

Um den flexiblen Abrechnungsmodus zu verwenden, muss sich Ihre Integration auf der Stripe-API-Version 2025-06-30.basil oder höher befinden. Um festzustellen, welche Version Sie verwenden, navigieren Sie zur Workbench-Übersicht und sehen Sie sich den Abschnitt API-Versionen an. Klicken Sie von dort aus auf Upgrade, um ein Upgrade auf eine neuere Version durchzuführen.

Wählen Sie auf der Seite Abonnements im Dashboard das Abonnement aus, das Sie migrieren möchten.
Wählen Sie Aktionen und dann Abonnement aktualisieren aus.
Scrollen Sie herunter zum Abschnitt Erweiterte Einstellungen.
Legen Sie Abrechnungsmodus auf Flexibel fest und wählen Sie Abonnement aktualisieren aus.

Abrechnungsmodus und Abonnementpläne

Wenn Sie einen Abonnementplan aus einem bestehenden Abo erstellen, setzen Sie billing_mode nicht, wenn das Abo bereits über einen solchen verfügt. Der Plan übernimmt automatisch den billing_mode vom ursprünglichen Abo.

Wenn Sie beim Verwenden von from_subscription einen billing_mode festlegen, gibt Stripe einen Fehler zurück. Falls Sie einen anderen billing_mode benötigen, stellen Sie sicher, dass er mit dem bestehenden Abo übereinstimmt oder erstellen Sie ein neues Abo.

Unterschiede zwischen dem klassischen und flexiblen Abrechnungsmodus.

In den folgenden Abschnitten wird beschrieben, wie sich die verschiedenen Abos im klassischen und im flexiblen Abrechnungsmodus verhalten.

Anteilsmäßige Verrechnung von Gutschriften

Anteilmäßige Verrechnungen werden ausgestellt, wenn Kund/innen ihre Abonnements herabstufen oder Posten vor dem Ende des Rechnungsstellungszeitraums stornieren. Der flexible Abrechnungsmodus berechnet Kund/innen anteilmäßige Verrechnungen auf der Grundlage des ursprünglich abgebuchten Betrags.

Eine vollständige Übersicht über die Berechnungen der anteilmäßigen Verrechnung finden Sie unter Verrechnungen.

Klassisch	Flexibel
Wenn eine Aktualisierung eines Abonnements zu einer anteilmäßigen Verrechnung führt, werden die anteilmäßigen Verrechnungsbeträge auf der Grundlage des aktuellen Preises, der Steuern, der Menge und der zuletzt in Anspruch genommenen Rabatte für den Posten des Abonnements berechnet.	Wenn eine Aktualisierung eines Abonnements eine anteilmäßige Verrechnung des Guthabens erzeugt, verwenden diese Verrechnungen den ursprünglich abgebuchten Betrag anstelle der aktuellen Werte des Abonnements.

Anwendung von proportionalen Rabatten für anteilmäßige Verrechnungen

We apply discounts proportionally to each subscription item during proration calculations instead of distributing them evenly. This results in more prorations, especially when invoicing on a per-item basis or canceling items with unevenly distributed discounts.

Klassisch	Flexibel
Wir verteilen Rabatte gleichmäßig auf alle Abonnementartikel.	Bei der anteilmäßigen Verrechnung wenden wir Rabatte proportional auf jeden Abonnementartikel an.

Nutzungsbasierte Tarife

Verhindern Sie Posten mit Nullbeträgen, wenn Sie nutzungsbasierte Posten hinzufügen.

Im flexiblen Abrechnungsmodus werden keine Posten mit Nullbeträgen erstellt, wenn Sie einem Abonnement nutzungsbasierte Posten hinzufügen. Wenn die Rechnung infolgedessen leer ist, erstellen wir keine Rechnung.

Zum Beispiel beim Hinzufügen eines monatlichen, nutzungsbasierten Postens bei der Erstellung oder Aktualisierung eines Abonnements:

Klassisch	Flexibel
Auf der Rechnung wird ein Posten 0 USD für den nutzungsbasierten Posten erzeugt. Dies gilt auch, wenn Sie ein Abonnement aktualisieren, ohne einen nutzungsbasierten Posten hinzuzufügen, während Sie `proration_behavior=always_invoice` verwenden.	Ein Posten 0 USD wird der Rechnung für den nutzungsbasierten Posten nicht hinzugefügt. Wenn die resultierende Rechnung keine Posten enthalten würde, erzeugen wir keine Rechnung.

Abrechnung für nutzungsbasierter Posten auf Basis des Preises zum Zeitpunkt der Meldung

Beim flexiblen Abrechnungsmodus wird die Nutzung auf der Grundlage des Preises berechnet, der zum Zeitpunkt der Meldung der Nutzung galt, und nicht auf dem neuesten Preis.

Die Nutzung eines Kunden/einer Kundin wird beispielsweise wie folgt gemeldet:

Nutzung am 5. Januar: 1000 API-Aufrufe zu (Preis A)
Preisänderung am 15. Januar: Der Preis ändert sich auf (Preis B).
Nutzung am 20. Januar: 500 API-Aufrufe

Klassisch	Flexibel
Stripe stellt nur die Nutzung in Rechnung, die seit der Umstellung auf den aktuellen Preis gemeldet wurde. 500 API-Aufrufe zu Preis B ( pro 100 Aufrufe) = Gesamtbetrag der Rechnung = .	Stripe stellt die gesamte Nutzung im aktuellen Zeitraum zu dem Preis in Rechnung, der zum Zeitpunkt der Meldung gültig ist. 1000 API-Aufrufe zu Preis A ( pro 100 Aufrufe) = 500 API-Aufrufe zu Preis B ( pro 100 Aufrufe) = Gesamtbetrag der Rechnung = .

Klassisch

Flexibel

Stripe stellt nur die Nutzung in Rechnung, die seit der Umstellung auf den aktuellen Preis gemeldet wurde.

500 API-Aufrufe zu Preis B ( pro 100 Aufrufe) =

Gesamtbetrag der Rechnung = .

Stripe stellt die gesamte Nutzung im aktuellen Zeitraum zu dem Preis in Rechnung, der zum Zeitpunkt der Meldung gültig ist.

1000 API-Aufrufe zu Preis A ( pro 100 Aufrufe) =
500 API-Aufrufe zu Preis B ( pro 100 Aufrufe) =

Gesamtbetrag der Rechnung = .

Abrechnung für nicht abgerechnete Nutzung beim Entfernen nutzungsbasierter Posten

Je nach dem Wert von proration_behavior kann der flexible Abrechnungsmodus beim Entfernen eines nutzungsbasierten Abonnementposten einen Rechnungsposten für nicht abgerechnete Nutzung erzeugen. Dies gilt für Entfernungen über die API oder während Phasenübergängen des Plans, die mitten in der Laufzeit stattfinden. Bei Phasenübergängen, die mit einem Abonnementposten current_period_end zusammenfallen, wird eine Rechnung mit einem Rechnungsposten für den entfernten, nutzungsbasierten Abonnementposten erstellt.

Szenario	Klassisch	Flexibel
Aktualisieren Sie Abonnements oder Pläne über die API	Beim Entfernen eines nutzungsbasierten Abonnementpostens wird kein Rechnungsposten bzw. keine Rechnung für nicht abgerechnete Nutzung erstellt.	Beim Entfernen eines nutzungsbasierten Abonnements wird ein Rechnungsposten für die nicht abgerechnete Nutzung erstellt.
Phasenübergang des Plans	Beim Entfernen eines nutzungsbasierten Abonnementpostens wird eine Rechnung (aber kein Rechnungsposten) für nicht abgerechnete Nutzung erstellt.	Abhängig vom `proration_behavior` der anstehenden Phase: `create_prorations`: Beim Entfernen eines nutzungsbasierten Abonnementpostens wird ein Rechnungsposten für nicht abgerechnete Nutzung erstellt. `always_invoice`: ein Rechnungsposten für nicht abgerechnete Nutzung wird erstellt und sofort in Rechnung gestellt. `none`: es wird kein Rechnungsposten erstellt.

Abrechnungszyklusanker zurücksetzen

Beim flexiblen Abrechnungsmodus wird Ihr Abrechnungszyklusanker nur bei Abonnementaktualisierungen zurückgesetzt, wenn Sie billing_cycle_anchor explizit auf einen anderen Wert als unchanged setzen.

Classic	Höchst flexibel
Der `billing_cycle_anchor` wird automatisch auf das aktuelle Datum zurückgesetzt, wenn ein Abo auf einen anderen Preis mit einem anderen wiederkehrenden Intervall umgestellt wird, von Preisen mit null Betrag auf einen Preis ungleich null oder wenn cancel_at auf ein Datum vor der nächsten Erneuerung des Abos gesetzt wird.	Der `billing_cycle_anchor` wird nie automatisch zurückgesetzt.

Konsolidierte Rechnungen für die Phasenübergänge der Abonnementpläne mit nutzungsbasierten Posten

Der flexible Abrechnungsmodus erstellt bei jeder Verlängerung eines Abos konsequent eine einzige Rechnung. Diese Änderung beseitigt separate Rechnungen für beseitigte nutzungsbasierte Posten und verbessert die Konsistenz der Abrechnung.

Wenn Ihr Abonnement mit nutzungsbasierten Posten zwischen den Phasen übergeht:

Klassisch	Flexibel
Es werden zwei Rechnungen generiert.	Es wird eine einzige konsolidierte Rechnung erstellt. Diese Rechnung enthält sowohl nutzungsbasierte als auch lizenzierte Posten, wendet Rabatte aus der vorherigen Phase auf die nutzungsbasierte Abrechnung an und verwendet Steuersätze aus der nächsten Phase.

Geplante Kündigung des Abonnements

Mit dem Parameter proration_behavior können Sie die anteilmäßige Verrechnung für einen abgeschnittenen ersten Rechnungsstellungszeitraum deaktivieren (bei der Einstellung cancel_at bei der Erstellung).

Klassisch	Flexibel
Anteilmäßige Verrechnungen werden auf den ersten Rechnungsstellungszeitraum angewendet.	Anteilmäßige Verrechnungen werden nicht auf den ersten Rechnungsstellungszeitraum angewandt.

Abonnements zurückdatieren

Wenn die Rückdatierung mit der regulären Abrechnung übereinstimmt, erstellt der flexible Abrechnungsmodus separate Rechnungsposten für jeden Rechnungsstellungszeitraum innerhalb des rückdatierten Zeitraums. Außerdem wird der Anker des Abrechnungszyklus automatisch an das backdate_start_date angepasst, wenn er nicht explizit festgelegt wurde. Die Rückdatierung wird nicht unterstützt, wenn die resultierende Rechnung mehr als 250 Posten enthält.

Beispielsweise muss ein Abo aufgrund einer fehlenden Rechnung für die letzten beiden Rechnungsstellungszeiträume rückdatiert werden. Der Kundin/dem Kunden wurden 2 verschiedene rückdatierte Zeiträume in Rechnung gestellt:

Abrechnungszeitraum 1 (1. März bis 31. März):
- Gemeldete Nutzung: 100 GB Speicherplatz belegt.
- Preis: 10 USD pro 10 GB.

Abrechnungszeitraum 2 (1. April bis 30. April):

Gemeldete Nutzung: 150 GB Speicherplatz belegt.
Preis: 10 USD pro 10 GB.

Der Dienstleister entscheidet sich, die Rechnung so rückzudatieren, dass sie beide Abrechnungszeiträume abdeckt: 1. März bis 30. April.

Classic	Höchst flexibel
Zahlungen für den gesamten rückdatierten Zeitraum werden zusammengefasst als Einzelposten berechnet. Zahlungen insgesamt: 250 GB = 25 x 10 USD = 250 USD Dieser Betrag wird als einzelner Posten auf der Rechnung angezeigt.	Rückdatierte Zeiträume werden in mehrere Rechnungsposten entsprechend den Grenzen des Rechnungsstellungszeitraums aufgeteilt. Gesamte Abbuchungen: Abrechnungszeitraum 1 (März): 100 GB = 10 x 10 USD = 100 USD (als separater Posten). Abrechnungszeitraum 2 (April): 150 GB = 15 x 10 USD = 150 USD (als separater Posten).

Testzeiträume

Startdatum für nachfolgende Testversionen aktualisieren

Beim flexiblen Abrechnungsmodus wird das letzte Startdatum der Testversion für Abonnements mit nachfolgenden Testversionen verwendet.

Zum Beispiel, wenn Sie Folgendes haben:

Testzeitraum vom 1. Januar bis 1. Februar
Normaler Abrechnungszeitraum vom 1. Februar bis 1. März
Testzeitraum vom 1. März bis 1. April

Klassisch	Flexibel
Das `subscription.trial_start`-Datum bezieht sich immer auf den ersten Testzeitraum eines Abonnements.	Das `subscription.trial_start`-Datum bezieht sich auf den Beginn der letzten Testphase eines Abonnements.

Ursprüngliches Enddatum der Testversion beibehalten, wenn ein Abonnement gekündigt wird

Beim flexiblen Abrechnungsmodus wird das trial_end-Datum beibehalten, wenn Sie das cancel_at-Datum ändern.

Classic	Höchst flexibel
Wenn das Datum von `trial_end` nach dem Datum von `cancel_at` liegt, wird `trial_end` auf das Datum der Kündigung gesetzt. Wenn `cancel_at` später aktualisiert oder entfernt wird, wird `trial_end` nicht auf seinen ursprünglichen Wert gesetzt.	Wenn Sie eine Abonnementkündigung mit `cancel_at` planen, bleibt das `trial_end`-Datum davon unberührt. Dadurch wird sichergestellt, dass Testversionen unabhängig von der Aktualisierung des Kündigungsdatums für die vorgesehene Dauer ausgeführt werden.

Postenbeschreibung für den Testzeitraum standardisieren

Der flexible Abrechnungsmodus verwendet ein einheitliches Beschreibungsformat sowohl für nutzungsbasierte als auch für lizenzierte Posten während der Testzeiträume.

Wenn Sie zum Beispiel ein monatliches Kaffee-Abonnement (lizenziert) und ein Abonnement für alpaca_ai_tokens (nutzungsbasiert) haben, wird die Beschreibung des Abonnements wie folgt angezeigt:

Klassisch Flexibel

Klassisch	Flexibel
Lizenzierte Posten verwenden die Vorlage `Trial period for {product name}`, während nutzungsbasierte Posten `{quantity} x {product name} (Free trial)` verwenden. Für lizenzierte Artikel: `Trial period for monthly coffee subscription` Für nutzungsbasierte Posten: `10 x monthly alpaca_ai_tokens (Free trial)`	Für alle Artikeltypen gilt das gleiche Format `Free trial for {quantity} x {product name}`, wodurch die Informationen zum Testzeitraum einheitlicher dargestellt werden. Diese Beschreibungen sind ebenfalls lokal angepasst. Für lizenzierte Artikel: `Free trial for 1 x monthly coffee subscription` Für nutzungsbasierte Posten: `Free trial for 10 x monthly alpaca_ai_tokens subscription`

Lizenzierte Posten verwenden die Vorlage Trial period for {product name}, während nutzungsbasierte Posten {quantity} x {product name} (Free trial) verwenden.

Für lizenzierte Artikel:
- Trial period for monthly coffee subscription
Für nutzungsbasierte Posten:
- 10 x monthly alpaca_ai_tokens (Free trial)

Für alle Artikeltypen gilt das gleiche Format Free trial for {quantity} x {product name}, wodurch die Informationen zum Testzeitraum einheitlicher dargestellt werden. Diese Beschreibungen sind ebenfalls lokal angepasst.

Für lizenzierte Artikel:
- Free trial for 1 x monthly coffee subscription
Für nutzungsbasierte Posten:
- Free trial for 10 x monthly alpaca_ai_tokens subscription

Erneute Abrechnung für Testposten

Der flexible Abrechnungsmodus generiert nur Einzelposten für Änderungen, die während eines Testzeitraums vorgenommen werden. Bestehende Posten ohne Änderungen werden nicht erneut abgerechnet.

Wenn Sie beispielsweise eine Aktualisierung vornehmen, um einem Testabonnement mit price_a einen weiteren Testposten price_b hinzuzufügen:

Classic	Höchst flexibel
Änderungen während eines Testzeitraums führen entweder zu keiner Rechnung oder zu einer Rechnung, die den gesamten Status des Abonnements wiedergibt.	Änderungen während eines Testzeitraums führen immer wieder zu Posten, die mit Änderungen außerhalb eines Testzeitraums vergleichbar sind. Wenn beispielsweise ein neuer Preis zu einem Abonnement hinzugefügt wird, wird auch ein Posten hinzugefügt, der diese Hinzufügung darstellt.

Ausstehende Rechnungsposten

Ausstehende Rechnungsposten durchgängig einbeziehen

Der flexible Abrechnungsmodus umfasst alle verfügbaren ausstehenden Rechnungsposten in Rechnungen, die durch das Zurücksetzen des Abrechnungszyklusankers generiert wurden, wobei proration_behavior = always_invoice.

Klassisch	Flexibel
Rechnungen zum Zurücksetzen des Abrechnungszyklusankers enthalten ausstehende Posten, Rechnungen mit Status `always_invoice` hingegen nicht.	Ausstehende Rechnungsposten sind immer in allen Rechnungen enthalten, die ein Abonnement generiert.

Gemischte Intervalle im selben Abo

Der flexible Abrechnungsmodus ermöglicht Ihnen den Zugriff auf Abonnements mit gemischten Intervallen. Sie können mehrere wiederkehrende Preise mit unterschiedlichen Intervallen für ein einzelnes Abonnement in Rechnung stellen, indem Sie Abonnements mit gemischten Intervallen verwenden. So können Sie verschiedene Preisstrukturen innerhalb eines einzigen Abonnements kombinieren.

Klassisch	Flexibel
Nicht unterstützt. Alle Posten in einem Abonnement müssen Preise mit dem gleichen Intervall und der gleichen Intervallanzahl haben.	Erstellen Sie Abonnements mit gemischten Intervallen, wobei die Posten eines Abonnements wiederkehrende Preise mit unterschiedlichen Intervallen oder Intervallzahlen haben können. Beispielsweise können ein monatlicher Preis und ein jährlicher Preis im selben Abonnement vorhanden sein.