一次支付实际发生了什么
1
客户点「立即购买」
商户前端把商品和数量发给商户后端，不直接调用 Clink。
2
商户后端先建一条商户订单
记下买了什么、多少钱、卖给谁。这条记录是商户系统里的真相，后面所有状态都挂在它上面。
3
商户后端创建 Checkout Session
Clink 返回
sessionId 和 url。url 就是收银台地址。4
客户在收银台付款
选支付方式、输入卡号、过 3DS 验证，全部在 Clink 的页面上完成，商户不接触卡号。
5
Clink 把结果推给 Webhook
付款成功推
order.succeeded，失败推 order.failed。6
商户后端确认收款，然后发货
收到事件、验完签、匹配上订单之后，才发货、充值或开通权益。
三个”订单”，别搞混
上面那六步里，有三样东西都能被叫做”订单”：Clink 建的 Checkout Session、客户付款产生的 Order、以及商户后端自己那条记录。名字像，作用完全不同。
一个 Session 可以产生多笔 Order。客户第一次刷卡失败、换张卡再刷成功，就是两笔 Order 挂在同一个 Session 下。所以判断付款结果要看 Order，不要看 Session。
状态怎么读
Checkout Session
status 描述这个支付入口还能不能用：
paymentStatus 另有 unpaid、processing、paid 三个值，适合展示给客户看进度。对账仍然看 Order。
Order
status 是付款结果，也是要映射到商户业务状态的那个字段：
pending 是最容易出事的状态。它的意思是”还不知道”，不是”失败了”。这时候重新发起扣款，客户很可能被扣两次。
什么才能作为发货依据
只有一件事算数：商户后端收到了通过验签的order.succeeded 事件，或主动查 GET /order/{id} 拿到了 success，并且这笔 Order 能匹配上商户订单。
两个环境
Clink 分沙盒和生产两套环境。沙盒就是通常说的测试环境，不动真钱。
两套环境是两个独立的后台地址，账号和密码共用一套，但数据和密钥完全隔离。沙盒里建的产品、客户、订单，生产环境查不到。
测试卡号
4242 4242 4242 4242，CVC 任意 3 位，有效期填任何未来日期。这张卡只在沙盒有效。
接下来
跑通第一笔测试支付
照着做，十几分钟能看到一笔成功订单。
选择接入方式
收银台是跳走还是嵌在自己页面里。