Changer de plan
Modifier le plan d’un abonnement existant, en permettant aussi bien les montées que les descentes vers différents paliers tarifaires.
Remarque: Par défaut, cette opération utilise les informations de paiement existantes du client. Définissez collect_via_payment_link pour facturer via une page de paiement hébergée à la place.
Modifications de plan programmées
Utilisez le paramètreeffective_at pour contrôler quand le changement de plan prend effet :
Gestion des échecs de paiement
Utilisez le paramètreon_payment_failure pour contrôler ce qui se passe en cas d’échec du paiement du changement de plan :
on_payment_failure n’est pas spécifié, le comportement par défaut dépend du paramètre de niveau entreprise configuré dans le tableau de bord.Collecte via un lien de paiement
Définissezcollect_via_payment_link sur true pour rediriger le client vers une page de paiement hébergée au lieu de facturer son moyen de paiement enregistré. La réponse inclut alors payment_id, payment_link, client_secret et expires_on — redirigez le client vers payment_link pour finaliser le paiement.
Cela nécessite les éléments suivants :
422. Tant que le lien n’est pas payé, l’abonnement reste sur son plan actuel et une nouvelle requête change-plan renvoie 409, sauf si vous définissez cancel_older_payment_link.
Redirection après le paiement
Définissezreturn_url pour renvoyer le client vers votre site après le paiement du lien. La redirection ajoute subscription_id, payment_id et status en tant que paramètres de requête.
statuscorrespond au statut du paiement du changement de plan, et non au statut de l’abonnement.- Lorsque le paiement échoue, l’abonnement reste actif sur son plan actuel. Pour réessayer, appelez à nouveau
change-planafin d’obtenir un nouveau lien. - Le nouveau plan peut s’appliquer peu après la redirection, lorsque le webhook de paiement arrive.
return_url nécessite collect_via_payment_link: true. Sans celui-ci, la requête renvoie 422.
Remplacement d’un lien de paiement en attente
Si le client quitte le checkout sans payer, définissezcancel_older_payment_link sur true dans la requête change-plan suivante. Dodo Payments annule le lien impayé, et le nouveau changement de plan remplace celui en attente. Le lien annulé n’accepte plus de paiement.
La requête est validée avant l’annulation du lien ; une requête non valide conserve donc le lien du client. Le lien est annulé uniquement si le client n’a pas commencé à payer :
change-plan émet sa propre facture. Le changement de plan remplacé et sa facture sont annulés.
Codes de réduction
Vous pouvez appliquer un ou plusieurs codes de réduction cumulés lors d’un changement de plan en transmettant le tableaudiscount_codes (20 entrées maximum, appliquées dans l’ordre du tableau). Le champ singulier discount_code est obsolète, mais reste fonctionnel pour les intégrations existantes ; il ne peut pas être combiné avec discount_codes dans la même requête.
Autorisations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Paramètres de chemin
Subscription Id
Corps
Unique identifier of the product to subscribe to
Proration Billing Mode
prorated_immediately, full_immediately, difference_immediately, do_not_bill, prorated_immediately_keep_cycle Number of units to subscribe for. Must be at least 1.
x >= 0Whether 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 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.
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.
DEPRECATED: Use discount_codes instead. Cannot be used together with discount_codes.
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.
When to apply the plan change.
immediately(default): Apply the plan change right awaynext_billing_date: Schedule the change for the next billing date
immediately, next_billing_date Metadata for the payment. If not passed, the metadata of the subscription will be taken
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.
Réponse
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.