The issue I’m having is that if someone signs up but doesn’t checkout and pay they still seem to be getting access to paywalled content.
See the screenshot showing clearly that the only user group who should be able to see the content are “paid members”. In the user group settings I’ve already stipulated that “paid members” are only those that have a stripe subscription based on the conditions in the user group settings under “add user based on conditions”
Hey @lolo Thanks a lot for reaching out, what about you make the users pay and after payment you redirect them to the Softr’s sign up block?
So for example you will have these steps after a user accesses you website.
Softr pricing block.
User gets redirected to a Stripe checkout and pays.
User lands on a Softr sign up form.
User signs up and gets redirected to a corresponding dashboard.
Please feel free to get back whenever any further question arises.
Hi @Andranik, I’m not the OP but was hoping you might explain how Softr is able to associate the subscription with a user who has not yet signed up (please err on the side of being too technical than not technical enough). Also, how would this work for allowing the user to sign up with a free trial?
@keymaker when users login their email is used to check a corresponding user in stripe and get their subscriptions and check against your user group definition…
You would need to share some details via live chat so we can check what user has access that should not have…
But if their cus_id is not stored in my back-end (Airtable) and they use a different email to create an account, how would we correlate the two (user in Softr vs user in Stripe)?
We use email to connect so you either need ask them to login then checkout or make sure they use the same email to signup for your account… either way email is the connecting field. This is however can only make them not see paif group content if your users see paid content without being in paid group then that’s a different issue
Hi @Andranik. This works, but the user journey is redundant. Stripe requires an email, name,…, just like Softr’s sign up blocks. So you’re asking the user to submit their credentials over again to sign up.
I don’t know if this is exactly what you expect but here are some best practice when using Stripe in Softr:
Do not use the dynamic “Simple Checkout form” block. The email will be automatically populated in the input… but it can be changed by the user…
Instead, when you want your users to pay with Stripe, use one of the static pricing blocks.
You will have to enter the price_id of the product and on click it will redirect the user to the stripe payment link. The email address will be populated the correct way and the user won’t be able to change it.
Right. This is the way I use Softr’s Stripe integration. You can avoid workarounds, as “native” integrations are intended, and I find it reduces sign up friction when users aren’t forced through a paywall up front, kind of the way Softr gets us to pay .
To clarify @keymaker, the user will have to be in your Softr users table with this configuration (ex. already signed up through Softr sign up block) for their email to populate in the Stripe checkout. Before this though, it would be a good idea to verify that email, but unfortunately there’s no way to do that with Softr’s sign up .
Thanks for clarifying! Is Softr also able to catch users who unsubscribe or update their plan using the customer portal payment block? Or would I need to create a separate webhook and find a way to update data in Airtable?
Hi Matthieu. Good ideas for using Stripe. Why do you suggest using the static pricing blocks over the Simple Checkout form, other than email auto population?
One year ago (and more) using the Simple Checkout form didn’t update very well the user groups based on Stripe subscription.
Many users had this problem: After a user had paid their subscription they had to wait many minutes before accessing the gated content because their user group was not updated accordingly.
So I just gave up using this block (by the way, it may work better now, I don’t know).
Relying on Stripe’s own checkout ensures I won’t never have a sudden bug one day. For this reason that’s also an insurance for me.
@matthieu_chateau not sure that issues is still relevant once user checks out and the stripe has paid status we read from stripe via API and don’t cache much.
Thansk for the clarification @artur
Do you know how can I get the “Stripe Status” on Airtable datasource?
My question is, how can I access online the list of users with their Payment Status?
What I mean by “access online” I mean to access it externally (via API, airtable, Gsheet, etc.)
BTW, In my case, I am using the “Simple Checkout form” but hiding the email and name with CSS so it is not possible by the user to change it. Having the email as a free text field, can generate a lot of orphaned subscriptions…
.
.