> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dodopayments.com/llms.txt
> Use this file to discover all available pages before exploring further.
# v1.101.0 (2. Juni 2026)
> Automatische Wiederholungen von Abonnementzahlungen zur Wiederherstellung fehlgeschlagener Erneuerungseinnahmen, Standard-Prorationswerte auf Geschäftsebene mit Überschreibungen pro Produktkollektion und Sammlung von Firmennamen für B2B-Rechnungen — plus Fehlerbehebungen und Verbesserungen.
## Neue Funktionen
### 1. **Wiederholungen von Abonnementzahlungen**
Fehlgeschlagene **Erneuerungs**zahlungen für Abonnements können nun automatisch wiederholt werden, um Einnahmen zu sichern, ohne dass eine Integration erforderlich ist. Aktivieren Sie es unter **Einstellungen → Wiederherstellung**, legen Sie ein Wiederherstellungsfenster fest, und Dodo Payments wiederholt die Erneuerung in einem intelligenten Zeitplan, bis sie erfolgreich ist oder das Fenster schließt.
| Einstellung | Beschreibung | Standard |
| ------------------------------------- | ------------------------------------------------------------------------------------------------------ | ------------ |
| **Zahlungswiederholungen aktivieren** | Fehlgeschlagene Erneuerungszahlungen für Abonnements automatisch wiederholen, um Einnahmen zu sichern. | Aus (Opt-in) |
| **Wiederherstellungsfenster (Tage)** | Wie lange ein fehlgeschlagener Zahlungsvorgang wiederholt werden soll, bevor abgebrochen wird (1–30). | 13 |
**Funktionsweise**
1. Eine Erneuerungszahlung für ein Abonnement schlägt fehl und das Abonnement wechselt zu `on_hold`.
2. Wenn der Rückgang wiederholbar ist (ein weicher Rückgang wie unzureichende Mittel oder ein vorübergehender Netzwerkfehler), wird der nächste Versuch automatisch geplant.
3. Wiederholungen erfolgen im Off-Session-Modus nach einem gestaffelten Zeitplan, begrenzt durch Ihr Wiederherstellungsfenster.
4. Beim ersten erfolgreichen Wiederholungsversuch kehrt das Abonnement zu `active` zurück und das nächste Rechnungsdatum wird wie üblich verschoben.
**Wiederholungszeitplan**
Wiederholungen werden gestaffelt, beginnend mit dem Zeitpunkt, zu dem die fehlgeschlagene Rechnung erstellt wurde. Bis zu **8 Versuche** werden unternommen, solange sie in Ihr Wiederherstellungsfenster passen:
| Versuch | Verzögerung nach vorherigem |
| ------- | --------------------------- |
| 1 | 12 Stunden |
| 2 | 24 Stunden |
| 3 | 48 Stunden |
| 4 | 72 Stunden |
| 5 | 96 Stunden |
| 6 | 120 Stunden |
| 7 | 7 Tage |
| 8 | 7 Tage |
Nur **weiche Rückgänge** werden wiederholt (z.B. unzureichende Mittel, generischer Rückgang, Verarbeitungs- oder Netzwerkfehler). **Harte Rückgänge** beenden die Wiederholungskette sofort, da Wiederholungen das Ergebnis nicht ändern.
Dies ergänzt die vorhandenen Wiederherstellungstools — **Abonnement-Mahnungen** senden dem Kunden eine E-Mail, um seine Zahlungsmethode zu aktualisieren, während Zahlungswiederholungen die vorhandene Methode stillschweigend erneut versuchen. Sie arbeiten gut zusammen.
Erfahren Sie mehr: [Wiederholungen von Abonnementzahlungen](/features/recovery/payment-retries) | [Abonnement-Mahnungen](/features/recovery/subscription-dunning)
### 2. **Geschäfts-Prorierungseinstellungen**
Sie können nun das **Standard-Verhalten für Upgrade & Downgrade** auf Geschäftsebene festlegen, anstatt Prorierungsparameter bei jeder Planänderung zu übergeben. Diese Standardwerte gelten, wann immer ein Kunde seinen Plan über das Kundenportal ändert, und Sie können **sie pro Produktkollektion überschreiben**.
Jede Richtung (Upgrade und Downgrade) hat zwei unabhängige Steuerungen, plus eine gemeinsame Zahlungsfehlerpolitik:
| Einstellung | Feld | Standard (Upgrade) | Standard (Downgrade) |
| ------------------------------------------- | --------------------------------------------------------------------------- | ------------------------ | ------------------------ |
| **Wann der neue Plan beginnt** | `effective_at_on_upgrade` / `effective_at_on_downgrade` | `immediately` | `next_billing_date` |
| **Wie der Kunde belastet wird** | `proration_billing_mode_on_upgrade` / `proration_billing_mode_on_downgrade` | `difference_immediately` | `difference_immediately` |
| **Wenn die Zahlung des Kunden fehlschlägt** | `on_payment_failure` | `apply_change` | `apply_change` |
**Wann der neue Plan beginnt** (`effective_at`)
| Wert | Verhalten |
| ------------------- | ------------------------------------------------------------------------------------------------------- |
| `immediately` | Der Kunde wechselt sofort zum neuen Plan. |
| `next_billing_date` | Der Kunde bleibt bis zum nächsten Rechnungsdatum auf seinem aktuellen Plan und wechselt dann zum neuen. |
**Wie der Kunde belastet wird** (`proration_billing_mode`)
| Wert | Verhalten |
| ------------------------ | ----------------------------------------------------------------------------------------------------------------- |
| `prorated_immediately` | Ein anteiliger Betrag wird jetzt basierend auf der verbleibenden Zeit im aktuellen Abrechnungszeitraum berechnet. |
| `full_immediately` | Der volle Preis des neuen Plans wird jetzt berechnet. |
| `difference_immediately` | Nur der Preisunterschied zwischen dem neuen und dem aktuellen Plan wird berechnet. |
| `do_not_bill` | Es wird jetzt nichts berechnet. Jede Anpassung wird auf die nächste Rechnung angewendet. |
**Wenn die Zahlung des Kunden fehlschlägt** (`on_payment_failure`)
| Wert | Verhalten |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| `prevent_change` | Den Kunden auf seinem aktuellen Plan belassen, wenn die Zahlung nicht erfolgt. |
| `apply_change` | Den Kunden trotzdem auf den neuen Plan umstellen, auch wenn die Zahlung nicht erfolgt. Sie können den Betrag später einziehen. |
**Überschreibungen pro Kollektion**
Jede Produktkollektion kann jede dieser Standardwerte überschreiben. Jedes Feld ist unabhängig — lassen Sie es auf **Vom Geschäft erben**, um dem Geschäftsstandard zu folgen, oder setzen Sie einen expliziten Wert, um es nur für diese Kollektion zu überschreiben.
Jede Einstellung wird in dieser Reihenfolge aufgelöst:
```
per-request value (Change Plan API) → collection field (if set) → business field → system default
```
Ein pro Anforderung übergebener Wert an die [Planänderungs-API](/api-reference/subscriptions/change-plan) (`proration_billing_mode`, `effective_at`, `on_payment_failure`) hat immer Vorrang vor den Kollektionen und Geschäftsstandards. Die neuen Einstellungen ändern lediglich, was passiert, wenn kein expliziter Wert angegeben wird — was bei Planänderungen im Kundenportal der Fall ist.
Erfahren Sie mehr: [Upgrade & Downgrade von Abonnements](/developer-resources/subscription-upgrade-downgrade) | [Produktkollektionen](/features/product-collections)
### 3. **Firmennamen für B2B-Rechnungen erfassen**
B2B-Kunden können nun ihren **rechtlichen Firmennamen** auf der Rechnung anstelle des persönlichen Namens des Käufers anzeigen lassen. Wenn beim Checkout eine gültige Steuernummer angegeben wird, können Sie auch die zugehörige `customer_business_name` erfassen, damit die Rechnung das kauffreudige Unternehmen widerspiegelt.
Wenn der Kunde beim Checkout **Einkauf als Unternehmen** auswählt, wird er sowohl nach einem **Firmennamen** als auch nach einer **Steuernummer** gefragt.
Der Firmenname erscheint auf der Rechnung nur, wenn **alle drei** Bedingungen erfüllt sind:
1. Die Transaktion ist B2B (`b2b = true`)
2. Eine `tax_id` liegt vor
3. Eine nicht-leere `customer_business_name` wird angegeben
Andernfalls wird der persönliche Name des Kunden verwendet.
**Erfassung beim Checkout**
Setzen Sie `customer_business_name` direkt und/oder aktivieren Sie `allow_customer_editing_business_name`, damit der Kunde es auf der Checkout-Seite zusammen mit seiner Steuernummer eingeben oder bearbeiten kann:
```typescript theme={null}
const session = await client.checkoutSessions.create({
product_cart: [{ product_id: 'prod_abc', quantity: 1 }],
customer: { email: 'buyer@acme.com' },
tax_id: 'GB123456789',
customer_business_name: 'Acme Corp Ltd',
feature_flags: {
allow_tax_id: true,
allow_customer_editing_business_name: true // let the customer enter/edit it
},
return_url: 'https://yoursite.com/return'
});
```
**Wo es zur Anwendung kommt**
| Oberfläche | Feld | Hinweise |
| ----------------- | ------------------------------------------------------------------------------ | ---------------------------------------------------- |
| Checkout-Sessions | `customer_business_name`, `feature_flags.allow_customer_editing_business_name` | Max. 250 Zeichen; Flag standardmäßig auf `false` |
| Zahlungen | `customer_business_name` | Max. 250 Zeichen |
| Abonnements | `customer_business_name` | Setzen oder löschen über `PATCH /subscriptions/{id}` |
`customer_business_name` kann nicht ohne eine `tax_id` gesetzt werden. Das Senden eines Firmennamens ohne Steuernummer wird abgelehnt. Das Löschen der `tax_id` löscht auch den Firmennamen, da die beiden auf der Rechnung gekoppelt sind.
Umgebende Leerzeichen werden entfernt und ausschließlich aus Leerzeichen bestehende Werte werden als explizite Löschung behandelt — so dass die gespeicherten Daten immer mit dem auf der Rechnung gezeigten übereinstimmen.
Erfahren Sie mehr: [B2B-Zahlungen](/features/b2b-payments) | [Rechnungsverwaltung](/features/invoice-generation) | [Checkout-Sitzung](/developer-resources/checkout-session)
## Fehlerbehebungen & Verbesserungen
* Kleinere Fehlerkorrekturen und Stabilitätsverbesserungen über die gesamte Plattform.