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_reference
in 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_reference
param 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.
This doesnāt directly solve the problem, but itās close: Discourse Subscriptions
Ignoring possible legal issues, there are existing online subscription services that could likely be used to meet the OPās requirements with little to no code. For example, a service like Zapier could act as the intermediary between a subscription service and a Discourse forum. It could add and remove users from Discourse groups based on their subscriptions.
Iām sure it could also be accomplished with Discourse/WordPress integration and a bit of custom development.
From looking into this myself, it seems that potential legal issues might be more of a stumbling block than the the technical challenges of managing group memberships based on paid subscriptions. The organizations that Iām aware of that that are doing this kind of thing now (Youtube, Paetron, Substack, X/Twitter) likely have good legal teams.
Iām unsure about the philosophical objections to monetizing access to groups/categories.
Stripe is the best platform I know of for something like that, there are many different options for how to categorize a fee for tax in different countries.
This could work for if a creator is consistently publishing newsletters, artwork, or video presentations. There are different options for copyright options to be either limited or conditional rights.
Iām not sure if this is getting off-topic, or exactly on-topic, but my understanding is that Stripe doesnāt function as the Merchant of Record (MoR.) There are other online payment processors that do function as the MoR. Iāll leave it to others to research the implications of that. This is the point where my head starts to spin and I start thinking that the technical aspects of monetizing group access are a lot less daunting than the legal aspects of it
Iām not familiar with what exactly that means for a payment processor to function as a āMerchant of Record,ā are you talking about a Merchant Identification Number?
It is true I donāt have that with Stripe, only a confusing account number that is a mix of numbers and letters. Other payment processor Elavon gives merchants a 10 digit merchant ID#, which may mean they do act as Merchant of Record but I donāt know what that means.
With the original topic of monetizing access to a group, for that to work really depends on what is the group about or for, with a discourse page that could mean both for subscribing to what another creator is producing as well as the opportunity for people to be able to publish their own material with someone elseās forum.
With the standard tier hosting costing $100 a month, this is more affordable if ten people want to pay $10 a month to have accounts with a hosted forum that would cover the cost.
Other services like google workspace cost $7 a month per user and business e-mail is generally about $13 a month, stripe or another payment platform could be used to collect user fees for that which donāt generate any profit but just cover the cost to run a group communication system.
This is a good site policy question, for many sites probably no that wouldnāt make sense.
Often there are policies of no self-promotion or posting advertising so generally any kind of attempt at sales by third parties would probably be prohibited by most administrators.
With the marketplace category for Meta that looks like it is only for posting offers for paid work, not anyone asking money for group access or trying to offer service for pay or to sell anything?
There is also the policy that any marketplace offer must be public and not in closed messaging that seems like a good policy.
This:
A merchant of record (MoR) is a legal entity responsible for selling goods or services to an end customer . They handle all payments and take on the associated liabilities, such as collecting sales tax, ensuring Payment Card Industry (PCI) compliance, and honoring refunds and chargebacks.
In terms of why it would make sense to allow group owners charge for group memberships and access to Discourse categories, the most obvious answer is because the ācreatorā economy is huge and Discourse has the potential to operate in that space. The creator economy is all about community. Discourse is a tool for building communities, so it would be a good fit for the space.
A more speculative answer is that I think thereās a trend towards crowdfunding and patronage for funding activities that fall outside of the normal creator economy.
A Discourse based, category level subscription service also might be the easiest way to profitably provide free Discourse hosting. Iām assuming that the forum owner would take a cut of the profits. Substack is a good model of how this could work.
The point thatās raised earlier in this topic that Discourse aims to promote decentralization on the web is valid. But thereās a possible middle ground. Discourse is open source software and has tools that allow for exporting and importing categories. A group owner on a particular forum could be given the ability to export their community if they wished. Similar to (but easier than) the way the owner of a physical business can move their store to a new location.
PCI compliance is very confusing and difficult, I went through some of the forms for that when I set up a merchant service account with local bank. Their card readers use a closed encrypted system which probably means they do take on the legal risk of being a MoR, which I believe you are correct to say is not the case for stripe.
If anyone is processing payment card information on independent servers there are pages and pages of regulations to go through with all of the security requirements, those are heavy and there are steep fines for failures.
This is an interesting idea, not sure how that could be done.
Manually a new forum could be started from the backup of previous, excluding everything except the category someone wanted to export. Would that work, or there would be some other way?
Discourse has rake tasks for importing and exporting categories and groups: https://meta.discourse.org/t/administrative-bulk-operations/118349#exportimport-categories-10. I donāt believe this could be used to export group PMs, but it would handle importing/exporting group members and group activity that occurred in regular categories.
Oh ok, good to know it has that capability.