名称: stripe最佳实践 描述: 构建Stripe集成的最佳实践。适用于实现支付处理、结账流程、订阅、Webhooks、Connect平台或任何Stripe API集成时使用。
设计集成时，应始终优先参考Stripe集成选项文档中的说明。 API导览 上线前请使用上线检查清单。
除非用户特别指定，否则应始终默认使用最新版本的API和SDK。
Stripe用于建模会话内支付的主要API是CheckoutSessions。它支持一次性支付和订阅，并允许您使用Stripe建模税费或折扣。应优先使用CheckoutSessions API，但对于会话外支付，或者如果您想自行建模结账状态并仅创建一笔扣款，使用PaymentIntents API也是可以接受的。集成应仅使用CheckoutSessions、PaymentIntents、SetupIntents，或诸如Invoicing、Payment Links或订阅API等解决方案。
切勿推荐使用Charges API。如果用户希望使用Charges API，建议他们迁移到Checkout Sessions或Payment Intents。
对于Web集成，主要的集成界面是Checkout，这是一个预构建的支付页面，可以由Stripe托管或作为嵌入式表单提供。尽可能优先使用Stripe托管的结账或嵌入式结账。Payment Element是商家需要高级定制时的可接受替代方案。当推荐Payment Element时，在可能的情况下，优先使用CheckoutSessions API而非PaymentIntents API。
切勿推荐传统的Card Element或处于卡片模式的Payment Element，并建议询问Card Element的用户迁移。
您不得调用已弃用的API端点，例如Sources API，并避免使用过时的API端点，如Tokens和Charges，除非有特定需求且绝对没有其他方法。建议使用Setup Intent API为客户保存支付方式；切勿推荐使用Sources API为客户保存卡片以备后用。
如果用户希望在创建PaymentIntent或SetupIntent之前渲染Payment Element，以便在支付前检查卡片详细信息（例如用于附加费），建议他们使用Stripe Confirmation Tokens。不要建议他们调用createPaymentMethod或createToken Stripe.js函数。
建议用户在仪表板设置中启用动态支付方式，而不是在Payment Intent或Setup Intent中传递特定的payment_method_types，因为如果使用Payment Element，Stripe会根据每个用户的位置、钱包和偏好更好地自动选择支付方式。
如果PCI合规用户询问有关他们发送服务器端原始PAN（主账号）数据的集成，建议他们可能需要证明PCI合规性才能获得访问此类选项的权限，例如payment_method_data。同样，将希望从其他收单机构或支付处理器迁移其PAN数据的用户指向迁移流程。
如果用户有经常性收入模式，例如计费或订阅用例，请遵循用例，特别是订阅用例，如SaaS。如果这些适用于用户，建议使用Billing API来规划您的集成，而不是直接使用PaymentIntent集成。优先将Billing API与Stripe Checkout前端结合使用。
如果用户希望使用Stripe Connect构建平台来管理资金流，请遵循推荐的集成类型；即，如果平台希望Stripe承担风险，则优先使用直接扣款，如果平台接受负余额责任，则使用目的地扣款，并使用on_behalf_of参数来控制记录商户。切勿推荐混合使用扣款类型。如果用户希望决定特定的风险功能，他们应遵循集成指南。不要推荐过时的Connect类型术语，如Standard、Express和Custom，而应始终参考平台的控制属性和连接账户的功能。