Tres formas de ganar aquí, y las tres terminan en la misma cuenta de Stripe.
Vía uno: vender en el Marketplace. Un comprador paga su anuncio, Xuda se queda con una comisión leída de su nivel de vendedor en el momento del cobro, y el resto se enruta a su cuenta conectada (cpi/stripe_module/index.mjs:3064-3070). Vía dos: ganar una comisión de partner en xuda.network. Un ambassador acumula un 15 por ciento y un mentor un 20 por ciento, las dos únicas tasas que existen en el código, en cpi/stripe_module/index.mjs:6480-6488. Vía tres: facturar a sus propios clientes a través de Xuda Finance, emitiendo presupuestos y facturas en su propia cuenta de Stripe, de modo que usted sigue siendo el comerciante registrado. Esa tercera vía está construida y activa en dev, con fecha 2026-08-02, y deliberadamente no está en prod. Lo que comparten las tres es el destino. Una compra se rechaza de plano cuando el vendedor no tiene un id de cuenta conectada de Stripe, con el mensaje "the seller is not set up to receive payments" (stripe_module:3047-3053), y un pago a partner se bloquea con "the partner has no active Stripe account to be paid into" hasta que exista una cuenta connect cobrable (stripe_module:9186-9218). La puerta para PUBLICAR es más laxa que la puerta para COBRAR: is_marketplace_pro devuelve true para una cuenta con la simple marca is_xuda_network_ambassador (marketplace_module:90-96), así que es posible ser un vendedor visible y estructuralmente impagable al mismo tiempo.
Tres mecanismos distintos, una cuenta en la que todos liquidan.
Una venta, una comisión y una factura no son variantes de una misma función: son tres rutas de código separadas, escritas en momentos distintos, con dueños del dinero distintos. Se encuentran en exactamente un objeto. Cada una de ellas necesita una cuenta de Stripe conectada que sea realmente cobrable antes de que un solo dólar pueda llegarle, y cada una rechaza con sus propias palabras cuando esa cuenta falta.
Tipos de anuncio declarados que tienen aprovisionador
La comisión que se queda Xuda, del nivel Free al Scale
Tasas de ambassador y mentor, las dos únicas en el código
Precio mínimo de un anuncio de pago, techo de $100000
Cuatro niveles, y la fila que importa es la última.
Lea cualquier columna de arriba abajo y la oferta queda clara: un precio mensual, el porcentaje que se queda Xuda, cuántos anuncios puede tener activos y cuáles de los cuatro tipos de anuncio declarados puede crear. Después lea la última fila, que es la que ninguna página de niveles le cuenta. LISTING_TYPES declara project, ai_agent, instance y managed_vps (marketplace_module:2640), y PROVISIONERS implementa dos de ellos, project y managed_vps (marketplace_module:3099, 3291). Cualquier otro registra provision_stat failed con provision_error nothing knows how to provision a "<type>" listing yet, y quien llama recibe no provisioner for listing_type. El nivel Free permite ai_agent por su nombre, que es uno de los dos que no tienen nada detrás. Managed VPS es el más estricto de los dos que sí funcionan: un anuncio no puede publicarse siquiera sin una imagen capturada y restaurable, comprobado en marketplace_module:2652-2672. Una salvedad sobre las filas de pago: la copia de config.json del repositorio lleva ids de precio de Stripe de marcador de posición en Starter, Grow y Scale (TODO_marketplace_starter y sus equivalentes), así que esta tabla expone la escalera tal como está declarada y no afirma nada sobre poder comprarla.
Free | Starter | Grow | Scale | |
|---|---|---|---|---|
| Precio mensual | 0 US$ | 19 US$ | 49 US$ | 149 US$ |
| Xuda se queda | 20% | 15% | 10% | 5% |
| Anuncios activos | 1 | 5 | 20 | Ilimitados, la marca indica 0 |
| Tipos que puede crear | project, ai_agent | más instance | más managed_vps, el primer nivel que puede vender un VPS | los cuatro tipos declarados |
| De esos, tipos que realmente se aprovisionan | 1 de 2, solo project | 1 de 3, solo project | 2 de 4, project y managed_vps | 2 de 4, project y managed_vps |
Una compra que se llevó el dinero y no entregó nada, en sus propios campos.
Una compra en el marketplace se PAGA PRIMERO y se aprovisiona después. stripe_module captura el cargo, escribe el documento marketplace_purchase y luego despacha el aprovisionamiento sin esperarlo: clonar un proyecto copia la base de datos, los documentos de studio, los plugins y los activos en disco y ejecuta npm install, demasiado lento para mantener abierto un checkout. Para un tipo sin aprovisionador, ese orden produce el registro de abajo. PROVISIONERS tiene exactamente dos entradas, project y managed_vps, LISTING_TYPES declara cuatro, y el nivel de vendedor por defecto permite un anuncio ai_agent por su nombre. El despachador busca el tipo, no encuentra nada y graba el fallo sobre una compra que ya se ha cobrado.
Dos roles por ciudad, y solo dos de las cuatro tasas existen en el código.
El marketplace vende artefactos. El programa de partners paga a personas, por ciudad, con dos roles dentro. PARTNERSHIP_PROGRAM.md es específico sobre lo que cada rol debe cada mes, lo que paga cada línea y el límite sobre el total. El código de comisiones es más estrecho que ese documento a propósito, y lo dice en un comentario. El panel son dos barras sólidas y dos aspiracionales.
- El ambassador es la cara visible de una ciudad: eventos, charlas en universidades y bootcamps, al menos 2 videos al mes en su idioma nativo y captación de prospectos. Tres líneas de pago: un override regional del 5 por ciento sobre los ingresos netos nuevos por suscripción de la ciudad durante 12 meses, una referencia directa del 15 por ciento sobre los ingresos del primer año de los clientes que haya captado, y estipendios fijos por actividad cualificada.
- El mentor es la mitad técnica: implementación, revisión de código en pareja, 1 video técnico al mes y un proyecto de referencia trimestral. Una participación del 20 por ciento en la implementación de los servicios que entregue, un override técnico regional del 3 por ciento sobre las cuentas que haya habilitado y mentoría pagada por hora. El pago total por ciudad está limitado al 25 por ciento de los ingresos netos de la ciudad.
- FINANCE_COMMISSION_BPS_BY_ROLE contiene dos entradas y ninguna más: ambassador 1500 bps, mentor 2000 bps. El comentario que hay encima nombra lo que falta deliberadamente y por qué. Los overrides regionales son atribución por código de región a lo largo de 12 meses, los estipendios requieren prueba y aprobación previa, y el tope por ciudad y la reducción progresiva del mes 12 son cuestiones de libro contable. Un porcentaje por factura no expresa ninguna de ellas, así que ninguna se finge.
- La brecha que importa a un partner: una cuenta marcada como is_xuda_network_ambassador pasa la puerta de vendedor sin más, sin ninguna cuenta de Stripe asociada. Un partner puede publicar y presupuestar mientras es estructuralmente impagable, y el pago es solo para el operador, rechazando con el mensaje de que el partner no tiene una cuenta de Stripe activa en la que cobrar. Xuda Finance está activo en dev y explícitamente no en prod.
Siete etapas de la creación a la publicación, y seis de ellas pueden rechazarle.
Crear un anuncio y publicarlo son métodos distintos con puertas distintas, y el orden no es el evidente. El tipo que su nivel puede vender se comprueba al CREAR, así que un Full Stack VPS se rechaza antes de que se ejecuten los efectos secundarios de su creación: la concesión de acceso al backup y la captura de imagen que el vendedor inicia a continuación. El tope y la puerta de imagen son de tiempo de publicación, y el estado de la cuenta se sitúa delante de la IA como un override determinista.
Tres pasos, y el último es leer.
Estar autorizado a publicar y poder recibir dinero son dos comprobaciones en dos módulos distintos, y pasar la primera no es prueba de la segunda.
- 01
Hágase cobrable, no solo autorizado
La puerta de vendedor acepta cualquiera de tres señales: la marca is_xuda_network_ambassador, finance_active true, o stripe_connect_account_status.status active. Solo la última es dinero. El checkout rechaza de plano cuando el vendedor no tiene un id de cuenta conectada de Stripe, diciendo the seller is not set up to receive payments, y el comprador también necesita un cliente de Stripe almacenado.
- 02
Elija la vía y póngale precio
Vender un artefacto: project y managed_vps son hoy los dos tipos con aprovisionador. Un anuncio de pago va de $5 a $100000, así que nunca es gratuito, y la comisión de Xuda es del 20 por ciento por defecto, leída de su nivel en el momento del cobro y grabada en el registro. La escalera: Free a $0 con un 20 por ciento y 1 anuncio, Starter a $19 con un 15 por ciento y 5, Grow a $49 con un 10 por ciento y 20, Scale a $149 con un 5 por ciento y sin tope. Vender servicios pasa en cambio por Xuda Finance: una cuenta connect le convierte en comerciante registrado, y un asiento de delegado es solo para presupuestos, con stripe_account_id deliberadamente null y Xuda como comerciante registrado. Finance está en fase dev, con fecha 2026-08-02.
- 03
Lea los dos campos de estado, no uno
publish_stat dice si un anuncio es visible, y se replica en stat. En una compra, stat dice que el dinero se movió y provision_stat dice si se entregó algo. Lea provision_stat, provision_attempts frente al techo de 3, y provisioned_ref para saber qué se creó. commission_percent es la tasa aplicada, guardada ahí para que un reembolso posterior la use. Una vez que provision_stat indica done, la ruta de reembolso rechaza: la facturación solo se detiene borrando lo que se aprovisionó.
Nueve cosas que leer antes de publicar, empezando por la que cobra y no entrega nada.
- Se declaran cuatro tipos de anuncio para la superficie de pago, project, ai_agent, instance y managed_vps, y PROVISIONERS implementa dos de ellos, project y managed_vps. Un anuncio ai_agent o instance puede publicarse, comprarse y COBRARSE, y luego registra provision_stat failed con el error nothing knows how to provision a "<type>" listing yet, devolviendo no provisioner for listing_type. El nivel de vendedor Free por defecto lista ai_agent por su nombre en su marca listing_types, así que el camino más barato para entrar al marketplace es también el que no tiene entrega detrás. cpi/marketplace_module/index.mjs, LISTING_TYPES en 2640 y el despacho en 3291 a 3301.
- El dinero se cobra primero y el aprovisionamiento se ejecuta después. El pago se liquida en stripe_module.purchase_marketplace_listing, y luego el aprovisionamiento se despacha de forma asíncrona a partir de ahí y deliberadamente no se espera, porque clonar un proyecto copia la base de datos, los documentos de studio y los activos en disco y después ejecuta npm install. El comentario en el código lo dice con esas palabras: una compra se PAGA PRIMERO y luego el aprovisionamiento se ejecuta de forma asíncrona.
- Nunca hay un reembolso automático. Un aprovisionamiento fallido registra un contador de intentos limitado a 3 por MAX_PROVISION_ATTEMPTS, y pasado ese punto se le dice al comprador que la compra ha agotado todos sus reintentos automáticos y que contacte con soporte o la cancele para obtener un reembolso. Una vez que provision_stat indica done, la ruta de reembolso rechaza de plano con esta compra está configurada y funcionando, y la única forma de detener la facturación es borrar lo que se aprovisionó.
- La puerta de vendedor es una comprobación de capacidad de cobro, no de plan. is_marketplace_pro devuelve true para una cuenta marcada como is_xuda_network_ambassador, o con finance_active true, o con stripe_connect_account_status.status active, en las líneas 90 a 96. Un ambassador, por tanto, pasa la puerta sin ninguna cuenta de Stripe, que es la razón por la que un partner puede publicar y presupuestar mientras es estructuralmente impagable.
- La copia de config.json del repositorio lleva ids de precio de Stripe de marcador de posición en los tres niveles de vendedor de pago, TODO_marketplace_starter, TODO_marketplace_growth y TODO_marketplace_scale, en las líneas 3249, 3274 y 3300. La escalera es real como conjunto de tasas y topes. Nada en esta página demuestra que esos niveles se puedan comprar hoy, y no lo estamos afirmando.
- Xuda Finance está construido y activo en dev, con fecha 2026-08-02 en su documento de diseño, que a continuación dice Not on prod. La facturación, los presupuestos y el asiento de delegado están en fase dev. El pago es solo para el operador, no hay retiro de autoservicio, y se bloquea con the partner has no active Stripe account to be paid into hasta que exista una cuenta connect cobrable.
- Solo existen dos tasas de comisión en el código, ambassador 1500 bps y mentor 2000 bps en FINANCE_COMMISSION_BPS_BY_ROLE. Los overrides regionales del 5 por ciento y del 3 por ciento, los estipendios por actividad, el tope de pago por ciudad del 25 por ciento, la reducción progresiva a partir del mes 12 y el ciclo de estado de cuenta mensual viven en un plan en markdown sin ningún libro contable detrás. El comentario encima de esa constante explica por qué: son atribución a lo largo de una ventana temporal en lugar de un porcentaje por factura, y fingir lo contrario pagaría en silencio la cifra equivocada.
- La marca del plan de finanzas documents_per_month, 25 en el nivel Free, aparece en config.json y en config_dev.json y no la lee ningún código en todo el repositorio. Es un tope anunciado sin nada que lo aplique, así que hoy nada le detiene en 25.
- La puerta de publicación no promete plazos. Nada registra el tiempo de resolución de una revisión, no hay ningún SLA en el código, y no hay campo de valoración, reseña ni reputación de vendedor en ninguna parte de cpi/marketplace_module/index.mjs. Hoy, la confianza en un anuncio viene de lo que la puerta rechazó, no de lo que dijeron otros compradores.
Las pantallas del vendedor, y las pantallas de finanzas que hay detrás.
Un recorrido por la superficie que describe esta página: crear un anuncio y elegir su tipo, el estado de publicación pasando de pendiente de revisión a publicado, y el lado financiero, donde se asocia una cuenta conectada y se emite un presupuesto. Las pantallas de finanzas están grabadas en el entorno de desarrollo, que es donde funciona actualmente esa mitad del producto.
Las cuatro preguntas que deciden si esto es para usted
Respondido frente al código publicado, incluido allí donde el código hace menos de lo que sugiere la interfaz que lo rodea.
Dos puertas, y la segunda es la que hace que le paguen.
Solicitar entrar al programa de partners de xuda.network es una solicitud real: ciudad, rol, su trabajo público y una motivación breve, revisada por una persona. Un ambassador organiza eventos y charlas universitarias, publica al menos 2 videos al mes en su idioma nativo y capta prospectos. Un mentor hace implementación, revisión de código en pareja, 1 video técnico al mes y un proyecto de referencia trimestral. La segunda puerta importa más de lo que parece: tanto si vende un anuncio como si gana comisión como partner, el dinero se mueve a través de una cuenta de Stripe conectada, y hasta que esa cuenta exista y esté activa la plataforma no tiene dónde enviarlo. Configúrela en facturación antes de publicar nada, no después de su primera venta.