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?
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.
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.
@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.
Questo non risolve direttamente il problema, ma ci si avvicina: Discourse Subscriptions Plugin
Ignorando le possibili questioni legali, esistono servizi di abbonamento online esistenti che potrebbero probabilmente essere utilizzati per soddisfare i requisiti dellâOP con poco o nessun codice. Ad esempio, un servizio come Zapier potrebbe fungere da intermediario tra un servizio di abbonamento e un forum Discourse. Potrebbe aggiungere e rimuovere utenti dai gruppi Discourse in base ai loro abbonamenti.
Sono sicuro che potrebbe anche essere realizzato con lâintegrazione Discourse/WordPress e un poâ di sviluppo personalizzato.
Dalle mie ricerche, sembra che i potenziali problemi legali potrebbero essere un ostacolo maggiore rispetto alle sfide tecniche di gestione delle appartenenze ai gruppi basate su abbonamenti a pagamento. Le organizzazioni che conosco che stanno facendo questo tipo di cose ora (Youtube, Paetron, Substack, X/Twitter) probabilmente hanno buoni team legali.
Non sono sicuro delle obiezioni filosofiche alla monetizzazione dellâaccesso a gruppi/categorie.
Stripe è la migliore piattaforma che conosco per qualcosa del genere, ci sono molte opzioni diverse su come classificare una commissione per le tasse in diversi paesi.
Questo potrebbe funzionare se un creatore pubblica costantemente newsletter, opere dâarte o presentazioni video. Ci sono diverse opzioni per i diritti dâautore, che possono essere diritti limitati o condizionali.
Non sono sicuro se questo stia andando fuori tema, o esattamente in tema, ma per quanto ne so Stripe non funziona come Merchant of Record (MoR). Ci sono altri processori di pagamento online che funzionano come MoR. Lascerò ad altri la ricerca delle implicazioni di ciò. Questo è il punto in cui la mia testa inizia a girare e inizio a pensare che gli aspetti tecnici della monetizzazione dellâaccesso di gruppo siano molto meno scoraggianti degli aspetti legali ![]()
Non ho familiaritĂ con cosa significhi esattamente per un processore di pagamento funzionare come âMerchant of Recordâ, stai parlando di un Merchant Identification Number?
à vero che non ho quello con Stripe, solo un numero di conto confuso che è un mix di numeri e lettere. Un altro processore di pagamento, Elavon, fornisce ai commercianti un ID commerciante di 10 cifre, il che potrebbe significare che agiscono come Merchant of Record, ma non so cosa significhi.
Tornando allâargomento originale della monetizzazione dellâaccesso a un gruppo, affinchĂŠ ciò funzioni dipende da cosa riguarda o a cosa serve il gruppo; con una pagina di discussione, ciò potrebbe significare sia lâiscrizione a ciò che un altro creatore sta producendo, sia lâopportunitĂ per le persone di pubblicare il proprio materiale nel forum di qualcun altro.
Con lâhosting di livello standard che costa $100 al mese, questo è piĂš conveniente se dieci persone vogliono pagare $10 al mese per avere account con un forum ospitato che copra il costo.
Altri servizi come Google Workspace costano $7 al mese per utente e lâe-mail aziendale costa generalmente circa $13 al mese; Stripe o unâaltra piattaforma di pagamento potrebbero essere utilizzate per riscuotere le quote degli utenti per questo, che non generano alcun profitto ma coprono solo il costo per gestire un sistema di comunicazione di gruppo.
Questa è una buona domanda sulla policy del sito, per molti siti probabilmente no, non avrebbe senso.
Spesso ci sono policy di non auto-promozione o di pubblicazione di pubblicitĂ , quindi in generale qualsiasi tentativo di vendita da parte di terzi sarebbe probabilmente proibito dalla maggior parte degli amministratori.
Con la categoria Marketplace per Meta, sembra che sia solo per la pubblicazione di offerte di lavoro retribuito, non per chiunque chieda denaro per lâaccesso a un gruppo o tenti di offrire servizi a pagamento o di vendere qualcosa?
Câè anche la policy secondo cui qualsiasi offerta del marketplace deve essere pubblica e non in messaggistica chiusa, il che sembra una buona policy.
Questo:
Un merchant of record (MoR) è unâentitĂ legale responsabile della vendita di beni o servizi a un cliente finale. Gestisce tutti i pagamenti e si assume le relative responsabilitĂ , come la riscossione delle imposte sulle vendite, la garanzia della conformitĂ al Payment Card Industry (PCI) e lâonorare rimborsi e chargeback.
In termini di perchĂŠ avrebbe senso consentire ai proprietari di gruppi di addebitare le quote di iscrizione ai gruppi e lâaccesso alle categorie di Discourse, la risposta piĂš ovvia è che lâeconomia dei âcreatoriâ è enorme e Discourse ha il potenziale per operare in questo spazio. Lâeconomia dei creatori riguarda la community. Discourse è uno strumento per costruire community, quindi si adatterebbe bene a questo spazio.
Una risposta piÚ speculativa è che penso ci sia una tendenza verso il crowdfunding e il mecenatismo per finanziare attività che esulano dalla normale economia dei creatori.
Un servizio di abbonamento basato su Discourse, a livello di categoria, potrebbe anche essere il modo piÚ semplice per fornire gratuitamente hosting Discourse in modo redditizio. Presumo che il proprietario del forum otterrebbe una parte dei profitti. Substack è un buon modello di come questo potrebbe funzionare.
Il punto sollevato in precedenza in questo argomento, ovvero che Discourse mira a promuovere la decentralizzazione sul web, è valido. Ma câè una possibile via di mezzo. Discourse è un software open source e dispone di strumenti che consentono lâesportazione e lâimportazione di categorie. A un proprietario di gruppo su un particolare forum potrebbe essere data la possibilitĂ di esportare la propria community, se lo desiderasse. Simile a (ma piĂš facile di) il modo in cui il proprietario di unâattivitĂ fisica può spostare il proprio negozio in una nuova sede.
La conformità PCI è molto confusa e difficile, ho esaminato alcuni dei moduli per questo quando ho aperto un conto di servizi per commercianti con la banca locale. I loro lettori di carte utilizzano un sistema crittografato chiuso, il che probabilmente significa che si assumono il rischio legale di essere un MoR, cosa che credo tu abbia ragione a dire non sia il caso per Stripe.
Se qualcuno sta elaborando informazioni sulle carte di pagamento su server indipendenti, ci sono pagine e pagine di regolamenti da esaminare con tutti i requisiti di sicurezza, questi sono pesanti e ci sono multe salate per le inadempienze.
Questa è unâidea interessante, non sono sicuro di come potrebbe essere realizzata.
Manualmente, un nuovo forum potrebbe essere avviato dal backup di uno precedente, escludendo tutto tranne la categoria che qualcuno desidera esportare. Funzionerebbe, o ci sarebbe un altro modo?
Discourse ha attivitĂ rake per importare ed esportare categorie e gruppi: https://meta.discourse.org/t/administrative-bulk-operations/118349#exportimport-categories-10. Non credo che questo possa essere utilizzato per esportare messaggi privati di gruppo, ma gestirebbe lâimportazione/esportazione di membri di gruppo e attivitĂ di gruppo che si sono verificate in categorie regolari.
Ok, bene sapere che ha tale funzionalitĂ .

