Skip to main content
POST
JavaScript

Modifications de plan programmées

Utilisez le paramètre effective_at pour contrôler quand le changement de plan prend effet :
Les modifications de plan programmées sont idéales pour les déclassements — les clients conservent les avantages de leur plan actuel jusqu’à la fin de la période de facturation, puis passent automatiquement au nouveau plan.
Pour annuler une modification de plan programmée avant qu’elle ne prenne effet, utilisez le point de terminaison Annuler la modification de plan programmée.

Gestion des échecs de paiement

Utilisez le paramètre on_payment_failure pour contrôler ce qui se passe en cas d’échec du paiement du changement de plan :
Si 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éfinissez collect_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 : Une requête qui ne respecte pas ces conditions renvoie 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.
Consultez le guide des montées et descentes de niveau d’abonnement pour connaître le flux complet, notamment la façon dont un client réessaie un paiement refusé et ce qui se passe si le lien expire.

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 tableau discount_codes (20 entrées maximum, appliquées dans l’ordre du tableau). Le champ singulier discount_code est obsolète, mais continue de fonctionner pour les intégrations existantes ; il ne peut pas être combiné avec discount_codes dans la même requête.
Utilisez des codes de réduction lors des changements de plan pour proposer des tarifs promotionnels sur les montées de niveau, ou transmettez des codes lors de la migration de clients vers un nouveau palier de plan.
Utilisez prevent_change pour les montées de niveau critiques lorsque vous souhaitez garantir le paiement avant d’accorder l’accès aux fonctionnalités premium.

Autorisations

Authorization
string
header
requis

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

Paramètres de chemin

subscription_id
string
requis

Subscription Id

Corps

application/json
product_id
string
requis

Unique identifier of the product to subscribe to

proration_billing_mode
enum<string>
requis

Proration Billing Mode

Options disponibles:
prorated_immediately,
full_immediately,
difference_immediately,
do_not_bill
quantity
integer<int32>
requis

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

Plage requise: 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_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
obsolète

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
Options disponibles:
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

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

Options disponibles:
prevent_change,
apply_change

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.

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.

Dernière modification le 26 août 2026