Запрос функции: Я хотел бы иметь возможность предлагать подписку, которая действует только один период. В конце этого периода:
Пользователь должен быть удалён из группы Discourse, связанной с подпиской (я не думаю, что это происходит при текущих разовых платежах).
Не должно производиться дальнейших списаний средств.
Возможное решение? Плагин Discourse Subscriptions должен позволять устанавливать атрибут iteration в расписании подписки. Я нашёл это в документации Stripe на странице API расписаний подписок:
Установка длительности фазы
Интервал цены определяет частоту выставления счетов за подписку. Например, при месячном интервале счёт выставляется каждый месяц. Фазы имеют атрибут iterations, с помощью которого можно указать, как долго должна длиться фаза. Умножьте это значение на интервал, чтобы определить длительность фазы. Если расписание подписки использует цену с месячным интервалом и вы установите iterations=2, фаза будет длиться два месяца.
…
Завершение расписания
Расписания подписок заканчиваются после завершения последней фазы. В этот момент подписка остаётся активной, но больше не связана с расписанием. Если вы хотите отменить подписку после завершения последней фазы расписания, вы можете установить end_behavior в значение cancel.
Пожалуйста, напишите, если у вас есть другие проблемы с этим плагином. Я думаю, что знаю о большинстве из них, но есть ещё некоторые моменты, которые мне хотелось бы изучить подробнее. Например, мне интересно узнать ваше мнение о функции кампаний. Кто-нибудь из вас её использовал?
Я использую кампанию для betterstreets.nz. Она работает, но довольно негибко. Я настроил её 9 месяцев назад, и она всё ещё функционирует (хотя и крайне медленно!).
Моя главная проблема в том, что сейчас я не могу позволить людям просто пожертвовать сумму X; вместо этого они должны оформить подписку на год.
Кроме того, предложение сформулировано в тех же терминах — то есть в расчёте на месяц. Это делает суммы странными и не соответствует тому, как большинство людей мыслят в контексте кампании: от нуля до X как абсолютной суммы. Даже если бы это было представлено в годовом разрезе, это было бы гораздо лучше.
Баннеры приемлемы (верхние для страниц обнаружения, нижние для тем), но их сложно настраивать. Было бы здорово иметь возможность увеличивать или уменьшать их, чтобы они гармонично вписывались в остальной дизайн сайта (например, другие баннеры или подвалы).
После того как пользователь закрывает баннер на устройстве, было бы неплохо иметь возможность периодически возвращать его или уменьшать до гораздо более компактного размера (но чтобы он оставался видимым, пока человек не сделает пожертвование).
Понял. Я зарегистрировался на вашем форуме, чтобы убедиться в этом, и понимаю, что вы имеете в виду.
Возможно, было бы лучше вообще не делать их отключаемыми? Они не кажутся особенно навязчивыми и предоставляют ценную информацию даже тем, кто уже сделал пожертвование. Это создаёт у сообщества общую цель, а жертвователи заслуживают признания за свой вклад.
В Discourse есть множество способов создания баннеров. Какой метод вы используете в настоящее время?
Заметил одну вещь: я не знал, что можно сделать пожертвование вашему проекту, пока не зарегистрировался на форуме. Как мы знаем, основная часть аудитории — это пассивные читатели, и лишь небольшое меньшинство решит зарегистрироваться.
Поэтому кажется хорошей идеей показывать баннер кампании также пользователям, не вошедшим в систему. Я уверен, что есть много людей, которые хотели бы сделать пожертвование, но в данный момент не являются активными или зарегистрированными участниками.
На сайте betterstreets.nz я использую только баннер, который является частью раздела кампании плагина Subscriptions. Его наличие мешает мне добавлять другие баннеры!
Однако на других сайтах я использую и другие баннеры.
Полностью согласен — но только если для них это будет максимально понятно и просто!
Я не помню точную терминологию Stripe, но весь плагин построен вокруг их старого подхода (который поддерживает только оплату кредитными картами), а не нового (который позволяет использовать множество вариантов оплаты).
Отмена описана запутанно (насколько я помню, речь идёт об отмене автоматического продления, но описывается как немедленная отмена).
Также было бы здорово, если бы подписку можно было оформить одновременно с регистрацией на форуме. В настоящее время двухэтапный процесс подходит не для всех сценариев.
Я успешно решил задачу с одноразовой подпиской с временным интервалом, добавив новый метаданный (“recurring:0/1”) в объект цены. А когда вы пытаетесь создать подписку с price[:metadata][:recurring]==“0”, я устанавливаю значение cancel_at_end = true в объекте Subscription.
Затем, когда вы создаете одноразовую цену, вам всё ещё нужно выбрать интервал (год, месяц, день, неделя), но вы не должны отмечать галочку “recurring”.
Когда пользователь оформляет подписку, бэкенд создаёт подписку с автоматическим продлением, которая завершится в указанную дату. Пользователю не нужно самостоятельно отменять продление.
Также необходимо добавить секрет вебхука Stripe в экземпляр Discourse (как настройку плагина «webhook secret»). Его можно найти в примере кода справа в форме создания вебхука на сайте Stripe.
Я подготовил короткое видео с обзором структур данных и того, как они связаны со структурами данных Discourse:
В целом согласен, но теперь это должно быть исправлено. С помощью этого плагина вы можете настроить в Stripe всё, что угодно (способы оплаты, налоги, таблицу цен и т. д.), и всё должно работать.
Плагин лишь управляет связью между пользователями Discourse и клиентами Stripe, а создание продуктов, тарифов и т. п. полностью выполняется в панели управления Stripe.
Тем не менее, баги всё ещё возможны. Если заметите что-то, пожалуйста, сообщите.
Значит, вы планируете отправить этот форк как PR-запрос для официального плагина, когда он будет немного доработан? Если так — великолепно!!! И спасибо за вашу отличную работу и энергию, вложенную в это!
Если так, я попробую это вскоре. Конечно, потребуется немного повозиться, чтобы полностью протестировать его.
Где именно мы это запускаем? На сервере от имени root или внутри Docker-контейнера? И используем ли мы URL нашего экземпляра перед /subscriptions/hooks?
И просто чтобы убедиться, что я делаю всё правильно: это то, что мы устанавливаем вместо официального плагина?
Это необходимо только для экземпляра разработки, который работает локально на вашем компьютере. Например, как видно из видео, мой экземпляр Discourse работает на localhost:4200, что означает, что он запущен на моём компьютере.
Если вы хотите воссоздать эту точную среду, вы можете следовать этому руководству:
Поскольку сервер Stripe не может обратиться к адресу localhost:4200 в моей локальной сети, необходимо выполнить эту команду для пересылки вебхуков, поступающих от сервера Stripe.
Если вы хотите протестировать это на сервере, подключённом к интернету, вы можете следовать настройке вебхуков из официального руководства: Discourse Subscriptions Plugin
Пожалуйста, пока не устанавливайте это на экземпляр, который уже содержит реальные данные клиентов и имеет установленную старую версию плагина Discourse Subscriptions. Попробуйте на втором тестовом сервере, так как две версии будут конфликтовать.
Огромное спасибо за тестирование! Это также позволит посетителям, у которых ещё нет аккаунта, купить план. Они будут автоматически приглашены в экземпляр Discourse и получат соответствующие групповые права после оплаты.
У меня есть относительно тихий рабочий сайт (betterstreets.nz) с всего тремя клиентами, включая меня, в результате практически провалившегося предыдущего эксперимента. Я был бы не против протестировать это там, удалив старый плагин и его данные, если потребуется (хотя мне нужна будет помощь с правильной командой в консоли Rails). Возникнет ли в таком случае конфликт?
