You can of course configure your Plan in Stripe this way. There’s a field for trial period.
I get that you don’t want to make users enter payment info, but I just wanted to make it clear that all of this functionality is in Stripe.
Obvs, the decision is yours about which is the better technique.
In terms of how, I would think about defining Trial(s) as a data type so that you can set up different versions (or just more easily maintain one Trial). A Trial would have fields like:
Duration [number - representing days]
Stripe Plan ID [Stripe Subscription Plan ID - the thing this would convert to at end of Trial duration]
Anything Else You Need to properly define a trial
These would be system constants that you define in App Data or via your own admin interface.
Create one more data type: A “User Trial” (or whatever you’d like to call it) - this would have at least two custom fields:
Trial: [type Trial]
Start Date: [date]
Expiration Date: [date] (this is actually optional!)
You would also add a User Trial field or a list of User Trials to the User data type – I’ll talk about this in context, below…
When you sign a user up for a Trial, you would then do this:
Step 1. Create a new User Trial with fields:
Trial = The Trial object that represents what they are signing up for
Start Date = Current Date/Time
Expiration Date = Current Date/Time+Days: The Trial object’s Duration (this is optional because we can always compute this as User Trial’s Start Date+days this User Trial’s Trial’s Duration, see?)
(Note that this User Trial will have an implicit User field as the User will be this User Trial's **Creator**)
Step 2. Attach the User Trial to the User. a. If you think you may eventually offer multiple different types of trials for different things, you would put a field on the User data type of type User Trials and this would be a List of type User Trial. b. If you are sure you will always and ever only offer one trial, this could be a non-list (single item) field named User Trial of type User Trial.
Depending on which route you go, the attach operation would be like this:
a. Make changes to a thing > Current User > field User Trials add item Results of Step 1 [the User Trial that was just created is now part of the User’s list of User Trials]
b. Make changes to a thing > Current User > field User Trial = Results of Step 1 [the User Trial that was just created is the User’s User Trial]
Step 3. You could now schedule any reminder operations that you want to do like send nag emails or whatever at various dates. You might also NOT schedule those just now but do that as Recurring Events in your app or using any of the other cron-job-style hacks one can do with Bubble.
As far as how you “expire” a user:
This depends on what your trial represents. If your trial is simply “access to your app” you just make checking the existence of the trial part of the login workflow or pages in your app:
- A user has full access if they are either:
- Subscribed to a real Stripe plan that is active
- Subscribed to a Trial that is active
How do we know if the Current User’s Trial is active?
The Current User’s Trial is active if Current User’s User Trial’s Expiration Date > Current date/time. (this is for case “b.”)
In case “a.” (where you have a list of Trials that may represent different types of trials), The Current User’s “app access” Trial is active if Current User’s User Trials’s:filtered [filter for the trial that represents “app access”]:first item’s:Expiration Date > Current date/time.
(Reminder: “Expiration Date” may or may not be a real field. You could choose to compute it on the fly from Start Date [Start Date+days Duration]. This can get cumbersome, though, due to Bubble’s limits on where and when you can do date math. But I did want to point out that it’s theoretically entirely optional.)
Now that you can differentiate between expired and active “Trial” Users your login workflow can detect this state and redirect them to a page to collect payment.
You can also see that now you could have scheduled workflows (like daily, weekly or whatever) or cron jobs that send nag messages to users warning them of impending trial expiry.
All of the above is like what @yusaney1 suggests but allows you more flexibility in future (maybe it turns out your trial period should be shorter or longer… maybe you want to a/b test between different Trial Duration’s…). You could do all of that really easily if you have things set up as described above.
For Trials that represent something else like a premium feature, add-on, or whatnot, the technique of making “User Trials” a list lets you differentiate access to that. (And it’s more-or-less parallel to Subscription Plans on the Stripe side. If you have multiple products and plans that represent subscriptions for different things, your Users are going to wind up with a LIST of Stripe Subscription Plans on them.)