Forum Academy Marketplace Showcase Pricing Features

Problems with Stripe subscriptions

  1. The plugin makes it mandatory to “Sign the user up” before “Subscribing the user”. Kind of silly. Isn’t it supposed to be the other way round? Here are more problems this introduces.

  2. If the Stripe subscription fails, the User is already signed up. Maybe he/she can access some subscriber-only functionality.

  3. If the user abandons checkout by clicking the back button, all the fields (email, name, etc.) are gone, and user needs to re-enter everything.

  4. Even if the user is patient enough to re-enter everything, he/she is NO longer allowed to use the previous email address as it’s already in the User table.

All these lead to frustration for the user and high abandonment rate. Of course, there are awkward workarounds. But isn’t it easier for everyone if these issues are fixed at the root? It seems like whoever designed these things didn’t put much thought into them.

Sorry, rant over.

Hi @jayy - I’ve done a fair bit with Stripe and have often just gone for a direct API connector. Happy to look at your setup if you want to share a link.

1 Like

The new user needs to be signed up as in return of the subscription the Stripe ID will be attached to this user in the DB. As a workaround, you could imagine an intermediate user state or role for new user without subscription, and you’ll manage to prevent access to subscriber pages using this state or role.

And if the user never complete the subscription, you could delete it after X hours or days or weeks.

1 Like

That’s the easy part.

How about if user enters the stripe page, clicks back, and is not able to use the same email again? This is such a 1990s problem lol.

  • One solution is to update user credentials, instead of sign up new user. But doing so requires the old password (which user might have changed).

  • The other solution is to delete the user record on page load. But this introduces other risks. e.g. Stripe returns to the previous page upon successful charge, then this workflow would delete a valid user record.

Whoever did this Stripe plugin totally ignores all these use cases, and assumes everything goes right. Probably a no-code programmer lol.

@davis.systems thanks man, let me try it again for a while… will let you know if i need help!

If the user clicks the back button, he will be back on the bubble app subscription page. But the user will be identified by bubble as a signed up / logged in user. So, your subscription form fields should use conditionalsbto automatically fill in some fields from the user database (if user is logged in, then initial email field value = user’s email, and so on). Then remove the password fields, no need (but you can add a link to the reset pwd page).

Back in 2000! :grinning_face_with_smiling_eyes:

And also when the user is already logged in :

  • fill in the email field frol the user email stored in db and make this field read only
  • when the form is submitted, do not repeat the sign up part of the subscription workflow (you can just overwrite the name and other user fields and then redirect the user to the Stripe page).
1 Like

Thanks!! Finally a workable workaround - disabled all registration fields if user is already logged in. :laughing:

1 Like