Comprendre le champ end_date d'un abonnement

Box et PrestaShop

Cette page vaut pour les boutiques box comme pour les boutiques PrestaShop.

Astuce

Le champ end_date est un concept clé pour comprendre l’état réel d’un abonnement. Ce guide explique son fonctionnement et ses cas d’usage pour les intégrateurs PrestaShop.

Prérequis

• Connaissance du cycle de vie d’un abonnement Ciklik
• Accès à l’API Ciklik
• Familiarité avec les concepts de rebill

Voir aussi : Gestion des abonnements (documentation plateforme)

Définition

Le champ end_date représente la date d’expiration de l’abonnement suite au dernier paiement accepté.

Point important

Ce champ est renseigné même pour les abonnements actifs. Il ne signifie pas que l’abonnement est terminé, mais jusqu’à quelle date il est “payé”.

Fonctionnement du cycle

Prenons l’exemple d’un abonnement mensuel :

Souscription : 15 janvier
├── Paiement accepté le 15 janvier
├── end_date = 14 février (veille du prochain rebill)
├── Prochain rebill prévu : 15 février
│
Rebill du 15 février
├── Si paiement accepté → end_date = 14 mars
├── Si paiement refusé → end_date reste au 14 février

Règle de mise à jour

• Paiement accepté : end_date est mise à jour à la veille du prochain rebill prévu
• Paiement refusé : end_date ne bouge pas

Statut actif vs end_date passée

Un abonnement peut être :

• Statut actif + end_date dans le futur = Abonnement en cours, à jour de paiement
• Statut actif + end_date dans le passé = Abonnement “zombie” - actif mais jamais renouvelé avec succès

Les abonnements “zombies”

Ce sont des abonnements qui :

• Ont le statut active dans Ciklik
• Mais dont la end_date est dans le passé (parfois depuis plusieurs mois)

Causes possibles :

• Échecs de paiement répétés (carte expirée, fonds insuffisants)
• Erreurs de stock empêchant le renouvellement
• Problèmes techniques (site PrestaShop inaccessible)

Cas d’usage pour le filtrage API

Identifier les abonnements “bloqués”

Pour trouver les abonnements actifs qui n’ont pas été renouvelés depuis longtemps :

GET /api/subscriptions?filter[activated]=1&filter[end_date_before]=2025-01-01

Cela retourne les abonnements marqués comme actifs mais dont la dernière facturation réussie remonte à avant janvier 2025.

Audit mensuel des abonnements

Pour identifier les abonnements nécessitant une attention :

# Abonnements actifs avec end_date dépassée depuis plus de 30 jours
GET /api/subscriptions?filter[activated]=1&filter[end_date_before]=2026-01-04

Attention à l’interprétation

Une end_date passée ne signifie pas nécessairement un problème de paiement. Cela peut être :

• Une rupture de stock côté PrestaShop (voir Comprendre les erreurs de renouvellement)
• Une indisponibilité temporaire du site PrestaShop
• Un problème de configuration produit

Lien avec les groupes clients PrestaShop

Le champ end_date est particulièrement utile pour les intégrateurs qui synchronisent l’état des abonnements Ciklik avec des groupes clients PrestaShop.

Scénario typique

Vous avez un groupe client “Abonnés Premium” dans PrestaShop qui donne accès à des prix réduits ou des fonctionnalités exclusives.

Logique recommandée :

Si abonnement.status == "active" ET abonnement.end_date >= aujourd'hui
    → Client reste dans le groupe "Abonnés Premium"

Si abonnement.status == "active" ET abonnement.end_date < aujourd'hui - 30 jours
    → Considérer le retrait du groupe (abonnement probablement en difficulté)

Si abonnement.status == "inactive"
    → Retirer du groupe "Abonnés Premium"

Voir aussi : Gérer ses abonnés dans un groupe client PrestaShop

Bonne pratique

Pour automatiser cette synchronisation, utilisez les webhooks Ciklik, notamment l’événement updated_subscription, qui peuvent notifier votre PrestaShop lors des changements d’état d’abonnement.

Différence avec next_billing

Champ	Signification
end_date	Jusqu’à quelle date l’abonnement est payé
next_billing	Date du prochain renouvellement de l’abonnement

Exemple :

• end_date = 14 février (dernier paiement couvrait jusqu’à cette date)
• next_billing = 15 février (prochain prélèvement prévu)

Si le paiement du 15 février échoue :

• end_date reste au 14 février
• next_billing ne bouge pas pendant les nouvelles tentatives : elles sont portées par la commande en attente, dont le champ next_try donne la date de la prochaine tentative (par exemple le 18 février, selon le réglage Relance de paiement : jours entre deux tentatives de votre site)
• si toutes les tentatives échouent, la commande est clôturée en échec et next_billing passe une période après la date de clôture (le 1er avril pour un abonnement mensuel clôturé le 1er mars)

Quand c’est votre boutique qui bloque le renouvellement (déclinaison supprimée, boutique injoignable), next_billing est décalé d’un jour à chaque blocage.

FAQ

Q : Un abonnement avec end_date passée va-t-il continuer à essayer de se renouveler ?

Oui, tant que l’abonnement a le statut active, les tentatives de renouvellement continueront selon le scénario de rebill configuré.

Q : Comment forcer la mise à jour de end_date sans paiement ?

Ce n’est pas possible via l’interface standard. Le champ end_date est uniquement mis à jour lors d’un paiement réussi. Pour des cas exceptionnels, contactez le support Ciklik.

Q : Si je résilie puis réactive un abonnement, que devient end_date ?

• Si réactivation pendant la période payée : end_date ne change pas
• Si réactivation après end_date : un paiement est déclenché immédiatement, et end_date est mise à jour si le paiement réussit

Voir : Résilier et réactiver un abonnement

Voir aussi

Résilier et réactiver un abonnement

Gérer les commandes liées aux abonnements

Gérer ses abonnés dans un groupe client PrestaShop

Événements : abonnements