¿Es posible que los usuarios cobren una tarifa para permitir el acceso de otros usuarios a sus grupos y al material relacionado con estos? Sé que no es una función estándar, pero ¿es posible?
La membresía de grupo de pago (que a su vez otorga acceso a categorías específicas) es una función existente. Echa un vistazo en #plugins.
Algunos ejemplos incluyen Patreon, Procourse Memberships y Subscriptia.
Si ya tienes un sitio web que gestiona este tipo de membresías, también puedes entregar la información de la membresía del grupo a través de tu carga útil de SSO.
Los usuarios no pueden cobrar tarifas directamente a otros en un sitio que no poseen; ¿tendría sentido que incluso pudieran hacerlo?
Gracias por la respuesta, @Stephen. Estoy al tanto de los ejemplos que has incluido, así como de la opción de SSO.
¿Tendría sentido? Cualquier cosa puede tener sentido. Imagina un foro animado donde grandes creadores de contenido se reúnen para debatir y resolver problemas; sin embargo, también podrían crear grupos privados a los que solo puedan acceder los miembros de pago. De esta manera, los participantes del foro podrían monetizar su actividad en el foro, y el propietario del foro podría monetizar mediante un reparto o comisión. Todos ganan.
Solo tengo curiosidad por saber si esto es posible. @angus, en términos generales (no busco una cita aquí), ¿te parece que algo así es posible?
Por favor, no etiquetes a las personas.
Hay muchas implicaciones que considerar aquí, así como ejemplos de cómo los usuarios pueden conectarse con proveedores de servicios sin escribir código. Tomemos el Marketplace como ejemplo: los usuarios se conectan con consultores sin necesidad de código especial ni procesamiento de pagos.
Gestionar este tipo de transacciones es un proceso muy delicado y arriesgado. Además, dentro de la UE y EE. UU., también debes tener en cuenta las numerosas leyes contra el lavado de dinero.
Mucha gente se le ocurre esta idea, pero al final cualquier creador puede tener su propio Discourse por 5 dólares al mes y saltarse la tarifa del intermediario. Lo cual es algo excelente; una de las misiones centrales de Discourse es promover la descentralización en la web.
Gracias por la respuesta, @Falco. Efectivamente, los creadores pueden iniciar su propio foro; sin embargo, tener un único foro donde muchos creadores discuten entre sí y luego ofrecen materiales especializados a cambio de una tarifa, crearía una plataforma que permite a las personas encontrar al creador desde el principio. Ese sería el valor. Entiendo que este tipo de funcionalidad no es posible. ¡Gracias por la retroalimentación!
La funcionalidad es totalmente posible. Obviamente, necesitarás financiar su desarrollo. Creo que con 10 000 $ podrías modificar ProCourse Memberships 💸 para que haya varias “membresías” que los miembros puedan comprar. Cada membresía otorga acceso a un grupo, y cada grupo, acceso a una categoría.
@Joshua_Kogan Puedes hacer esto ahora mismo de dos maneras diferentes utilizando el plugin Custom Wizard.
Realizar el pago externamente
Un método sería enviar al usuario a un proveedor de pagos al finalizar un paso de un asistente personalizado, asegurarse de que el pago se complete usando una combinación de parámetros permitidos y datos requeridos, y luego agregar al usuario a un grupo en un paso posterior (usando la acción “Agregar al grupo”).
Esta es una descripción completa de la parte del pago de este enfoque. La parte de agregar al grupo debería ser autoexplicativa:
Configuración para enviar al usuario al proveedor de pagos
- Enrutar a una acción: Existe un nuevo tipo de acción llamado “Enrutar a” que te permite enviar a un usuario a una URL de destino al finalizar un paso. Para tus asistentes, la acción debe agregarse al paso que precede al pago del usuario. Actualmente se agregan al paso “pago” en sí, pero puedes eliminar este paso y agregarlos al paso anterior si lo prefieres. La acción “Enrutar a” tiene actualmente dos configuraciones:
-
url: Esta es la URL de destino. Al igual que con otras entradas del asistente, puedes interpoler datos usando w{} para campos del asistente y u{} para campos del usuario.
-
código: Un código único para agregar como parámetro a la URL de destino. Cuando esta configuración está completada, el asistente personalizado generará una cadena hexadecimal aleatoria única que:
- agrega a la URL como un parámetro de consulta adicional usando la clave que proporciones; y
- guarda el código en los datos de la entrega usando la clave que proporciones
Asociar una clave única con cada solicitud permite validar cualquier devolución de llamada para esa solicitud (es decir, cuando el usuario regresa al asistente). En el caso de Chargify, Chargify almacenará cualquier valor que envíes en el parámetro “reference” (ver más), el cual luego puedes agregar a la “URL de retorno” a la que Chargify redirige al usuario después de completar el pago.
-
Parámetros permitidos: Esta es una nueva configuración de paso que te permite especificar qué parámetros de consulta están permitidos para el paso y la clave con la que deben guardarse en los datos de la entrega. Puedes usar esto tanto para guardar datos estadísticos o analíticos (como desde dónde ingresó el usuario al asistente) como para devoluciones de llamada. En el caso de Chargify, pasamos el código “reference” a Chargify (y lo guardamos en los datos de la entrega) cuando redirigimos al usuario a Chargify para completar el pago. Luego, agregaríamos este código a la “URL de retorno” como un parámetro de retorno, el cual luego guardamos en las entregas agregando cualquier parámetro que especifiquemos que contenga
customer_referenceen los parámetros de retorno. Ten en cuenta que en Chargify necesitarás configurar la “URL de retorno” a la URL del paso posterior al paso al que adjuntaste la acción “Enrutar a”. Esto significa que agregarás el parámetrocustomer_referencecomo un parámetro permitido a ese mismo paso. -
Datos requeridos: Esta es una nueva configuración de paso que te permite imponer una verificación de datos antes de permitir que un usuario vea el paso. Actualmente, puedes requerir que un fragmento de datos de entrega sea igual a otro fragmento de datos de entrega. Si el usuario intenta cargar el paso y la verificación de datos requerida falla, verá un mensaje de error. En el caso de Chargify, usaremos esto para requerir que el código que creamos en la acción “Enrutar a” sea igual al
customer_referencedevuelto por Chargify. Puedes personalizar el mensaje de error mostrado a los usuarios usando el campo “Mensaje mostrado cuando los datos no están presentes” en la administración del asistente. Además, hay un enlace “Reiniciar asistente” añadido al mensaje de error que permite al usuario restablecer el asistente al paso 1 y limpiar las entradas existentes.
Realizar el pago internamente
Puedes usar ProCourse Memberships para realizar el pago.
También puedes usar casi cualquier proveedor de pagos si tienen una API que soporte OAuth2 o autorización básica (Stripe usa autorización básica, por ejemplo), configurando una conexión API usando la acción “Enviar a API” de Custom Wizard y el sistema de gestión de puntos de conexión API asociado. Cómo configures esto dependerá del proveedor. Este enfoque es menos estable; es una función en versión beta, pero tiene un potencial significativo.
Esto no resuelve el problema directamente, pero está cerca: Discourse Subscriptions Plugin
Ignorando los posibles problemas legales, existen servicios de suscripción en línea que probablemente podrían usarse para cumplir con los requisitos del OP con poco o ningún código. Por ejemplo, un servicio como Zapier podría actuar como intermediario entre un servicio de suscripción y un foro de Discourse. Podría agregar y eliminar usuarios de grupos de Discourse según sus suscripciones.
Estoy seguro de que también se podría lograr con la integración de Discourse/WordPress y un poco de desarrollo personalizado.
Por lo que he investigado, parece que los posibles problemas legales podrían ser un obstáculo mayor que los desafíos técnicos de administrar membresías de grupos basadas en suscripciones pagas. Las organizaciones que conozco que hacen este tipo de cosas ahora (Youtube, Paetron, Substack, X/Twitter) probablemente tengan buenos equipos legales.
No estoy seguro de las objeciones filosóficas a la monetización del acceso a grupos/categorías.
Stripe es la mejor plataforma que conozco para algo así, hay muchas opciones diferentes sobre cómo categorizar una tarifa para impuestos en diferentes países.
Esto podría funcionar si un creador publica constantemente boletines informativos, obras de arte o presentaciones en video. Existen diferentes opciones para los derechos de autor, ya sean derechos limitados o condicionales.
No estoy seguro de si esto se está desviando del tema o si está exactamente en el tema, pero entiendo que Stripe no funciona como el Comerciante Registrado (MoR). Hay otros procesadores de pagos en línea que sí funcionan como el MoR. Dejaré que otros investiguen las implicaciones de eso. Este es el punto en el que mi cabeza empieza a dar vueltas y empiezo a pensar que los aspectos técnicos de la monetización del acceso grupal son mucho menos desalentadores que los aspectos legales de ello 
No estoy familiarizado con lo que significa exactamente que un procesador de pagos funcione como un “Comerciante Registrado”. ¿Se refieren a un Número de Identificación de Comerciante?
Es cierto que no tengo eso con Stripe, solo un número de cuenta confuso que es una mezcla de números y letras. Otro procesador de pagos, Elavon, proporciona a los comerciantes un ID de comerciante de 10 dígitos, lo que podría significar que actúan como Comerciante Registrado, pero no sé qué significa eso.
Con el tema original de monetizar el acceso a un grupo, para que eso funcione realmente depende de qué sea el grupo o para qué sea. Con una página de discusión, eso podría significar tanto suscribirse a lo que otro creador está produciendo como la oportunidad para que las personas publiquen su propio material en el foro de otra persona.
Con el nivel estándar de alojamiento que cuesta $100 al mes, esto es más asequible si diez personas quieren pagar $10 al mes para tener cuentas en un foro alojado que cubra el costo.
Otros servicios como Google Workspace cuestan $7 al mes por usuario y el correo electrónico comercial generalmente cuesta alrededor de $13 al mes. Stripe u otra plataforma de pago podrían usarse para cobrar las tarifas de usuario por eso, que no generan ninguna ganancia, sino que solo cubren el costo de administrar un sistema de comunicación grupal.
Esta es una buena pregunta sobre la política del sitio, para muchos sitios probablemente no tendría sentido.
A menudo existen políticas de no autopromoción o de publicación de publicidad, por lo que, en general, cualquier intento de venta por parte de terceros probablemente estaría prohibido por la mayoría de los administradores.
Con la categoría Marketplace para Meta, parece que es solo para publicar ofertas de trabajo remunerado, ¿no para cualquiera que pida dinero por acceso a un grupo o intente ofrecer un servicio de pago o vender algo?
También existe la política de que cualquier oferta del mercado debe ser pública y no en mensajes cerrados, lo que parece una buena política.
Esto:
Un comerciante registrado (MoR) es una entidad legal responsable de vender bienes o servicios a un cliente final. Se encargan de todos los pagos y asumen las responsabilidades asociadas, como la recaudación del impuesto sobre las ventas, la garantía del cumplimiento de la industria de tarjetas de pago (PCI) y la gestión de reembolsos y contracargos.
En cuanto a por qué tendría sentido permitir que los propietarios de grupos cobren por las membresías de grupo y el acceso a las categorías de Discourse, la respuesta más obvia es porque la economía del “creador” es enorme y Discourse tiene el potencial de operar en ese espacio. La economía del creador se basa en la comunidad. Discourse es una herramienta para construir comunidades, por lo que encajaría bien en ese espacio.
Una respuesta más especulativa es que creo que hay una tendencia hacia la financiación colectiva y el patrocinio para financiar actividades que quedan fuera de la economía habitual del creador.
Un servicio de suscripción a nivel de categoría basado en Discourse también podría ser la forma más fácil de ofrecer alojamiento gratuito de Discourse de manera rentable. Supongo que el propietario del foro se llevaría una parte de las ganancias. Substack es un buen modelo de cómo esto podría funcionar.
El punto que se plantea anteriormente en este tema de que Discourse tiene como objetivo promover la descentralización en la web es válido. Pero existe un posible punto intermedio. Discourse es un software de código abierto y tiene herramientas que permiten exportar e importar categorías. Se le podría dar al propietario de un grupo en un foro particular la capacidad de exportar su comunidad si lo deseara. Similar a (pero más fácil que) la forma en que el propietario de un negocio físico puede trasladar su tienda a una nueva ubicación.
El cumplimiento de PCI es muy confuso y difícil. Revisé algunos de los formularios para eso cuando abrí una cuenta de servicio comercial con un banco local. Sus lectores de tarjetas utilizan un sistema encriptado cerrado, lo que probablemente significa que asumen el riesgo legal de ser un MoR, lo cual creo que es correcto al decir que no es el caso de Stripe.
Si alguien está procesando información de tarjetas de pago en servidores independientes, hay páginas y páginas de regulaciones que revisar con todos los requisitos de seguridad, que son pesados y existen fuertes multas por incumplimiento.
Esta es una idea interesante, no estoy seguro de cómo se podría hacer.
Manualmente, se podría iniciar un nuevo foro a partir de la copia de seguridad anterior, excluyendo todo excepto la categoría que alguien quisiera exportar. ¿Funcionaría eso, o habría alguna otra manera?
Discourse tiene tareas rake para importar y exportar categorías y grupos: https://meta.discourse.org/t/administrative-bulk-operations/118349#exportimport-categories-10. No creo que esto se pueda usar para exportar PMs de grupo, pero manejaría la importación/exportación de miembros de grupo y la actividad de grupo que ocurrió en categorías regulares.
Oh ok, bueno saber que tiene esa capacidad.