Bubble rend la construction d'une application SaaS accessible sans code. Mais monétiser cette application - encaisser un paiement one-shot, gérer des abonnements, traiter les annulations - ça se passe dans Stripe, pas dans Bubble. La connexion entre les deux se fait en quelques heures si on connaît les bonnes étapes. Voici comment.
Pourquoi Stripe, et pas autre chose
Bubble a un plugin officiel Stripe maintenu par l'équipe Bubble. C'est la seule intégration paiement bénéficiant d'un support natif, d'une compatibilité garantie après les mises à jour de Bubble, et d'une documentation officielle. PayPal et d'autres processeurs existent en plugins tiers, mais leur maintenance est aléatoire.
Stripe lui-même est devenu le standard de facto pour les SaaS et les marketplaces. Sa documentation est exhaustive, son API stable, et ses tarifs transparents. Côté France, les frais publiés par Stripe partent de 1,5 % + 0,25 € par transaction pour les cartes standard de l'Espace économique européen, montent à 1,9 % + 0,25 € pour les cartes premium EEE, et atteignent 2,5 % + 0,25 € (UK) ou 3,25 % + 0,25 € pour les cartes hors EEE (stripe.com/fr/pricing, vérifié avril 2026). Il n'y a pas de frais mensuels fixes sur le plan standard.
Le plugin officiel Bubble couvre les cas d'usage principaux : paiements one-shot, abonnements récurrents avec Stripe Checkout, et Strong Customer Authentication (SCA/3DS) activée par défaut. Si vous construisez une place de marché avec redistribution de fonds entre vendeurs, il existe un plugin séparé pour Stripe Connect.
Mise en place initiale
Commencez par créer un compte Stripe sur stripe.com si ce n'est pas déjà fait. Activez votre compte en mode test par défaut - vous pouvez encaisser de vraies transactions une fois le compte vérifié, mais pour le développement, le mode test est suffisant et non facturable.
Dans Bubble, installez le plugin via Plugins > Add plugins > chercher "Stripe". Sélectionnez le plugin officiel "Stripe" publié par Bubble. Une fois installé, rendez-vous dans les paramètres du plugin et collez vos clés API Stripe :
- Test publishable key (commence par
pk_test_) - Test secret key (commence par
sk_test_) - Live publishable key et live secret key pour la production
Bubble gère automatiquement le switch entre test et live selon que votre application tourne en mode Development ou Live. Pas besoin de logique conditionnelle : en dev, les clés test sont utilisées ; en live, les clés production. C'est un des avantages du plugin officiel par rapport à une intégration API directe.
Paiements one-shot avec Stripe Checkout
La façon la plus rapide d'encaisser un premier paiement est Stripe Checkout : une page hébergée par Stripe, avec formulaire de carte prérempli, gestion du 3DS, et confirmation automatique. Vous n'avez rien à coder côté interface de paiement.
Dans Bubble, créez un workflow sur le bouton "Payer" de votre app. L'action à utiliser est "Charge current user" du plugin Stripe. Paramètres nécessaires :
- Amount : le montant en centimes (ex : 2900 pour 29 €)
- Currency : "eur" pour l'euro
- Description : texte libre visible sur le reçu Stripe
- Checkout mode : sélectionner "Checkout v3" dans les paramètres du plugin pour activer la page hébergée avec SCA
Stripe redirige l'utilisateur vers votre app après le paiement avec un paramètre URL indiquant le succès ou l'échec. Ajoutez une page de confirmation dans Bubble qui lit ce paramètre et affiche le bon message.
Un point à connaître sur la structure Bubble : les actions du plugin Stripe s'exécutent côté client dans l'éditeur, mais la charge réelle est traitée via un serveur intermédiaire Bubble. Vous ne manipulez jamais les données de carte directement - Stripe les capture dans sa propre interface sécurisée.
Abonnements récurrents
Les abonnements demandent une étape supplémentaire dans Stripe Dashboard : créer des produits et des prix avant de les utiliser dans Bubble.
Créer produits et prix dans Stripe
Dans Stripe Dashboard > Produits, créez un produit (ex : "Plan Pro"). Ajoutez-y un prix avec le type "Récurrent" et choisissez l'intervalle (mensuel, annuel) et le montant. Notez l'ID du prix - il commence par price_. C'est cet identifiant que vous utiliserez dans Bubble.
Cette séparation produit/prix permet de proposer plusieurs plans tarifaires (mensuel et annuel) pour un même produit, ou d'ajouter des plans sans casser les abonnements existants.
Déclencher l'abonnement dans Bubble
Le workflow Bubble utilise l'action "Subscribe user to plan" du plugin Stripe. Collez l'ID du prix (price_...) dans le champ prévu. Stripe Checkout gère ensuite la saisie de carte et la confirmation.
À ce stade, votre base de données Bubble ne sait pas encore que l'utilisateur s'est abonné. C'est là qu'interviennent les webhooks.
Webhooks : la partie que 80 % des apps Bubble zappent
Un webhook est une notification envoyée par Stripe à votre application quand un événement se produit : abonnement activé, paiement échoué, abonnement annulé. Sans webhook, votre app Bubble encaisse les paiements mais ne met jamais à jour la base de données en conséquence. L'utilisateur peut annuler son abonnement dans Stripe et continuer à accéder à votre produit.
Activer les Backend Workflows dans Bubble
Rendez-vous dans Settings > API de votre app Bubble, puis activez "This app exposes a Workflow API". Une nouvelle section "Backend workflows" apparaît dans le menu des pages. C'est ici que vous créerez les endpoints qui recevront les webhooks Stripe.
Créer l'endpoint webhook
Dans Backend workflows, créez un nouvel endpoint API (bouton "New API workflow"). Nommez-le par exemple stripe-webhook. Cochez "This workflow can be run without authentication". Définissez les paramètres d'entrée attendus (type JSON) selon l'événement Stripe.
L'URL de cet endpoint ressemble à :
https://votre-app.bubbleapps.io/version-test/api/1.1/wf/stripe-webhook
Copiez cette URL. Dans Stripe Dashboard > Développeurs > Webhooks, ajoutez un endpoint avec cette URL. Sélectionnez les événements à surveiller :
invoice.payment_succeeded: paiement mensuel/annuel réussiinvoice.payment_failed: paiement échoué (carte expirée, fonds insuffisants)customer.subscription.deleted: abonnement annulécheckout.session.completed: session de paiement Checkout terminée
Logique dans le workflow
Pour chaque type d'événement, ajoutez une action dans le workflow qui met à jour le champ correspondant dans la base de données Bubble. Par exemple, sur customer.subscription.deleted : chercher l'utilisateur par son Stripe Customer ID (à stocker en base lors de la création), puis mettre le champ subscription_status à "inactive" et subscription_end_date à la date du jour.
Ce champ subscription_status doit conditionner l'accès aux fonctionnalités payantes dans vos workflows Bubble. C'est la mécanique centrale d'un SaaS avec gating de contenu. Pour une architecture plus robuste avec logique backend séparée, voir notre article sur Bubble et Xano.
Tester l'intégration end-to-end
Stripe fournit des numéros de carte de test. Le plus utile : 4242 4242 4242 4242 avec n'importe quelle date d'expiration future et n'importe quel CVC. Ce numéro simule un paiement réussi. Pour tester un échec de paiement, utilisez 4000 0000 0000 9995.
Testez le flux complet dans l'ordre : paiement > vérification de la mise à jour en base Bubble > annulation depuis le portail Stripe > vérification que l'accès est bien révoqué dans l'app. Vérifiez aussi que les webhooks arrivent bien dans Stripe Dashboard > Webhooks > onglet "Tentatives récentes". Si vous voyez des erreurs 400, c'est souvent que la structure JSON attendue par votre endpoint Bubble ne correspond pas au format réel du webhook Stripe.
Quand le plugin officiel ne suffit plus
Le plugin Bubble couvre 80 % des besoins d'un SaaS standard. Il a des limites documentées sur des cas avancés :
- Facturation à l'usage (metered billing)
- Coupons de réduction avec logique conditionnelle complexe
- Interface de paiement entièrement intégrée à votre design (sans redirection vers Stripe Checkout)
- Gestion de plusieurs modes de paiement (SEPA, Bancontact, etc.)
Pour ces cas, l'alternative est d'appeler l'API Stripe directement depuis un workflow Bubble via l'API Connector. Cela donne accès à la totalité de l'API Stripe, au prix d'une complexité de configuration plus élevée. La troisième option est d'utiliser un plugin Stripe tiers plus complet comme Stripe.js, qui expose davantage de fonctionnalités mais dépend d'un mainteneur externe.
Selon le forum Bubble, le débat plugin vs API directe est récurrent. La réponse dépend du projet : pour un MVP qui doit être en ligne en 2 semaines, le plugin officiel est largement suffisant. Pour un SaaS qui gère des centaines d'abonnements avec une logique de facturation complexe, une couche backend dédiée vaut l'investissement.
Portail client Stripe
Un détail souvent oublié : Stripe propose un portail client hébergé où vos utilisateurs peuvent gérer leurs abonnements eux-mêmes (changer de plan, mettre à jour leur carte, annuler). L'activer vous évite de construire ces fonctionnalités dans Bubble.
Dans Stripe Dashboard > Paramètres > Portail client, configurez les options autorisées. Dans Bubble, ajoutez un bouton "Gérer mon abonnement" qui appelle l'action du plugin "Open Billing Portal". Stripe redirige l'utilisateur vers le portail avec toutes ses informations pré-remplies, puis renvoie sur votre app une fois les modifications effectuées.
Si votre application évolue vers plus de complexité côté facturation ou logique métier, la question de l'architecture se pose naturellement. Notre article sur les coûts d'une application Bubble donne des repères budgétaires selon les différentes phases de développement.
Questions fréquentes
Les clés Stripe sont-elles sécurisées dans Bubble ?
Les clés API Stripe stockées dans les paramètres du plugin Bubble ne sont pas exposées côté client. La clé secrète (sk_) reste côté serveur. En revanche, la clé publiable (pk_) est visible dans le code JavaScript frontend - c'est le comportement normal et attendu par Stripe. Elle ne permet pas de déclencher des charges non autorisées.
Que se passe-t-il si Stripe envoie un webhook et que Bubble est hors ligne ?
D'après la documentation Stripe, les Smart Retries reprogramment automatiquement les webhooks échoués sur plusieurs tentatives étalées dans le temps - le paramètre par défaut est de 8 tentatives sur 2 semaines, configurable jusqu'à 2 mois (Stripe Smart Retries). En pratique, les apps Bubble hébergées sur les plans Growth et Team ont une disponibilité proche de 100 %. Le vrai risque est une erreur dans votre endpoint qui renvoie systématiquement un code 500 - surveillez les tentatives échouées dans Stripe Dashboard.
Comment gérer les remboursements ?
Les remboursements s'initialisent depuis Stripe Dashboard (manuellement) ou via l'action "Refund" du plugin Bubble dans un workflow. Stripe ne rembourse pas ses frais de traitement : sur un paiement de 29 €, vous perdez les ~0,68 € de commission carte EEE standard même en cas de remboursement total. Prévoyez cette règle dans votre politique commerciale.
Le plugin Stripe est-il compatible avec les apps Bubble en mode native mobile ?
Le plugin Stripe officiel utilise des éléments web qui ne fonctionnent pas nativement dans une app Bubble encapsulée (via BDK Native ou Natively). Des solutions alternatives existent - Stripe Payment Sheet via un plugin tiers - mais la configuration est plus complexe. Pour une app mobile avec paiements critiques, c'est un point à anticiper avant de choisir l'architecture.
