> ## 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.112.0 (5. August 2026)
> Rabattcodes bieten jetzt Betragsrabatte, zeitliche Planung, Regeln zur Kundenberechtigung und Optionen pro Währung. Gleichzeitig wurde das native Webhooks-Erlebnis mit E-Mail-Benachrichtigungen neu aufgebaut — außerdem gibt es Cash App Pay für Abonnements, SEPA Direct Debit für einmalige EUR-Zahlungen, kundenfreundliche Meldungen bei fehlgeschlagenen Zahlungen, Payout-Webhooks, eine Self-Service-Änderung der Login-E-Mail-Adresse, eine Einstellung, mit der Kunden ihre eigenen Abonnements kündigen können, sowie einen Währungsfilter für die Zahlungsliste.
## Neue Funktionen
### 1. **Rabattcodes: Betragsrabatte, zeitliche Planung und Berechtigungsregeln**
Rabattcodes sind nicht mehr auf prozentuale Rabatte beschränkt. Ein Code kann jetzt einen festen Betrag abziehen, nach einem Zeitplan starten, je nach Währung unterschiedlich bepreist werden und festlegen, wer ihn einlösen darf.
**Betragsrabatte**
Setze `type` auf `flat`, um statt eines Prozentsatzes einen festen Betrag abzuziehen. Der Abzug wird über den gesamten Warenkorb zusammengefasst und nicht auf einzelne Positionen angewendet.
| Typ | API-Wert | Verhalten |
| ----------- | ------------ | ----------------------------------------------------------------------------------- |
| Prozentsatz | `percentage` | Reduziert den Preis um einen Prozentsatz, optional mit einer Begrenzung pro Währung |
| Betrag | `flat` | Zieht einen festen Betrag ab, zusammengefasst über den Warenkorb |
**Optionen pro Währung**
`currency_options` sorgt dafür, dass sich ein Code in jeder von dir angebotenen Währung korrekt verhält. Jeder Eintrag legt für eine einzelne Währung den maximalen Rabatt (den Abzug selbst bei einem Betragscode, eine Obergrenze bei einem Prozentsatzcode) und den Mindestwert des Warenkorbs fest. Ein Betragsrabatt erfordert mindestens eine Währungsoption mit einem auflösbaren Standardwert; bei prozentualen Rabatten bleiben Währungsoptionen optional.
**Kundenberechtigung**
`customer_eligibility` legt fest, wer einen Code einlösen darf:
| Wert | Wer kann ihn einlösen |
| ------------ | ------------------------------------------------------ |
| `any` | Jeder Kunde. Dies ist die Standardeinstellung. |
| `first_time` | Kunden, die zuvor noch nichts bei dir gekauft haben. |
| `existing` | Kunden, die zuvor bereits bei dir gekauft haben. |
| `specific` | Nur Kunden, die du der Allowlist des Codes hinzufügst. |
Verwalte die Allowlist über das Dashboard oder mit den neuen Endpoints: `GET /discounts/{discount_id}/customers` listet die verknüpften Kunden auf, `POST /discounts/{discount_id}/customers` fügt sie hinzu und `DELETE /discounts/{discount_id}/customers/{customer_id}` entfernt einen einzelnen Kunden.
Ein `specific`-Code beginnt mit **null** berechtigten Kunden und lehnt jede Einlösung ab, bis du Kunden hinzufügst.
**Zeitliche Planung und Limits pro Kunde**
Setze `starts_at`, um einen Code für einen zukünftigen Start zu planen — bleibt der Wert leer, wird der Code sofort aktiv. Der Wert muss strikt vor `expires_at` liegen. Verwende `per_customer_usage_limit`, um zu begrenzen, wie oft ein einzelner Kunde einen Code einlösen kann. Dieses separate Limit darf `usage_limit` nicht überschreiten.
Ein Mindestwert des Warenkorbs wird immer anhand der ursprünglichen Preise des Warenkorbs berechnet, niemals anhand der Zwischensumme während einer Rabattstapelung. Die Reihenfolge der Stapelung ändert daher nie, ob ein Mindestwert erreicht wird.
Mehr erfahren: [Rabatte](/features/discount-codes) | [Rabatt erstellen](/api-reference/discounts/create-discount)
### 2. **Ein neu aufgebautes Webhooks-Erlebnis**
Der Webhooks-Bereich des Dashboards wurde als native Oberfläche neu aufgebaut und ersetzt das eingebettete Portal. Alles befindet sich jetzt direkt im Dashboard, mit einheitlichen Tabellen, Filtern und einer einheitlichen Navigation. Außerdem funktioniert der Bereich nun zuverlässig auf Mobilgeräten.
* **Endpoints** — Erstelle und bearbeite Endpoints in einem Seitenbereich, wähle Eventtypen aus einem durchsuchbaren Baum aus und sieh die Fehlerrate der letzten 24 Stunden auf einen Blick.
* **Aktivität und Logs** — Verfolge Zustellversuche im Zeitverlauf im Diagramm **Zustellaktivität**, durchsuche zugestellte Nachrichten und öffne eine Seite mit **Nachrichtendetails**, um Payload und jeden Zustellversuch einschließlich Response-Code und Dauer zu prüfen. Jeder Versuch kann von dort erneut abgespielt werden.
* **Eventkatalog** — Durchsuche jeden von Dodo Payments gesendeten Eventtyp mit seinem Schema und einem Beispiel-Payload.
* **Endpoint-Übersicht** — Zustellstatistiken der letzten 24 Stunden, das anzeigbare oder rotierbare Signing Secret sowie der **Replay-Verlauf**.
* **Testing** — Sende ein Beispiel-Event an einen Endpoint, um deinen Receiver vor dem Livegang zu überprüfen.
* **Erweitert** — Begrenze die Zustellrate, verwalte die benutzerdefinierten Header, die mit jeder Anfrage an diesen Endpoint gesendet werden, und bearbeite seine Transformation.
* **Massen-Replay** — Stelle auf einem Endpoint fehlgeschlagene Nachrichten wieder her, spiele nie gesendete Nachrichten erneut ab oder wiederhole einen gefilterten Bereich.
* **E-Mail-Benachrichtigungen** — Ein neuer Tab **Einstellungen**, in dem du die Adressen auflisten kannst, die per E-Mail benachrichtigt werden sollen, wenn Zustellungen an einen Endpoint fehlschlagen. Trenne mehrere Adressen durch Kommas. Lasse das Feld leer, um Benachrichtigungen zu deaktivieren.
Dies ist ausschließlich eine Änderung am Dashboard. Deine bestehenden Endpoints, Signing Secrets, Signaturprüfungen, Eventnamen und Payloads bleiben unverändert — es ist keine Anpassung der Integration erforderlich.
Mehr erfahren: [Webhooks](/developer-resources/webhooks) | [Webhook-Events](/developer-resources/webhooks/intents/webhook-events-guide)
### 3. **Cash App Pay für Abonnements**
Cash App Pay kann jetzt ein wiederkehrendes Abonnement unterstützen, nicht nur eine einmalige Zahlung. Die Zahlungsmethode ist bei US-Checkouts mit Abrechnung in USD neben den bestehenden Kartenoptionen verfügbar.
Mehr erfahren: [Digitale Wallets](/features/payment-methods/digital-wallets)
### 4. **SEPA Direct Debit**
SEPA Direct Debit ist jetzt in der gesamten Eurozone verfügbar. Kunden können dadurch direkt von ihrem Bankkonto zahlen, anstatt eine Karte zu verwenden. Die Zahlungsmethode wird bei EUR-Checkouts für einmalige Zahlungen angeboten.
SEPA Direct Debit ist nicht sofort. Die Bestätigung einer Zahlung dauert **6 Werktage**. Behandle daher die Autorisierung nicht als Abwicklung — erfülle die Bestellung erst, wenn die Zahlung den Status succeeded erreicht.
Mehr erfahren: [Europäische Zahlungsmethoden](/features/payment-methods/europe)
### 5. **Verständlichere Meldungen bei fehlgeschlagenen Zahlungen**
Wenn eine Zahlung fehlschlägt, sehen du und dein Kunde jetzt eigens formulierte Texte anstelle von rohem Processor-Text. Jeder Fehler wird über eine Taxonomie aus **46 einheitlichen Fehlercodes** aufgelöst, die jeweils zwei Zielgruppen zugeordnet sind:
* **Du** siehst bei der Zahlung eine Überschrift und eine empfohlene Aktion. So weißt du, ob du den Kunden auffordern solltest, es erneut zu versuchen, seine Bank zu kontaktieren oder eine andere Karte zu verwenden. `error_message` am Payment-Objekt enthält diesen Text jetzt, wenn `error_code` ein erkannter einheitlicher Code ist.
* **Dein Kunde** sieht eine verständliche Erklärung auf dem Bildschirm für fehlgeschlagene Checkouts, im Customer Portal und in Dunning-E-Mails — zum Beispiel: *„Der Sicherheitscode deiner Karte (CVC) scheint nicht korrekt zu sein. Bitte gib ihn erneut ein und versuche es noch einmal.“*
Bei betrugssensiblen Ablehnungen — `FRAUDULENT`, `LOST_CARD`, `STOLEN_CARD` und `PICKUP_CARD` — sieht der Kunde immer eine allgemeine Meldung, damit der tatsächliche Grund niemals preisgegeben wird. Du siehst weiterhin den wahren Grund, versehen mit einem Hinweis, ihn nicht weiterzugeben.
Mehr erfahren: [Fehler bei Transaktionen](/api-reference/transaction-failures) | [Zahlungen](/features/transactions/payments) | [Zahlungsdetails abrufen](/api-reference/payments/get-payments-1)
### 6. **Kunden erlauben, ihre eigenen Abonnements zu kündigen**
**Kündigung von Abonnements erlauben** ist jetzt eine eigenständige Einstellung im Tab **Abonnements** der Dashboard-Einstellungen und wird durchgängig erzwungen. Wenn du die Einstellung deaktivierst, deaktiviert das Customer Portal die Kündigungsschaltfläche und die API lehnt eine vom Kunden initiierte Kündigung mit einem `403` ab — sowohl bei der sofortigen Kündigung als auch bei der Option „zum nächsten Abrechnungsdatum kündigen“. Zuvor wurde durch die Einstellung nur die Schaltfläche ausgeblendet, sodass ein entschlossener Kunde weiterhin über die API kündigen konnte.
Die Einstellung ist **standardmäßig aktiviert**. Deine eigenen Kündigungen über die Merchant API und das Dashboard sind davon nie betroffen. Ein Kunde kann eine bereits geplante Kündigung jederzeit zurücknehmen.
Mehr erfahren: [Customer Portal](/features/customer-portal) | [Abonnements](/features/subscription)
### 7. **Payout-Webhooks**
Du erhältst jetzt Webhooks für deine eigenen Auszahlungen und kannst sie dadurch in deinen Buchhaltungssystemen abgleichen, ohne regelmäßig Abfragen senden zu müssen.
| Event | Wird ausgelöst, wenn |
| -------------------- | ----------------------------------------------------------------------------------------------------- |
| `payout.created` | eine Auszahlung erstellt wird, entweder durch den automatischen Auszahlungszyklus oder außerplanmäßig |
| `payout.in_progress` | das Fälligkeitsdatum der Auszahlung erreicht ist und die Verarbeitung beginnt |
| `payout.on_hold` | die Auszahlung pausiert oder zur Prüfung zurückgestellt wird |
| `payout.success` | die Auszahlung auf deinem Bankkonto abgewickelt wird |
| `payout.failed` | die Auszahlung fehlschlägt und Betrag sowie Gebühren deinem Wallet gutgeschrieben werden |
`payout.created` wurde zuvor als `payout.not_initiated` ausgegeben. Wenn ein bestehender Endpoint nach `payout.not_initiated` filtert, aktualisiere den Filter auf `payout.created`, damit er weiterhin passende Events findet. Das Feld `status` im Payload meldet in dieser Phase weiterhin `not_initiated`.
Mehr erfahren: [Payout-Webhooks](/developer-resources/webhooks/intents/payout) | [Auszahlungsprozess](/features/payouts/payout-structure)
### 8. **Login-E-Mail-Adresse im Dashboard ändern**
Du kannst jetzt die E-Mail-Adresse ändern, mit der du dich anmeldest, ohne den Support zu kontaktieren. Der Tab „Konto“ wurde neu gestaltet und enthält einen neuen Bereich **E-Mail-Adresse ändern** mit einer Schaltfläche **E-Mail-Adresse ändern**, die den Vorgang startet.
Die Verifizierung erfolgt in zwei Schritten: Wir senden einen Code an deine **aktuelle** Adresse, um zu bestätigen, dass du es bist, und anschließend einen zweiten Code an deine **neue** Adresse, um zu bestätigen, dass du Zugriff darauf hast. Sobald beide Adressen verifiziert sind:
* Meldest du dich künftig mit der neuen Adresse an. Die vorherige Adresse funktioniert nicht mehr für Passwörter, Magic Links und per E-Mail gesendete Codes.
* Werden verknüpfte Identity Provider wie die Anmeldung über Google oder GitHub getrennt und müssen erneut verbunden werden.
* Bleiben dein Passwort, deine Unternehmen, dein Teamzugriff und dein Verifizierungsstatus unverändert.
* Wird eine Benachrichtigung an deine vorherige Adresse gesendet, damit eine unerwartete Änderung nicht unbemerkt bleibt.
Mehr erfahren: [Mein Konto](/miscellaneous/accounts)
### 9. **Analysen: Neue Widgets und Verbesserungen**
Aufbauend auf der Überarbeitung von Analytics v3 fügt diese Version neue Visualisierungen hinzu und verbessert die bestehenden.
* **Umsatz nach Land ist jetzt eine vollbreite Choroplethenkarte** mit der Rangliste der Länder daneben. Die Karte kann wie die übrigen Karten geteilt werden.
* **Neu gezeichnete Trenddiagramme** mit Fadenkreuz beim Darüberfahren, einer rollierenden Datumsauswahl auf der x-Achse und einem kompakten Tooltip.
* **Neue Datumsvoreinstellungen** — **Letzte 30 Tage** ersetzt „Letzte 4 Wochen“, und **Letzte 6 Monate** wurde hinzugefügt.
* **Deine Filter bleiben erhalten.** Die Datumsvoreinstellung und der Vergleichsmodus werden jetzt pro Unternehmen gespeichert und geräteübergreifend übernommen, anstatt in jeder Sitzung auf die Standardwerte zurückgesetzt zu werden.
* **Top-Kunden werden anhand ihres Namens identifiziert**, ersatzweise anhand ihrer E-Mail-Adresse.
* Der Umsatz nach Land enthält jetzt bis zu den **Top 150** Ländern.
Mehr erfahren: [Dashboard-Analysen](/features/analytics-and-reporting)
## Verbesserungen und Fehlerbehebungen
### 10. **Zahlungen nach Währung filtern**
`GET /payments` akzeptiert jetzt einen optionalen **`currency`**-Query-Parameter. Dadurch kannst du nur die Zahlungen auflisten, die in einer bestimmten Währung abgewickelt wurden — zum Beispiel `GET /payments?currency=EUR`. Derselbe Filter ist auch in der Zahlungstabelle des Dashboards verfügbar.
Mehr erfahren: [Zahlungen auflisten](/api-reference/payments/get-payments)
### 11. **Antwortfrist für Disputes auf 10 Tage verlängert**
Du hast jetzt **10 Tage** Zeit, auf einen Dispute nach seiner Erstellung zu antworten, statt bisher 4 Tage. Der Countdown des Disputes im Dashboard und die von der API zurückgegebene Antwortfrist spiegeln beide das verlängerte Zeitfenster wider.
Mehr erfahren: [Disputes](/features/transactions/disputes)
### 12. **Verständlichere Formulare für Payout-Bankkonten**
Das Hinzufügen eines Payout-Bankkontos ist jetzt eindeutiger. Feldbezeichnungen, Beschreibungen und Tooltips passen sich nun an deinen Unternehmenstyp an, sodass Kontoinhaber und Name des Zahlungsempfängers bei Einzelunternehmen nicht mehr wie Duplikate wirken. Wenn du **Andere** als Bank auswählst, kannst du den Namen frei eingeben. Der chinesische Code für inländische Banken ist als **CNAPS** gekennzeichnet, und die Payouts-Seite bleibt im Testmodus sichtbar, damit du deine verknüpften Konten aus beiden Modi erreichen kannst.
Mehr erfahren: [Auszahlungsprozess](/features/payouts/payout-structure)
### Weitere Fehlerbehebungen und Verbesserungen
* **Gutschriften bei Planänderungen werden bei fehlgeschlagenen Zahlungen zurückgenommen.** Prorationsgutschriften, die während einer Änderung des Abonnementplans ausgestellt wurden, bleiben nicht mehr bestehen, wenn die daraus resultierende Zahlung nicht erfolgreich ist.
* **Rechnungen für kostenpflichtige Testphasen zeigen die Testphasengebühr**, nicht den regulären wiederkehrenden Preis.
* **Prozentuale Rabatte berücksichtigen den Mindestwert des Warenkorbs**, der anhand des Basispreises und nicht der Zwischensumme berechnet wird. Ein Timeout beim Sperren eines Rabatts gibt jetzt außerdem einen eigenen Fehlercode statt eines allgemeinen `503` zurück.
* **Das Löschen einer bereits entfernten Zahlungsmethode ist jetzt erfolgreich**, statt einen Fehler zurückzugeben. Dadurch ist der Aufruf sicher idempotent.
* **Die für die Mindestgrenze des India-Mandats verwendete Währung wurde korrigiert**, wenn die Zahlungsmethode eines Abonnements aktualisiert wird.
* **Guthabenbuchungen außerhalb der zulässigen Grenzen** werden mit einem typisierten `400` abgelehnt, statt später fehlzuschlagen.
* **Pay-what-you-want-Produkte unterstützen in gemeinsamen Checkout-Links einen festen Betrag**, und Entitlement-IDs werden im Detailbereich der Entitlements angezeigt.
* Fehlerbehebungen in Analytics: Lifetime-Value-Reihen, in MRR einbezogene Add-ons, kein Periodenvergleich bei Gesamtzeiträumen, Reihen, die beim aktuellen Bucket enden, sowie klarere Bezeichnungen für Zeiträume und Vergleiche.
* Kleinere Fehlerbehebungen und Stabilitätsverbesserungen auf der gesamten Plattform.