User monetization with group access?

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?

1 curtida

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 curtidas

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 curtidas

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 curtidas

@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
  1. 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.

  1. 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 the customer_reference param as a permitted paramter to that same step.

  2. 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 curtidas

Isso não resolve o problema diretamente, mas está próximo: Discourse Subscriptions Plugin

Ignorando possíveis questões legais, existem serviços de assinatura online existentes que provavelmente poderiam ser usados para atender aos requisitos do OP com pouco ou nenhum código. Por exemplo, um serviço como o Zapier poderia atuar como intermediário entre um serviço de assinatura e um fórum Discourse. Ele poderia adicionar e remover usuários de grupos Discourse com base em suas assinaturas.

Tenho certeza de que isso também poderia ser alcançado com integração Discourse/WordPress e um pouco de desenvolvimento personalizado.

Pelo que investiguei, parece que as potenciais questões legais podem ser um obstáculo maior do que os desafios técnicos de gerenciar associações de grupos com base em assinaturas pagas. As organizações que conheço que estão fazendo esse tipo de coisa agora (Youtube, Paetron, Substack, X/Twitter) provavelmente têm boas equipes jurídicas.

Não tenho certeza sobre as objeções filosóficas à monetização do acesso a grupos/categorias.

3 curtidas

O Stripe é a melhor plataforma que conheço para algo assim, existem muitas opções diferentes sobre como categorizar uma taxa para impostos em diferentes países.

Isso poderia funcionar se um criador estiver publicando consistentemente newsletters, obras de arte ou apresentações em vídeo. Existem diferentes opções para direitos autorais, que podem ser direitos limitados ou condicionais.

Não tenho certeza se isso está saindo do tópico, ou exatamente no tópico, mas entendo que a Stripe não funciona como a Merchant of Record (MoR). Existem outros processadores de pagamento online que funcionam como MoR. Deixo para outros pesquisarem as implicações disso. Este é o ponto em que minha cabeça começa a girar e começo a pensar que os aspectos técnicos de monetizar o acesso a grupos são muito menos assustadores do que os aspectos legais deles :slight_smile:

2 curtidas

Não estou familiarizado com o que exatamente significa para um processador de pagamentos funcionar como um “Merchant of Record” (Comerciante Registrado), você está falando de um Merchant Identification Number (Número de Identificação do Comerciante)?

É verdade que não tenho isso com a Stripe, apenas um número de conta confuso que é uma mistura de números e letras. Outro processador de pagamentos, Elavon, dá aos comerciantes um ID de comerciante de 10 dígitos, o que pode significar que eles atuam como Merchant of Record, mas não sei o que isso significa.

Com o tópico original de monetizar o acesso a um grupo, para que isso funcione realmente depende do que é o grupo ou para quê, com uma página de discussão isso pode significar tanto para assinar o que outro criador está produzindo quanto a oportunidade para as pessoas publicarem seu próprio material no fórum de outra pessoa.

Com o plano de hospedagem padrão custando US$ 100 por mês, isso é mais acessível se dez pessoas quiserem pagar US$ 10 por mês para ter contas em um fórum hospedado que cubra o custo.

Outros serviços como o Google Workspace custam US$ 7 por mês por usuário e o e-mail comercial geralmente custa cerca de US$ 13 por mês, a Stripe ou outra plataforma de pagamento poderia ser usada para coletar taxas de usuário para isso, que não geram lucro, mas apenas cobrem o custo para executar um sistema de comunicação em grupo.

Esta é uma boa pergunta sobre a política do site, para muitos sites provavelmente não faria sentido.

Muitas vezes existem políticas de não auto-promoção ou postagem de publicidade, então, geralmente, qualquer tipo de tentativa de vendas por terceiros provavelmente seria proibida pela maioria dos administradores.

Com a categoria Marketplace para Meta, parece que é apenas para postar ofertas de trabalho pago, não para alguém pedindo dinheiro pelo acesso a um grupo ou tentando oferecer serviços pagos ou vender algo?

Há também a política de que qualquer oferta de marketplace deve ser pública e não em mensagens fechadas, o que parece ser uma boa política.

Isso:

Um Merchant of Record (MoR) é uma entidade legal responsável por vender bens ou serviços a um cliente final. Eles lidam com todos os pagamentos e assumem as responsabilidades associadas, como a coleta de impostos sobre vendas, garantia de conformidade com o Padrão de Segurança de Dados da Indústria de Cartões de Pagamento (PCI) e o processamento de reembolsos e estornos.

Em termos de por que faria sentido permitir que os proprietários de grupos cobrassem por assinaturas de grupos e acesso a categorias do Discourse, a resposta mais óbvia é porque a economia do “criador” é enorme e o Discourse tem o potencial de operar nesse espaço. A economia do criador é sobre comunidade. O Discourse é uma ferramenta para construir comunidades, então seria uma boa opção para o espaço.

Uma resposta mais especulativa é que acredito que há uma tendência em direção ao crowdfunding e ao patrocínio para financiar atividades que ficam fora da economia normal do criador.

Um serviço de assinatura baseado em Discourse, em nível de categoria, também pode ser a maneira mais fácil de fornecer hospedagem gratuita de Discourse de forma lucrativa. Estou assumindo que o proprietário do fórum receberia uma parte dos lucros. O Substack é um bom modelo de como isso poderia funcionar.

O ponto levantado anteriormente neste tópico de que o Discourse visa promover a descentralização na web é válido. Mas há um possível meio-termo. O Discourse é um software de código aberto e possui ferramentas que permitem exportar e importar categorias. Um proprietário de grupo em um fórum específico poderia ter a capacidade de exportar sua comunidade, se assim desejasse. Semelhante a (mas mais fácil do que) a maneira como o proprietário de um negócio físico pode mudar sua loja para um novo local.

1 curtida

A conformidade com PCI é muito confusa e difícil. Passei por alguns dos formulários para isso quando configurei uma conta de serviço de comerciante com o banco local. Os leitores de cartão deles usam um sistema criptografado fechado, o que provavelmente significa que eles assumem o risco legal de serem um MoR, o que acredito que você esteja correto ao dizer que não é o caso da Stripe.

Se alguém estiver processando informações de cartão de pagamento em servidores independentes, há páginas e páginas de regulamentos para analisar com todos os requisitos de segurança, que são pesados e há multas altas por falhas.

Esta é uma ideia interessante, não tenho certeza de como isso poderia ser feito.

Manualmente, um novo fórum poderia ser iniciado a partir do backup anterior, excluindo tudo, exceto a categoria que alguém gostaria de exportar. Isso funcionaria, ou haveria alguma outra maneira?

1 curtida

O Discourse tem tarefas rake para importar e exportar categorias e grupos: https://meta.discourse.org/t/administrative-bulk-operations/118349#exportimport-categories-10. Não acredito que isso possa ser usado para exportar MPs de grupo, mas lidaria com a importação/exportação de membros de grupo e atividades de grupo que ocorreram em categorias regulares.

Ah, ok, bom saber que tem essa capacidade.