The Stripe API (available as a plugin straight from the Bubble team) makes this simple - can instantiate subscriptions within your Stripe account and then tie your users to that subscription via your API when your user subscribes (after capturing their CC info and sending that to Stripe as well).

Every pro has a con of course, and this ties you to Stripe’s ecosystem. I’ve heard of (rare) instances where if Stripe has any intermittent outage, you’ll be unable to verify if your users have an active subscription, are all paid up, etc. SO make your app design sensitive to this potentiality.

Personally, I build subscription model internally and just call Stripe at the appropriate times to charge the user’s stored CC over at Stripe, via daily internal API’s that check everyone’s rollover dates. The con to this pro is that I’ve noticed a (rare again) potential for Bubble to errantly issue parallel calls of the same scheduled API when your app is running under a bit of high traffic at the same time it’s conducting calls. I have had to personally issue refunds to users who get a charge-the-credit-card API called on them multiple times in parallel when it was scheduled to run in advance.

Both situations are rare and capable of being mitigated with the appropriate constructs. (Graceful user-status checking against Stripe and tying CC API’s against a DB PID (like an authorization key to lock-out other parallel errant API calls), respectively.

3 Likes