We're a group of makers shipping together. We help each other stay accountable and reach our goals.
Apply for access
Sander
@sanderfish
I'm working on Checkout Page (checkoutpage.co) and am looking for good reasons to add recurring billing. I can imagine something like filling in a Typeform -> link to Checkout Page -> return to a certain URL after subscribing.
Could you explain in more detail what you're looking for?
I've got two products - one is a paid newsletter, the other is a community not too different from WIP/Nomadlist. Both need recurring payments.
I really enjoy Typeform's seamlessly embeddable interface and that it integrates easily with Mailchimp / GA etc - but the lack of recurring billing is a bummer.
Yeah, it is a bummer that TypeForm doesn't support subscriptions. Also, when a customer makes a purchase in Stripe, TypeForm doesn't create a customer in your stripe account. For example, I've made over 500 sales via TypeForm, and my Stripe account shows 0 customers.
I would suggest the next best option is PaperForm:
paperform.co/
Here's how to sign the customer to a subscription using PaperForm:
paperform.co/help/article/rec…
Then after they fill out the form, direct them to another URL as you mentioned. PaperForm also supports webhooks for doing more advanced things.
And if you don't need a complex multi-step questionnaire like you'd be able to create using TypeForm or PaperForm, if you just need something simple that can handle recurring billing, here's a good option:
LandingPay
www.landingpay.com/
What I'm referring to is just about the routing (part static, part dynamic). I think that who can access which route doesn't have anything to do with Gatsby – you should handle that yourself.
Oh okk. I don't think it will help for what I am trying to do. What you are saying is like running code on a site which is dynamic. I think I have to make a different server for payment processing & I can send AJAX requests from the Gatsby site. I'll build a prototype to test this idea. It makes sense.
I think Gatsby has a solution for this here: www.gatsbyjs.org/docs/buildin…
"A classic example would be a site that has a landing page, various marketing pages, a login page, and then an app section for logged-in users. The logged-in section doesn’t need to be server rendered as all data will be loaded live from your API after the user logs so it makes sense to make this portion of your site client-only."
Wow thanks man. I hope it works. But I need some server for processing Payments, right?
I read it & it means I can have an API which will result in requests/response cycle.
But my use case is I have an /apps route containing all my apps. Lets suppose I have a MarkdownViewer.dmg that I want to show only after Payment is done.
If I make this Client only with Gatsby it will show the url at which MarkdownViewer.dmg is stored in HTML which will cause people to download without paying. From what you are saying will this work with Gatsby ?
And mind you I have seen big companies like Egghead doing it. I found that security issue when they stored all their videos URLs in Redux & I was easily able to download it without a lot of security knowledge.
What I'm referring to is just about the routing (part static, part dynamic). I think that who can access which route doesn't have anything to do with Gatsby – you should handle that yourself.
Oh okk. I don't think it will help for what I am trying to do. What you are saying is like running code on a site which is dynamic. I think I have to make a different server for payment processing & I can send AJAX requests from the Gatsby site. I'll build a prototype to test this idea. It makes sense.
there's the telegram group @liftordie which is fitness related
Pugson's rikko.io/?
Not a bad idea. But... I'd rather not make my voters see the "Let's create your account" screen before voting.
This might happen one day: roadmap.rikko.io/idea/5