Solicitud de función: Me gustaría poder ofrecer una suscripción que dure solo un período. Al final de ese período:
El usuario debería ser eliminado del grupo de Discourse de la suscripción (lo que creo que no sucede con los pagos únicos actuales).
No se debería realizar ningún pago adicional.
¿Posible solución? El plugin Discourse Subscriptions debería permitir establecer el atributo iteration de un programa de suscripción. Encontré esto en la documentación de Stripe, en la página de la API de Programas de Suscripción:
Establecer la duración de una fase
El intervalo de un precio determina con qué frecuencia se factura una suscripción. Por ejemplo, un intervalo mensual se factura cada mes. Las fases tienen un atributo iterations que se utiliza para especificar la duración de una fase. Multiplique este valor por el intervalo para determinar la duración de la fase. Si un programa de suscripción utiliza un precio con un intervalo mensual y establece iterations=2, la fase dura dos meses.
…
Completar un programa
Los programas de suscripción finalizan después de que se completa la última fase. En este punto, la suscripción permanece y ya no está asociada con el programa. Si desea cancelar una suscripción después de que se completa la última fase de un programa, puede establecer end_behavior en cancel.
No, desafortunadamente hubo demasiadas idiosincrasias y características faltantes con este plugin. No sé si ha cambiado desde mi pregunta, sin embargo.
Por favor, ponte en contacto si tienes algún otro punto débil con este plugin. Creo que soy consciente de la mayoría, pero todavía hay algunas partes sobre las que me gustaría saber más. Por ejemplo, me gustaría aprender más sobre tu percepción de la función de campaña. ¿Hay alguien aquí que la haya utilizado?
Estoy usando la campaña de betterstreets.nz. Está bien, pero es bastante inflexible. La configuré hace 9 meses y todavía sigue funcionando (¡aunque extremadamente lenta!).
Mi mayor problema es que actualmente no puedo hacer que la gente simplemente done X cantidad; en cambio, deben suscribirse anualmente.
Además, se presenta en los mismos términos, es decir, por mes. Eso hace que las cantidades sean extrañas y no es realmente la forma en que la mayoría de la gente piensa para una campaña: de cero a X como una cantidad absoluta. Incluso si se presentara anualmente, sería mucho mejor.
Los banners están bien (arriba para las páginas de descubrimiento y abajo para los temas), pero no son muy personalizables. Sería bueno hacerlos más grandes o más pequeños para que encajen con el resto del sitio (por ejemplo, otros banners / pies de página).
Una vez que un usuario los descarta en un dispositivo, sería bueno poder forzarlos a aparecer ocasionalmente, o que se reduzcan a algo mucho más discreto (pero que aún esté presente hasta que la persona haya donado).
Ya veo. Me registré en tu foro para verificarlo y entiendo lo que quieres decir.
¿Quizás sería bueno no hacerlos descartables en absoluto? No parecen muy intrusivos y ofrecen información valiosa incluso a las personas que ya han donado. Le da a la comunidad un objetivo común y los donantes merecen ser reconocidos por contribuir.
Hay muchas formas de crear pancartas en Discourse. ¿Qué método utilizas actualmente?
Algo que reconocí: no sabía que era posible donar a tu iniciativa hasta que me registré en el foro. Como sabemos, la mayor parte de la audiencia serán lectores pasivos y solo una pequeña minoría decidirá registrarse.
Así que parece una buena idea mostrar la pancarta de la campaña también a los usuarios no registrados. Estoy seguro de que hay muchas personas a las que les gustaría donar pero que actualmente no son miembros activos / registrados.
En betterstreets.nz, solo uso el banner que forma parte de la sección de campañas del plugin Subscriptions. ¡Su presencia me impide añadir otros banners!
Sin embargo, utilizo otros banners en otros sitios.
Totalmente de acuerdo, ¡pero solo si fuera súper claro y fácil para ellos hacerlo!
No recuerdo la jerga de Stripe, pero todo el plugin gira en torno a su antigua forma de hacer las cosas (que solo permite tarjetas de crédito) en lugar de la nueva forma (que permite una amplia variedad de opciones de pago).
La cancelación se describe de una manera confusa (según recuerdo, es la cancelación de la renovación automática pero parece describirse como cancelación inmediata).
También sería genial si se pudiera realizar una suscripción al mismo tiempo que el registro en el foro. En este momento, el proceso de dos etapas no es ideal para todos los escenarios.
Resolví con éxito la suscripción única con un intervalo de tiempo agregando metadatos nuevos (“recurring:0/1”) en el objeto de precio. Y cuando intentes crear una suscripción con price[:metadata][:recurring]==“0”, estableceré el valor cancel_at_end = true en el objeto Subscription.
Luego, cuando crees un precio único, aún necesitarás elegir un intervalo (año, mes, día, semana), pero no deberías marcar la casilla “recurrente”.
Y cuando un usuario se suscriba, el backend creará una suscripción recurrente que finalizará en la fecha de finalización. El usuario no necesitará cancelar la renovación por sí mismo.
También necesitan añadir el secreto del webhook de Stripe a la instancia de Discourse (como ajuste del plugin “webhook secret”). Pueden encontrarlo en la muestra de código a la derecha en el formulario de creación de webhook en Stripe.
Hice un video corto para dar una visión general de las estructuras de datos y cómo se conectan con las estructuras de datos de Discourse:
Estoy bastante de acuerdo con esto, pero ahora debería estar solucionado. Pueden configurar lo que quieran en Stripe con esto (métodos de pago / impuestos / tabla de precios, etc.) y todo debería funcionar.
El plugin solo gestiona la conexión entre los usuarios de Discourse y los clientes de Stripe, y la creación de productos, planes, etc., se realiza completamente en el panel de control de Stripe.
Aún puede haber errores. Si ven algo, por favor, repórtenlo.
¿Así que esta es una bifurcación que planeas enviar como solicitud de PR para el plugin oficial una vez que esté un poco más pulida? Si es así, ¡¡¡genial!!! ¡Y gracias por tu buen trabajo y energía en esto!
Si es así, lo probaré en breve. Por supuesto, llevará un poco de tiempo para probarlo completamente.
[quote=“spirobel, post:17, topic:246395”]tendrás que ejecutar el stripe cli localmente para transmitir los mensajes del webhook. Este es el comando a usar:
stripe listen --forward-to http://localhost:4200/subscriptions/hooks --api-key y
[/quote]
¿Dónde ejecutamos esto? ¿En el servidor como root, o dentro del contenedor docker? ¿Y usamos nuestra instancia URL antes de /subscriptions/hooks?
Y solo para asegurarme de que estoy haciendo lo correcto, ¿es esto lo que instalamos en lugar del plugin oficial?
Esto solo es necesario para una instancia de desarrollo que se ejecuta localmente en tu computadora. Por ejemplo, puedes ver en el video que mi instancia de Discourse se ejecuta en localhost:4200, lo que significa que se ejecuta en mi computadora.
Si deseas recrear exactamente este entorno, puedes seguir esta guía:
Debido a que el servidor de Stripe no puede acceder a la dirección localhost:4200 en mi red local, es necesario ejecutar este comando para reenviar las solicitudes de webhook que provienen del servidor de Stripe.
Si deseas probar esto en un servidor conectado a Internet, puedes seguir la configuración de webhook del tutorial oficial: Discourse Subscriptions Plugin
Por favor, no lo instales (todavía) en una instancia que ya tenga datos de clientes en vivo y la versión anterior del plugin de suscripciones de Discourse instalada. Pruébalo en un segundo servidor de staging, porque las dos versiones entrarán en conflicto.
¡Muchas gracias por probar esto! También permitirá a los visitantes que aún no tienen una cuenta comprar un plan. Serán invitados automáticamente a la instancia de Discourse y tendrán las membresías de grupo apropiadas una vez que paguen.
Tengo un sitio en vivo relativamente tranquilo (betterstreets.nz) con solo 3 clientes, incluyéndome a mí, de un experimento anterior esencialmente fallido. Estaría bastante contento probándolo allí, eliminando el plugin anterior y sus datos si fuera necesario (aunque necesitaría ayuda con el comando correcto de la consola de Rails). ¿Todavía tendría un conflicto en ese caso?
