Pourquoi et comment nous utilisons Chargebee

Chargebee : une plateforme en SaaS pour vendre des abonnements et gérer la facturation

Nous utilisons depuis 2020 ce service de gestion d'abonnements et de facturation, que nous avons découvert dans le cadre d'un projet de monétisation des contenus pour un de nos clients dans le secteur de la presse.

À l'occasion de la récente publication sur notre Github de 2 packages PHP open-source pour Chargebee (chargebee-php-sdk et chargebee-php-sdk-wp), nous revenons sur pourquoi et comment nous utilisons cette plateforme SaaS.

Les solutions e-commerces traditionnelles à bout de souffle

Nous développons depuis des années des applications e-commerce, qui incluent souvent des fonctionnalités d'abonnements payants. Par le passé, nous avons testé et utilisé de nombreuses solutions différentes, qu'il s'agisse de solutions du marché (WooCommerce, Magento, Prestashop ...) ou d'applications sur mesure créées avec des frameworks PHP (Laravel, CodeIgniter, Symfony, Slim ...).

De ces expériences, nous faisons deux observations :

• Les solutions du marché peuvent être simples à mettre en place, mais représentent un frein majeur à la personnalisation des fonctionnalités et à l'adaptation aux spécificités du projet. La maintenance évolutive est souvent difficile et rapidement, on se retrouve avec un code illisible, rempli de surcharges et d'exceptions. Au bout de plusieurs années, on peut facilement dépasser le coût de développement d'une solution sur mesure, sans que la qualité fonctionnelle soit à la hauteur de l'investissement.
• Inversement, le développement d'une solution sur mesure permet d'avoir une application mieux adaptée aux besoins du projet, un code plus lisible et plus maintenable, mais représente un coût initial de mise en place plus élevé, qui souvent, ne correspond pas aux budgets des clients. Par ailleurs, stocker en base de données des volumes toujours plus élevés d'abonnements et de factures, soulève des problématiques majeures de performance et de scalabilité mais aussi de sécurité et de politique de gestion des données personnelles.

Pour résumer, la gestion d'abonnements et de facturation est un métier à part entière, et le faire de façon propre tout en gardant des coûts de développements raisonnables est loin d'être évident.

C'est la problématique à laquelle des services comme Chargebee ou Recurly tentent de répondre, en s'appuyant sur un modèle de plus en plus répandu, le Service as a Software, ou "SaaS". Ce modèle a certes un coût (voir par exemple les tarifs de Chargebee) et peut être surdimensionné ou inadapté pour des petits projets, mais il a notre préférence dès lors qu’on veut construire une application professionnelle avec une vision long terme.

Les avantages du SaaS pour gérer les abonnements et les paiements

Le modèle de Chargebee (mais aussi de la plupart de ses concurrents) est le suivant :

• Une interface d'administration permet de gérer l'ensemble de la base produits et abonnés. On peut ainsi consulter, créer, modifier, supprimer les entités principales de l'application : catalogues, clients, abonnements, factures etc.
• L'ensemble de ces données est accessible en lecture et en écriture via une API REST, avec laquelle on peut interagir via n'importe quel langage de programmation capable de faire des requêtes HTTP.
• Les fonctionnalités indispensables d'une application e-commerce sont fournies : rapports statistiques et graphiques, export excel des données, génération des factures PDF, workflows d'emails transactionnels, prise en compte native de plusieurs dizaines de passerelles de paiements, etc.

On délègue donc la majeure partie de la logique métier et "backend" à Chargebee, ce qui réduit mécaniquement les coûts de développements initiaux et de maintenance, et on se concentre sur la construction d'un "frontend" sur mesure, qui contiendra en général un tunnel d'abonnement et un espace "mon compte" permettant d'accéder aux factures, de suspendre son abonnement, ou encore de modifier ses moyens de paiements.

Une seule base abonnés pour plusieurs interfaces utilisateurs

Outre les considérations de fonctionnalités et de coûts, cette architecture a aussi l’avantage des architectures distribuées : en séparant la logique métier et le frontend, on rend plus facile la mise en place de plusieurs applications partageant la même base abonnés. Par exemple, un site WordPress d’une part, et une application mobile React de l’autre, interagissant tous deux avec Chargebee pour vérifier les droits d’accès de l’utilisateur aux contenus payants.

Au terme des différentes étapes d’un projet, voici un exemple d’architecture que nous pouvons rencontrer, incluant l’utilisation de WordPress en mode « headless » et d’une API Slim (un microframework qu’on aime bien chez Globalis) comme contrôleur intermédiaire entre d’un côté, le frontend, et de l’autre, les 2 bases de données « clients » et « contenus » :

Globalis partage ses développements autour de Chargebee

Au terme de notre dernier projet, nous avons publié deux packages PHP en open-source, disponibles sur Github :

chargebee-php-sdk est un client PHP pour les API de Chargebee. Il encapsule les appels HTTP, lève des Exceptions typées correspondant aux codes d’erreur de l’API, et déclenche des événements implémentant la PSR-14 sur les réponses de l’API.

Voir sur Github : https://github.com/globalis-ms/chargebee-php-sdk

chargebee-php-sdk-wp est une intégration pour WordPress de ce client PHP. Il convertit les évènements en hooks WordPress, et implémente une vue des appels à l’API pour l’extension Query-Monitor (un outil de monitoring pour WordPress que nous aimons beaucoup chez Globalis, intégré par défaut à notre stack wp-cubi).

Voir sur Github : https://github.com/globalis-ms/chargebee-php-sdk-wp

Ces deux packages sont tout neufs, et comme toujours, nous sommes preneurs d'avis, feedbacks, rapports de bugs ou pull-requests sur GitHub !

Nous avons en réserve un certain nombre d'idées pour les améliorer :

• Proposer une logique de cache des résultats de requête avec plusieurs implémentations (cache non-persistent en mémoire du script PHP, cache persistent en base de données SQL …), possiblement en s'appuyant sur les PSR-6 ou PSR-16 afin de pouvoir brancher n'importe quelle implémentation de cache system et faciliter les intégrations.
• Fournir un endpoint pour recevoir les webhooks de Chargebee et les convertir en évènements implémentant la PSR-14 et en hooks WordPress
• Ajouter la possibilité de faire des requêtes parallèles et asynchrones
• Prendre en constructeur du client d'API un objet de log PSR-3 et générer des traces d’exécution et de journalisation des erreurs

Cet article vous inspire ? Vous souhaitez discuter de Chargebee avec nous ou discuter d'un projet de PayWall ? Echangeons ensemble.

VOTRE PROJET

Une solution de Paywall à mettre en place ?

Des résultats certifiés par Scorefact, + de 20 ans d’expérience. Décrivez-nous votre besoin et échangeons ensemble.

ÊTRE CONTACTÉ PAR UN EXPERT

Être contacté par un expert