接支付这件事，坑不在代码里
做会员、做付费下载、做电商，站长迟早要跟支付打交道。很多人以为难点在调接口，其实接口文档通常写得挺清楚，真正让人焦头烂额的是另外四件事：资质、费率、回调和对账。这四样里有一样没想明白，上线后就得交学费。
第一件：资质够不够
这是最容易被忽略的前置条件。不同支付通道对接入主体的要求不一样：企业主体和个体工商户能选的通道，通常比个人主体多得多，个人主体在很多场景下根本接不进去。除此之外还有几个常见门槛：域名是否完成备案、网站经营类目是否在允许范围内、涉及预付费或会员储值时是否还有额外要求。
建议动手写代码之前，先把通道的接入条件看一遍，确认自己的主体和类目能过。否则写完一整套接了才发现审核不过，白折腾。
图片由 AI 生成
第二件：费率之外，更该看结算周期
费率当然要看，但别只盯着那个百分比。几个同样影响现金流的因素：
- 费率因通道和行业而异，不同类目可能差出一大截，签约前问清楚自己这个类目适用哪一档
- 结算周期：钱多久能到你的账户，是次日还是更久，对小本生意影响很实在
- 提现与退款规则：提现是否另收手续费，退款时已扣的手续费退不退
- 是否有单笔或月度门槛，量小的时候这类固定成本占比会很明显
第三件：回调才是真正的重灾区
支付成功与否，不能只看用户浏览器跳回来的那个结果。用户付完款直接关掉页面、网络抖动导致跳转失败，都会让你收不到前端结果。可靠的依据是支付方发到你服务器的异步通知。
处理回调有四条规定动作，缺一不可：
- 必须验签：不校验签名的话，任何人都能伪造一条"支付成功"的通知，等于白送东西
- 必须做幂等：同一笔支付的通知可能重复送达，要用商户订单号去重，避免重复发货或重复开通
- 必须有主动查单补偿：用户确实付了但通知迟迟不来，要能主动去查这一单的真实状态
- 必须正确响应：处理成功后按文档返回约定的结果，否则对方会认为你没收到，一直重试
还有一条安全底线：金额以服务端计算为准。前端传过来的价格一律不可信，否则改个请求就能低价买走东西。
图片由 AI 生成
第四件：对账不能省
系统跑起来之后，每天要把本地订单和支付通道的账单对一遍，核对三个维度：金额是否一致、状态是否一致、笔数是否对得上。差异通常来自漏单、重复入账和金额不符，越早发现越好查。
对账日志要留存，出问题的时候这就是唯一的线索。规模小的时候可以每天人工核一遍，量大之后就该做成自动任务，异常自动告警。
上线前，把这三个场景测一遍
测试环境里别只测"正常支付成功"这一条快乐路径，下面三种情况必须各跑一遍：
- 同一笔通知重复送达两次，看是否只发货一次
- 通知故意不处理，看主动查单能否补上状态
- 篡改请求里的金额，看服务端是否拒绝
这三关过了，线上出问题的概率会低一个数量级。至于卡号、有效期这类敏感信息，原则上不要存在自己的库里，能不碰就不碰。
一句话
资质先确认、费率看全貌、回调按四条铁律写、对账每天跑。把这四件事列成清单逐项打勾，比事后救火轻松得多。
