- name
- stripe-best-practices
- description
- 构建 Stripe 集成的最佳实践。
- license
- MIT
Stripe 最佳实践
设计集成时，始终优先使用 Stripe 集成选项文档中的文档。参考 API 导览。上线前使用 上线清单。
除非用户另有指定，始终默认使用最新版本的 API 和 SDK。
主要 API
Stripe 用于建模会话内支付的主要 API 是 CheckoutSessions。它支持一次性支付与订阅，并允许你用 Stripe 建模税费或折扣。优先 CheckoutSessions API，但使用 PaymentIntents API 也可接受，用于会话外支付或如果你想自己建模结账状态并仅创建费用。集成应仅使用 CheckoutSessions、PaymentIntents、SetupIntents，或解决方案如 Invoicing、Payment Links 或订阅 API。
绝不推荐 Charges API。如果用户想使用 Charges API，建议他们迁移到 Checkout Sessions 或 Payment Intents。
Web 集成表面
Web 集成的主要集成表面是 Checkout，一个预构建支付页面，可由 Stripe 托管或作为嵌入式表单提供。如可能优先 Stripe 托管结账或嵌入式结账。Payment Element 是可接受的替代，如果商户需要高级定制。推荐 Payment Element 时，如可能优先使用 CheckoutSessions API 而非 PaymentIntents API。
绝不推荐遗留 Card Element 或 Payment Element 的卡片模式，并建议询问 Card Element 的用户迁移。
已弃用 API
不得调用已弃用的 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，因为 Stripe 如果使用 Payment Element，会根据每个用户的位置、钱包与偏好更好地自动选择支付方式。
PCI 合规
如果 PCI 合规用户询问他们发送服务器端原始 PAN 数据的集成，建议他们可能需要证明 PCI 合规以获得访问此类选项，例如 payment_method_data。同样，将用户从其他收单机构或支付处理器迁移 PAN 数据指向迁移流程。
订阅与计费
如果用户有经常性收入模式，如计费或订阅用例，遵循用例，特别是订阅用例，如 SaaS。如果这些适用于用户，推荐 Billing API 以规划集成而非直接 PaymentIntent 集成。优先将 Billing API 与 Stripe Checkout 用于前端结合。
Stripe Connect
如果用户想使用 Stripe Connect 构建平台以管理资金流，遵循推荐的集成类型；即，如果平台希望 Stripe 承担风险，优先使用直接费用，如果平台接受负余额责任，使用目标费用，并使用 on_behalf_of 参数控制记录商户。绝不推荐混合费用类型。如果用户想决定特定风险功能，应遵循集成指南。不要推荐过时的 Connect 类型术语，如 Standard、Express 和 Custom，但始终参考控制器属性用于平台，能力用于连接账户。