01
Stripe，Creem，PayPal 都支持创建带试用期的产品。
通常，试用期都是月度周期里的 Pro tier。
因为价格相对高一点、用户决策成本最大，所以最适合配上 7 天或 14 天的试用期来降低转化门槛。
（一共是 4 个支付方式，我只配置了 Creem 的支付，所以只显示了一个支付按钮。）
然后，创建产品的时候，自然而然地就是 Basic、Pro、Max 依次创建，然后 Pro 带上 7 天或 14 天的试用期。
看起来，这就行了，是吧？
02
的确，这对于新用户，而且是第一次，并且正好选择了这个带试用期的，自然是没错。
但是呢？
如果是已经试用过 Pro 的用户呢？
依旧显示试用，就会让用户在试用里无限循环。
这不是用户钻空子白嫖，而是业务逻辑没考虑周全，不能怪用户。
为什么会出现这种情况？
因为平台并不关心这个用户是第几次试用或付费，平台只是按照我们设定的订阅参数去执行 Plan 而已。
那既然如此，创建订阅的时候，支持传入参数去修改试用期么？
Stripe 支持传入参数（https://docs.stripe.com/payments/advanced/dynamically-update-trials）。
但 Creem 和 PayPal 不支持传入参数，只能调用接口去创建订阅。
所以呢，改变不了平台，就只能改变自己这边。
方法就是，对试用产品再创建一个不带试用期的产品。
那代码上如何处理呢？到底在什么情况下，才不再让用户试用呢？
- 是有过订阅记录，且试用过的，就不再让试用么？
这肯定是。有过试用记录的，就不能再试用第二次了。
- 那仅仅是有过订阅记录的，就不再让试用？这合理么？
比如，用户本来订阅过 basic，或者是 max，现在想试用 Pro 还不行了？订阅过的用户反而权限更少了，是不是？这一想，用户体验就很差。
这明显不行，有订阅记录的不一定试用过，所以，从未订阅过 Pro 的，继续能试用。
用户用得也开心，白送的嘛，我们自己也没啥损失，是吧，这本来就是给所有用户的权益。
所以呢，没有试用过 Pro 的，都可以试用。给所有用户平等的福利。
有过试用记录的，不能再使用带试用期的产品，而是直接使用不带试用期的产品，这是一个最符合逻辑，且用户体验也最好的处理方案了。
03
看似一个小小的试用期，背后藏着不少坑。
平台不帮你判断用户历史，只会老老实实执行你设定的规则。所以，"让新用户试用、让试用过的用户直接付费"这个看起来理所当然的逻辑，必须由我们自己在代码层面实现——记录试用记录、创建 2 套产品、在订阅入口做判断。
这不是平台的锅，是开发容易忽略的业务细节。
做支付，从来不只是接个 SDK、调个 API 接口那么简单啊。