Plateforme
Paiements : un block propulsé par Stripe pour de vrais revenus
Checkout, abonnements et reçus atterrissent dans votre app comme du vrai code — avec un mode test pour répéter et un mode live pour quand vous êtes prêt à facturer.
Le block Paiements de Ciao ajoute des paiements propulsés par Stripe à une application construite par IA : checkout, abonnements, reçus, et modes test et live séparés. Contrairement aux widgets de paiement intégrés sur des plateformes fermées, le block s'installe comme du vrai code dans votre application, connecté à votre propre compte Stripe — les revenus vous reviennent, et l'intégration est à vous d'inspecter, d'étendre et d'exporter.
Publié 2026-07-03 · Dernière mise à jour 2026-07-03
L'argent est où les prototypes cessent d'être suffisants
L'écart entre une app et une entreprise, c'est un checkout qui fonctionne. C'est aussi là où la tolérance aux bugs tombe à zéro : doubles facturations, reçus manquants et états d'abonnement cassés coûtent une confiance qu'un jeune produit ne peut pas se permettre de perdre. Le code de paiement est exactement la plomberie que les fondateurs ne devraient pas coder eux-mêmes et que les agences ne devraient pas reconstruire pour chaque client.
Le block Paiements ajoute des paiements propulsés par Stripe à une application Ciao en un clic : checkout, abonnements et reçus, avec des modes test et live séparés. Il se connecte à votre propre compte Stripe et s'installe comme du vrai code dans votre app — inspectable, extensible et à vous.
Ce que le block inclut
Le block couvre la plomberie de revenus dont chaque produit payant a besoin.
Checkout
Un flux d'achat propulsé par Stripe branché dans votre application, gérant la partie de la transaction que vous ne voulez jamais improviser.
Abonnements
Plans, essais, mises à niveau et annulations construits sur le modèle d'abonnement de Stripe, pilotés par des règles que vous décrivez en langage clair.
Reçus
Les clients reçoivent des reçus pour leurs charges sans que personne n'ait à construire un pipeline d'emails au préalable.
Modes test et live
Répétez chaque flux avec des cartes de test Stripe avant qu'une vraie carte ne soit jamais facturée ; basculez en live délibérément, après que les portes soient passées.
Du zéro revenu à la première facturation
Le chemin de l'installation du block à la facturation d'une vraie carte est délibérément contrôlé.
1. Ajoutez le block Paiements
Un clic génère des flux de checkout, la gestion d'abonnements et les reçus dans votre codebase, sur une branche comme toute autre modification.
2. Connectez votre compte Stripe
Votre compte, vos clients, vos versements. Ciao câble l'intégration ; la relation commerciale est entre vous et Stripe.
3. Décrivez ce que vous vendez
Produits, prix et plans en langage clair — achats uniques, paliers mensuels, essais — et les flux sont construits pour correspondre.
4. Répétez en mode test
Exécutez le parcours complet avec des cartes de test Stripe. QA capture le flux d'achat comme un replay déterministe, si bien qu'il reste protégé dès lors.
5. Passez les portes et passez en live
Les smoke gates et le dashboard bon-à-publier s'appliquent comme d'habitude. Quand tout est vert, basculez de test à live et encaissez le premier vrai paiement.
6. Continuez à itérer en sécurité
Les changements de tarification et les nouveaux plans sont des modifications d'une zone protégée — Guardrails peut exiger une revue senior pour tout ce qui touche les flux de paiement.
Pourquoi c'est important
Les paiements comme capacité gouvernée changent le profil de risque de livrer des fonctionnalités de revenu. Le checkout est couvert par des replays de QA déterministes, des sondes de contrôle d'accès exercent les frontières autour des données de facturation, et chaque modification près de l'argent peut exiger une revue enregistrée. C'est une fondation différente d'un widget déposé dans une page.
Et parce que c'est du vrai code dans votre application, les cas limites restent atteignables : un chemin de mise à niveau personnalisé, une logique par siège, le libellé de reçu que votre équipe finance demande. Vous étendez du code que vous possédez au lieu de négocier avec un plugin.
Il y a une raison pour laquelle les paiements sont souvent le premier block vers lequel une équipe se tourne : c'est le test le plus clair pour savoir si une application construite par IA est un vrai produit. Un checkout qui passe des replays déterministes, un flux d'abonnement avec une revue enregistrée derrière lui, des reçus qui arrivent sans que personne ne se souvienne de les envoyer — c'est ce que « prêt pour la production » signifie quand de l'argent est en jeu.
Qui utilise le block Paiements
- Fondateurs — La première version payante du produit est livrée avec le checkout déjà répété en mode test.
- Agences — Les produits clients payants cessent de nécessiter une construction de facturation sur mesure par engagement — le block s'installe, le compte Stripe du client se connecte.
- Équipes SaaS — Logique d'abonnement avec contrôle de changement gouverné, si bien que les expérimentations de tarification ne contournent jamais la revue.
- Équipes internes et opérations — Réservations, inscriptions et commandes payantes dans des outils par ailleurs internes, avec les reçus gérés.
Notes sur la sécurité et la gouvernance
- ✓ Tourne sur votre propre compte Stripe — les fonds se règlent vers vous.
- ✓ Les détails de carte sont gérés par le checkout de Stripe, pas stockés dans la base de données de votre application.
- ✓ Les modes test et live sont séparés ; chaque flux peut être répété avant une vraie charge.
- ✓ Les replays de QA couvrent les parcours d'achat ; les smoke gates s'exécutent avant chaque publication.
- ✓ Guardrails peut exiger une revue senior pour les modifications aux flux de paiement.
- ✓ Les modifications près de la facturation atterrissent dans l'audit trail append-only.
Mode test vs mode live
Les deux modes existent pour que rien de votre première vraie facturation ne soit une surprise.
| Mode test | Mode live | |
|---|---|---|
| Cartes | Cartes de test Stripe | Vraies cartes clients |
| Argent | Aucun fonds ne bouge | Les charges se règlent vers votre compte Stripe |
| Objectif | Répéter les flux et exécuter des replays de QA | Servir les clients |
| Basculement | Par défaut pour les nouvelles fonctionnalités de paiement | Basculé délibérément, après que les portes soient passées |
Questions fréquentes
Ai-je besoin de mon propre compte Stripe ?
Oui — le block se connecte à votre compte Stripe, si bien que les clients, les paiements et les versements sont les vôtres. Ciao génère et maintient le code d'intégration dans votre application.
Puis-je personnaliser la logique de checkout et de facturation ?
Oui. Le block est du vrai code dans votre app, donc vous pouvez le modifier comme vous modifiez tout le reste — décrivez l'ajustement dans Builder, ou pointez la page de checkout avec inspect-to-prompt. Les modifications aux flux de paiement passent par les mêmes portes que tout.
Comment les abonnements gèrent-ils les mises à niveau et les annulations ?
Ils sont construits sur le modèle d'abonnement de Stripe, avec votre policy décrite en langage clair — prorater les mises à niveau, annuler en fin de période, offrir un essai. Les flux qui en résultent sont capturés comme des replays de QA, si bien qu'ils continuent de fonctionner à mesure que l'app évolue.
Est-il sûr d'expérimenter avec des fonctionnalités de paiement ?
C'est exactement à cela que sert la structure : les modifications se produisent sur des branches, le mode test signifie qu'aucune vraie charge n'a lieu, les smoke gates s'exécutent avant toute publication, et Guardrails peut exiger une revue senior pour les modifications de flux de paiement. L'expérimentation a lieu ; les surprises en production n'ont pas à l'être.
Combien coûte le block Paiements ?
Le block fait partie de la plateforme ; les frais de traitement de Stripe sont entre vous et Stripe. Les builders individuels démarrent en self-serve avec des crédits, et les programmes de production sérieux démarrent à 10 000 USD par an — voir la page tarifs.