Guide de mise à niveau et de rétrogradation d'abonnement

Référence API Changer de Plan

Accédez à la documentation API complète pour changer les plans d’abonnement et testez les demandes de changement de plan de manière interactive.

Aperçu de l'API de Changement de Plan

Prévisualisez le montant exact de la charge avant de vous engager dans un changement de plan.

Guide d'Intégration d'Abonnement

Apprenez à créer et à gérer des abonnements depuis le début avec notre guide d’intégration complet.

Qu’est-ce qu’une mise à niveau ou une rétrogradation d’abonnement ?

Changer de plan vous permet de déplacer un client entre des niveaux ou des quantités d’abonnement. Utilisez-le pour :

Aligner les prix avec l’utilisation ou les fonctionnalités
Passer d’un abonnement mensuel à annuel (ou vice versa)
Ajuster la quantité pour des produits basés sur des sièges

Les changements de plan peuvent déclencher une charge immédiate en fonction du mode de proratisation que vous choisissez.

Quand utiliser les changements de plan

Mise à niveau lorsque le client a besoin de plus de fonctionnalités, d’utilisation ou de sièges
Rétrogradation lorsque l’utilisation diminue
Migrer des utilisateurs vers un nouveau produit ou prix sans annuler leur abonnement

Prérequis

Avant de mettre en œuvre des changements de plan d’abonnement, assurez-vous d’avoir :

Un compte marchand Dodo Payments avec des produits d’abonnement actifs
Des identifiants API (clé API et clé secrète de webhook) depuis le tableau de bord
Un abonnement actif existant à modifier
Un point de terminaison de webhook configuré pour gérer les événements d’abonnement

Pour des instructions de configuration détaillées, consultez notre Guide d’Intégration.

Guide de Mise en Œuvre Étape par Étape

Suivez ce guide complet pour mettre en œuvre des changements de plan d’abonnement dans votre application :

Comprendre les Exigences de Changement de Plan

Avant de mettre en œuvre, déterminez :

Quels produits d’abonnement peuvent être changés pour lesquels
Quel mode de proratisation convient à votre modèle commercial
Comment gérer les échecs de changement de plan de manière élégante
Quels événements de webhook suivre pour la gestion des états

Testez les changements de plan de manière approfondie en mode test avant de les mettre en production.

Choisissez Votre Stratégie de Proratisation

Sélectionnez l’approche de facturation qui correspond à vos besoins commerciaux :

prorated_immediately
difference_immediately
full_immediately

Idéal pour : les applications SaaS souhaitant facturer équitablement pour le temps non utilisé

Calcule le montant proratisé exact basé sur le temps de cycle restant
Facture un montant proratisé basé sur le temps non utilisé restant dans le cycle
Fournit une facturation transparente aux clients

Implémentez l'API Changer de Plan

Utilisez l’API Changer de Plan pour modifier les détails de l’abonnement :

subscription_id

string

required

L’ID de l’abonnement actif à modifier.

product_id

string

required

Le nouvel ID de produit pour changer l’abonnement.

quantity

integer

default:"1"

Nombre d’unités pour le nouveau plan (pour les produits basés sur des sièges).

proration_billing_mode

string

required

Comment gérer la facturation immédiate : prorated_immediately, full_immediately, ou difference_immediately.

addons

array

Addons optionnels pour le nouveau plan. Laisser ceci vide supprime tous les addons existants.

Gérer les Événements de Webhook

Configurez la gestion des webhooks pour suivre les résultats des changements de plan :

subscription.active : Changement de plan réussi, abonnement mis à jour
subscription.plan_changed : Plan d’abonnement changé (mise à niveau/rétrogradation/mise à jour d’addon)
subscription.on_hold : Échec de la charge de changement de plan, abonnement suspendu
payment.succeeded : Charge immédiate pour le changement de plan réussie
payment.failed : Échec de la charge immédiate

Vérifiez toujours les signatures des webhooks et mettez en œuvre un traitement d’événements idempotent.

Mettez à Jour l'État de Votre Application

En fonction des événements de webhook, mettez à jour votre application :

Accorder/révoquer des fonctionnalités en fonction du nouveau plan
Mettre à jour le tableau de bord client avec les nouveaux détails du plan
Envoyer des e-mails de confirmation concernant les changements de plan
Enregistrer les changements de facturation à des fins d’audit

Tester et Surveiller

Testez soigneusement votre mise en œuvre :

Testez tous les modes de proratisation avec différents scénarios
Vérifiez que la gestion des webhooks fonctionne correctement
Surveillez les taux de réussite des changements de plan
Configurez des alertes pour les échecs de changement de plan

Votre mise en œuvre de changement de plan d’abonnement est maintenant prête pour une utilisation en production.

Prévisualiser les Changements de Plan

Avant de vous engager dans un changement de plan, utilisez l’API de Prévisualisation pour montrer aux clients exactement ce qu’ils seront facturés :

SDK Node.js
SDK Python

const preview = await client.subscriptions.previewChangePlan('sub_123', {
  product_id: 'prod_pro',
  quantity: 1,
  proration_billing_mode: 'prorated_immediately'
});

// Show customer the charge before confirming
console.log('Immediate charge:', preview.immediate_charge.summary);
console.log('New plan details:', preview.new_plan);

preview = client.subscriptions.preview_change_plan(
    subscription_id="sub_123",
    product_id="prod_pro",
    quantity=1,
    proration_billing_mode="prorated_immediately"
)

# Show customer the charge before confirming
print("Immediate charge:", preview.immediate_charge.summary)
print("New plan details:", preview.new_plan)

Utilisez l’API de prévisualisation pour créer des dialogues de confirmation qui montrent aux clients le montant exact qu’ils seront facturés avant qu’ils ne confirment un changement de plan.

API Changer de Plan

Utilisez l’API Changer de Plan pour modifier le produit, la quantité et le comportement de proratisation pour un abonnement actif.

Exemples de démarrage rapide

SDK Node.js
SDK Python
SDK Go
HTTP

import DodoPayments from 'dodopayments';

const client = new DodoPayments({
  bearerToken: process.env.DODO_PAYMENTS_API_KEY,
  environment: 'test_mode', // defaults to 'live_mode'
});

async function changePlan() {
  const result = await client.subscriptions.changePlan('sub_123', {
    product_id: 'prod_new',
    quantity: 3,
    proration_billing_mode: 'prorated_immediately',
  });
  console.log(result.status, result.invoice_id, result.payment_id);
}

changePlan();

import os
from dodopayments import DodoPayments

client = DodoPayments(
    bearer_token=os.environ.get("DODO_PAYMENTS_API_KEY"),
    environment="test_mode",  # defaults to "live_mode"
)

result = client.subscriptions.change_plan(
    subscription_id="sub_123",
    product_id="prod_new",
    quantity=3,
    proration_billing_mode="prorated_immediately",
)
print(result.status, result.get("invoice_id"), result.get("payment_id"))

package main

import (
  "context"
  "fmt"
  "github.com/dodopayments/dodopayments-go"
  "github.com/dodopayments/dodopayments-go/option"
)

func main() {
  client := dodopayments.NewClient(option.WithBearerToken("YOUR_TOKEN"))
  res, err := client.Subscriptions.ChangePlan(context.TODO(), dodopayments.SubscriptionChangePlanParams{
    SubscriptionID: dodopayments.F("sub_123"),
    ProductID:             dodopayments.F("prod_new"),
    Quantity:              dodopayments.F(int64(3)),
    ProrationBillingMode:  dodopayments.F(dodopayments.SubscriptionChangePlanParamsProrationBillingModeProratedImmediately),
  })
  if err != nil { panic(err) }
  fmt.Println(res.Status, res.InvoiceID, res.PaymentID)
}

curl -X POST "$DODO_API_BASE/subscriptions/sub_123/change-plan" \
  -H "Authorization: Bearer $DODO_PAYMENTS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "product_id": "prod_new",
    "quantity": 3,
    "proration_billing_mode": "prorated_immediately"
  }'

Success

{
  "status": "processing",
  "subscription_id": "sub_123",
  "invoice_id": "inv_789",
  "payment_id": "pay_456",
  "proration_billing_mode": "prorated_immediately"
}

Des champs comme invoice_id et payment_id ne sont retournés que lorsqu’une charge immédiate et/ou une facture est créée lors du changement de plan. Comptez toujours sur les événements de webhook (par exemple, payment.succeeded, subscription.plan_changed) pour confirmer les résultats.

Si la charge immédiate échoue, l’abonnement peut passer à subscription.on_hold jusqu’à ce que le paiement réussisse.

Gestion des Addons

Lors du changement de plans d’abonnement, vous pouvez également modifier les addons :

// Add addons to the new plan
await client.subscriptions.changePlan('sub_123', {
  product_id: 'prod_new',
  quantity: 1,
  proration_billing_mode: 'difference_immediately',
  addons: [
    { addon_id: 'addon_123', quantity: 2 }
  ]
});

// Remove all existing addons
await client.subscriptions.changePlan('sub_123', {
  product_id: 'prod_new',
  quantity: 1,
  proration_billing_mode: 'difference_immediately',
  addons: [] // Empty array removes all existing addons
});

Les addons sont inclus dans le calcul de proratisation et seront facturés selon le mode de proratisation sélectionné.

Modes de Proratisation

Choisissez comment facturer le client lors du changement de plans :

`prorated_immediately`

Facture pour la différence partielle dans le cycle actuel
Si en période d’essai, facture immédiatement et passe au nouveau plan maintenant
Rétrogradation : peut générer un crédit proratisé appliqué aux renouvellements futurs

`full_immediately`

Facture le montant total du nouveau plan immédiatement
Ignore le temps restant de l’ancien plan

Les crédits créés par les rétrogradations utilisant difference_immediately sont spécifiques à l’abonnement et distincts des Crédits Clients. Ils s’appliquent automatiquement aux renouvellements futurs du même abonnement et ne sont pas transférables entre abonnements.

`difference_immediately`

Mise à niveau : facturer immédiatement la différence de prix entre les anciens et nouveaux plans
Rétrogradation : ajouter la valeur restante comme crédit interne à l’abonnement et l’appliquer automatiquement aux renouvellements

Scénarios d’exemple

Mise à niveau : Basique (30 $) → Pro (80 $) avec difference_immediately

await client.subscriptions.changePlan('sub_123', {
  product_id: 'prod_pro',
  quantity: 1,
  proration_billing_mode: 'difference_immediately'
})
// Immediate charge: $50

Rétrogradation : Plus (50 $) → Starter (20 $) avec difference_immediately

await client.subscriptions.changePlan('sub_123', {
  product_id: 'prod_starter',
  quantity: 1,
  proration_billing_mode: 'difference_immediately'
})
// Credit added: $30 (auto-applied to future renewals for this subscription)

Mise à niveau en milieu de cycle avec prorated_immediately

await client.subscriptions.changePlan('sub_123', {
  product_id: 'prod_new',
  quantity: 1,
  proration_billing_mode: 'prorated_immediately'
})
// Immediate prorated charge based on remaining days in cycle

Réinitialiser la facturation avec full_immediately

await client.subscriptions.changePlan('sub_123', {
  product_id: 'prod_new',
  quantity: 1,
  proration_billing_mode: 'full_immediately'
})
// Immediate full charge for new plan; no credits calculated

Choisissez prorated_immediately pour une comptabilité équitable ; choisissez full_immediately pour redémarrer la facturation ; utilisez difference_immediately pour des mises à niveau simples et un crédit automatique sur les rétrogradations.

Gestion des webhooks

Suivez l’état de l’abonnement via des webhooks pour confirmer les changements de plan et les paiements.

Types d’événements à gérer

subscription.active : abonnement activé
subscription.plan_changed : plan d’abonnement changé (mise à niveau/rétrogradation/changements d’addon)
subscription.on_hold : échec de la charge, abonnement suspendu
subscription.renewed : renouvellement réussi
payment.succeeded : paiement pour le changement de plan ou le renouvellement réussi
payment.failed : échec du paiement

Nous recommandons de diriger la logique commerciale à partir des événements d’abonnement et d’utiliser les événements de paiement pour la confirmation et la réconciliation.

Vérifier les signatures et gérer les intentions

Gestionnaire de Route Next.js
Express.js

import { NextRequest, NextResponse } from 'next/server';

export async function POST(req) {
  const webhookId = req.headers.get('webhook-id');
  const webhookSignature = req.headers.get('webhook-signature');
  const webhookTimestamp = req.headers.get('webhook-timestamp');
  const secret = process.env.DODO_WEBHOOK_SECRET;

  const payload = await req.text();
  // verifySignature is a placeholder – in production, use a Standard Webhooks library
  const { valid, event } = await verifySignature(
    payload,
    { id: webhookId, signature: webhookSignature, timestamp: webhookTimestamp },
    secret
  );
  if (!valid) return NextResponse.json({ error: 'Invalid signature' }, { status: 400 });

  switch (event.type) {
    case 'subscription.active':
      // mark subscription active in your DB
      break;
    case 'subscription.plan_changed':
      // refresh entitlements and reflect the new plan in your UI
      break;
    case 'subscription.on_hold':
      // notify user to update payment method
      break;
    case 'subscription.renewed':
      // extend access window
      break;
    case 'payment.succeeded':
      // reconcile payment for plan change
      break;
    case 'payment.failed':
      // log and alert
      break;
    default:
      // ignore unknown events
      break;
  }

  return NextResponse.json({ received: true });
}

import express from 'express';

const app = express();
app.post('/webhooks/dodo', express.raw({ type: 'application/json' }), async (req, res) => {
  const webhookId = req.header('webhook-id');
  const webhookSignature = req.header('webhook-signature');
  const webhookTimestamp = req.header('webhook-timestamp');
  const secret = process.env.DODO_WEBHOOK_SECRET;
  const payload = req.body.toString('utf8');

  const { valid, event } = await verifySignature(
    payload,
    { id: webhookId, signature: webhookSignature, timestamp: webhookTimestamp },
    secret
  );
  if (!valid) return res.status(400).send('Invalid signature');

  // handle events like above
  res.json({ received: true });
});

app.listen(3000);

Pour des schémas de charge utile détaillés, consultez les charges utiles des webhooks d’abonnement et les charges utiles des webhooks de paiement.

Meilleures Pratiques

Suivez ces recommandations pour des changements de plan d’abonnement fiables :

Stratégie de Changement de Plan

Testez de manière approfondie : Testez toujours les changements de plan en mode test avant la production
Choisissez la proratisation avec soin : Sélectionnez le mode de proratisation qui correspond à votre modèle commercial
Gérez les échecs de manière élégante : Mettez en œuvre une gestion des erreurs appropriée et une logique de réessai
Surveillez les taux de réussite : Suivez les taux de réussite/échec des changements de plan et enquêtez sur les problèmes

Mise en Œuvre des Webhooks

Vérifiez les signatures : Validez toujours les signatures des webhooks pour garantir leur authenticité
Mettez en œuvre l’idempotence : Gérez les événements de webhook en double de manière élégante
Traitez de manière asynchrone : Ne bloquez pas les réponses des webhooks avec des opérations lourdes
Enregistrez tout : Maintenez des journaux détaillés pour le débogage et les audits

Expérience Utilisateur

Communiquez clairement : Informez les clients des changements de facturation et des délais
Fournissez des confirmations : Envoyez des e-mails de confirmation pour les changements de plan réussis
Gérez les cas particuliers : Prenez en compte les périodes d’essai, les proratisations et les paiements échoués
Mettez à jour l’interface utilisateur immédiatement : Réflétez les changements de plan dans l’interface de votre application

Problèmes Courants et Solutions

Résolvez les problèmes typiques rencontrés lors des changements de plan d’abonnement :

Charge créée mais abonnement non mis à jour

Symptômes : L’appel API réussit mais l’abonnement reste sur l’ancien planCauses courantes :

Traitement du webhook échoué ou retardé
État de l’application non mis à jour après la réception des webhooks
Problèmes de transaction de base de données lors de la mise à jour de l’état

Solutions :

Mettez en œuvre une gestion robuste des webhooks avec une logique de réessai
Utilisez des opérations idempotentes pour les mises à jour d’état
Ajoutez une surveillance pour détecter et alerter sur les événements de webhook manqués
Vérifiez que le point de terminaison du webhook est accessible et répond correctement

Crédits non appliqués après rétrogradation

Symptômes : Le client rétrograde mais ne voit pas de solde de créditCauses courantes :

Attentes concernant le mode de proratisation : les rétrogradations créditent la différence de prix du plan complet avec difference_immediately, tandis que prorated_immediately crée un crédit proratisé basé sur le temps restant dans le cycle
Les crédits sont spécifiques à l’abonnement et ne se transfèrent pas entre abonnements
Le solde de crédit n’est pas visible dans le tableau de bord du client

Solutions :

Utilisez difference_immediately pour les rétrogradations lorsque vous souhaitez des crédits automatiques
Expliquez aux clients que les crédits s’appliquent aux renouvellements futurs du même abonnement
Mettez en œuvre un portail client pour afficher les soldes de crédit
Vérifiez l’aperçu de la prochaine facture pour voir les crédits appliqués

Échec de la vérification de la signature du webhook

Symptômes : Événements de webhook rejetés en raison d’une signature invalideCauses courantes :

Clé secrète de webhook incorrecte
Corps de la requête brute modifié avant la vérification de la signature
Mauvais algorithme de vérification de signature

Solutions :

Vérifiez que vous utilisez le bon DODO_WEBHOOK_SECRET depuis le tableau de bord
Lisez le corps brut de la requête avant tout middleware de parsing JSON
Utilisez la bibliothèque standard de vérification des webhooks pour votre plateforme
Testez la vérification de la signature du webhook dans l’environnement de développement

Le changement de plan échoue avec une erreur 422

Symptômes : L’API retourne une erreur 422 Entité non traitableCauses courantes :

ID d’abonnement ou ID de produit invalide
Abonnement non actif
Paramètres requis manquants
Produit non disponible pour les changements de plan

Solutions :

Vérifiez que l’abonnement existe et est actif
Vérifiez que l’ID de produit est valide et disponible
Assurez-vous que tous les paramètres requis sont fournis
Consultez la documentation API pour les exigences de paramètres

Échec de la charge immédiate lors du changement de plan

Symptômes : Changement de plan initié mais la charge immédiate échoueCauses courantes :

Fonds insuffisants sur le moyen de paiement du client
Moyen de paiement expiré ou invalide
La banque a refusé la transaction
La détection de fraude a bloqué la charge

Solutions :

Gérez les événements de webhook payment.failed de manière appropriée
Informez le client de mettre à jour son moyen de paiement
Mettez en œuvre une logique de réessai pour les échecs temporaires
Envisagez de permettre des changements de plan avec des charges immédiates échouées

Abonnement en attente après le changement de plan

Symptômes : La charge de changement de plan échoue et l’abonnement passe à l’état on_holdQue se passe-t-il : Lorsque la charge de changement de plan échoue, l’abonnement est automatiquement placé dans l’état on_hold. L’abonnement ne se renouvellera pas automatiquement tant que le moyen de paiement n’est pas mis à jour.Solution : Mettez à jour le moyen de paiement pour réactiver l’abonnementPour réactiver un abonnement de l’état on_hold après un changement de plan échoué :

Mettez à jour le moyen de paiement en utilisant l’API Mettre à Jour le Moyen de Paiement
Création automatique de charge : L’API crée automatiquement une charge pour les montants dus
Génération de facture : Une facture est générée pour la charge
Traitement du paiement : Le paiement est traité en utilisant le nouveau moyen de paiement
Réactivation : Après un paiement réussi, l’abonnement est réactivé dans l’état active

// Reactivate subscription from on_hold after failed plan change
async function reactivateAfterFailedPlanChange(subscriptionId) {
  // Update payment method - automatically creates charge for remaining dues
  const response = await client.subscriptions.updatePaymentMethod(subscriptionId, {
    type: 'new',
    return_url: 'https://example.com/return'
  });
  
  if (response.payment_id) {
    console.log('Charge created for remaining dues:', response.payment_id);
    console.log('Payment link:', response.payment_link);
    
    // Redirect customer to payment_link to complete payment
    // Monitor webhooks for:
    // 1. payment.succeeded - charge succeeded
    // 2. subscription.active - subscription reactivated
  }
  
  return response;
}

// Or use existing payment method if available
async function reactivateWithExistingPaymentMethod(subscriptionId, paymentMethodId) {
  const response = await client.subscriptions.updatePaymentMethod(subscriptionId, {
    type: 'existing',
    payment_method_id: paymentMethodId
  });
  
  // Monitor webhooks for payment.succeeded and subscription.active
  return response;
}

Événements de webhook à surveiller :

subscription.on_hold : Abonnement placé en attente (reçu lorsque la charge de changement de plan échoue)
payment.succeeded : Paiement pour les montants dus réussi (après mise à jour du moyen de paiement)
subscription.active : Abonnement réactivé après un paiement réussi

Meilleures pratiques :

Informez immédiatement les clients lorsque la charge de changement de plan échoue
Fournissez des instructions claires sur la façon de mettre à jour leur moyen de paiement
Surveillez les événements de webhook pour suivre l’état de réactivation
Envisagez de mettre en œuvre une logique de réessai automatique pour les échecs de paiement temporaires

Référence API Mettre à Jour le Moyen de Paiement

Consultez la documentation API complète pour mettre à jour les moyens de paiement et réactiver les abonnements.

Tester Votre Mise en Œuvre

Suivez ces étapes pour tester soigneusement votre mise en œuvre de changement de plan d’abonnement :

Configurer l'environnement de test

Utilisez des clés API de test et des produits de test
Créez des abonnements de test avec différents types de plan
Configurez le point de terminaison de webhook de test
Mettez en place une surveillance et des journaux

Tester différents modes de proratisation

Testez prorated_immediately avec diverses positions de cycle de facturation
Testez difference_immediately pour les mises à niveau et les rétrogradations
Testez full_immediately pour réinitialiser les cycles de facturation
Vérifiez que les calculs de crédit sont corrects

Tester la gestion des webhooks

Vérifiez que tous les événements de webhook pertinents sont reçus
Testez la vérification de la signature des webhooks
Gérez les événements de webhook en double de manière élégante
Testez les scénarios d’échec de traitement des webhooks

Tester les scénarios d'erreur

Testez avec des ID d’abonnement invalides
Testez avec des moyens de paiement expirés
Testez les pannes réseau et les délais d’attente
Testez avec des fonds insuffisants

Surveiller en production

Configurez des alertes pour les échecs de changement de plan
Surveillez les temps de traitement des webhooks
Suivez les taux de réussite des changements de plan
Examinez les tickets de support client pour les problèmes de changement de plan

Gestion des Erreurs

Gérez les erreurs API courantes de manière élégante dans votre mise en œuvre :

Codes d’État HTTP

200 OK

Demande de changement de plan traitée avec succès. L’abonnement est en cours de mise à jour et le traitement du paiement a commencé.

400 Bad Request

Paramètres de requête invalides. Vérifiez que tous les champs requis sont fournis et correctement formatés.

401 Unauthorized

Clé API invalide ou manquante. Vérifiez que votre DODO_PAYMENTS_API_KEY est correct et dispose des autorisations appropriées.

404 Not Found

ID d’abonnement non trouvé ou n’appartient pas à votre compte.

422 Unprocessable Entity

L’abonnement ne peut pas être changé (par exemple, déjà annulé, produit non disponible, etc.).

500 Internal Server Error

Une erreur serveur s’est produite. Réessayez la demande après un court délai.

Format de Réponse d’Erreur

{
  "error": {
    "code": "subscription_not_found",
    "message": "The subscription with ID 'sub_123' was not found",
    "details": {
      "subscription_id": "sub_123"
    }
  }
}

Prochaines étapes

Consultez la API Changer de Plan
Explorez Crédits Clients
Mettez en œuvre des alertes pour subscription.on_hold
Consultez notre Guide d’Intégration des Webhooks

Integration Guides

Cookbooks

Guide de mise à niveau et de rétrogradation d'abonnement

Référence API Changer de Plan

Aperçu de l'API de Changement de Plan

Guide d'Intégration d'Abonnement

Qu’est-ce qu’une mise à niveau ou une rétrogradation d’abonnement ?

Quand utiliser les changements de plan

Prérequis

Guide de Mise en Œuvre Étape par Étape

Prévisualiser les Changements de Plan

API Changer de Plan

Exemples de démarrage rapide

Gestion des Addons

Modes de Proratisation

`prorated_immediately`

`full_immediately`

`difference_immediately`

Scénarios d’exemple

Gestion des webhooks

Types d’événements à gérer

Vérifier les signatures et gérer les intentions

Meilleures Pratiques

Stratégie de Changement de Plan

Mise en Œuvre des Webhooks

Expérience Utilisateur

Problèmes Courants et Solutions

Référence API Mettre à Jour le Moyen de Paiement

Tester Votre Mise en Œuvre

Gestion des Erreurs

Codes d’État HTTP

Format de Réponse d’Erreur

Prochaines étapes

Integration Guides

Cookbooks

Référence API Changer de Plan

Aperçu de l'API de Changement de Plan

Guide d'Intégration d'Abonnement

​Qu’est-ce qu’une mise à niveau ou une rétrogradation d’abonnement ?

​Quand utiliser les changements de plan

​Prérequis

​Guide de Mise en Œuvre Étape par Étape

​Prévisualiser les Changements de Plan

​API Changer de Plan

​Exemples de démarrage rapide

​Gestion des Addons

​Modes de Proratisation

​prorated_immediately

​full_immediately

​difference_immediately

​Scénarios d’exemple

​Gestion des webhooks

​Types d’événements à gérer

​Vérifier les signatures et gérer les intentions

​Meilleures Pratiques

​Stratégie de Changement de Plan

​Mise en Œuvre des Webhooks

​Expérience Utilisateur

​Problèmes Courants et Solutions

Référence API Mettre à Jour le Moyen de Paiement

​Tester Votre Mise en Œuvre

​Gestion des Erreurs

​Codes d’État HTTP

​Format de Réponse d’Erreur

​Prochaines étapes

Qu’est-ce qu’une mise à niveau ou une rétrogradation d’abonnement ?

Quand utiliser les changements de plan

Prérequis

Guide de Mise en Œuvre Étape par Étape

Prévisualiser les Changements de Plan

API Changer de Plan

Exemples de démarrage rapide

Gestion des Addons

Modes de Proratisation

`prorated_immediately`

`full_immediately`

`difference_immediately`

Scénarios d’exemple

Gestion des webhooks

Types d’événements à gérer

Vérifier les signatures et gérer les intentions

Meilleures Pratiques

Stratégie de Changement de Plan

Mise en Œuvre des Webhooks

Expérience Utilisateur

Problèmes Courants et Solutions

Tester Votre Mise en Œuvre

Gestion des Erreurs

Codes d’État HTTP

Format de Réponse d’Erreur

Prochaines étapes