Checkout block has Name and Email (username) fields NOT locked - that's an issue

[bbelo]

Hi.

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.

Thanks
Boris

[Ben]

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.

[bbelo]

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.

Thanks
Boris

[Ben]

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”.

Sync Softr Subscription Status from Stripe

Sure Artur. Paying users (subscribed to a paid user group condition) are not mapped to enough requisite events that occur in Stripe. For instance, when a user attempts to upgrade their subscription by selecting a different subscription from a Softr pricing block, Stripe creates another customer with a new subscription that has the same email instead of switching that user’s subscription (product). So this subscription change is not reflected in Softr. Apparently, Stripe is having the user ju…

[bbelo]

Interesting digression from the original topic…

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.

Boris

[bbelo]

Interesting to see no additional replies on this issue.

Three things could be happening:

1. Either I am not seeing something that’s there that should negate my concern.
2. The issue is present, but isn’t being recognized by the community, which is odd, because virtually every paid app should be using a checkout block, I would think.
3. The issue is present and is being recognized by the community, but isn’t actually stirring many real problems, as the app users aren’t overwriting their names and emails in the checkout block.

I wonder.

Thanks

[artur]

@bbelo I would suggest as a quick solution to apply a small custom code. We had those fields not editable, then part of the community wanted it to be editable, so until we make it configurable, we could share a small code snippet.

[bbelo]

Thank you Artur. This would be very helpful to us. Please, let me know how we can access the code snippet you are referring to.

Thanks

[bbelo]

@artur was kind enough to provide the code snippet to cause the name and email on this check-out block to be read-only. It needs to be put in the page’s footer.

<script>
document.addEventListener("DOMContentLoaded", function() {        
    $('#full-name-element').prop("readonly", true);
    $('#email-element').prop("readonly", true);
});
</script>

Thanks