Могут ли пользователи взимать плату за предоставление доступа к своим группам и связанным с ними материалам другим пользователям? Я знаю, что это не стандартная функция, но возможно ли это?
Членство в платных группах (которое, в свою очередь, предоставляет доступ к определённым категориям) — это уже существующая функция. Посмотрите в канале #plugins.
Примеры включают Patreon, Procourse Memberships и Subscriptia.
Если у вас уже есть веб-сайт, который обрабатывает такие членства, вы также можете передавать информацию о членстве в группах через ваш SSO-набор данных.
Пользователи не могут напрямую взимать плату с других на сайте, которым они не владеют. Имеет ли вообще смысл предоставлять им такую возможность?
Спасибо за ответ, @Stephen. Я знаком с приведёнными вами примерами, а также с вариантом SSO.
Имеет ли это смысл? В принципе, что угодно может иметь смысл. Представьте себе оживлённый форум, где талантливые создатели контента собираются для дискуссий и решения проблем; при этом они могли бы создавать закрытые группы, доступные только платным участникам. Таким образом, участники форума могли бы монетизировать свою активность на платформе, а владелец форума получал бы свою долю от комиссии. Выигрыш для всех сторон.
Меня просто интересует, возможно ли это в принципе. @angus, в общем и целом (не ищу здесь точной оценки), кажется ли вам такая идея реализуемой?
Пожалуйста, не отмечайте людей.
Здесь есть множество аспектов, которые следует учитывать, и примеры того, как пользователи могут быть связаны с поставщиками услуг без написания кода. Возьмем, к примеру, Marketplace пользователи подключаются к консультантам без необходимости в специальном коде или обработке платежей.
Управление такими транзакциями — очень сложный и рискованный процесс. В странах ЕС и США также необходимо учитывать множество законов о противодействии отмыванию денег.
Многие люди приходят к этой идее, но в итоге любой создатель может за 5 долларов в месяц создать собственный форум на Discourse и избежать комиссии посредника. Это замечательно, ведь одна из ключевых миссий Discourse — продвижение децентрализации в интернете.
Спасибо за ответ, @Falco. Действительно, создатели могут запустить свой собственный форум; однако наличие одного форума, где множество создателей общаются друг с другом, а затем предлагают специализированные материалы за плату, создало бы платформу, позволяющую людям в первую очередь находить создателя. Именно в этом и заключается ценность. Я делаю вывод, что такая функциональность невозможна. Спасибо за обратную связь!
Такая функциональность вполне реализуема. Очевидно, что потребуется финансирование разработки. Думаю, за 10 тысяч долларов можно модифицировать ProCourse Memberships 💸, чтобы пользователи могли приобретать несколько «членских пакетов». Каждый пакет даёт доступ к группе, а каждая группа — к категории.
@Joshua_Kogan Вы можете сделать это прямо сейчас двумя способами, используя плагин Custom Wizard.
Принять оплату внешним способом
Один из методов — перенаправить пользователя на платежного провайдера после отправки одного из шагов пользовательского мастера, убедиться в завершении оплаты с помощью комбинации разрешенных параметров и необходимых данных, а затем добавить пользователя в группу на следующем шаге (используя действие «Добавить в группу»).
Ниже приведено полное описание части, касающейся оплаты в этом подходе. Часть добавления в группу должна быть очевидной:
Настройка перенаправления пользователя на платежного провайдера
- Маршрутизация к действию (Route To Action). Существует новый тип действия под названием «Маршрутизация к» (Route To), который позволяет отправлять пользователя по указанному URL-адресу после отправки шага. Для ваших мастеров это действие должно быть добавлено к любому шагу, предшествующему оплате пользователем. В настоящее время оно добавляется к самому шагу «Оплата», но вы можете удалить этот шаг и добавить действие к предыдущему шагу, если хотите. Действие «Маршрутизация к» в настоящее время имеет два параметра:
-
url: Это целевой URL-адрес. Как и в случае с другими полями мастера, вы можете подставлять данные, используя w{} для полей мастера и u{} для полей пользователя.
-
code: Уникальный код, который добавляется как параметр к целевому URL-адресу. Когда этот параметр заполнен, пользовательский мастер генерирует уникальную случайную шестнадцатеричную строку, которая:
- добавляется к URL-адресу в качестве дополнительного параметра запроса с использованием предоставленного вами ключа; и
- сохраняется в данных отправки с использованием предоставленного вами ключа
Связывание уникального ключа с каждым запросом позволяет проверить любой обратный вызов для этого запроса (т. е. когда пользователь возвращается в мастер). В случае с Chargify, Chargify сохранит любое значение, которое вы отправите в параметре «reference» (см. далее), которое вы затем можете добавить в «URL возврата», на который Chargify перенаправит пользователя после завершения оплаты.
-
Разрешенные параметры (Permitted Params). Это новый параметр шага, который позволяет указать, какие параметры запроса разрешены для шага и с каким ключом они должны быть сохранены в данных отправки. Вы можете использовать это как для сохранения статистических или аналитических данных (например, откуда пользователь вошел в мастер), так и для обратных вызовов. В случае с Chargify мы передавали код «reference» в Chargify (и сохраняли его в данных отправки), когда перенаправляли пользователя в Chargify для завершения оплаты. Затем мы добавляли этот код в «URL возврата» как параметр возврата, который затем сохраняли в отправлениях, добавляя любой параметр, который мы указываем как содержащий
customer_reference, в параметры возврата. Обратите внимание, что в Chargify вам нужно будет установить «URL возврата» на URL-адрес шага, следующего за шагом, к которому вы добавили действие «Маршрутизация к». Это означает, что вы добавите параметрcustomer_referenceкак разрешенный параметр для того же шага. -
Необходимые данные (Required Data). Это новый параметр шага, который позволяет провести проверку данных перед тем, как разрешить пользователю просмотреть шаг. В настоящее время вы можете требовать, чтобы часть данных отправки равнялась другой части данных отправки. Если пользователь попытается загрузить шаг и проверка необходимых данных не пройдет, он увидит сообщение об ошибке. В случае с Chargify мы будем использовать это для требования, чтобы код, созданный в действии «Маршрутизация к», равнялся
customer_reference, возвращенному Chargify. Вы можете настроить сообщение об ошибке, отображаемое пользователям, используя поле «Сообщение, отображаемое при отсутствии данных» в администраторе мастера. Кроме того, к сообщению об ошибке добавляется ссылка «Перезапустить мастер», позволяющая пользователю сбросить мастер на шаг 1 и очистить существующие входные данные.
Принять оплату внутренним способом
Вы можете использовать ProCourse Memberships для приема оплаты.
Вы также можете использовать практически любого платежного провайдера, если у него есть API, поддерживающий OAuth2 или базовую авторизацию (например, Stripe использует базовую авторизацию), настроив соединение API с помощью действия «Отправить в API» (Send to API) в пользовательском мастере и связанной системы управления конечными точками API. То, как вы это настроите, будет зависеть от провайдера. Этот подход менее стабилен; это функция в бета-версии, но у нее есть значительный потенциал.
Это не решает проблему напрямую, но близко к решению: Discourse Subscriptions Plugin
Опуская возможные юридические вопросы, существуют уже готовые онлайн-сервисы подписки, которые, скорее всего, можно использовать для удовлетворения требований ТС практически без написания кода. Например, сервис вроде Zapier может выступать посредником между сервисом подписки и форумом Discourse. Он может добавлять и удалять пользователей из групп Discourse в зависимости от их подписок.
Уверен, что это также можно реализовать с помощью интеграции Discourse/WordPress и небольшой доработки.
Судя по моим исследованиям, потенциальные юридические проблемы могут стать более серьезным препятствием, чем технические сложности управления членством в группах на основе платных подписок. Организации, о которых мне известно и которые уже занимаются подобным (YouTube, Patreon, Substack, X/Twitter), скорее всего, имеют хорошие юридические отделы.
Я не уверен насчет философских возражений против монетизации доступа к группам/категориям.
Stripe — лучшая платформа, которую я знаю, для таких задач. Она предлагает множество вариантов классификации сборов для целей налогообложения в разных странах.
Это может подойти, если создатель регулярно публикует рассылки, художественные работы или видео-презентации. Существуют различные варианты авторских прав: как с ограниченным, так и с условным правом использования.
Не уверен, выходит ли это за рамки темы или, наоборот, точно по теме, но, насколько я понимаю, Stripe не выступает в роли продавца (Merchant of Record, MoR). Существуют другие онлайн-платёжные процессоры, которые выполняют функции MoR. Оставлю другим исследовать последствия этого. Вот здесь у меня уже начинает кружиться голова, и я начинаю думать, что технические аспекты монетизации доступа к группам гораздо менее пугающие, чем юридические 
Я не совсем понимаю, что именно означает, что платежный процессор выступает в роли «мерчанта-регистратора» (Merchant of Record). Вы имеете в виду номер идентификатора мерчанта (Merchant Identification Number)?
Действительно, у меня в Stripe нет такого номера, только запутанный номер аккаунта, состоящий из комбинации цифр и букв. Платежный процессор Elavon предоставляет мерчантам 10-значный номер идентификатора мерчанта (Merchant ID#), что может означать, что они выступают в роли Merchant of Record, но я не до конца понимаю, что это значит.
Что касается первоначальной темы монетизации доступа к группе, то успех этого зависит от того, о чем или для чего эта группа. В случае с платформой Discourse это может означать как возможность подписки на контент другого создателя, так и возможность для пользователей публиковать свои собственные материалы на форуме, созданном кем-то другим.
При стандартном тарифе хостинга стоимостью 100 долларов в месяц это становится более доступным, если десять человек будут платить по 10 долларов в месяц за аккаунты на размещенном форуме, что покроет расходы.
Другие сервисы, такие как Google Workspace, стоят 7 долларов в месяц за пользователя, а бизнес-электронная почта обычно обходится примерно в 13 долларов в месяц. Платежная платформа, такая как Stripe или аналогичная, может использоваться для сбора взносов с пользователей, которые не приносят прибыли, а лишь покрывают расходы на работу системы коммуникации группы.
Это хороший вопрос о политике сайта. Для многих сайтов, вероятно, нет, это не имело бы смысла.
Часто существуют правила против саморекламы или размещения рекламы, поэтому любые попытки продаж со стороны третьих лиц, как правило, запрещаются большинством администраторов.
Что касается категории Marketplace для Meta, похоже, она предназначена только для размещения предложений о платной работе, а не для запросов денег за доступ к группе, предложения услуг за плату или продажи чего-либо?
Также существует правило, согласно которому любое предложение на маркетплейсе должно быть публичным и не размещаться в закрытых сообщениях. Это кажется хорошей политикой.
Вот что это значит:
Merchant of Record (MoR, торговый агент) — это юридическое лицо, ответственное за продажу товаров или услуг конечному потребителю. Оно обрабатывает все платежи и берет на себя связанные с этим обязательства, такие как сбор налога с продаж, обеспечение соответствия стандартам индустрии платежных карт (PCI) и обработка возвратов средств и оспариваний транзакций.
Если говорить о том, почему имеет смысл позволить владельцам групп взимать плату за членство в группах и доступ к категориям Discourse, то самый очевидный ответ заключается в том, что экономика создателей контента (creator economy) огромна, и у Discourse есть потенциал для работы в этой сфере. Экономика создателей контента строится вокруг сообществ. Discourse — это инструмент для создания сообществ, поэтому он идеально подходит для этой ниши.
Более спекулятивный ответ заключается в том, что я считаю, существует тенденция к краудфандингу и патронажу для финансирования деятельности, выходящей за рамки обычной экономики создателей контента.
Также сервис подписки на уровне категорий на базе Discourse может стать самым простым способом обеспечить прибыльное бесплатное хостинг-обслуживание для форумов Discourse. Я предполагаю, что владелец форума будет получать долю от прибыли. Substack — хороший пример того, как это может работать.
Аргумент, поднятый ранее в этой теме о том, что Discourse стремится способствовать децентрализации в интернете, является верным. Однако возможен и промежуточный вариант. Discourse — это программное обеспечение с открытым исходным кодом, и в нем есть инструменты для экспорта и импорта категорий. Владельцу группы на конкретном форуме может быть предоставлена возможность экспортировать свое сообщество, если он того пожелает. Это похоже на (но проще, чем) возможность владельца физического бизнеса перенести свой магазин в новое место.
Соответствие стандартам PCI — это очень запутанно и сложно. Я сталкивался с некоторыми формами для этого, когда открывал счет торгового обслуживания в местном банке. Их терминалы используют закрытую зашифрованную систему, что, вероятно, означает, что они берут на себя юридические риски, связанные с ролью хранителя данных (MoR). Я считаю, что вы правы, утверждая, что это не относится к Stripe.
Если кто-то обрабатывает информацию о платежных картах на независимых серверах, существует множество страниц нормативных требований со всеми необходимыми мерами безопасности. Эти требования крайне обременительны, а штрафы за нарушения очень высоки.
Это интересная идея, но не совсем понятно, как это можно реализовать.
Вручную можно было бы создать новый форум на основе резервной копии предыдущего, исключив всё, кроме категории, которую кто-то хочет экспортировать. Сработает ли такой подход или есть какой-то другой способ?
В Discourse есть rake-задачи для импорта и экспорта категорий и групп: https://meta.discourse.org/t/administrative-bulk-operations/118349#exportimport-categories-10. Я не думаю, что это можно использовать для экспорта личных сообщений групп, но это позволит импортировать/экспортировать участников групп и активность групп, которая происходила в обычных категориях.
О, хорошо, что я знаю об этой возможности.