Leitfaden zum Upgrade und Downgrade von Abonnements

API-Referenz zum Planwechsel

Greifen Sie auf die vollständige API-Dokumentation zum Ändern von Abonnementplänen zu und testen Sie Planwechselanfragen interaktiv.

API zur Vorschau von Planänderungen

Vorschau auf den genauen Betrag, der vor der Bestätigung einer Planänderung berechnet wird.

Leitfaden zur Abonnementintegration

Erfahren Sie, wie Sie Abonnements von Grund auf erstellen und verwalten können, mit unserem umfassenden Integrationsleitfaden.

Was ist ein Upgrade oder Downgrade eines Abonnements?

Planänderungen ermöglichen es Ihnen, einen Kunden zwischen Abonnementstufen oder -mengen zu verschieben. Verwenden Sie es, um:

Preise an Nutzung oder Funktionen anzupassen
Von monatlich auf jährlich (oder umgekehrt) zu wechseln
Die Menge für sitzbasierte Produkte anzupassen

Planänderungen können je nach gewähltem Proratisierungsmodus eine sofortige Gebühr auslösen.

Wann sollten Planänderungen verwendet werden

Upgrade, wenn ein Kunde mehr Funktionen, Nutzung oder Plätze benötigt
Downgrade, wenn die Nutzung abnimmt
Benutzer auf ein neues Produkt oder einen neuen Preis migrieren, ohne ihr Abonnement zu kündigen

Voraussetzungen

Bevor Sie Änderungen an Abonnementplänen implementieren, stellen Sie sicher, dass Sie:

Ein Dodo Payments-Händlerkonto mit aktiven Abonnementprodukten haben
API-Anmeldeinformationen (API-Schlüssel und Webhook-Geheimschlüssel) aus dem Dashboard haben
Ein bestehendes aktives Abonnement zur Modifikation haben
Einen Webhook-Endpunkt konfiguriert haben, um Abonnementereignisse zu verarbeiten

Für detaillierte Einrichtungsanleitungen siehe unseren Integrationsleitfaden.

Schritt-für-Schritt-Implementierungsleitfaden

Befolgen Sie diesen umfassenden Leitfaden, um Änderungen an Abonnementplänen in Ihrer Anwendung zu implementieren:

Verstehen Sie die Anforderungen an Planänderungen

Bevor Sie implementieren, bestimmen Sie:

Welche Abonnementprodukte auf welche anderen geändert werden können
Welcher Proratisierungsmodus zu Ihrem Geschäftsmodell passt
Wie Sie fehlgeschlagene Planänderungen elegant handhaben
Welche Webhook-Ereignisse Sie zur Statusverwaltung verfolgen sollten

Testen Sie Planänderungen gründlich im Testmodus, bevor Sie sie in der Produktion implementieren.

Wählen Sie Ihre Proratisierungsstrategie

Wählen Sie den Abrechnungsansatz, der zu Ihren Geschäftsbedürfnissen passt:

prorated_immediately
difference_immediately
full_immediately

Am besten geeignet für: SaaS-Anwendungen, die fair für ungenutzte Zeit abrechnen möchten

Berechnet den genauen proratisierten Betrag basierend auf der verbleibenden Zykluszeit
Berechnet einen proratisierten Betrag basierend auf der verbleibenden ungenutzten Zeit im Zyklus
Bietet transparente Abrechnung für Kunden

Implementieren Sie die Change Plan API

Verwenden Sie die Change Plan API, um Abonnementdetails zu ändern:

subscription_id

string

required

Die ID des aktiven Abonnements, das geändert werden soll.

product_id

string

required

Die neue Produkt-ID, auf die das Abonnement geändert werden soll.

quantity

integer

default:"1"

Anzahl der Einheiten für den neuen Plan (für sitzbasierte Produkte).

proration_billing_mode

string

required

Wie die sofortige Abrechnung gehandhabt werden soll: prorated_immediately, full_immediately oder difference_immediately.

addons

array

Optionale Addons für den neuen Plan. Wenn Sie dies leer lassen, werden vorhandene Addons entfernt.

Webhook-Ereignisse verarbeiten

Richten Sie die Verarbeitung von Webhook-Ereignissen ein, um die Ergebnisse von Planänderungen zu verfolgen:

subscription.active: Planänderung erfolgreich, Abonnement aktualisiert
subscription.plan_changed: Abonnementplan geändert (Upgrade/Downgrade/Add-on-Update)
subscription.on_hold: Planänderungsgebühr fehlgeschlagen, Abonnement pausiert
payment.succeeded: Sofortige Gebühr für Planänderung erfolgreich
payment.failed: Sofortige Gebühr fehlgeschlagen

Überprüfen Sie immer die Webhook-Signaturen und implementieren Sie idempotente Ereignisverarbeitung.

Aktualisieren Sie den Status Ihrer Anwendung

Basierend auf Webhook-Ereignissen aktualisieren Sie Ihre Anwendung:

Gewähren/entziehen Sie Funktionen basierend auf dem neuen Plan
Aktualisieren Sie das Kunden-Dashboard mit den neuen Plandetails
Senden Sie Bestätigungs-E-Mails über Planänderungen
Protokollieren Sie Abrechnungsänderungen zu Prüfungszwecken

Testen und Überwachen

Testen Sie Ihre Implementierung gründlich:

Testen Sie alle Proratisierungsmodi mit verschiedenen Szenarien
Überprüfen Sie, ob die Verarbeitung von Webhooks korrekt funktioniert
Überwachen Sie die Erfolgsquoten von Planänderungen
Richten Sie Alarme für fehlgeschlagene Planänderungen ein

Ihre Implementierung zur Änderung des Abonnementplans ist jetzt bereit für den Produktionsgebrauch.

Vorschau von Planänderungen

Bevor Sie sich zu einer Planänderung verpflichten, verwenden Sie die Vorschau-API, um den Kunden genau zu zeigen, was ihnen berechnet wird:

Node.js SDK
Python SDK

const preview = await client.subscriptions.previewChangePlan('sub_123', {
  product_id: 'prod_pro',
  quantity: 1,
  proration_billing_mode: 'prorated_immediately'
});

// Show customer the charge before confirming
console.log('Immediate charge:', preview.immediate_charge.summary);
console.log('New plan details:', preview.new_plan);

preview = client.subscriptions.preview_change_plan(
    subscription_id="sub_123",
    product_id="prod_pro",
    quantity=1,
    proration_billing_mode="prorated_immediately"
)

# Show customer the charge before confirming
print("Immediate charge:", preview.immediate_charge.summary)
print("New plan details:", preview.new_plan)

Verwenden Sie die Vorschau-API, um Bestätigungsdialoge zu erstellen, die den Kunden den genauen Betrag anzeigen, der ihnen vor der Bestätigung einer Planänderung berechnet wird.

Change Plan API

Verwenden Sie die Change Plan API, um Produkt, Menge und Proratisierungsverhalten für ein aktives Abonnement zu ändern.

Schnellstartbeispiele

Node.js SDK
Python SDK
Go SDK
HTTP

import DodoPayments from 'dodopayments';

const client = new DodoPayments({
  bearerToken: process.env.DODO_PAYMENTS_API_KEY,
  environment: 'test_mode', // defaults to 'live_mode'
});

async function changePlan() {
  const result = await client.subscriptions.changePlan('sub_123', {
    product_id: 'prod_new',
    quantity: 3,
    proration_billing_mode: 'prorated_immediately',
  });
  console.log(result.status, result.invoice_id, result.payment_id);
}

changePlan();

import os
from dodopayments import DodoPayments

client = DodoPayments(
    bearer_token=os.environ.get("DODO_PAYMENTS_API_KEY"),
    environment="test_mode",  # defaults to "live_mode"
)

result = client.subscriptions.change_plan(
    subscription_id="sub_123",
    product_id="prod_new",
    quantity=3,
    proration_billing_mode="prorated_immediately",
)
print(result.status, result.get("invoice_id"), result.get("payment_id"))

package main

import (
  "context"
  "fmt"
  "github.com/dodopayments/dodopayments-go"
  "github.com/dodopayments/dodopayments-go/option"
)

func main() {
  client := dodopayments.NewClient(option.WithBearerToken("YOUR_TOKEN"))
  res, err := client.Subscriptions.ChangePlan(context.TODO(), dodopayments.SubscriptionChangePlanParams{
    SubscriptionID: dodopayments.F("sub_123"),
    ProductID:             dodopayments.F("prod_new"),
    Quantity:              dodopayments.F(int64(3)),
    ProrationBillingMode:  dodopayments.F(dodopayments.SubscriptionChangePlanParamsProrationBillingModeProratedImmediately),
  })
  if err != nil { panic(err) }
  fmt.Println(res.Status, res.InvoiceID, res.PaymentID)
}

curl -X POST "$DODO_API_BASE/subscriptions/sub_123/change-plan" \
  -H "Authorization: Bearer $DODO_PAYMENTS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "product_id": "prod_new",
    "quantity": 3,
    "proration_billing_mode": "prorated_immediately"
  }'

Success

{
  "status": "processing",
  "subscription_id": "sub_123",
  "invoice_id": "inv_789",
  "payment_id": "pay_456",
  "proration_billing_mode": "prorated_immediately"
}

Felder wie invoice_id und payment_id werden nur zurückgegeben, wenn eine sofortige Gebühr und/oder Rechnung während der Planänderung erstellt wird. Verlassen Sie sich immer auf Webhook-Ereignisse (z. B. payment.succeeded, subscription.plan_changed), um Ergebnisse zu bestätigen.

Wenn die sofortige Gebühr fehlschlägt, kann das Abonnement in den Status subscription.on_hold verschoben werden, bis die Zahlung erfolgreich ist.

Verwaltung von Addons

Bei Änderungen an Abonnementplänen können Sie auch Addons ändern:

// Add addons to the new plan
await client.subscriptions.changePlan('sub_123', {
  product_id: 'prod_new',
  quantity: 1,
  proration_billing_mode: 'difference_immediately',
  addons: [
    { addon_id: 'addon_123', quantity: 2 }
  ]
});

// Remove all existing addons
await client.subscriptions.changePlan('sub_123', {
  product_id: 'prod_new',
  quantity: 1,
  proration_billing_mode: 'difference_immediately',
  addons: [] // Empty array removes all existing addons
});

Addons sind in die Proratisierungsberechnung einbezogen und werden gemäß dem gewählten Proratisierungsmodus berechnet.

Proratisierungsmodi

Wählen Sie, wie Sie den Kunden bei Planänderungen abrechnen:

`prorated_immediately`

Berechnet die teilweise Differenz im aktuellen Zyklus
Wenn im Testzeitraum, wird sofort abgerechnet und jetzt auf den neuen Plan gewechselt
Downgrade: kann eine proratisierte Gutschrift für zukünftige Erneuerungen erzeugen

`full_immediately`

Berechnet den vollen Betrag des neuen Plans sofort
Ignoriert die verbleibende Zeit des alten Plans

Gutschriften, die durch Downgrades mit difference_immediately erstellt werden, sind abonnementspezifisch und unterscheiden sich von Kundenkrediten. Sie gelten automatisch für zukünftige Erneuerungen des gleichen Abonnements und sind nicht übertragbar zwischen Abonnements.

`difference_immediately`

Upgrade: sofortige Berechnung der Preisunterschiede zwischen alten und neuen Plänen
Downgrade: verbleibenden Wert als interne Gutschrift zum Abonnement hinzufügen und automatisch bei Erneuerungen anwenden

Beispielszenarien

Upgrade: Basic ($30) → Pro ($80) mit difference_immediately

await client.subscriptions.changePlan('sub_123', {
  product_id: 'prod_pro',
  quantity: 1,
  proration_billing_mode: 'difference_immediately'
})
// Immediate charge: $50

Downgrade: Plus ($50) → Starter ($20) mit difference_immediately

await client.subscriptions.changePlan('sub_123', {
  product_id: 'prod_starter',
  quantity: 1,
  proration_billing_mode: 'difference_immediately'
})
// Credit added: $30 (auto-applied to future renewals for this subscription)

Upgrade mitten im Zyklus mit prorated_immediately

await client.subscriptions.changePlan('sub_123', {
  product_id: 'prod_new',
  quantity: 1,
  proration_billing_mode: 'prorated_immediately'
})
// Immediate prorated charge based on remaining days in cycle

Abrechnung zurücksetzen mit full_immediately

await client.subscriptions.changePlan('sub_123', {
  product_id: 'prod_new',
  quantity: 1,
  proration_billing_mode: 'full_immediately'
})
// Immediate full charge for new plan; no credits calculated

Wählen Sie prorated_immediately für eine faire Zeitabrechnung; wählen Sie full_immediately, um die Abrechnung zurückzusetzen; verwenden Sie difference_immediately für einfache Upgrades und automatische Gutschriften bei Downgrades.

Verarbeitung von Webhooks

Verfolgen Sie den Abonnementstatus über Webhooks, um Planänderungen und Zahlungen zu bestätigen.

Zu verarbeitende Ereignistypen

subscription.active: Abonnement aktiviert
subscription.plan_changed: Abonnementplan geändert (Upgrade/Downgrade/Add-on-Änderungen)
subscription.on_hold: Gebühr fehlgeschlagen, Abonnement pausiert
subscription.renewed: Erneuerung erfolgreich
payment.succeeded: Zahlung für Planänderung oder Erneuerung erfolgreich
payment.failed: Zahlung fehlgeschlagen

Wir empfehlen, Geschäftslogik aus Abonnementereignissen abzuleiten und Zahlungsevents zur Bestätigung und Abstimmung zu verwenden.

Überprüfen Sie Signaturen und verarbeiten Sie Absichten

Next.js Route Handler
Express.js

import { NextRequest, NextResponse } from 'next/server';

export async function POST(req) {
  const webhookId = req.headers.get('webhook-id');
  const webhookSignature = req.headers.get('webhook-signature');
  const webhookTimestamp = req.headers.get('webhook-timestamp');
  const secret = process.env.DODO_WEBHOOK_SECRET;

  const payload = await req.text();
  // verifySignature is a placeholder – in production, use a Standard Webhooks library
  const { valid, event } = await verifySignature(
    payload,
    { id: webhookId, signature: webhookSignature, timestamp: webhookTimestamp },
    secret
  );
  if (!valid) return NextResponse.json({ error: 'Invalid signature' }, { status: 400 });

  switch (event.type) {
    case 'subscription.active':
      // mark subscription active in your DB
      break;
    case 'subscription.plan_changed':
      // refresh entitlements and reflect the new plan in your UI
      break;
    case 'subscription.on_hold':
      // notify user to update payment method
      break;
    case 'subscription.renewed':
      // extend access window
      break;
    case 'payment.succeeded':
      // reconcile payment for plan change
      break;
    case 'payment.failed':
      // log and alert
      break;
    default:
      // ignore unknown events
      break;
  }

  return NextResponse.json({ received: true });
}

import express from 'express';

const app = express();
app.post('/webhooks/dodo', express.raw({ type: 'application/json' }), async (req, res) => {
  const webhookId = req.header('webhook-id');
  const webhookSignature = req.header('webhook-signature');
  const webhookTimestamp = req.header('webhook-timestamp');
  const secret = process.env.DODO_WEBHOOK_SECRET;
  const payload = req.body.toString('utf8');

  const { valid, event } = await verifySignature(
    payload,
    { id: webhookId, signature: webhookSignature, timestamp: webhookTimestamp },
    secret
  );
  if (!valid) return res.status(400).send('Invalid signature');

  // handle events like above
  res.json({ received: true });
});

app.listen(3000);

Für detaillierte Payload-Schemas siehe die Webhook-Payloads für Abonnements und Webhook-Payloads für Zahlungen.

Best Practices

Befolgen Sie diese Empfehlungen für zuverlässige Änderungen an Abonnementplänen:

Strategie zur Planänderung

Gründlich testen: Testen Sie Planänderungen immer im Testmodus, bevor Sie in die Produktion gehen
Proratisierung sorgfältig wählen: Wählen Sie den Proratisierungsmodus, der zu Ihrem Geschäftsmodell passt
Fehler elegant behandeln: Implementieren Sie eine ordnungsgemäße Fehlerbehandlung und Wiederholungslogik
Erfolgsquoten überwachen: Verfolgen Sie die Erfolgs-/Fehlerquoten von Planänderungen und untersuchen Sie Probleme

Webhook-Implementierung

Signaturen überprüfen: Überprüfen Sie immer die Webhook-Signaturen, um die Authentizität sicherzustellen
Idempotenz implementieren: Behandeln Sie doppelte Webhook-Ereignisse elegant
Asynchron verarbeiten: Blockieren Sie Webhook-Antworten nicht mit schweren Operationen
Alles protokollieren: Führen Sie detaillierte Protokolle für Debugging- und Prüfungszwecke

Benutzererfahrung

Klar kommunizieren: Informieren Sie die Kunden über Änderungen bei der Abrechnung und deren Zeitpunkt
Bestätigungen bereitstellen: Senden Sie E-Mail-Bestätigungen für erfolgreiche Planänderungen
Randfälle behandeln: Berücksichtigen Sie Testzeiträume, Proratisierungen und fehlgeschlagene Zahlungen
UI sofort aktualisieren: Spiegeln Sie Planänderungen in Ihrer Anwendungsoberfläche wider

Häufige Probleme und Lösungen

Lösen Sie typische Probleme, die bei Änderungen an Abonnementplänen auftreten:

Gebühr erstellt, aber Abonnement nicht aktualisiert

Symptome: API-Aufruf erfolgreich, aber Abonnement bleibt im alten PlanHäufige Ursachen:

Verarbeitung von Webhooks fehlgeschlagen oder verzögert
Anwendungsstatus nicht aktualisiert nach Erhalt von Webhooks
Datenbanktransaktionsprobleme während der Statusaktualisierung

Lösungen:

Implementieren Sie eine robuste Verarbeitung von Webhooks mit Wiederholungslogik
Verwenden Sie idempotente Operationen für Statusaktualisierungen
Fügen Sie Überwachungen hinzu, um verpasste Webhook-Ereignisse zu erkennen und zu alarmieren
Überprüfen Sie, ob der Webhook-Endpunkt zugänglich und korrekt antwortet

Gutschriften werden nach Downgrade nicht angewendet

Symptome: Kunde downgradiert, sieht aber keinen GutschriftensaldoHäufige Ursachen:

Erwartungen an den Proratisierungsmodus: Downgrades gutschreiben die volle Preisunterschied des Plans mit difference_immediately, während prorated_immediately eine proratisierte Gutschrift basierend auf der verbleibenden Zeit im Zyklus erzeugt
Gutschriften sind abonnementspezifisch und werden nicht zwischen Abonnements übertragen
Gutschriftensaldo nicht im Kundendashboard sichtbar

Lösungen:

Verwenden Sie difference_immediately für Downgrades, wenn Sie automatische Gutschriften wünschen
Erklären Sie den Kunden, dass Gutschriften für zukünftige Erneuerungen des gleichen Abonnements gelten
Implementieren Sie ein Kundenportal, um Gutschriftensalden anzuzeigen
Überprüfen Sie die Vorschau der nächsten Rechnung, um angewendete Gutschriften zu sehen

Webhook-Signaturüberprüfung schlägt fehl

Symptome: Webhook-Ereignisse werden aufgrund ungültiger Signatur abgelehntHäufige Ursachen:

Falscher Webhook-Geheimschlüssel
Rohkörper der Anfrage wurde vor der Signaturüberprüfung geändert
Falsches Signaturüberprüfungsalgorithmus

Lösungen:

Überprüfen Sie, ob Sie den richtigen DODO_WEBHOOK_SECRET aus dem Dashboard verwenden
Lesen Sie den Rohkörper der Anfrage vor allen JSON-Parsing-Middleware
Verwenden Sie die Standardbibliothek zur Überprüfung von Webhooks für Ihre Plattform
Testen Sie die Überprüfung der Webhook-Signatur in der Entwicklungsumgebung

Planänderung schlägt mit 422-Fehler fehl

Symptome: API gibt 422 Unprocessable Entity-Fehler zurückHäufige Ursachen:

Ungültige Abonnement-ID oder Produkt-ID
Abonnement nicht im aktiven Zustand
Fehlende erforderliche Parameter
Produkt nicht für Planänderungen verfügbar

Lösungen:

Überprüfen Sie, ob das Abonnement existiert und aktiv ist
Überprüfen Sie, ob die Produkt-ID gültig und verfügbar ist
Stellen Sie sicher, dass alle erforderlichen Parameter bereitgestellt werden
Überprüfen Sie die API-Dokumentation für Parameteranforderungen

Sofortige Gebühr schlägt während der Planänderung fehl

Symptome: Planänderung eingeleitet, aber sofortige Gebühr schlägt fehlHäufige Ursachen:

Unzureichende Mittel auf der Zahlungsmethode des Kunden
Zahlungsmethode abgelaufen oder ungültig
Bank hat die Transaktion abgelehnt
Betrugsüberprüfung hat die Gebühr blockiert

Lösungen:

Behandeln Sie payment.failed Webhook-Ereignisse angemessen
Benachrichtigen Sie den Kunden, um die Zahlungsmethode zu aktualisieren
Implementieren Sie eine Wiederholungslogik für vorübergehende Fehler
Erwägen Sie, Planänderungen mit fehlgeschlagenen sofortigen Gebühren zuzulassen

Abonnement pausiert nach Planänderung

Symptome: Planänderungsgebühr schlägt fehl und Abonnement wechselt in den Status on_holdWas passiert: Wenn eine Planänderungsgebühr fehlschlägt, wird das Abonnement automatisch in den Status on_hold versetzt. Das Abonnement wird nicht automatisch erneuert, bis die Zahlungsmethode aktualisiert wird.Lösung: Aktualisieren Sie die Zahlungsmethode, um das Abonnement wieder zu aktivierenUm ein Abonnement aus dem Status on_hold nach einer fehlgeschlagenen Planänderung wieder zu aktivieren:

Aktualisieren Sie die Zahlungsmethode mit der Update Payment Method API
Automatische Gebührenerstellung: Die API erstellt automatisch eine Gebühr für ausstehende Beträge
Rechnungserstellung: Eine Rechnung wird für die Gebühr erstellt
Zahlungsabwicklung: Die Zahlung wird mit der neuen Zahlungsmethode verarbeitet
Reaktivierung: Nach erfolgreicher Zahlung wird das Abonnement in den Status active reaktiviert

// Reactivate subscription from on_hold after failed plan change
async function reactivateAfterFailedPlanChange(subscriptionId) {
  // Update payment method - automatically creates charge for remaining dues
  const response = await client.subscriptions.updatePaymentMethod(subscriptionId, {
    type: 'new',
    return_url: 'https://example.com/return'
  });
  
  if (response.payment_id) {
    console.log('Charge created for remaining dues:', response.payment_id);
    console.log('Payment link:', response.payment_link);
    
    // Redirect customer to payment_link to complete payment
    // Monitor webhooks for:
    // 1. payment.succeeded - charge succeeded
    // 2. subscription.active - subscription reactivated
  }
  
  return response;
}

// Or use existing payment method if available
async function reactivateWithExistingPaymentMethod(subscriptionId, paymentMethodId) {
  const response = await client.subscriptions.updatePaymentMethod(subscriptionId, {
    type: 'existing',
    payment_method_id: paymentMethodId
  });
  
  // Monitor webhooks for payment.succeeded and subscription.active
  return response;
}

Webhook-Ereignisse zur Überwachung:

subscription.on_hold: Abonnement wurde pausiert (erhalten, wenn die Planänderungsgebühr fehlschlägt)
payment.succeeded: Zahlung für ausstehende Beträge erfolgreich (nach Aktualisierung der Zahlungsmethode)
subscription.active: Abonnement nach erfolgreicher Zahlung reaktiviert

Best Practices:

Benachrichtigen Sie die Kunden sofort, wenn eine Planänderungsgebühr fehlschlägt
Geben Sie klare Anweisungen zur Aktualisierung ihrer Zahlungsmethode
Überwachen Sie Webhook-Ereignisse, um den Reaktivierungsstatus zu verfolgen
Erwägen Sie, eine automatische Wiederholungslogik für vorübergehende Zahlungsfehler zu implementieren

API-Referenz zur Aktualisierung der Zahlungsmethode

Sehen Sie sich die vollständige API-Dokumentation zur Aktualisierung von Zahlungsmethoden und zur Reaktivierung von Abonnements an.

Testen Ihrer Implementierung

Befolgen Sie diese Schritte, um Ihre Implementierung zur Änderung des Abonnementplans gründlich zu testen:

Testumgebung einrichten

Verwenden Sie Test-API-Schlüssel und Testprodukte
Erstellen Sie Testabonnements mit verschiedenen Plantypen
Konfigurieren Sie den Test-Webhooks-Endpunkt
Richten Sie Überwachung und Protokollierung ein

Testen Sie verschiedene Proratisierungsmodi

Testen Sie prorated_immediately mit verschiedenen Positionen im Abrechnungszyklus
Testen Sie difference_immediately für Upgrades und Downgrades
Testen Sie full_immediately, um Abrechnungszyklen zurückzusetzen
Überprüfen Sie, ob die Gutschriftberechnungen korrekt sind

Webhook-Verarbeitung testen

Überprüfen Sie, ob alle relevanten Webhook-Ereignisse empfangen werden
Testen Sie die Überprüfung der Webhook-Signatur
Behandeln Sie doppelte Webhook-Ereignisse elegant
Testen Sie Szenarien für das Fehlschlagen der Webhook-Verarbeitung

Fehler-Szenarien testen

Testen Sie mit ungültigen Abonnement-IDs
Testen Sie mit abgelaufenen Zahlungsmethoden
Testen Sie Netzwerkfehler und Zeitüberschreitungen
Testen Sie mit unzureichenden Mitteln

Überwachung in der Produktion

Richten Sie Alarme für fehlgeschlagene Planänderungen ein
Überwachen Sie die Verarbeitungszeiten von Webhooks
Verfolgen Sie die Erfolgsquoten von Planänderungen
Überprüfen Sie Kundenanfragen zu Problemen mit Planänderungen

Fehlerbehandlung

Behandeln Sie häufige API-Fehler elegant in Ihrer Implementierung:

HTTP-Statuscodes

200 OK

Planänderungsanfrage erfolgreich verarbeitet. Das Abonnement wird aktualisiert und die Zahlungsabwicklung hat begonnen.

400 Bad Request

Ungültige Anfrageparameter. Überprüfen Sie, ob alle erforderlichen Felder bereitgestellt und korrekt formatiert sind.

401 Unauthorized

Ungültiger oder fehlender API-Schlüssel. Überprüfen Sie, ob Ihr DODO_PAYMENTS_API_KEY korrekt ist und über die richtigen Berechtigungen verfügt.

404 Not Found

Abonnement-ID nicht gefunden oder gehört nicht zu Ihrem Konto.

422 Unprocessable Entity

Das Abonnement kann nicht geändert werden (z. B. bereits gekündigt, Produkt nicht verfügbar usw.).

500 Internal Server Error

Ein Serverfehler ist aufgetreten. Wiederholen Sie die Anfrage nach einer kurzen Verzögerung.

Fehlerantwortformat

{
  "error": {
    "code": "subscription_not_found",
    "message": "The subscription with ID 'sub_123' was not found",
    "details": {
      "subscription_id": "sub_123"
    }
  }
}

Nächste Schritte

Überprüfen Sie die Change Plan API
Erkunden Sie Kundenkredite
Implementieren Sie Alarme für subscription.on_hold
Sehen Sie sich unseren Leitfaden zur Webhook-Integration an

Integration Guides

Cookbooks

Leitfaden zum Upgrade und Downgrade von Abonnements

API-Referenz zum Planwechsel

API zur Vorschau von Planänderungen

Leitfaden zur Abonnementintegration

Was ist ein Upgrade oder Downgrade eines Abonnements?

Wann sollten Planänderungen verwendet werden

Voraussetzungen

Schritt-für-Schritt-Implementierungsleitfaden

Vorschau von Planänderungen

Change Plan API

Schnellstartbeispiele

Verwaltung von Addons

Proratisierungsmodi

`prorated_immediately`

`full_immediately`

`difference_immediately`

Beispielszenarien

Verarbeitung von Webhooks

Zu verarbeitende Ereignistypen

Überprüfen Sie Signaturen und verarbeiten Sie Absichten

Best Practices

Strategie zur Planänderung

Webhook-Implementierung

Benutzererfahrung

Häufige Probleme und Lösungen

API-Referenz zur Aktualisierung der Zahlungsmethode

Testen Ihrer Implementierung

Fehlerbehandlung

HTTP-Statuscodes

Fehlerantwortformat

Nächste Schritte

Integration Guides

Cookbooks

API-Referenz zum Planwechsel

API zur Vorschau von Planänderungen

Leitfaden zur Abonnementintegration

​Was ist ein Upgrade oder Downgrade eines Abonnements?

​Wann sollten Planänderungen verwendet werden

​Voraussetzungen

​Schritt-für-Schritt-Implementierungsleitfaden

​Vorschau von Planänderungen

​Change Plan API

​Schnellstartbeispiele

​Verwaltung von Addons

​Proratisierungsmodi

​prorated_immediately

​full_immediately

​difference_immediately

​Beispielszenarien

​Verarbeitung von Webhooks

​Zu verarbeitende Ereignistypen

​Überprüfen Sie Signaturen und verarbeiten Sie Absichten

​Best Practices

​Strategie zur Planänderung

​Webhook-Implementierung

​Benutzererfahrung

​Häufige Probleme und Lösungen

API-Referenz zur Aktualisierung der Zahlungsmethode

​Testen Ihrer Implementierung

​Fehlerbehandlung

​HTTP-Statuscodes

​Fehlerantwortformat

​Nächste Schritte

Was ist ein Upgrade oder Downgrade eines Abonnements?

Wann sollten Planänderungen verwendet werden

Voraussetzungen

Schritt-für-Schritt-Implementierungsleitfaden

Vorschau von Planänderungen

Change Plan API

Schnellstartbeispiele

Verwaltung von Addons

Proratisierungsmodi

`prorated_immediately`

`full_immediately`

`difference_immediately`

Beispielszenarien

Verarbeitung von Webhooks

Zu verarbeitende Ereignistypen

Überprüfen Sie Signaturen und verarbeiten Sie Absichten

Best Practices

Strategie zur Planänderung

Webhook-Implementierung

Benutzererfahrung

Häufige Probleme und Lösungen

Testen Ihrer Implementierung

Fehlerbehandlung

HTTP-Statuscodes

Fehlerantwortformat

Nächste Schritte