能否在RevenueCat中实现手动银行卡录入？是否需迁移至Stripe？

针对你的核心需求——不想放弃RevenueCat对应用内购的优势，同时补充手动银行卡支付选项，以下是具体解决方案：

一、RevenueCat Connect + Stripe 混合支付（官方推荐） #

• 这是最省心的方案，RevenueCat原生支持和Stripe集成：
  1. 在RevenueCat后台绑定你的Stripe账号（通过RevenueCat Connect功能）。
  2. 在你的独立网页端，用Stripe Elements实现手动银行卡录入（Stripe全程处理PCI合规，你无需接触原始银行卡信息），创建对应订阅产品。
  3. 用户完成网页支付后，Stripe的订阅数据会自动同步到RevenueCat，你无需额外开发Webhook逻辑。
  4. App内依然通过RevenueCat SDK处理Apple Pay/Google Pay原生支付，所有订阅状态、续期、退款逻辑统一在RevenueCat后台管理，App端代码无需大幅改动。
• 关键合规提醒：严格遵守App Store和Google Play规则，不能在App内直接引导用户跳转至网页支付，只能在用户主动发起（比如通过网页端自行操作）且不违反商店条款的场景下提供该选项，否则会影响审核。

二、Web Billing + RevenueCat Webhooks 自定义同步 #

如果需要更灵活的控制，可以自己搭建Web支付流程并通过Webhooks同步数据：

1. 在Stripe后台创建与App内产品SKU对应的订阅项目。
2. 用Stripe Elements搭建合规的支付网页，收集用户银行卡信息（确保PCI合规）。
3. 用户支付成功后，监听Stripe的订阅创建Webhook事件，调用RevenueCat的API（如POST /v1/subscribers）将Stripe订阅ID关联到RevenueCat用户ID上。
4. 后续Stripe的订阅状态变化（续期、取消等）也通过Webhooks同步到RevenueCat，保证两端数据一致。

关于全量迁移Stripe的建议 #

全量迁移到Stripe确实需要自行处理大量应用内购相关的工作：包括App Store/Google Play的收据验证、订阅状态同步、商店规则合规审核等，开发成本高且容易踩坑（比如App Store强制要求数字订阅提供App内购选项，除非符合豁免条件）。因此，除非有特殊业务需求，否则不建议全迁，混合支付模式是更优选择。

内容的提问来源于stack exchange，提问作者Noah Lejolivet