Documentation sur les mises à jour en suspens

Attributs pris en charge

Seuls certains attributs peuvent être utilisés pour créer une mise à jour en suspens. Soit ces attributs contrôlent le comportement de prorata, soit ils génèrent de nouvelles factures.

Les attributs pris en charge pour l’endpoint mettre à jour l’abonnement sont :

• expand
• payment_behavior
• proration_behavior
• proration_date
• billing_cycle_anchor
• items
  • price
  • quantity
• trial_end
• trial_from_plan
• add_invoice_items

Les attributs pris en charge pour les endpoints créer un poste d’abonnement et mettre à jour un poste d’abonnement sont :

• expand
• payment_behavior
• proration_behavior
• proration_date
• price
• quantity

Cycle de vie des mises à jour en suspens

Si le paiement est effectué avec succès, la facture est actualisée en paid et les modifications sont immédiatement appliquées à l’abonnement. Si le paiement échoue, les valeurs mises à jour sont ajoutées au hachage pending_update sur l’objet Subscription. La latest_invoice pour l’abonnement fait référence à une facture non payée avec un état open. Le cycle de l’abonnement continuera comme si aucune demande de mise à jour n’avait été effectuée.

Il existe deux moyens de gérer les échecs de paiement. Ils concernent les refus de paiement et l’authentification du client. Suite à la résolution de ces problèmes, une nouvelle tentative de paiement est effectuée. Si le paiement est validé, les modifications sont appliquées et le hachage pending_update est effacé. Si le paiement échoue une nouvelle fois, le hachage pending_update reste sur l’abonnement avec la date d’expiration originale et aucune modification n’est appliquée.

Si vous annulez une mise à jour en suspens, le hachage pending_update est effacé et les changements associés sont abandonnés.

Expiration

Si aucune action n’est entreprise suite à un échec de mise à jour, la facture n’est pas valable et la mise à jour en suspens est rejetée dès que la date de expired_at sur la pending_update est passée. Cette date est soit définie par la date de la fin de l’essai, soit par la fin de la période actuelle, selon l’occurrence qui se produit en premier. Si ces deux dates sont supérieures à 23 heures à partir de la date de la réalisation de la mise à jour, la date de expired_at est calculée 23 heures après la réalisation de l’appel de mise à jour.

Stripe annule aussi automatiquement la facture et supprime la mise à jour en suspens si l’un des événements suivants se produit :

• L’abonnement atteint un seuil de facturation.
• Une planification d’abonnement associée à l’abonnement migre vers une nouvelle phase.

Événements de mise à jour en suspens

Vous pouvez utiliser des webhooks pour écouter les événements suivants en relation avec les mises à jour en suspens :

Mises à jour en suspens et planification d’abonnement

Les mises à jour en suspens et la planification de l’abonnement peuvent toutes les deux être utilisées pour gérer les abonnements. Si une mise à jour en suspens existe lors de phases de modifications de la planification, la mise à jour en suspens est abandonnée et la facture associée est annulée avant que la transition de la phase ne se produise. Le cas échéant, vous pouvez effectuer une nouvelle tentative de demande de mise à jour après la transition de la phase.

Enregistrements d’utilisation

Si un abonnement comprend des articles facturés à la consommation, Stripe facture tout enregistrement d’utilisation sur la facture de mise à jour en attente. Cependant, si le paiement pour la mise à jour en attente n’a pas lieu avant la date d’expiration, Stripe ignore ces enregistrements d’utilisation, ce qui empêche de les comptabiliser sur la facture suivante. De plus, si la mise à jour en attente supprime un tarif calculé à la consommation, Stripe ignore toute utilisation signalée entre la création de la mise à jour en attente et le paiement de la facture qui en résulte, et l’exclut de toutes les factures.