01
Stripe, Creem, and PayPal all support creating products with trial periods.
Typically, trial periods are for the Pro tier in monthly cycles.
Because the price is relatively higher and user decision-making cost is greatest, it's most suitable to add a 7-day or 14-day trial period to lower the conversion barrier.
(There are 4 payment methods in total, but I only configured Creem payment, so only one payment button is displayed.)
Then, when creating products, it's natural to create Basic, Pro, Max in sequence, with Pro having a 7-day or 14-day trial period.
This seems fine, right?
02
Indeed, this is correct for new users, and it's their first time, and they happen to choose the one with a trial period.
But what about users who have already tried Pro?
If it still shows trial, it will put users in an infinite trial loop.
This isn't users exploiting loopholes for free access, but rather incomplete business logic consideration. You can't blame users.
Why does this happen?
Because the platform doesn't care whether this is the user's first or second trial or payment. The platform just executes the Plan according to our set subscription parameters.
So, does the platform support passing parameters to modify the trial period when creating subscriptions?
Stripe supports passing parameters (https://docs.stripe.com/payments/advanced/dynamically-update-trials).
But Creem and PayPal don't support passing parameters; you can only call APIs to create subscriptions.
So, if you can't change the platform, you can only change your own side.
The solution is to create another product without a trial period for trial products.
How do you handle this in code? Under what circumstances should users no longer be allowed to trial?
- Should users who have subscription records and have tried before no longer be allowed to trial?
This is definitely the case. Users who have trial records should not be allowed to trial a second time.
- But should users who merely have subscription records no longer be allowed to trial? Is this reasonable?
For example, if a user previously subscribed to Basic or Max, and now wants to try Pro, wouldn't that be unfair? Subscribed users would have fewer privileges, right? When you think about it this way, the user experience is very poor.
This clearly won't work. Having a subscription record doesn't necessarily mean they've trialed, so users who have never subscribed to Pro can continue to trial.
Users are happy, it's free after all, and we don't lose anything, right? This was originally a benefit for all users.
So, users who haven't trialed Pro can all trial. Give all users equal benefits.
Users who have trial records cannot use products with trial periods again, but instead directly use products without trial periods. This is the most logical solution with the best user experience.
03
What seems like a small trial period hides quite a few pitfalls.
The platform doesn't help you judge user history; it will only faithfully execute the rules you set. So the seemingly obvious logic of "let new users trial, let users who've trialed pay directly" must be implemented by us at the code level—recording trial records, creating 2 sets of products, and making judgments at the subscription entry point.
This isn't the platform's fault, it's a business detail that developers easily overlook.
Implementing payments has never been as simple as just integrating an SDK or calling an API.