Can someone explain how to offer a 30 day trial for an app and then force the user to pay via stripe? I understand the 2nd part but how do you set it up for the first part where there is a countdown to then force the user to pay?
I don’t want them to enter their credit card until the 30 days is up. Essentially, this should start when they do the initial sign up.
Add a new field for the User called “registration date”
Set it to the date when the user registers(You could do it in you “registration workflow”)
After that whenever anyone logs in, in your “log in workflow” you could perform a simple calculation between the date when the user registered (stored in the “registration date” field) and the current date to see whether they are within their 30 days trial period
If they are within their trial period you could redirect them to your app, otherwise redirect them to the payment page
Or just create end-date field, when sign up, add current date + the trial days i.e 30.
Add another field trial yes/no.
And then a condition when current user trial is yes and trial date > or equal to current date redirect to subscription page or show a pop-up that’s not closable.
When user does payment and gets subscribed you change field trial to no.
This is an approximation.
I suggest you also to create webhooks if you will be using recurring payments and add to end-date the ending date of the current subscription.
Regards.
Thanks @yusaney1 Can you explain this a little more “I suggest you also to create webhooks if you will be using recurring payments and add to end-date the ending date of the current subscription.”
One other thing. Do I have to create a popup for the payment or does the stripe plugin have the template?
Create an endpoint, add some fields like start date, end date.
Get the endpoint url.
Add webhook in stripe every time a user subscribed to plan.
Get data from stripe and add it to current user.
You can use transaction_id to filter the user.
Convert the date from Unix to human date and then add it the the end field.
Make sure you check for user end date every time.
PS. The payment happens on bubble side so there’s no template from stripe.
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:
Name [text]
Description [text]
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:
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.)
When you sign a user, create a new field of “Expiration date” which is Current date/time + 30 days and create a new user.
Next, on all the pages, create a workflow that General -> Do this when condition is true. In the dialog box change “Run this” to Every time and “only when” Current user’s expiration date is < Current date/time. Then create a condition to navigate to a new page where you offer the option to upgrade the plan.
Let me know if you encounter any problem!