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 « J'aime »
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 « J'aime »
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 « J'aime »
@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 « J'aime »
Cela ne résout pas directement le problème, mais c’est proche : Discourse Subscriptions Plugin
En ignorant les problèmes juridiques possibles, il existe des services d’abonnement en ligne qui pourraient probablement être utilisés pour répondre aux exigences de l’OP avec peu ou pas de code. Par exemple, un service comme Zapier pourrait servir d’intermédiaire entre un service d’abonnement et un forum Discourse. Il pourrait ajouter et supprimer des utilisateurs des groupes Discourse en fonction de leurs abonnements.
Je suis sûr que cela pourrait également être réalisé avec une intégration Discourse/WordPress et un peu de développement personnalisé.
D’après mes recherches, il semble que les problèmes juridiques potentiels pourraient être un obstacle plus important que les défis techniques de gestion des adhésions aux groupes basées sur des abonnements payants. Les organisations que je connais qui font ce genre de choses maintenant (Youtube, Paetron, Substack, X/Twitter) ont probablement de bonnes équipes juridiques.
Je ne suis pas sûr des objections philosophiques à la monétisation de l’accès aux groupes/catégories.
3 « J'aime »
Stripe est la meilleure plateforme que je connaisse pour ce genre de chose, il existe de nombreuses options différentes pour catégoriser des frais pour les impôts dans différents pays.
Cela pourrait fonctionner si un créateur publie régulièrement des newsletters, des œuvres d’art ou des présentations vidéo. Il existe différentes options pour les droits d’auteur, qu’ils soient limités ou conditionnels.
Je ne suis pas sûr si cela sort du sujet, ou si c’est exactement le sujet, mais d’après ce que je comprends, Stripe ne fonctionne pas comme le Marchand Enregistré (MoR). Il existe d’autres processeurs de paiement en ligne qui fonctionnent comme le MoR. Je laisse aux autres le soin de rechercher les implications de cela. C’est là que ma tête commence à tourner et que je commence à penser que les aspects techniques de la monétisation de l’accès de groupe sont beaucoup moins intimidants que les aspects juridiques de celui-ci 
2 « J'aime »
Je ne suis pas familier avec ce que signifie exactement pour un processeur de paiement de fonctionner comme un « Marchand Enregistré », parlez-vous d’un numéro d’identification de marchand ?
Il est vrai que je n’ai pas cela avec Stripe, seulement un numéro de compte confus qui est un mélange de chiffres et de lettres. Un autre processeur de paiement, Elavon, donne aux marchands un numéro d’identification de marchand à 10 chiffres, ce qui pourrait signifier qu’ils agissent en tant que Marchand Enregistré, mais je ne sais pas ce que cela signifie.
Concernant le sujet initial de la monétisation de l’accès à un groupe, cela dépend vraiment de ce que le groupe concerne ou de son objectif. Avec une page de discussion, cela pourrait signifier à la fois s’abonner à ce qu’un autre créateur produit, ainsi que l’opportunité pour les gens de publier leur propre matériel sur le forum de quelqu’un d’autre.
Avec un hébergement de niveau standard coûtant 100 par mois, cela devient plus abordable si dix personnes veulent payer 10 par mois pour avoir des comptes sur un forum hébergé qui couvrirait le coût.
D’autres services comme Google Workspace coûtent 7 par mois par utilisateur et la messagerie professionnelle coûte généralement environ 13 par mois. Stripe ou une autre plateforme de paiement pourrait être utilisée pour collecter les frais d’utilisation pour cela, ce qui ne génère aucun profit mais couvre simplement le coût de fonctionnement d’un système de communication de groupe.
C’est une bonne question de politique de site, pour de nombreux sites, cela n’aurait probablement pas de sens.
Souvent, il existe des politiques de non-auto-promotion ou de publication de publicité, donc généralement toute tentative de vente par des tiers serait probablement interdite par la plupart des administrateurs.
Avec la catégorie Marketplace pour Meta, cela ressemble à une publication d’offres de travail rémunéré uniquement, et non à quelqu’un demandant de l’argent pour l’accès à un groupe ou essayant d’offrir un service payant ou de vendre quoi que ce soit ?
Il y a aussi la politique selon laquelle toute offre de marketplace doit être publique et non dans la messagerie fermée, ce qui semble être une bonne politique.
Ceci :
Un marchand enregistré (MoR) est une entité juridique responsable de la vente de biens ou de services à un client final. Il gère tous les paiements et assume les responsabilités associées, telles que la collecte de la taxe de vente, la garantie de la conformité à la norme PCI (Payment Card Industry) et le traitement des remboursements et des rétrofacturations.
Quant à savoir pourquoi il serait logique de permettre aux propriétaires de groupes de facturer les adhésions aux groupes et l’accès aux catégories Discourse, la réponse la plus évidente est que l’économie des « créateurs » est énorme et que Discourse a le potentiel d’opérer dans cet espace. L’économie des créateurs est axée sur la communauté. Discourse est un outil pour construire des communautés, il serait donc bien adapté à cet espace.
Une réponse plus spéculative est que je pense qu’il y a une tendance vers le financement participatif et le patronage pour financer des activités qui sortent de l’économie des créateurs habituelle.
Un service d’abonnement basé sur Discourse, au niveau des catégories, pourrait également être le moyen le plus simple de fournir un hébergement Discourse gratuit et rentable. Je suppose que le propriétaire du forum prendrait une part des bénéfices. Substack est un bon modèle de la façon dont cela pourrait fonctionner.
L’argument soulevé plus tôt dans ce sujet selon lequel Discourse vise à promouvoir la décentralisation sur le web est valable. Mais il existe un terrain d’entente possible. Discourse est un logiciel open source et dispose d’outils permettant d’exporter et d’importer des catégories. Un propriétaire de groupe sur un forum particulier pourrait se voir accorder la possibilité d’exporter sa communauté s’il le souhaitait. Similaire (mais plus facile) à la façon dont le propriétaire d’une entreprise physique peut déplacer son magasin vers un nouvel emplacement.
1 « J'aime »
La conformité PCI est très déroutante et difficile. J’ai examiné certains des formulaires à cet effet lorsque j’ai ouvert un compte de service marchand auprès de ma banque locale. Leurs lecteurs de cartes utilisent un système crypté fermé, ce qui signifie probablement qu’ils assument le risque juridique d’être un MoR (Merchant of Record), ce qui, je crois, est correct de dire que ce n’est pas le cas pour Stripe.
Si quelqu’un traite des informations de carte de paiement sur des serveurs indépendants, il y a des pages et des pages de réglementations à examiner avec toutes les exigences de sécurité, celles-ci sont lourdes et il y a de lourdes amendes en cas d’échec.
C’est une idée intéressante, je ne suis pas sûr de la façon dont cela pourrait être fait.
Manuellement, un nouveau forum pourrait être créé à partir de la sauvegarde précédente, en excluant tout sauf la catégorie que quelqu’un voulait exporter. Est-ce que cela fonctionnerait, ou y aurait-il un autre moyen ?
1 « J'aime »
Discourse dispose de tâches Rake pour importer et exporter des catégories et des groupes : \u003chttps://meta.discourse.org/t/administrative-bulk-operations/118349#exportimport-categories-10\u003e. Je ne pense pas que cela puisse être utilisé pour exporter des MP de groupe, mais cela gérerait l’importation/exportation des membres de groupe et de l’activité de groupe qui s’est produite dans des catégories régulières.
Ah d’accord, c’est bien de savoir qu’il a cette capacité.