Est-il possible pour les utilisateurs de demander des frais afin d’autoriser l’accès à leurs groupes et aux ressources associées ? Je sais qu’il ne s’agit pas d’une fonctionnalité standard, mais est-ce réalisable ?
L’adhésion payante à un groupe (qui accorde ensuite l’accès à des catégories spécifiques) est une fonctionnalité existante. Jetez un coup d’œil dans #plugins.
Des exemples incluent Patreon, Procourse Memberships et Subscriptia.
Si vous disposez d’un site web existant qui gère ce type d’adhésions, vous pouvez également transmettre les informations d’adhésion au groupe via votre charge utile SSO.
Les utilisateurs ne peuvent pas facturer directement des frais à d’autres sur un site qu’ils ne possèdent pas. Aurait-il même du sens qu’ils en soient capables ?
Merci pour ta réponse, @Stephen. Je connais les exemples que tu as inclus, ainsi que l’option SSO.
Est-ce que cela aurait du sens ? Tout peut avoir du sens. Imaginez un forum animé où de grands créateurs de contenu se réunissent pour débattre et résoudre des problèmes ; ils pourraient également créer des groupes privés accessibles uniquement aux membres payants. De cette façon, les participants du forum pourraient monétiser leur activité, et le propriétaire du forum pourrait le faire via un partage de revenus ou une commission. Gagnant-gagnant-gagnant.
Je me demande simplement si c’est possible. @angus, d’une manière générale (je ne cherche pas une citation ici), est-ce que quelque chose comme cela semble possible ?
Veuillez ne pas taguer les personnes.
Il y a de nombreuses implications à prendre en compte ici, ainsi que des exemples de la manière dont les utilisateurs peuvent être connectés à des prestataires de services sans écrire le moindre code. Prenons l’exemple du Marketplace : les utilisateurs sont connectés à des consultants sans avoir besoin de code spécial ni de traitement des paiements.
Gérer ce type de transactions est un processus très délicat et risqué. Dans l’UE et aux États-Unis, vous devez également tenir compte des nombreuses lois contre le blanchiment d’argent.
Beaucoup de gens ont cette idée, mais au final, tout créateur peut avoir son propre Discourse pour 5 $ par mois et éviter les frais d’intermédiaire. Ce qui est une excellente chose : l’une des missions fondamentales de Discourse est de promouvoir la décentralisation sur le web.
Merci pour ta réponse, @Falco. En effet, les créateurs peuvent lancer leur propre forum Discourse ; cependant, avoir un seul forum où de nombreux créateurs échangent entre eux, puis proposer du contenu spécialisé payant, permettrait de créer une plateforme qui aide les gens à trouver les créateurs dès le départ. C’est là que réside la valeur. Je comprends que ce type de fonctionnalité n’est pas possible. Merci pour ton retour !
Cette fonctionnalité est tout à fait réalisable. Évidemment, vous devrez financer son développement. Je pense qu’avec 10 000 $, vous pouvez obtenir une version modifiée de ProCourse Memberships 💸 permettant d’offrir plusieurs « abonnements » que les membres peuvent acheter. Chaque abonnement donne accès à un groupe, et chaque groupe donne accès à une catégorie.
@Joshua_Kogan Vous pouvez le faire dès maintenant de deux manières différentes en utilisant le plugin Custom Wizard.
Effectuer le paiement en externe
Une méthode consisterait à rediriger l’utilisateur vers un fournisseur de paiement lors de la soumission d’une étape d’un assistant personnalisé, à s’assurer que le paiement est effectué en combinant des paramètres autorisés et des données requises, puis à ajouter l’utilisateur à un groupe lors d’une étape ultérieure (en utilisant l’action « Ajouter au groupe »).
Voici une description complète de la partie paiement de cette approche. La partie « ajouter au groupe » devrait être évidente :
Configuration de la redirection de l'utilisateur vers le fournisseur de paiement
- Route To Action (Action de redirection). Il existe un nouveau type d’action appelé « Route To » qui vous permet d’envoyer un utilisateur vers une URL de destination lors de la soumission d’une étape. Pour vos assistants, l’action doit être ajoutée à l’étape qui précède le paiement de l’utilisateur. Actuellement, elles sont ajoutées à l’étape « payment » elle-même, mais vous pouvez supprimer cette étape et les ajouter à l’étape précédente si vous le souhaitez. L’action « Route To » dispose actuellement de deux paramètres :
-
url : Il s’agit de l’URL de destination. Comme pour les autres entrées de l’assistant, vous pouvez interpoler des données en utilisant w{} pour les champs de l’assistant et u{} pour les champs de l’utilisateur.
-
code : Un code unique à ajouter en tant que paramètre à l’URL de destination. Lorsque ce paramètre est rempli, l’assistant personnalisé génère une chaîne hexadécimale aléatoire unique qu’il :
- ajoute à l’URL en tant que paramètre de requête supplémentaire en utilisant la clé que vous fournissez ; et
- enregistre le code dans les données de soumission en utilisant la clé que vous fournissez
Associer une clé unique à chaque demande permet de valider tout rappel pour cette demande (c’est-à-dire lorsque l’utilisateur revient vers l’assistant). Dans le cas de Chargify, Chargify stockera toute valeur que vous envoyez dans le paramètre « reference » (voir plus loin), que vous pourrez ensuite ajouter à l’« URL de retour » vers laquelle Chargify redirigera l’utilisateur après qu’il aura terminé le paiement.
-
Permitted Params (Paramètres autorisés). Il s’agit d’un nouveau paramètre d’étape qui vous permet de spécifier quels paramètres de requête sont autorisés pour l’étape et la clé sous laquelle ils doivent être enregistrés dans les données de soumission. Vous pouvez l’utiliser pour enregistrer à la fois des données statistiques ou analytiques (telles que l’endroit où l’utilisateur a entré l’assistant) et pour les rappels. Dans le cas de Chargify, nous avons transmis le code « reference » à Chargify (et l’avons enregistré dans les données de soumission) lorsque nous avons redirigé l’utilisateur vers Chargify pour effectuer le paiement. Nous ajouterions ensuite ce code à l’« URL de retour » en tant que paramètre de retour, que nous enregistrerions ensuite dans les soumissions en ajoutant le paramètre que nous spécifions comme contenant le
customer_referencedans les paramètres de retour. Notez que dans Chargify, vous devrez définir l’« URL de retour » sur l’URL de l’étape suivant l’étape à laquelle vous avez attaché l’action « route to ». Cela signifie que vous ajouterez le paramètrecustomer_referenceen tant que paramètre autorisé à cette même étape. -
Required Data (Données requises). Il s’agit d’un nouveau paramètre d’étape qui vous permet d’imposer une vérification des données avant d’autoriser un utilisateur à afficher l’étape. Actuellement, vous pouvez exiger qu’un élément de données de soumission soit égal à un autre élément de données de soumission. Si l’utilisateur tente de charger l’étape et que la vérification des données requises échoue, il verra un message d’erreur. Dans le cas de Chargify, nous l’utiliserons pour exiger que le code créé dans l’action « Route To » soit égal au
customer_referencerenvoyé par Chargify. Vous pouvez personnaliser le message d’erreur affiché aux utilisateurs en utilisant le champ « Message affiché lorsque les données sont absentes » dans l’administration de l’assistant. De plus, un lien « Redémarrer l’assistant » est ajouté au message d’erreur, permettant à l’utilisateur de réinitialiser l’assistant à l’étape 1 et d’effacer les saisies existantes.
Effectuer le paiement en interne
Vous pouvez utiliser ProCourse Memberships pour effectuer le paiement.
Vous pouvez également utiliser presque n’importe quel fournisseur de paiement s’il dispose d’une API prenant en charge OAuth2 ou l’autorisation de base (Stripe utilise par exemple l’autorisation de base), en configurant une connexion API à l’aide de l’action « Send to API » de Custom Wizard et du système de gestion des points de terminaison API associé. La manière dont vous configurez cela dépendra du fournisseur. Cette approche est moins stable ; il s’agit d’une fonctionnalité en version bêta, mais elle présente un potentiel significatif.
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.
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 
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.
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 ?
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é.