Solicitação de recurso: Gostaria de poder oferecer uma assinatura que dure apenas um período. Ao final desse período:
O usuário deve ser removido do grupo do Discourse da assinatura (o que acho que não acontece com os pagamentos únicos atuais).
Nenhum pagamento adicional deve ser efetuado.
Possível solução? O plugin Discourse Subscriptions deve permitir a configuração do atributo iteration de um cronograma de assinatura. Encontrei isso na documentação do Stripe, na página da API de Cronogramas de Assinatura:
Definindo a duração de uma fase
O intervalo de um preço determina com que frequência a cobrança de uma assinatura será feita. Por exemplo, um intervalo mensal é cobrado a cada mês. As fases têm um atributo iterations que você usa para especificar a duração de uma fase. Multiplique esse valor pelo intervalo para determinar a duração da fase. Se um cronograma de assinatura usar um preço com intervalo mensal e você definir iterations=2, a fase durará dois meses.
…
Concluindo um cronograma
Os cronogramas de assinatura terminam após a conclusão da última fase. Neste ponto, a assinatura é mantida e não está mais associada ao cronograma. Se você quiser cancelar uma assinatura após a conclusão da última fase de um cronograma, pode definir end_behavior como cancel.
Entre em contato se houver outros pontos problemáticos que você tenha com este plugin. Acho que estou ciente da maioria, mas ainda há algumas partes sobre as quais gostaria de saber mais. Por exemplo, gostaria de saber mais sobre sua percepção do recurso de campanha. Há alguém aqui que o utilizou?
Estou usando a campanha do betterstreets.nz. Ela é aceitável, mas bastante inflexível. Configurei-a há 9 meses e ela continua funcionando (embora extremamente devagar!).
Meu maior problema é que, atualmente, as pessoas não podem simplesmente doar um valor X; em vez disso, elas precisam assinar anualmente.
Além disso, é apresentada nesses mesmos termos - ou seja, por mês. Isso torna os valores estranhos e não é realmente a forma como a maioria das pessoas pensa para uma campanha: de zero a X como um valor absoluto. Mesmo que fosse apresentado anualmente, seria muito melhor.
Os banners são aceitáveis (topo para páginas de descoberta e rodapé para tópicos), mas não são muito personalizáveis. Seria bom torná-los maiores ou menores para se adequarem ao resto do site (por exemplo, outros banners / rodapés).
Uma vez dispensados por um usuário em um dispositivo, seria bom poder forçá-los a reaparecer ocasionalmente, ou fazê-los encolher para algo muito mais discreto (mas ainda presente até que a pessoa tenha doado).
Entendo. Eu me inscrevi no seu fórum para verificar isso e entendo o que você quer dizer.
Talvez fosse bom não torná-los dispensáveis? Eles não parecem muito intrusivos e oferecem informações valiosas, mesmo para pessoas que já doaram. Isso dá à comunidade um objetivo comum e os doadores merecem ser reconhecidos por contribuir.
Existem muitas maneiras de criar banners no Discourse. Qual método você usa atualmente?
Algo que reconheci: eu não sabia que era possível doar para o seu empreendimento até me inscrever no fórum. Como sabemos, a maior parte do público será de leitores passivos e apenas uma minoria decidirá se registrar.
Portanto, parece uma boa ideia mostrar o banner da campanha também para usuários não logados. Tenho certeza de que há muitas pessoas que gostariam de doar, mas que atualmente não são membros ativos / registrados.
No betterstreets.nz, eu só uso o banner que faz parte da seção de campanha do plugin Subscriptions. Sua presença me impede de adicionar outros banners!
Eu uso outros banners em outros sites, no entanto.
Concordo totalmente - mas apenas se fosse super claro e fácil para eles fazerem isso!
Não me lembro da terminologia do Stripe, mas todo o plugin gira em torno da maneira antiga de fazer as coisas deles (que permite apenas cartão de crédito) em vez da nova maneira (que permite uma ampla variedade de opções de pagamento).
O cancelamento é descrito de forma confusa (pelo que me lembro, é o cancelamento da renovação automática, mas parece ser descrito como cancelamento imediato).
Também seria ótimo se uma assinatura pudesse ser feita ao mesmo tempo que o registro no fórum. No momento, o processo de duas etapas não é ideal para todos os cenários.
Consegui resolver a assinatura única com um intervalo de tempo adicionando um novo metadado (“recurring:0/1”) no objeto de preço. E quando você tenta criar uma assinatura com price[:metadata][:recurring]==“0”, eu definirei o valor cancel_at_end = true no objeto Subscription.
Então, quando você cria um preço único, você ainda precisa escolher um intervalo (ano, mês, dia, semana), mas não deve marcar a caixa “recorrente”.
E quando um usuário assina, o backend criará uma assinatura recorrente que terminará na data de término. O usuário não precisará cancelar a renovação por conta própria.
Vocês também precisam adicionar o segredo do webhook do Stripe à instância do Discourse (como a configuração do plugin “webhook secret”). Vocês podem encontrá-lo no exemplo de código à direita no formulário de criação de webhook no Stripe.
Fiz um vídeo curto para dar uma visão geral das estruturas de dados e como elas se conectam às estruturas de dados do Discourse:
Concordo bastante com isso, mas agora deve estar corrigido. Vocês podem configurar o que quiserem no Stripe com isso (métodos de pagamento / impostos / tabela de preços etc.) e tudo deve funcionar.
O plugin apenas gerencia a conexão entre os usuários do Discourse e os clientes do Stripe, e a criação de produtos, planos, etc. é feita inteiramente no painel do Stripe.
Ainda pode haver bugs. Se virem alguma coisa, por favor, reportem.
Então este é um fork que você planeja enviar como uma solicitação de PR para o plugin oficial assim que estiver um pouco mais polido? Se sim - brilhante!!! E obrigado pelo seu bom trabalho e energia nisso!
Se sim, vou experimentá-lo em breve. Levará um pouco de tempo para testá-lo completamente, é claro.
[quote=“spirobel, post:17, topic:246395”]você terá que executar o stripe cli localmente para retransmitir as mensagens do webhook. Este é o comando a ser usado:
stripe listen --forward-to http://localhost:4200/subscriptions/hooks --api-key y
[/quote]Onde executamos isso? No servidor como root, ou dentro do contêiner docker? E usamos nossa URL de instância antes de /subscriptions/hooks?
E só para ter certeza de que estou fazendo a coisa certa, é isso que instalamos em vez do plugin oficial?
Isso só é necessário para uma instância de desenvolvimento que roda localmente no seu computador. Por exemplo, você pode ver no vídeo que minha instância do Discourse roda em localhost:4200, o que significa que ela roda no meu computador.
Se você quiser recriar exatamente este ambiente, pode seguir este guia:
Como o servidor Stripe não consegue alcançar o endereço localhost:4200 em minha rede local, é necessário executar este comando para retransmitir as solicitações de webhook que vêm do servidor Stripe.
Se você quiser tentar isso em um servidor conectado à internet, pode seguir a configuração de webhook do tutorial oficial: Discourse Subscriptions Plugin
Por favor, não o instale (ainda) em uma instância que já tenha dados de clientes ativos e a versão antiga do plugin Discourse Subscriptions instalada. Tente em um segundo servidor de staging, pois as duas versões entrarão em conflito.
Muito obrigado por testar isso! Isso também permitirá que visitantes que ainda não têm uma conta comprem um plano. Eles serão convidados automaticamente para a instância do Discourse e terão as associações de grupo apropriadas assim que pagarem.
Tenho um site ativo relativamente tranquilo (betterstreets.nz) com apenas 3 clientes, incluindo eu, de um experimento anterior essencialmente falhado. Eu ficaria bastante feliz em testá-lo lá, removendo o plugin anterior e seus dados, se necessário (embora eu precisasse de ajuda com o comando correto do console Rails). Eu ainda teria um conflito nesse caso?
