This is an issue I shared with Softr support a while ago. Was really hoping they’d address it, but I see it’s still an open issue.
Here is the situation - when my user is redirected to a checkout page (using a checkout block), the block will have the Name and Email (username) fields conveniently filled in with the user information. That’s great!
But… I don’t know if anybody realizes that these fields are not locked - allowing the user overwrite the information before hitting the subscribe button. Not that anybody would want to do that. But on an off-chance somebody did do that - I think it would cause a serious issue of data discrepancy between Stripe and Softr/Airtable.
I put out a message at the top of the block saying "The Full Name and Email must match that of your {Our App Name} account. But the fact remains that I cannot enforce it, and my experience tells me that if you open the door for something to go wrong, it eventually will…
Wondering what the Community thinks of this.
Feels like a fairly easy change for Softr to make. Actually, I don’t even know if putting the Name and Email fields on the block is necessary. Probably a good thing, but they need to be grayed out / locked.
Hi Borris. Softr’s “Stripe Integration” is very limited. I agree that the logged in user’s email should be locked into the field. It doesn’t make sense otherwise, because email is the only parameter Softr uses to identify a Stripe customer. Should a logged in Softr user change the email address when they checkout, the Softr product/subscription will be reflected to that email address rather than their Softr user email address.
Thanks Ben. And that’s exactly the issue.
Because the integration between Softr and Stripe is somewhat limited, although not bad actually, I supplement it with Airtable/Make workflows to keep my app user’s email and that of the Stripe subscriber in sync. But the whole thing may fall apart if someone inadvertently changes the email address upon checkout.
Actually, I didn’t think locking / graying out the email field in the Softr block would be a Stripe issue. I thought it was squarely a Softr issue and could be easily fixed by Softr making this field locked / grayed out in its block. Maybe I am wrong…
Softr support didn’t indicate to me it was a Stripe limitation. It was more of a Softr feature request that could be fairly easily fulfilled.
This goes into some the limitations and how Stripe Ids should also be used for a “Stripe Integration”. IMO, you shouldn’t need Zapier or Make if an application is “integrated”.
I was actually thinking of switching away from a single plan that I’ve set up to a multi-plan setup before going live with MVP. I haven’t tested it yet, but I was wondering how Softr might signal to Stripe to cancel the existing subscription, pro-rate it if needed and charge for a new one, and optionally only charge for the difference in pricing. I always thought that multiple subscriptions can be spun up under a Stripe “customer”. Never thought that it cause it to create a new actual Stripe “customer” as your note indicates. Still doubt it. But I’ll have to test.
Either way, the original issue raised was just merely about graying out the name and email fields on the checkout block, not taking them out, but graying them out, simply forcing Softr to pass the app user info, as it is known to Softr, and disallowing the app user to change it at checkout time. I still think this is just a Softr thing.
