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_
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 veralteten Parameters
max_
occurences
Abrechnungsmodus konfigurieren
Neues Abonnement mit flexiblem Abrechnungsmodus erstellen
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
.
Billing mode and subscription schedules
Wenn Sie einen Abonnementplan aus einem bestehenden Abo erstellen, setzen Sie billing_
nicht, wenn das Abo bereits über einen solchen verfügt. Der Plan übernimmt automatisch den billing_
vom ursprünglichen Abo.
Wenn Sie beim Verwenden von from_
einen billing_mode festlegen, gibt Stripe einen Fehler zurück. Falls Sie einen anderen billing_
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.
The following sections describe how various subscription behaviors differ between the classic and flexible billing modes.
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_ 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.
Gesamtbetrag der Rechnung = . | Stripe stellt die gesamte Nutzung im aktuellen Zeitraum zu dem Preis in Rechnung, der zum Zeitpunkt der Meldung gültig ist.
Gesamtbetrag der Rechnung = . |
Abrechnung für nicht abgerechnete Nutzung beim Entfernen nutzungsbasierter Posten
Je nach dem Wert von proration_
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_
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_ der anstehenden Phase:
|
Abrechnungszyklusanker zurücksetzen
Beim flexiblen Abrechnungsmodus wird Ihr Abrechnungszyklusanker nur bei Abonnementaktualisierungen zurückgesetzt, wenn Sie billing_
explizit auf einen anderen Wert als unchanged
setzen.
Classic | Höchst flexibel |
---|---|
Der billing_ 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_ 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_
können Sie die anteilmäßige Verrechnung für einen abgeschnittenen ersten Rechnungsstellungszeitraum deaktivieren (bei der Einstellung cancel_
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_
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:
| Rückdatierte Zeiträume werden in mehrere Rechnungsposten entsprechend den Grenzen des Rechnungsstellungszeitraums aufgeteilt. Gesamte Abbuchungen:
|
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. -Datum bezieht sich immer auf den ersten Testzeitraum eines Abonnements. | Das subscription. -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_
-Datum beibehalten, wenn Sie das cancel_
-Datum ändern.
Classic | Höchst flexibel |
---|---|
Wenn das Datum von trial_ nach dem Datum von cancel_ liegt, wird trial_ auf das Datum der Kündigung gesetzt. Wenn cancel_ später aktualisiert oder entfernt wird, wird trial_ nicht auf seinen ursprünglichen Wert gesetzt. | Wenn Sie eine Abonnementkündigung mit cancel_ planen, bleibt das trial_ -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_
(nutzungsbasiert) haben, wird die Beschreibung des Abonnements wie folgt angezeigt:
Klassisch | Flexibel |
---|---|
Lizenzierte Posten verwenden die Vorlage
| Für alle Artikeltypen gilt das gleiche Format
|
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_
einen weiteren Testposten price_
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_
.
Klassisch | Flexibel |
---|---|
Rechnungen zum Zurücksetzen des Abrechnungszyklusankers enthalten ausstehende Posten, Rechnungen mit Status always_ hingegen nicht. | Ausstehende Rechnungsposten sind immer in allen Rechnungen enthalten, die ein Abonnement generiert. |
Mixed intervals on the same subscription
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. |