Zum Hauptinhalt springen
POST
JavaScript

Geplante Tarifänderungen

Verwenden Sie den effective_at-Parameter, um zu steuern, wann die Tarifänderung wirksam wird:
Geplante Tarifänderungen sind ideal für Downgrades – Kunden behalten ihre aktuellen Tarifvorteile bis zum Ende des Abrechnungszeitraums und wechseln dann automatisch zum neuen Tarif.
Um eine geplante Tarifänderung zu stornieren, bevor sie wirksam wird, verwenden Sie den Geplante Tarifänderung stornieren Endpunkt.

Zahlungsfehlerbehandlung

Verwenden Sie den on_payment_failure-Parameter, um zu steuern, was passiert, wenn die Zahlung für die Tarifänderung fehlschlägt:
Falls on_payment_failure nicht angegeben ist, erfolgt die Standardverhalten gemäß Ihrer Geschäftseinstellung im Dashboard.
Setzen Sie collect_via_payment_link auf true, um den Kunden stattdessen zu einer gehosteten Checkout-Seite weiterzuleiten, anstatt die gespeicherte Zahlungsmethode zu belasten. Die Antwort enthält dann payment_id, payment_link, client_secret und expires_on — leiten Sie den Kunden zu payment_link weiter, um die Zahlung abzuschließen. Dies erfordert: Ein Request, der diese Bedingungen nicht erfüllt, gibt 422 zurück. Solange der Link unbezahlt ist, bleibt das Abonnement auf seinem aktuellen Plan, und ein weiterer change-plan-Request gibt 409 zurück, sofern Sie nicht cancel_older_payment_link setzen.

Weiterleitung nach der Zahlung

Setzen Sie return_url, um den Kunden nach der Zahlung des Links zu Ihrer Website zurückzuleiten. Die Weiterleitung fügt subscription_id, payment_id und status als Query-Parameter hinzu.
  • status ist der Status der Zahlung für die Planänderung, nicht der Status des Abonnements.
  • Wenn die Zahlung fehlschlägt, bleibt das Abonnement auf seinem aktuellen Plan aktiv. Um es erneut zu versuchen, rufen Sie change-plan erneut auf, um einen neuen Link zu erhalten.
  • Der neue Plan kann kurz nach der Weiterleitung angewendet werden, sobald der Payment-Webhook eintrifft.
return_url benötigt collect_via_payment_link: true. Ohne dieses Feld gibt der Request 422 zurück. Wenn der Kunde den Checkout verlässt, ohne zu bezahlen, setzen Sie cancel_older_payment_link beim nächsten change-plan-Request auf true. Dodo Payments storniert den unbezahlten Link, und die neue Planänderung ersetzt die ausstehende. Der stornierte Link akzeptiert keine Zahlungen mehr. Der Request wird validiert, bevor der Link storniert wird. Dadurch bleibt der Link des Kunden bei einem ungültigen Request erhalten. Der Link wird nur storniert, wenn der Kunde noch nicht mit der Zahlung begonnen hat: Jeder change-plan-Request erstellt eine eigene Rechnung. Die ersetzte Planänderung und ihre Rechnung werden storniert.
Im Leitfaden zu Upgrades und Downgrades von Abonnements finden Sie den vollständigen Ablauf, einschließlich abgelehnter Zahlungen, des Ersetzens eines ausstehenden Links und der Folgen des Ablaufs eines Links.

Rabattcodes

Sie können beim Ändern von Plänen einen oder mehrere gestapelte Rabattcodes anwenden, indem Sie das Array discount_codes übergeben (maximal 20 Einträge, die in Array-Reihenfolge angewendet werden). Das einzelne Feld discount_code ist veraltet, funktioniert aber weiterhin für bestehende Integrationen. Es kann im selben Request nicht mit discount_codes kombiniert werden.
Verwenden Sie Rabattcodes bei Planänderungen, um bei Upgrades Aktionspreise anzubieten, oder übergeben Sie Codes, wenn Sie Kunden zu einer neuen Planstufe migrieren.
Verwenden Sie prevent_change für kritische Upgrades, bei denen Sie die Zahlung vor der Freigabe des Zugriffs auf Premiumfunktionen sicherstellen möchten.

Autorisierungen

Authorization
string
header
erforderlich

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Pfadparameter

subscription_id
string
erforderlich

Subscription Id

Body

application/json
product_id
string
erforderlich

Unique identifier of the product to subscribe to

proration_billing_mode
enum<string>
erforderlich

Proration Billing Mode

Verfügbare Optionen:
prorated_immediately,
full_immediately,
difference_immediately,
do_not_bill,
prorated_immediately_keep_cycle
quantity
integer<int32>
erforderlich

Number of units to subscribe for. Must be at least 1.

Erforderlicher Bereich: x >= 0
adaptive_currency_fees_inclusive
boolean | null

Whether adaptive currency fees should be included in the price (true) or added on top (false). If not specified, uses the subscription's stored setting.

addons
Attach Addon Request · object[] | null

Addons for the new plan. Note : Leaving this empty would remove any existing addons

Cancel the payment link of a pending plan change, so that this change can replace it.

The link is cancelled only if the customer has not started to pay. A paid or in-progress payment gives a 409. A failed cancel gives a 503, and a retry is safe.

The request is validated before the cancel. A later failure, for example an amount below the minimum, leaves the subscription on its current plan with no open link. A retry is safe.

The preview route shares this request body and ignores this field.

cancel_scheduled_change_plan
boolean

Replace a scheduled plan change with this one.

The scheduled change is cancelled by the transaction that applies this change. A change that never applies leaves the schedule in place.

effective_at: next_billing_date is allowed. The new schedule then replaces the old one in the request transaction.

A pending plan change still gets a 409. This field does not affect it.

The preview route shares this request body, so a preview that sets this field also passes the scheduled-change 409.

Collect the plan-change amount with a payment link. The customer then pays on a checkout page.

The business needs the allow_plan_change_via_payment_link capability. The request needs effective_at: immediately. The request also needs on_payment_failure: prevent_change.

The preview route shares this request body and ignores this field.

discount_code
string | null
veraltet

DEPRECATED: Use discount_codes instead. Cannot be used together with discount_codes.

discount_codes
string[] | null

Stacked discount codes to apply to the new plan. Max 20. Cannot be used together with discount_code. If provided, replaces any existing discount codes. Empty array removes all discounts. If not provided (None), existing discounts with preserve_on_plan_change=true are preserved.

effective_at
enum<string>

When to apply the plan change.

  • immediately (default): Apply the plan change right away
  • next_billing_date: Schedule the change for the next billing date
Verfügbare Optionen:
immediately,
next_billing_date
metadata
null | Metadata · object

Metadata for the payment. If not passed, the metadata of the subscription will be taken

on_payment_failure
null | enum<string>

Controls behavior when the plan change payment fails.

  • prevent_change: Keep subscription on current plan until payment succeeds
  • apply_change (default): Apply plan change immediately regardless of payment outcome

With effective_at: next_billing_date, the plan change payment replaces the renewal payment. If that payment fails with prevent_change, the plan change is cancelled. The subscription then renews on the current plan, with the usual payment retries.

If not specified, uses the business-level default setting.

Verfügbare Optionen:
prevent_change,
apply_change
return_url
string | null

The URL that receives the customer after they pay the payment link. Needs collect_via_payment_link: true. Without it, the request gets a 422. A change that collects no money issues no link and does not use the URL. The preview route validates this field but does not use it.

The redirect adds subscription_id, payment_id and status. The status value is the status of the plan-change payment. It is not the status of the subscription. When that payment fails, the subscription stays active on its current plan. To try again, call this endpoint again to get a new link. The new plan can apply after the redirect, when the payment webhook arrives.

Antwort

Subscription plan changed. A link request can return checkout details. A pending plan change applies after payment succeeds.

Handles for a hosted checkout page that settles a plan change.

The four fields repeat UpdatePaymentMethodResponse and a subset of CreateSubscriptionResponse. A shared type would rename the generated SDK types for all three routes, so each route keeps its own.

client_secret
string | null

Client secret for an embedded checkout.

expires_on
string<date-time> | null

When the link stops working.

payment_id
string | null

Id of the payment that settles the plan change.

Checkout page URL. Give this to the customer.

Zuletzt geändert am 8. Oktober 2026