Hey,
I’ve seen some bubblers add new fields in the User to store the customer id and the subscription id.
Why aren’t you using the built in Current User’s Stripe Customer ID and Current User’s Stripe Customer subscription's Subscription ID?
Is there any benefit in storing this as fields?
Thanks in advance 
Some individuals choose to utilize various plugins for their needs. Bubble’s in-house Stripe plugin offers the convenience of prebuilt fields, while other plugins, like Stripe.JS, necessitate the creation of a separate area for storing the ID while harnessing the power of Stripe elements.
The choice ultimately lies with you, allowing you to select the option that best suits your preferences and requirements.
I have a list of list of reasons why I NEVER use the Stripe Bubble plugin - mostly to do with how limited it is in functionality, how inflexible it is, and how it handle’s post-payment flows (i.e. redirecting back to the previous page) - plus I generally avoid using plugins wherever possible, as I prefer to be in control of my own apps rather than relying on other people’s solutions.
Plus, Stripe’s API is so simple, and the docs are so good, it’s just as easy (if not easier) to deal directly with their API and have full control over the process as it is trying to figure out how some plugin works, only to find it doesn’t do what you need it to do - so you end up compromising and changing what you’re doing just to make it work with a particular plugin.
The Bubble Stripe plugin is fine if you want a quick and easy Stripe integration, and what you need is amoungst it’s (fairly limited) features. But if you want more flexibility, control, and the full power of Stripe’s API you’ll need another solution, and for that you’ll need to store the Customer ID in a custom field.
Thanks, @adamhholmes.
Can you explain this further?
The Bubble Stripe Plugin doesn’t let you define the Success URL for the checkout.
Instead it redirects the User back the page they came from - which is a very unusual UX - and extremely annoying for both the customer and the developer.
I suppose, they have to do that because of how the plugin stores subsequent post-chekout data on the User datatype (as the plugin can’t use webhooks) - so it has to redirect to the previous page in order to continue it’s built in flows of storing the Customer ID and/or subscription ID on the User.
But it makes for a VERY annoying, and strange user experience - it’s much more desirable to be able to redirect Users directly to an appropriate success page after checkout (like practically EVERY website does), rather than have to redirect back to the post-checkout page.
This is a pretty major UX issue in my opinion - just that alone is enough for me to never even consider using this plugin for any serios payment integration (although it’s just one of many reasons).
Ohh, okay. I understand now.
Agree. Terrible user experience.
This topic was automatically closed after 70 days. New replies are no longer allowed.
