Trois façons de gagner de l'argent ici, et toutes trois aboutissent au même compte Stripe.
Voie une : vendre sur le Marketplace. Un acheteur paie pour votre listing, Xuda prélève une commission lue sur votre palier vendeur au moment du paiement, et le solde est routé vers votre compte connecté (cpi/stripe_module/index.mjs:3064-3070). Voie deux : gagner une commission de partenaire sur xuda.network. Un ambassadeur accumule 15 pour cent et un mentor 20 pour cent, les deux seuls taux qui existent dans le code, à cpi/stripe_module/index.mjs:6480-6488. Voie trois : facturer vos propres clients via Xuda Finance, en émettant devis et factures sur votre propre compte Stripe afin de rester le marchand de référence. Cette troisième voie est construite et active en dev, datée du 2026-08-02, et elle n'est délibérément pas en production. Ce que les trois voies ont en commun, c'est la destination. Un achat est refusé sans appel lorsque le vendeur n'a pas d'identifiant de compte Stripe connecté, avec le message "le vendeur n'est pas configuré pour recevoir des paiements" (stripe_module:3047-3053), et un versement de partenaire est bloqué avec "le partenaire n'a pas de compte Stripe actif pour être payé" tant qu'aucun compte connect facturable n'existe (stripe_module:9186-9218). La porte pour LISTER est plus large que la porte pour être PAYÉ : is_marketplace_pro renvoie vrai pour un compte simplement marqué is_xuda_network_ambassador (marketplace_module:90-96), il est donc possible d'être un vendeur visible et structurellement impayable en même temps.
Trois mécanismes différents, un compte où ils convergent tous.
Une vente, une commission et une facture ne sont pas des variantes d'une même fonctionnalité : ce sont trois chemins de code distincts, écrits à des moments différents, avec des propriétaires de l'argent différents. Ils se rejoignent en exactement un seul point. Chacun d'eux exige un compte Stripe connecté réellement facturable avant qu'un seul euro ne puisse vous parvenir, et chacun refuse avec ses propres mots quand ce compte manque.
Types de listings déclarés disposant d'un provisionneur
La commission conservée par Xuda, du palier Free au palier Scale
Taux ambassadeur et mentor, les deux seuls dans le code
Prix plancher d'un listing payant, plafond 100000$
Quatre paliers, et la ligne qui compte est la dernière.
Lisez n'importe quelle colonne de haut en bas et l'offre est claire : un prix mensuel, le pourcentage que Xuda conserve, le nombre de listings que vous pouvez avoir en ligne, et lesquels des quatre types de listings déclarés vous êtes autorisé à créer. Puis lisez la dernière ligne, celle qu'aucune page de palier ne vous dit. LISTING_TYPES déclare project, ai_agent, instance et managed_vps (marketplace_module:2640), et PROVISIONERS n'en implémente que deux, project et managed_vps (marketplace_module:3099, 3291). Tout le reste enregistre provision_stat failed avec provision_error nothing knows how to provision a "<type>" listing yet, et l'appelant reçoit no provisioner for listing_type. Le palier Free permet ai_agent nommément, l'un des deux types sans rien derrière. Managed VPS est le plus strict des deux qui fonctionnent : un listing ne peut pas passer en ligne sans une image capturée et restaurable, vérifiée à marketplace_module:2652-2672. Une réserve sur les lignes payantes : la copie du dépôt de config.json porte des identifiants de prix Stripe fictifs sur Starter, Grow et Scale (TODO_marketplace_starter et ses homologues), donc ce tableau énonce l'échelle telle que déclarée et n'affirme rien quant à la possibilité d'y souscrire.
Free | Starter | Grow | Scale | |
|---|---|---|---|---|
| Prix mensuel | 0 $US | 19 $US | 49 $US | 149 $US |
| Xuda conserve | 20% | 15% | 10% | 5% |
| Listings en ligne | 1 | 5 | 20 | Illimité, le flag lit 0 |
| Types que vous pouvez créer | project, ai_agent | plus instance | plus managed_vps, le premier palier pouvant vendre un VPS | les quatre types déclarés |
| Parmi eux, les types qui provisionnent réellement | 1 sur 2, project uniquement | 1 sur 3, project uniquement | 2 sur 4, project et managed_vps | 2 sur 4, project et managed_vps |
Un achat qui a pris l'argent et n'a rien livré, dans ses propres champs.
Un achat sur le marketplace est PAYÉ D'ABORD et provisionné ensuite. stripe_module capture le paiement, écrit le document marketplace_purchase, puis déclenche le provisionnement sans l'attendre : cloner un projet copie la base de données, les documents studio, les plugins et les actifs disque, et exécute npm install, bien trop lent pour maintenir un paiement ouvert. Pour un type sans provisionneur, cet ordonnancement produit l'enregistrement ci-dessous. PROVISIONERS compte exactement deux entrées, project et managed_vps, LISTING_TYPES en déclare quatre, et le palier vendeur par défaut permet un listing ai_agent nommément. Le dispatcher recherche le type, ne trouve rien, et inscrit l'échec sur un achat déjà finalisé.
Deux rôles par ville, et seuls deux des quatre taux existent dans le code.
Le marketplace vend des artefacts. Le programme partenaires paie des personnes, par ville, avec deux rôles. PARTNERSHIP_PROGRAM.md précise ce que chaque rôle doit fournir mensuellement, ce que chaque ligne paie, et le garde-fou sur le total. Le code de commission est plus restreint que ce document, à dessein, et le dit dans un commentaire. Le panneau affiche deux barres solides et deux aspirationnelles.
- L'ambassadeur est la vitrine d'une ville : événements, conférences en université et en bootcamp, au moins 2 vidéos en langue locale par mois, prospection de clients. Trois lignes de paiement : une surcote régionale de 5 pour cent sur le revenu d'abonnement net nouveau de la ville pendant 12 mois, un apport direct de 15 pour cent sur le revenu de première année des clients qu'il a apportés, et des indemnités fixes par activité qualifiée.
- Le mentor est la moitié technique : implémentation, accompagnement en revue de code, 1 vidéo technique par mois, un projet de référence trimestriel. Une part de 20 pour cent sur les prestations qu'il livre, une surcote technique régionale de 3 pour cent sur les comptes qu'il a activés, un accompagnement payé à l'heure. Le versement total par ville est plafonné à 25 pour cent du revenu net de la ville.
- FINANCE_COMMISSION_BPS_BY_ROLE contient deux entrées et aucune autre : ambassadeur 1500 points de base, mentor 2000 points de base. Le commentaire au-dessus nomme ce qui est délibérément absent, et pourquoi. Les surcotes régionales sont une attribution par code région sur 12 mois, les indemnités exigent une preuve et une pré-approbation, et le plafond par ville ainsi que la dégressivité au mois 12 sont des questions de grand livre. Un pourcentage par facture n'exprime aucun de ces éléments, donc aucun n'est simulé.
- L'écart qui compte pour un partenaire : un compte marqué is_xuda_network_ambassador franchit la porte vendeur sans appel, sans aucun compte Stripe rattaché. Un partenaire peut lister et établir des devis tout en étant structurellement impayable, et le versement est réservé à l'opérateur, refusant avec le message que le partenaire n'a pas de compte Stripe actif pour être payé. Xuda Finance est actif en dev et explicitement absent de la production.
Sept étapes de la création à la mise en ligne, et six d'entre elles peuvent vous refuser.
Créer un listing et le publier sont deux méthodes différentes avec des portes différentes, et l'ordre n'est pas celui auquel on s'attend. Le type que votre palier peut vendre est vérifié à la CRÉATION, un Full Stack VPS est donc refusé avant que ses effets de bord de création ne s'exécutent : l'octroi d'accès à la sauvegarde, puis la capture d'image que le vendeur lance ensuite. Le plafond et la porte de l'image se vérifient à la publication, et le statut du compte se place devant l'IA comme une décision déterministe prioritaire.
Trois mouvements, et le dernier consiste à lire.
Être autorisé à lister et être capable de recevoir de l'argent sont deux vérifications dans deux modules différents, et réussir la première n'est pas une preuve de la seconde.
- 01
Devenez solvable, pas seulement autorisé
La porte vendeur accepte n'importe lequel de trois signaux : le flag is_xuda_network_ambassador, finance_active à true, ou stripe_connect_account_status.status active. Seul le dernier concerne réellement l'argent. Le paiement est refusé sans appel lorsque le vendeur n'a pas d'identifiant de compte Stripe connecté, indiquant que le vendeur n'est pas configuré pour recevoir des paiements, et l'acheteur doit lui aussi disposer d'un client Stripe enregistré.
- 02
Choisissez la voie, et fixez son prix
Vendre un artefact : project et managed_vps sont aujourd'hui les deux seuls types dotés d'un provisionneur. Un listing payant va de 5$ à 100000$, il n'est donc jamais gratuit, et la commission de Xuda est de 20 pour cent par défaut, lue sur votre palier au moment du paiement et inscrite sur l'enregistrement. L'échelle : Free à 0$ pour 20 pour cent et 1 listing, Starter à 19$ pour 15 pour cent et 5, Grow à 49$ pour 10 pour cent et 20, Scale à 149$ pour 5 pour cent et sans plafond. Vendre des services passe par Xuda Finance à la place : un compte connect fait de vous le marchand de référence, un siège délégué permet uniquement d'émettre des devis, avec stripe_account_id délibérément nul et Xuda restant le marchand de référence. Finance est au stade dev, daté du 2026-08-02.
- 03
Lisez les deux champs de statut, pas un seul
publish_stat indique si un listing est visible, et se répercute dans stat. Sur un achat, stat indique que l'argent a bougé et provision_stat indique si quelque chose a été livré. Lisez provision_stat, provision_attempts par rapport au plafond de 3, et provisioned_ref pour ce qui a été créé. commission_percent est le taux appliqué, conservé là afin qu'un remboursement ultérieur l'utilise. Une fois que provision_stat lit done, la voie du remboursement se refuse : la facturation ne s'arrête qu'en supprimant ce qui a été provisionné.
Neuf choses à lire avant de lister, en commençant par celle qui facture et ne livre rien.
- Quatre types de listings sont déclarés pour la surface payante, project, ai_agent, instance et managed_vps, et PROVISIONERS n'en implémente que deux, project et managed_vps. Un listing ai_agent ou instance peut être publié, acheté et FACTURÉ, puis enregistrer provision_stat failed avec l'erreur nothing knows how to provision a "<type>" listing yet, renvoyant no provisioner for listing_type. Le palier vendeur Free par défaut liste ai_agent nommément dans son flag listing_types, donc le chemin le moins cher vers le marketplace est aussi celui sans aucune livraison derrière lui. cpi/marketplace_module/index.mjs, LISTING_TYPES à 2640 et le dispatch à 3291-3301.
- L'argent est prélevé d'abord et le provisionnement s'exécute ensuite. Le paiement se solde dans stripe_module.purchase_marketplace_listing, puis le provisionnement est déclenché de manière asynchrone à sa suite et délibérément pas attendu, car un clonage de projet copie la base de données, les documents studio et les actifs disque puis exécute npm install. Le commentaire dans le code source le dit en ces termes : un achat est PAYÉ D'ABORD, puis le provisionnement s'exécute de manière asynchrone.
- Il n'existe jamais de remboursement automatique. Un provisionnement échoué enregistre un compteur de tentatives plafonné à 3 par MAX_PROVISION_ATTEMPTS, et passé ce plafond, l'acheteur est informé que l'achat a épuisé ses tentatives automatiques et qu'il doit contacter le support ou l'annuler pour obtenir un remboursement. Une fois que provision_stat lit done, la voie du remboursement se refuse purement et simplement avec this purchase is set up and running, et le seul moyen d'arrêter la facturation est de supprimer ce qui a été provisionné.
- La porte vendeur est une vérification de solvabilité, pas une vérification de plan. is_marketplace_pro renvoie vrai pour un compte marqué is_xuda_network_ambassador, ou avec finance_active à true, ou avec stripe_connect_account_status.status active, aux lignes 90 à 96. Un ambassadeur franchit donc la porte sans aucun compte Stripe, ce qui explique comment un partenaire peut lister et établir des devis tout en étant structurellement impayable.
- La copie du dépôt de config.json porte des identifiants de prix Stripe fictifs sur les trois paliers vendeurs payants, TODO_marketplace_starter, TODO_marketplace_growth et TODO_marketplace_scale, aux lignes 3249, 3274 et 3300. L'échelle est réelle en tant qu'ensemble de taux et de plafonds. Rien sur cette page ne prouve que ces paliers sont achetables aujourd'hui, et nous ne l'affirmons pas.
- Xuda Finance est construit et actif en dev, daté du 2026-08-02 dans son document de conception, qui précise ensuite Not on prod. Facturation, devis et siège délégué sont au stade dev. Le versement est réservé à l'opérateur, il n'existe aucun retrait en libre-service, et il se bloque avec the partner has no active Stripe account to be paid into tant qu'un compte connect facturable n'existe pas.
- Seuls deux taux de commission existent dans le code, ambassadeur 1500 points de base et mentor 2000 points de base dans FINANCE_COMMISSION_BPS_BY_ROLE. Les surcotes régionales de 5 pour cent et 3 pour cent, les indemnités d'activité, le plafond de versement de 25 pour cent par ville, la dégressivité après le mois 12 et le cycle de relevé mensuel vivent dans un plan markdown sans grand livre derrière eux. Le commentaire au-dessus de cette constante en explique la raison : ce sont des attributions sur une fenêtre plutôt qu'un pourcentage par facture, et prétendre le contraire paierait silencieusement le mauvais montant.
- Le flag de plan finance documents_per_month, 25 sur le palier Free, apparaît dans config.json et dans config_dev.json et n'est lu par aucun code nulle part dans le dépôt. C'est un plafond annoncé sans rien pour l'appliquer, donc rien ne vous arrête à 25 aujourd'hui.
- La porte de publication ne promet aucun délai de traitement. Rien n'enregistre le temps d'issue d'une revue, il n'existe aucun SLA nulle part dans le code, et il n'y a ni note, ni avis, ni champ de réputation vendeur nulle part dans cpi/marketplace_module/index.mjs. La confiance dans un listing vient aujourd'hui de ce que la porte a refusé, pas de ce que d'autres acheteurs ont dit.
Les écrans vendeur, et les écrans finance qui se trouvent derrière eux.
Une visite guidée de la surface que cette page décrit : créer un listing et choisir son type, l'état de publication passant de en attente de revue à publié, et le volet finance où un compte connecté est rattaché et un devis est émis. Les écrans finance sont enregistrés sur l'environnement de développement, là où cette moitié du produit fonctionne actuellement.
Les quatre questions qui déterminent si c'est fait pour vous
Réponses fondées sur le code livré, y compris là où le code fait moins que ce que l'interface qui l'entoure laisse penser.
Deux portes, et c'est la seconde qui vous fait payer.
Postuler au programme partenaires xuda.network est une véritable candidature : ville, rôle, vos travaux publics, et une courte motivation, examinée par une personne. Un ambassadeur organise des événements et des conférences en université, publie au moins 2 vidéos en langue locale par mois et prospecte des clients. Un mentor fait de l'implémentation, de l'accompagnement en revue de code, 1 vidéo technique par mois et un projet de référence trimestriel. La seconde porte compte plus qu'il n'y paraît : que vous vendiez un listing ou gagniez une commission en tant que partenaire, l'argent transite par un compte Stripe connecté, et tant que ce compte n'existe pas et n'est pas actif, la plateforme n'a nulle part où l'envoyer. Configurez-le dans facturation avant de lister quoi que ce soit, pas après votre première vente.