Is it possible for users to charge a fee to permit other users access to their groups, and related group materials? I know it is not an off-the-shelf feature, but is it possible?
Paid group membership (in turn granting access to specific categories) is an existing feature. Take a look in #plugins
Examples include Patreon, Procourse Memberships and Subscriptia.
If you have an existing website which handles such memberships you can also deliver group membership information via your SSO payload.
Users can’t charge others fees directly on a site they don’t own, would it make sense for them to even be able to?
6 Me gusta
Thanks for the reply, @Stephen. I am aware of the examples that you’ve included, as well as the sso option.
Would it make sense? Anything can make sense. Imagine a lively forum with great content creators coming together for discourse and solving problems; however, they could also create private groups that only paying members could access. This way, the forum participants could monetize their activity on the forum, and the forum owner could monetize with a split/commission. Win-win-win.
I’m only curious if this is possible. @angus, generally speaking (not looking for a quote here), does something like this seem possible?
Please don’t tag people.
There are lots of implications here to be considered, and examples of how users can be connected to service providers without writing any code. Take the marketplace for example, users are connected to consultants without the need for special code or payment processing.
Managing these kinds of transactions is a very tricky and risky process. Within the EU and US you also have to consider the many money laundering laws.
A lot of people come up with this idea, but in the end any creator can have their own Discourse for $5 a month and skip the middleman fee. Which is a great thing, one of the core missions of Discourse is to promote decentralization on the web.
4 Me gusta
Thanks for the reply, @Falco. Indeed creators can start-up their own discourse; however, having one discourse with many creators discussing with one another, then offering specialized materials for fee, would create a platform that lets people find the creator in the first place. That would be the value. I’m gathering that this type of functionality is not possible. Thanks for the feedback!
The functionality is completely possible. Obviously, you will need to fund the development of it. I think with $10K you can get a modified ProCourse Memberships 💸 to have multiple “memberships” members can buy would do it. Each membership gives access to a group, each group access to a category.
4 Me gusta
@Joshua_Kogan You could do this right now in two different ways using the Custom Wizard plugin.
Take payment externally
One method would be to send the user to a payment provider upon submission of one step of a custom wizard, ensure the payment is completed using a combination of permitted params and required data, then add the user to a group on a subsequent step (using the “Add to Group” action).
This is a full description of the payment piece of this approach. The add to group piece should be self explanatory:
Send user to payment provider setup
- Route To Action . There’s a new action type called “Route To” that allows you to send a user to a destination url upon submission of a step. For your wizards, the action should be added to whatever step precedes the user’s payment. Currently they’re added to the ‘payment’ step itself, but you can remove this step and add them to the preceding step if you like.The route to action currently has two settings:
-
url: This is the destination url. As with other wizard inputs, you can interpolate data using w{} for wizard fields and u{} for user fields.
-
code: A unique code to add as a parameter to the destination url. When this setting is filled the custom wizard will generate a unique random hex string that it:
- adds to the url as an addtional query param using the key you provide; and
- saves the code in the submission data using the key you provide
Associating a unique key with each request allows any callback for that request (i.e. when the user returns to the wizard) to be validated. In the chargify case, chargify will store any value you send in the parameter ‘reference’ (see further), which you can then add to the ‘return url’ what chargify redirects the user to after they’ve completed payment.
-
Permitted Params . This a new step setting that allows you to specify what query params are permitted for the step and the key they should be saved with in the submission data. You can use this to both save statistical or analytical data (such as where the user has entered the wizard from), and for callbacks. In the chargify case we passed the ‘reference’ code to chargify (and saved it in the submission data) when we redirected the user to chargify to complete payment. We would then add this code to the ‘return url’ as a return parameter which we then save to the submissions by adding whatever paramter we specify as holding the
customer_referencein the return paramters.Note that in chargify you’ll need to set the ‘return url’ to url of the step after the step you attached the ‘route to’ action to. This means that you’ll be adding thecustomer_referenceparam as a permitted paramter to that same step. -
Required Data . This is a new step setting that allows you to impose a data check before allowing a user to view the step. Currently you can require a piece of submission data to equal another piece of submission data.If the user tries to load the step and the required data check fails, they’ll see an error message. In the chargify case we’ll use this to require the code we created in the “Route To” action to equal the customer_reference returned by chargify.You can customise the error message show to users using the “Message show when data not present” field in the wizard admin. Additionally, there is a “Restart Wizard” link appended to the error message allowing the user to reset the wizard to step 1 and clear existing inputs.
Take payment internally
You can use ProCourse Memberships to take payment.
You can also use almost any payment provider if they have an API that supports OAuth2, or Basic authorization (Stripe uses Basic authorization for exmple), by setting up an API connection using the Custom Wizard’s “Send to API” action and associated API endpoint management system. How you set this up will depend on the provider. This approach is less stable; it’s a feature in beta, but it has significant potential.
6 Me gusta
Esto no resuelve el problema directamente, pero está cerca: Discourse Subscriptions Plugin
Ignorando los posibles problemas legales, existen servicios de suscripción en línea que probablemente podrían usarse para cumplir con los requisitos del OP con poco o ningún código. Por ejemplo, un servicio como Zapier podría actuar como intermediario entre un servicio de suscripción y un foro de Discourse. Podría agregar y eliminar usuarios de grupos de Discourse según sus suscripciones.
Estoy seguro de que también se podría lograr con la integración de Discourse/WordPress y un poco de desarrollo personalizado.
Por lo que he investigado, parece que los posibles problemas legales podrían ser un obstáculo mayor que los desafíos técnicos de administrar membresías de grupos basadas en suscripciones pagas. Las organizaciones que conozco que hacen este tipo de cosas ahora (Youtube, Paetron, Substack, X/Twitter) probablemente tengan buenos equipos legales.
No estoy seguro de las objeciones filosóficas a la monetización del acceso a grupos/categorías.
3 Me gusta
Stripe es la mejor plataforma que conozco para algo así, hay muchas opciones diferentes sobre cómo categorizar una tarifa para impuestos en diferentes países.
Esto podría funcionar si un creador publica constantemente boletines informativos, obras de arte o presentaciones en video. Existen diferentes opciones para los derechos de autor, ya sean derechos limitados o condicionales.
No estoy seguro de si esto se está desviando del tema o si está exactamente en el tema, pero entiendo que Stripe no funciona como el Comerciante Registrado (MoR). Hay otros procesadores de pagos en línea que sí funcionan como el MoR. Dejaré que otros investiguen las implicaciones de eso. Este es el punto en el que mi cabeza empieza a dar vueltas y empiezo a pensar que los aspectos técnicos de la monetización del acceso grupal son mucho menos desalentadores que los aspectos legales de ello 
2 Me gusta
No estoy familiarizado con lo que significa exactamente que un procesador de pagos funcione como un “Comerciante Registrado”. ¿Se refieren a un Número de Identificación de Comerciante?
Es cierto que no tengo eso con Stripe, solo un número de cuenta confuso que es una mezcla de números y letras. Otro procesador de pagos, Elavon, proporciona a los comerciantes un ID de comerciante de 10 dígitos, lo que podría significar que actúan como Comerciante Registrado, pero no sé qué significa eso.
Con el tema original de monetizar el acceso a un grupo, para que eso funcione realmente depende de qué sea el grupo o para qué sea. Con una página de discusión, eso podría significar tanto suscribirse a lo que otro creador está produciendo como la oportunidad para que las personas publiquen su propio material en el foro de otra persona.
Con el nivel estándar de alojamiento que cuesta $100 al mes, esto es más asequible si diez personas quieren pagar $10 al mes para tener cuentas en un foro alojado que cubra el costo.
Otros servicios como Google Workspace cuestan $7 al mes por usuario y el correo electrónico comercial generalmente cuesta alrededor de $13 al mes. Stripe u otra plataforma de pago podrían usarse para cobrar las tarifas de usuario por eso, que no generan ninguna ganancia, sino que solo cubren el costo de administrar un sistema de comunicación grupal.
Esta es una buena pregunta sobre la política del sitio, para muchos sitios probablemente no tendría sentido.
A menudo existen políticas de no autopromoción o de publicación de publicidad, por lo que, en general, cualquier intento de venta por parte de terceros probablemente estaría prohibido por la mayoría de los administradores.
Con la categoría Marketplace para Meta, parece que es solo para publicar ofertas de trabajo remunerado, ¿no para cualquiera que pida dinero por acceso a un grupo o intente ofrecer un servicio de pago o vender algo?
También existe la política de que cualquier oferta del mercado debe ser pública y no en mensajes cerrados, lo que parece una buena política.
Esto:
Un comerciante registrado (MoR) es una entidad legal responsable de vender bienes o servicios a un cliente final. Se encargan de todos los pagos y asumen las responsabilidades asociadas, como la recaudación del impuesto sobre las ventas, la garantía del cumplimiento de la industria de tarjetas de pago (PCI) y la gestión de reembolsos y contracargos.
En cuanto a por qué tendría sentido permitir que los propietarios de grupos cobren por las membresías de grupo y el acceso a las categorías de Discourse, la respuesta más obvia es porque la economía del “creador” es enorme y Discourse tiene el potencial de operar en ese espacio. La economía del creador se basa en la comunidad. Discourse es una herramienta para construir comunidades, por lo que encajaría bien en ese espacio.
Una respuesta más especulativa es que creo que hay una tendencia hacia la financiación colectiva y el patrocinio para financiar actividades que quedan fuera de la economía habitual del creador.
Un servicio de suscripción a nivel de categoría basado en Discourse también podría ser la forma más fácil de ofrecer alojamiento gratuito de Discourse de manera rentable. Supongo que el propietario del foro se llevaría una parte de las ganancias. Substack es un buen modelo de cómo esto podría funcionar.
El punto que se plantea anteriormente en este tema de que Discourse tiene como objetivo promover la descentralización en la web es válido. Pero existe un posible punto intermedio. Discourse es un software de código abierto y tiene herramientas que permiten exportar e importar categorías. Se le podría dar al propietario de un grupo en un foro particular la capacidad de exportar su comunidad si lo deseara. Similar a (pero más fácil que) la forma en que el propietario de un negocio físico puede trasladar su tienda a una nueva ubicación.
1 me gusta
El cumplimiento de PCI es muy confuso y difícil. Revisé algunos de los formularios para eso cuando abrí una cuenta de servicio comercial con un banco local. Sus lectores de tarjetas utilizan un sistema encriptado cerrado, lo que probablemente significa que asumen el riesgo legal de ser un MoR, lo cual creo que es correcto al decir que no es el caso de Stripe.
Si alguien está procesando información de tarjetas de pago en servidores independientes, hay páginas y páginas de regulaciones que revisar con todos los requisitos de seguridad, que son pesados y existen fuertes multas por incumplimiento.
Esta es una idea interesante, no estoy seguro de cómo se podría hacer.
Manualmente, se podría iniciar un nuevo foro a partir de la copia de seguridad anterior, excluyendo todo excepto la categoría que alguien quisiera exportar. ¿Funcionaría eso, o habría alguna otra manera?
1 me gusta
Discourse tiene tareas rake para importar y exportar categorías y grupos: https://meta.discourse.org/t/administrative-bulk-operations/118349#exportimport-categories-10. No creo que esto se pueda usar para exportar PMs de grupo, pero manejaría la importación/exportación de miembros de grupo y la actividad de grupo que ocurrió en categorías regulares.
Oh ok, bueno saber que tiene esa capacidad.