È possibile che gli utenti applichino un fee per consentire ad altri utenti l’accesso ai loro gruppi e ai relativi materiali del gruppo? So che non è una funzionalità pronta all’uso, ma è possibile?
L’iscrizione a gruppi a pagamento (che a sua volta concede l’accesso a categorie specifiche) è una funzionalità esistente. Dai un’occhiata in #plugins
Esempi includono Patreon, Procourse Memberships e Subscriptia.
Se disponi di un sito web esistente che gestisce tali iscrizioni, puoi anche fornire le informazioni relative all’iscrizione al gruppo tramite il tuo payload SSO.
Gli utenti non possono addebitare direttamente commissioni ad altri su un sito di cui non sono proprietari; avrebbe senso che potessero farlo?
Grazie per la risposta, @Stephen. Sono a conoscenza degli esempi che hai incluso, così come dell’opzione SSO.
Ha senso? In teoria, tutto può avere senso. Immagina un forum vivace dove creatori di contenuti eccezionali si riuniscono per discutere e risolvere problemi; allo stesso tempo, potrebbero creare gruppi privati accessibili solo ai membri paganti. In questo modo, i partecipanti al forum potrebbero monetizzare la propria attività, mentre il proprietario del forum potrebbe guadagnare tramite una quota di commissione. Una situazione vantaggiosa per tutti.
Sono solo curioso di sapere se questo sia possibile. @angus, in generale (non sto cercando una citazione formale), sembra che qualcosa del genere sia fattibile?
Si prega di non taggare le persone.
Ci sono molte implicazioni da considerare, e esempi di come gli utenti possano essere collegati ai fornitori di servizi senza scrivere alcun codice. Prendiamo ad esempio Marketplace gli utenti sono collegati ai consulenti senza la necessità di codice speciale o di elaborazione dei pagamenti.
Gestire questo tipo di transazioni è un processo molto complesso e rischioso. Nell’UE e negli Stati Uniti è inoltre necessario tenere conto delle numerose normative sul riciclaggio di denaro.
Molte persone hanno questa idea, ma alla fine ogni creatore può avere il proprio Discourse per 5 dollari al mese ed evitare le commissioni dell’intermediario. Il che è un’ottima cosa: una delle missioni fondamentali di Discourse è promuovere la decentralizzazione sul web.
Grazie per la risposta, @Falco. Effettivamente i creatori possono avviare il proprio Discourse; tuttavia, avere un unico Discourse in cui molti creatori discutono tra loro, offrendo poi materiali specializzati a pagamento, creerebbe una piattaforma che permette alle persone di trovare il creatore fin dall’inizio. Questo sarebbe il valore. Raccogliendo le informazioni, sembra che questo tipo di funzionalità non sia possibile. Grazie per il feedback!
La funzionalità è assolutamente fattibile. Ovviamente, sarà necessario finanziarne lo sviluppo. Penso che con 10.000 $ si possa ottenere una versione modificata di ProCourse Memberships 💸 che permetta di acquistare più “iscrizioni”. Ogni iscrizione garantisce l’accesso a un gruppo, e ogni gruppo l’accesso a una categoria.
@Joshua_Kogan Puoi farlo immediatamente in due modi diversi utilizzando il plugin Custom Wizard.
Effettuare il pagamento esternamente
Un metodo consiste nell’invio dell’utente a un provider di pagamenti al completamento di una fase di un wizard personalizzato, assicurarsi che il pagamento sia stato completato utilizzando una combinazione di parametri consentiti e dati obbligatori, quindi aggiungere l’utente a un gruppo nella fase successiva (utilizzando l’azione “Aggiungi al gruppo”).
Questa è una descrizione completa della parte relativa al pagamento di questo approccio. La parte relativa all’aggiunta al gruppo dovrebbe essere di per sé chiara:
Configurazione per l'invio dell'utente al provider di pagamenti
- Route To Action . È disponibile un nuovo tipo di azione chiamato “Route To” che ti consente di inviare un utente a un URL di destinazione al completamento di una fase. Per i tuoi wizard, l’azione deve essere aggiunta a qualsiasi fase che precede il pagamento dell’utente. Attualmente vengono aggiunte alla fase ‘payment’ stessa, ma puoi rimuovere questa fase e aggiungerle alla fase precedente se lo desideri. L’azione “Route To” ha attualmente due impostazioni:
-
url: Questo è l’URL di destinazione. Come per altri input del wizard, puoi interpolare i dati utilizzando w{} per i campi del wizard e u{} per i campi dell’utente.
-
code: Un codice univoco da aggiungere come parametro all’URL di destinazione. Quando questa impostazione è compilata, il Custom Wizard genererà una stringa esadecimale casuale unica che:
- aggiunge all’URL come parametro di query aggiuntivo utilizzando la chiave che fornisci; e
- salva il codice nei dati di submission utilizzando la chiave che fornisci
Associare una chiave unica a ogni richiesta consente di validare qualsiasi callback per quella richiesta (cioè quando l’utente torna al wizard). Nel caso di Chargify, Chargify memorizzerà qualsiasi valore inviato nel parametro ‘reference’ (vedi oltre), che potrai poi aggiungere all’URL di ritorno a cui Chargify reindirizza l’utente dopo aver completato il pagamento.
-
Permitted Params . Questa è una nuova impostazione della fase che ti consente di specificare quali parametri di query sono consentiti per la fase e la chiave con cui devono essere salvati nei dati di submission. Puoi utilizzarlo sia per salvare dati statistici o analitici (come da dove l’utente ha iniziato il wizard), sia per le callback. Nel caso di Chargify abbiamo passato il codice ‘reference’ a Chargify (e lo abbiamo salvato nei dati di submission) quando abbiamo reindirizzato l’utente a Chargify per completare il pagamento. Successivamente, abbiamo aggiunto questo codice all’URL di ritorno come parametro di ritorno, che poi salviamo nelle submission aggiungendo qualsiasi parametro specifichiamo per contenere
customer_referencenei parametri di ritorno. Nota che in Chargify dovrai impostare l’URL di ritorno sull’URL della fase successiva alla fase a cui hai aggiunto l’azione “Route To”. Ciò significa che dovrai aggiungere il parametrocustomer_referencecome parametro consentito a quella stessa fase. -
Required Data . Questa è una nuova impostazione della fase che ti consente di imporre un controllo dei dati prima di consentire a un utente di visualizzare la fase. Attualmente puoi richiedere che un pezzo di dati di submission sia uguale a un altro pezzo di dati di submission. Se l’utente tenta di caricare la fase e il controllo dei dati richiesti fallisce, vedrà un messaggio di errore. Nel caso di Chargify, useremo questo per richiedere che il codice creato nell’azione “Route To” sia uguale al
customer_referencerestituito da Chargify. Puoi personalizzare il messaggio di errore mostrato agli utenti utilizzando il campo “Messaggio mostrato quando i dati non sono presenti” nell’amministratore del wizard. Inoltre, c’è un link “Ricomincia Wizard” aggiunto al messaggio di errore che consente all’utente di reimpostare il wizard alla fase 1 e cancellare gli input esistenti.
Effettuare il pagamento internamente
Puoi utilizzare ProCourse Memberships per effettuare il pagamento.
Puoi anche utilizzare quasi qualsiasi provider di pagamenti se dispone di un’API che supporta OAuth2 o l’autorizzazione Basic (ad esempio, Stripe utilizza l’autorizzazione Basic), configurando una connessione API utilizzando l’azione “Send to API” del Custom Wizard e il relativo sistema di gestione degli endpoint API. Come impostare questo dipenderà dal provider. Questo approccio è meno stabile; è una funzionalità in beta, ma ha un potenziale significativo.
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à.