Adyen创建Token：/sessions和/payments两个端点分别适合什么场景
如果你正在接入Adyen的tokenization，选择端点的答案可以先用一句话概括：希望尽量缩小PCI合规范围、走最简集成路径，用POST /sessions；需要对结账流程和数据流保持更多控制、处理更复杂的支付流程，用POST /payments。 下面的内容围绕这两者的分工展开，并给出可以自己动手核对的检查点。
/sessions：把收集支付详情的复杂度交给会话
/sessions被Adyen描述为创建token最简单的方式。支付会话本身包含了安全收集支付详情所需的全部信息，因此你的集成不需要自己接触和传递原始支付数据，PCI范围可以降到最简一级（SAQ A）。
这适合的场景是：你的结账页面希望在尽量少的自建逻辑下完成“收集支付详情 + 创建token”，把安全收集的环节交给会话机制处理。判断是否适合你，可以做一个简单核对：你的结账流程是否主要由一个会话承载、你并不需要在服务端对每一步支付状态和数据流做细致编排？如果答案是肯定的，/sessions通常是更省事的选择。
需要注意，这里说的是缩小PCI范围这一机制性收益，并不意味着任何具体行业或业务类型都适用同一套集成方案；具体范围认定仍应以你实际的集成方式和合规评估为准。
/payments：把控制权留在自己手里
/payments提供对结账体验的更多控制，适合需要自行管理状态和数据流的更复杂支付流程。当你需要在支付请求中携带tokenization参数、由自己编排请求与状态时，这个端点更合适。
在/payments上带授权创建token的典型动作是：在支付请求中包含tokenization参数，用购物者的支付详情创建token；交易获得授权后，从recurring.token.created webhook中获取token的唯一标识及其他信息。这条链路说明token是与一笔已授权的交易绑定的。
后续扣款：来源未说明端点归属，需另行核对
创建token只是第一步。当你之后要用这个token发起订阅扣款或商户主动发起的扣款时，具体应使用哪个端点，来源材料未作说明，需要你另行核对Adyen文档或与Adyen确认后再定。不要把/sessions与/payments在创建token阶段的分工，直接外推为后续扣款的端点结论。
一个可复算的核对例子
以下例子中的业务设定（首笔支付 + 后续按月扣款）为假设，仅用于核对端点职责是否自洽：
- 首笔：购物者在你的结账页完成支付并同意后续扣款安排。若你使用
/sessions，你需要自行确认该端点在你的集成中如何完成token创建——来源仅说明它是最简单的创建token方式，未列出参数细节。 - 记录：从
recurring.token.createdwebhook中取出data.storedPaymentMethodId，与data.shopperReference对应保存，作为后续扣款要引用的token标识。 - 后续每期：用保存的token标识构造扣款请求。扣款端点归属按上一节的说明另行核对，不要默认沿用创建token时的端点。
这个例子只用于核对端点职责是否匹配，不构成任何交易或法律建议。
两个容易忽略的配套动作
启用webhook。 要获得token创建、更新、禁用的通知，需要启用Recurring tokens life cycle events webhook。它包含data.storedPaymentMethodId（被创建、更新或禁用的token ID）、data.shopperReference（你的唯一购物者标识）、eventId（用于存储购物者支付详情的那笔交易的pspReference）以及type（webhook类型）。该webhook提供token标识等信息，是你获取这些信息的渠道之一。
告知购物者扣款安排。 在带授权创建token的支付请求中应包含tokenization参数，同时必须告知购物者支付计划和你将扣取的金额，以降低拒付（chargeback）风险。这是流程设计的一部分，不是可选项。
一个需要留意的选项
POST /storedPaymentMethods可以在没有授权的情况下创建token，但该端点仅在Checkout API v70及以后版本可用。Adyen的建议是带授权创建token，以确保token关联到活跃、可扣款的账户。因此除非你有明确理由，优先走带授权的路径，并以上述webhook作为token信息的来源。