שלוש דרכים להרוויח כאן, ושלושתן מסתיימות באותו חשבון Stripe.
נתיב ראשון: מכירה בזירת המסחר. קונה משלם על הפריט שלך, Xuda גובה נתח שנקרא מדרגת המוכר שלך ברגע החיוב, והיתרה מנותבת לחשבון המחובר שלך (cpi/stripe_module/index.mjs:3064-3070). נתיב שני: עמלת שותף ב-xuda.network. שגריר צובר 15 אחוז ומנטור 20 אחוז, שני התעריפים היחידים שקיימים בקוד, ב-cpi/stripe_module/index.mjs:6480-6488. נתיב שלישי: הפקת חשבוניות ללקוחות שלך דרך Xuda Finance, כשהצעות המחיר והחשבוניות נוצרות בחשבון Stripe שלך כך שסוחר הרשומה נשאר בעל החשבון. הנתיב השלישי בנוי ופעיל על dev, בתאריך 2026-08-02, ובמכוון אינו על prod. מה שמשותף לשלושתם הוא היעד. רכישה נדחית על הסף כשלמוכר אין מזהה חשבון Stripe מחובר, עם ההודעה "המוכר אינו מוגדר לקבלת תשלומים" (stripe_module:3047-3053), ותשלום לשותף נחסם עם ההודעה "לשותף אין חשבון Stripe פעיל שאליו אפשר לשלם" עד שקיים חשבון connect שניתן לחייב (stripe_module:9186-9218). השער לפרסום פריט רופף מהשער לקבלת תשלום: is_marketplace_pro מחזירה true עבור חשבון שמסומן רק בדגל is_xuda_network_ambassador (marketplace_module:90-96), ולכן אפשר להיות מוכר גלוי ובלתי ניתן לתשלום מבחינה מבנית בעת ובעונה אחת.
שלושה מנגנונים שונים, חשבון אחד שכולם מתנקזים אליו.
מכירה, עמלה וחשבונית אינן וריאציות של יכולת אחת: אלה שלושה נתיבי קוד נפרדים, שנכתבו בזמנים שונים, עם בעלים שונים של הכסף. הם נפגשים באובייקט אחד בדיוק. כל אחד מהם דורש חשבון Stripe מחובר שאפשר באמת לחייב בו לפני שדולר אחד יכול להגיע אליך, וכל אחד מהם מסרב בניסוח משלו כשהחשבון הזה חסר.
סוגי פריטים מוצהרים שיש להם מנגנון הקצאה
הנתח ש-Xuda שומרת, מדרגת Free ועד Scale
תעריפי שגריר ומנטור, השניים היחידים בקוד
מחיר הרצפה של פריט בתשלום, תקרה $100000
ארבע דרגות, והשורה שחשובה היא האחרונה.
קריאה של כל עמודה מלמעלה למטה מציגה הצעה פשוטה: מחיר חודשי, האחוז ש-Xuda שומרת, כמה פריטים מותר להחזיק פעילים, ואילו מבין ארבעת סוגי הפריטים המוצהרים מותר ליצור. ואז יש לקרוא את השורה האחרונה, זו שאף עמוד דרגות אינו מספר עליה. LISTING_TYPES מצהיר על project, ai_agent, instance ו-managed_vps (marketplace_module:2640), ו-PROVISIONERS מממש שניים מהם, project ו-managed_vps (marketplace_module:3099, 3291). כל סוג אחר רושם provision_stat failed עם provision_error שאומר שאין עדיין דרך להקצות פריט מסוג "<type>", והקורא מקבל הודעה שאין מנגנון הקצאה ל-listing_type. דרגת Free מתירה ai_agent בשמו, והוא אחד מהשניים שאין מאחוריהם דבר. Managed VPS הוא המחמיר מבין השניים שכן עובדים: פריט אינו יכול לעלות לאוויר כלל בלי image שנלכד וניתן לשחזור, נבדק ב-marketplace_module:2652-2672. הסתייגות אחת לגבי השורות בתשלום: העותק של config.json ב-repo נושא מזהי מחיר Stripe זמניים על Starter, Grow ו-Scale (TODO_marketplace_starter ואחיו), ולכן הטבלה הזו מציגה את הסולם כפי שהוא מוצהר ואינה טוענת דבר על האפשרות לרכוש אותו.
Free | Starter | Grow | Scale | |
|---|---|---|---|---|
| מחיר חודשי | 0 $ | 19 $ | 49 $ | 149 $ |
| Xuda שומרת | 20% | 15% | 10% | 5% |
| פריטים פעילים | 1 | 5 | 20 | ללא הגבלה, בדגל רשום 0 |
| סוגים שמותר ליצור | project, ai_agent | בנוסף instance | בנוסף managed_vps, הדרגה הראשונה שיכולה למכור VPS | כל ארבעת הסוגים המוצהרים |
| מתוכם, סוגים שבאמת מבצעים הקצאה | 1 מתוך 2, project בלבד | 1 מתוך 3, project בלבד | 2 מתוך 4, project ו-managed_vps | 2 מתוך 4, project ו-managed_vps |
רכישה שלקחה את הכסף ולא סיפקה דבר, בשדות שלה עצמה.
רכישה בזירת המסחר משולמת תחילה ומוקצית לאחר מכן. stripe_module לוכד את החיוב, כותב את מסמך marketplace_purchase, ואז משגר את ההקצאה בלי להמתין לה: שכפול פרויקט מעתיק את בסיס הנתונים, את מסמכי Studio, את התוספים ואת נכסי הדיסק ומריץ npm install, איטי בהרבה מכדי להחזיק checkout פתוח. עבור סוג שאין לו מנגנון הקצאה, הסדר הזה מייצר את הרשומה שלהלן. ב-PROVISIONERS יש בדיוק שתי רשומות, project ו-managed_vps, LISTING_TYPES מצהיר על ארבעה, ודרגת המוכר שבברירת המחדל מתירה פריט ai_agent בשמו. המשגר מחפש את הסוג, לא מוצא דבר, ומטביע את הכישלון על רכישה שכבר עברה בהצלחה.
שני תפקידים לכל עיר, ורק שניים מארבעת התעריפים קיימים בקוד.
זירת המסחר מוכרת תוצרים. תוכנית השותפים משלמת לאנשים, לכל עיר, ויש בה שני תפקידים. PARTNERSHIP_PROGRAM.md מפרט בדיוק במה חייב כל תפקיד מדי חודש, כמה משלמת כל שורה, ומהי מגבלת המגן על הסך הכולל. קוד העמלות צר מהמסמך הזה במכוון, ואומר זאת בהערה. הפאנל מורכב משתי עמודות מוצקות ושתיים שאפתניות.
- השגריר הוא החזית של העיר: אירועים, הרצאות באוניברסיטאות וב-bootcamp, לפחות 2 סרטונים בשפה המקומית בחודש, ואיתור לקוחות פוטנציאליים. שלוש שורות תשלום: עמלת-על אזורית של 5 אחוז על הכנסות מנויים חדשות נטו בעיר במשך 12 חודשים, עמלת הפניה ישירה של 15 אחוז על הכנסות השנה הראשונה מלקוחות שהוא איתר, ומענקים קבועים לכל פעילות מוכרת.
- המנטור הוא החצי הטכני: יישום, עבודה זוגית על בדיקת קוד, סרטון טכני 1 בחודש, ופרויקט ייחוס רבעוני. נתח יישום של 20 אחוז על שירותים שהוא מספק, עמלת-על טכנית אזורית של 3 אחוז על חשבונות שהוא הכשיר, וחניכה שעתית בתשלום. סך התשלום לכל עיר מוגבל ל-25 אחוז מההכנסה נטו של העיר.
- ב-FINANCE_COMMISSION_BPS_BY_ROLE יש שתי רשומות ולא יותר: שגריר 1500 bps, מנטור 2000 bps. ההערה שמעליו מונה מה נעדר במכוון ומדוע. עמלות-העל האזוריות הן ייחוס לפי קוד אזור על פני 12 חודשים, המענקים דורשים הוכחה ואישור מראש, והתקרה לכל עיר וההפחתה ההדרגתית מחודש 12 הן שאלות של ספר חשבונות. אחוז לכל חשבונית אינו מבטא אף אחד מהם, ולכן אף אחד מהם אינו מוצג כאילו קיים.
- הפער שחשוב לשותף: חשבון שמסומן בדגל is_xuda_network_ambassador עובר את שער המוכר על הסף, בלי שום חשבון Stripe מקושר. שותף יכול לפרסם פריטים ולהפיק הצעות מחיר בזמן שהוא בלתי ניתן לתשלום מבחינה מבנית, והתשלום נעשה על ידי מפעיל בלבד ומסרב עם ההודעה שלשותף אין חשבון Stripe פעיל שאליו אפשר לשלם. Xuda Finance פעיל על dev ובמפורש אינו על prod.
שבעה שלבים מיצירה עד פרסום, ושישה מהם יכולים לסרב.
יצירת פריט ופרסום פריט הן מתודות שונות עם שערים שונים, והסדר אינו המתבקש. הסוג שהדרגה שלך רשאית למכור נבדק ביצירה, ולכן Full Stack VPS נדחה עוד לפני שתופעות הלוואי של היצירה רצות: הענקת הגישה לגיבוי, ולכידת ה-image שהמוכר מתחיל מיד אחר כך. התקרה ושער ה-image הם בזמן הפרסום, ומצב החשבון יושב לפני ה-AI כעקיפה דטרמיניסטית.
שלושה מהלכים, והאחרון שבהם הוא קריאה.
הרשות לפרסם פריט והיכולת לקבל כסף הן שתי בדיקות בשני מודולים שונים, ומעבר של הראשונה אינו ראיה לשנייה.
- 01
הפיכה לבר-תשלום, לא רק למורשה
שער המוכר מקבל כל אחד משלושה סימנים: דגל is_xuda_network_ambassador, finance_active true, או stripe_connect_account_status.status active. רק האחרון הוא כסף. ה-checkout מסרב על הסף כשלמוכר אין מזהה חשבון Stripe מחובר, ואומר שהמוכר אינו מוגדר לקבלת תשלומים, ולקונה נדרש גם Stripe customer שמור.
- 02
בחירת הנתיב ותמחורו
מכירת תוצר: project ו-managed_vps הם שני הסוגים שיש להם מנגנון הקצאה כיום. פריט בתשלום נע בין $5 ל-$100000, כלומר לעולם אינו חינם, והנתח של Xuda עומד כברירת מחדל על 20 אחוז, נקרא מהדרגה שלך ברגע החיוב ומוטבע על הרשומה. הסולם: Free ב-$0 עבור 20 אחוז ופריט 1, Starter ב-$19 עבור 15 אחוז ו-5, Grow ב-$49 עבור 10 אחוז ו-20, Scale ב-$149 עבור 5 אחוז וללא תקרה. מכירת שירותים עוברת דרך Xuda Finance במקום זאת: חשבון connect הופך אותך לסוחר הרשומה, ומושב delegate מוגבל להצעות מחיר בלבד עם stripe_account_id שהוא null במכוון, ו-Xuda נשארת סוחר הרשומה. Finance נמצא בשלב dev, בתאריך 2026-08-02.
- 03
קריאת שני שדות הסטטוס, לא אחד
publish_stat אומר אם פריט גלוי, ומשתקף אל stat. ברכישה, stat אומר שהכסף זז ו-provision_stat אומר אם סופק משהו. יש לקרוא את provision_stat, את provision_attempts מול התקרה של 3, ואת provisioned_ref כדי לדעת מה נוצר. commission_percent הוא התעריף שהוחל, ונשמר שם כדי שהחזר מאוחר יותר ישתמש בו. ברגע ש-provision_stat קורא done נתיב ההחזר מסרב: החיוב נפסק רק על ידי מחיקת מה שהוקצה.
תשעה דברים לקריאה לפני פרסום פריט, החל בזה שמחייב ולא מספק דבר.
- ארבעה סוגי פריטים מוצהרים עבור המשטח בתשלום, project, ai_agent, instance ו-managed_vps, ו-PROVISIONERS מממש שניים מהם, project ו-managed_vps. פריט ai_agent או instance יכול להתפרסם, להירכש ולחייב בפועל, ואז לרשום provision_stat failed עם השגיאה שאין עדיין דרך להקצות פריט מסוג "<type>", ולהחזיר הודעה שאין מנגנון הקצאה ל-listing_type. דרגת המוכר Free שבברירת המחדל מונה את ai_agent בשמו בדגל listing_types שלה, ולכן הדרך הזולה ביותר להיכנס לזירת המסחר היא גם זו שאין מאחוריה אספקה. cpi/marketplace_module/index.mjs, LISTING_TYPES בשורה 2640 והשיגור בשורות 3291 עד 3301.
- הכסף נלקח תחילה וההקצאה רצה אחר כך. התשלום נסגר ב-stripe_module.purchase_marketplace_listing, ואז ההקצאה משוגרת אסינכרונית בעקבותיו ובמכוון לא ממתינים לה, משום ששכפול פרויקט מעתיק את בסיס הנתונים, את מסמכי Studio ואת נכסי הדיסק ואז מריץ npm install. ההערה בקוד המקור אומרת זאת במילים האלה: רכישה משולמת תחילה, ואז ההקצאה רצה אסינכרונית.
- אין אף פעם החזר אוטומטי. הקצאה שנכשלה רושמת מונה ניסיונות שמוגבל ל-3 על ידי MAX_PROVISION_ATTEMPTS, ומעבר לכך נאמר לקונה שהרכישה ניצלה את כל הניסיונות החוזרים האוטומטיים שלה ושעליו לפנות לתמיכה או לבטל אותה כדי לקבל החזר. ברגע ש-provision_stat קורא done נתיב ההחזר מסרב על הסף עם ההודעה שהרכישה הזו מוגדרת ופועלת, והדרך היחידה לעצור את החיוב היא למחוק את מה שהוקצה.
- שער המוכר הוא בדיקת יכולת תשלום, לא בדיקת מסלול. is_marketplace_pro מחזירה true עבור חשבון שמסומן בדגל is_xuda_network_ambassador, או עם finance_active true, או עם stripe_connect_account_status.status active, בשורות 90 עד 96. שגריר עובר לכן את השער בלי שום חשבון Stripe, וכך שותף יכול לפרסם פריטים ולהפיק הצעות מחיר בזמן שהוא בלתי ניתן לתשלום מבחינה מבנית.
- העותק של config.json ב-repo נושא מזהי מחיר Stripe זמניים בשלוש דרגות המוכר בתשלום, TODO_marketplace_starter, TODO_marketplace_growth ו-TODO_marketplace_scale, בשורות 3249, 3274 ו-3300. הסולם אמיתי כמערכת של תעריפים ותקרות. שום דבר בעמוד הזה אינו מוכיח שהדרגות האלה ניתנות לרכישה היום, ואיננו טוענים זאת.
- Xuda Finance בנוי ופעיל על dev, בתאריך 2026-08-02 במסמך העיצוב שלו, שאומר מיד אחר כך לא על prod. הפקת חשבוניות, הצעות מחיר ומושב delegate הם בשלב dev. התשלום נעשה על ידי מפעיל בלבד, אין משיכה בשירות עצמי, והוא נחסם עם ההודעה שלשותף אין חשבון Stripe פעיל שאליו אפשר לשלם עד שקיים חשבון connect שניתן לחייב.
- רק שני תעריפי עמלה קיימים בקוד, שגריר 1500 bps ומנטור 2000 bps ב-FINANCE_COMMISSION_BPS_BY_ROLE. עמלות-העל האזוריות של 5 אחוז ו-3 אחוז, מענקי הפעילות, תקרת התשלום של 25 אחוז לכל עיר, ההפחתה ההדרגתית אחרי חודש 12 ומחזור הדוח החודשי חיים במסמך תוכנית markdown בלי שום ספר חשבונות מאחוריהם. ההערה שמעל אותו קבוע מסבירה מדוע: הם ייחוס על פני חלון זמן ולא אחוז לכל חשבונית, והעמדת פנים אחרת הייתה משלמת בשקט את הסכום הלא נכון.
- דגל מסלול הפיננסים documents_per_month, 25 בדרגת Free, מופיע ב-config.json וב-config_dev.json ואינו נקרא על ידי שום קוד ב-repo. זו תקרה מפורסמת שאין דבר שאוכף אותה, ולכן שום דבר אינו עוצר אותך ב-25 היום.
- שער הפרסום אינו מבטיח זמן טיפול. שום דבר אינו מתעד את מועד ההכרעה בבדיקה, אין SLA בשום מקום בקוד, ואין שדה דירוג, ביקורת או מוניטין מוכר בשום מקום ב-cpi/marketplace_module/index.mjs. האמון בפריט היום נובע ממה שהשער סירב לו, לא ממה שקונים אחרים אמרו.
מסכי המוכר, ומסכי הפיננסים שמאחוריהם.
סיור במשטח שהעמוד הזה מתאר: יצירת פריט ובחירת הסוג שלו, מצב הפרסום שעובר מממתין לבדיקה למפורסם, וצד הפיננסים שבו מקושר חשבון מחובר ומופקת הצעת מחיר. מסכי הפיננסים מוקלטים בסביבת הפיתוח, שבה רץ כרגע החצי הזה של המוצר.
ארבע השאלות שמכריעות אם זה מתאים לך
התשובות ניתנות מול הקוד שנשלח, כולל במקומות שבהם הקוד עושה פחות ממה שהממשק סביבו מרמז.
שתי דלתות, והשנייה היא זו שמביאה את הכסף.
הגשת מועמדות לתוכנית השותפים של xuda.network היא בקשה אמיתית: עיר, תפקיד, העבודה הפומבית שלך ומוטיבציה קצרה, שנבדקות בידי אדם. שגריר מקיים אירועים והרצאות באוניברסיטאות, מפרסם לפחות 2 סרטונים בשפה המקומית בחודש ומאתר לקוחות פוטנציאליים. מנטור עוסק ביישום, בעבודה זוגית על בדיקת קוד, בסרטון טכני 1 בחודש ובפרויקט ייחוס רבעוני. הדלת השנייה חשובה יותר ממה שהיא נראית: בין אם מוכרים פריט ובין אם מרוויחים עמלה כשותף, הכסף עובר דרך חשבון Stripe מחובר, ועד שהחשבון הזה קיים ופעיל אין לפלטפורמה לאן לשלוח אותו. ההגדרה שלו נעשית במסך החיוב לפני פרסום של פריט כלשהו, לא אחרי המכירה הראשונה.