Ändra plan
Ändra planen för en befintlig prenumeration och möjliggör både uppgraderingar och nedgraderingar till andra prisnivåer.
Obs: Som standard används kundens befintliga betalningsuppgifter. Ange collect_via_payment_link för att ta betalt via en hosted checkout-sida i stället.
Schemalagda ändringar av plan
Använd parameterneffective_at för att kontrollera när planändringen träder i kraft:
Hantering av betalningsfel
Använd parameternon_payment_failure för att kontrollera vad som händer när betalningen för planändringen misslyckas:
on_payment_failure inte anges, är beteendet förvalt till din affärsnivåinställning som konfigureras i instrumentpanelen.Insamling via betalningslänk
Angecollect_via_payment_link till true för att skicka kunden till en hosted checkout-sida i stället för att debitera den sparade betalningsmetoden. Svaret innehåller då payment_id, payment_link, client_secret och expires_on — omdirigera kunden till payment_link för att slutföra betalningen.
Detta kräver:
422. Medan länken är obetald ligger prenumerationen kvar på sin nuvarande plan, och en ytterligare begäran med change-plan returnerar 409.
Rabattkoder
Du kan använda en eller flera staplade rabattkoder när du ändrar planer genom att skicka arrayendiscount_codes (högst 20 poster, tillämpas i arrayens ordning). Det singulära fältet discount_code är föråldrat men fungerar fortfarande för befintliga integrationer; det kan inte kombineras med discount_codes i samma begäran.
Auktoriseringar
Send your API key as a bearer token: Authorization: Bearer <api_key>. A test mode key starts with dodo_test_, for example dodo_test_AbCd1234EfGh5678.<secret>. A live mode key starts with dodo_live_. Use a test mode key on test.dodopayments.com and a live mode key on live.dodopayments.com. Keys from before these tags have no tag and operate as before.
Kropp
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.
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.
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.
Controls behavior when the plan change payment fails.
prevent_change: Keep subscription on current plan until payment succeedsapply_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.
prevent_change, apply_change 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.
Svar
Subscription plan changed. A link request can return checkout details. A pending plan change applies after payment succeeds. For an invoice-led subscription, an invoice bills the change (invoice_id), or the change is credited.
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.