做了这么多年后端真正让我觉得“离钱最近”的代码就是支付模块。早些年APP内支付基本只考虑微信和支付宝后来云闪付因为银联的营销活动和不少银行的积分补贴也慢慢成了必选项。这篇文章我想把三个渠道从商户申请、服务端下单、客户端拉起、异步回调验签到多渠道统一抽象的完整链路梳理一遍。不管你是第一次接支付还是准备把存量支付逻辑重构一次应该都能从中找到可以直接落地的思路和代码片段。1. 三个渠道的选型逻辑与入驻准备工作1.1 用户场景决定接入优先级微信支付和支付宝是国民级流量入口电商、知识付费、生活服务类APP基本都会同时接。微信的强项是社交关系链带来的支付场景拼单、分享、群聊之后的交易转化明显偏高支付宝强在电商生态和花呗、余额宝这类金融能力客单价高的商品用支付宝的营销工具往往更多。云闪付则靠银联体系和各家银行APP的联动在银行积分兑换、满减活动中被高频使用而且云闪付的费率政策有时候比前两家灵活。如果你们的APP目标用户偏二线城市以下或者业务本身带金融属性云闪付一定不能省。这里有个很实际的取舍经验如果团队资源有限第一版先做微信支付宝云闪付放二期。因为云闪付的商户报备流程需要走线下商务材料周期不可控而技术上三家的抽象模式是基本一致的后期补渠道的成本并没有想象中高。反过来如果产品已经在做银行合作或政务类服务云闪付就应该和微信、支付宝同期上线否则会丢掉一批只习惯用云闪付的用户。1.2 商户号与开放平台的关键配置微信支付需要先注册开放平台账号并创建移动应用拿到AppID后去微信支付商户平台申请商户号。签约APP支付产品之后有几个配置项容易被忽略一是API密钥需要设置为32位随机字符串二是API证书按需下载备用三是APP支付的回调域名和支付目录配置错误会导致客户端拉起时直接报“支付验证签名失败”。曾经遇到一个环境代码完全没问题就是支付目录少配了一个路径前缀线上一直失败最后看商户平台配置才找到原因。支付宝走的是开放平台流程创建移动应用后签约“App支付”产品然后生成应用公钥、应用私钥并上传公钥。需要注意的是支付宝密钥体系分老RSA和新RSA2两套现在新应用一律用RSA2也就是SHA256withRSA生成和验签方式都不要混用。老项目如果还在用RSA建议尽早迁移。云闪付的入驻路径比较特殊需要找银联商务或有资质的机构渠道报备拿到商户号和终端号再到银联开发者社区创建应用并下载控件SDK。这块商务流程通常要预留一到两周时间技术服务联调反而快。如果你发现某一天赶上大促节点务必提前规划报备时间不然就会卡在“程序写完了但商户号还没下来”。2. 从下单到回调支付链路的完整时序2.1 业务订单与支付单据为什么要拆开我强烈建议把“业务订单”和“支付单”分成两个模型。业务订单描述用户买了什么商品、金额多少、处于什么状态支付单记录某笔订单发起的某一次支付行为关联渠道、渠道单号、支付金额、支付状态。为什么要拆因为一个业务订单可能因为超时关闭、用户重试、部分退款等原因发起多次支付每次都要重新落一条支付单。如果不拆把所有信息堆在业务订单表里后期对账和退款会变得非常痛苦。而且支付单据独立之后渠道回调直接更新支付单不影响业务订单的锁状态业务侧再根据支付单成功事件去推进订单状态职责清晰得多。实际项目中常见的问题是两张表互相反查或者状态互相覆盖这通常就是没理清“业务订单是目的支付单是过程”这个关系。2.2 金额、状态机与幂等设计金额处理必须统一原则所有与渠道交互的金额一律用“分”为单位、用整数存储。不管是微信的total_fee支付宝的total_amount还是云闪付的txnAmt最终落库都换算成分。浮点数做支付金额是事故高发区任何语言里0.10.2都可能出现精度问题线上出过一次“多付一分钱”的客诉就是前端传了元、后端转分时用了float导致的。支付单状态机建议按下面这张表设计状态含义允许流转目标INIT已创建待拉起PROCESSING / CLOSEDPROCESSING用户渠道支付中SUCCESS / FAILED / CLOSEDSUCCESS支付成功已确认REFUNDING / REFUNDEDREFUNDING退款处理中REFUNDEDREFUNDED已全额退款终态FAILED支付失败CLOSEDCLOSED超时关闭或主动取消终态状态流转必须由服务端驱动客户端传参不能直接改状态。回调更新时要加条件更新语句比如UPDATE payment SET statusSUCCESS WHERE id? AND status IN (INIT,PROCESSING)防止迟到的重复回调把已经终态的数据覆盖掉。幂等设计主要落在两点一是渠道回调处理接口要天然幂等同一个渠道单号重复回调只生效一次二是退款、关单这类操作要有幂等键渠道侧和自身服务端都做去重。表结构上建议给支付单加上(pay_channel, channel_trade_no)的唯一索引回调先尝试落一条回调流水记录冲突就说明处理过了。3. 微信支付集成实录统一下单与二次签名3.1 第一次签名服务端调起统一下单微信支付的APP支付核心是两步签名。第一步是服务端拿着商户参数调统一下单接口获取prepay_id。接口走的是XML协议地址是/pay/unifiedorder所有参数除了业务项之外还有一个sign。签名规则不复杂把非空参数按key字典序排列拼成key1value1key2value2最后拼接key你的API密钥用MD5计算后转大写。我写了一个可复用的Java签名片段核心思路是先过滤空值再排序拼接最后加密private String sign(MapString, String params, String apiKey) throws Exception { MapString, String sorted new TreeMap(); for (Map.EntryString, String entry : params.entrySet()) { if (entry.getValue() ! null !.equals(entry.getValue()) !sign.equals(entry.getKey()) !key.equals(entry.getKey())) { sorted.put(entry.getKey(), entry.getValue()); } } String content sorted.entrySet().stream() .map(e - e.getKey() e.getValue()) .collect(Collectors.joining()) key apiKey; return DigestUtils.md5Hex(content).toUpperCase(); }统一下单必须传的参数包括appid、mch_id、nonce_str、body、out_trade_no、total_fee、spbill_create_ip、notify_url、trade_type。APP支付时trade_type固定传“APP”。这里的out_trade_no用我方支付单号total_fee是分单位的整数notify_url必须是公网可访问的HTTPS地址回调域名要在商户平台提前报备。3.2 第二次签名客户端支付参数组装拿到prepay_id后不能直接把prepay_id丢给客户端。客户端拉起微信时需要六个参数appid、partnerid就是mch_id、prepayid、package固定值“SignWXPay”、noncestr、timestamp。把这六个参数再走一遍签名算法生成新的sign组装成JSON返回给客户端。注意这里的timestamp是秒不是毫秒。这一步是新手最容易踩的坑。我见过不少同学把第一次签名结果直接当客户端参数用客户端一直报“支付验证签名失败”。其实区分很简单第一次签名是服务端和微信服务器之间的认证第二次签名是客户端和微信SDK之间的认证参数集合不同、签名内容不同必须分开计算。调试时把两次签名的参数字符串分别打日志一眼就能看出问题。3.3 客户端接收支付结果的正确姿势Android端需要注册WXPayEntryActivity在onResp回调里拿errCode0代表成功-1代表错误-2代表用户取消。iOS端通过SDK回调block拿结果。这里有个关键认知onResp的结果不等于最终支付结果必须以服务端收到的微信异步通知为准。客户端回调只能用来刷新界面不能据此把订单置为已支付。微信异步通知是POST到notify_url内容为XML。服务端处理顺序先验签再检查return_code和result_code是否都为SUCCESS然后核对out_trade_no和total_fee是否与本地支付单一致最后更新状态并向微信返回纯文本“SUCCESS”。如果返回其他内容或超过时间不返回微信会按策略自动重试通知。回调接口要做轻验签和状态更新之外的事情尽量丢到消息队列异步处理。4. 支付宝接入密钥体系与orderString组装4.1 RSA2密钥对的生成与公钥上传支付宝接入的核心是RSA2签名。在开放平台创建应用后用官方工具或openssl生成应用公钥和应用私钥把应用公钥上传到支付宝开放平台平台校验后返回支付宝公钥。回调验签用支付宝公钥生成请求参数用应用私钥。私钥务必只放在服务端客户端只拿orderString不要接触任何密钥。用openssl生成密钥对的命令很简单openssl genrsa -out app_private_key.pem 2048 openssl rsa -in app_private_key.pem -pubout -out app_public_key.pem生成后复制公钥内容到开放平台的“应用公钥”配置栏平台会返回对应的支付宝公钥字符串存到服务端配置中心。这里最常见的坑是公钥和私钥填反表现是下单时老报“验签失败”因为支付宝用上传的公钥验签时发现签名不匹配。可以先在开放平台的“沙箱环境”里用相同的密钥跑通再切正式。4.2 服务端生成orderString的参数拼接支付宝的APP支付接口是alipay.trade.app.pay服务端需要组装一个字符串orderString返回给客户端。结构分两部分公共参数包括app_id、method、charset、sign_type、timestamp、version、notify_url业务参数放在biz_content里是JSON格式包含out_trade_no、total_amount、subject等。total_amount单位是元按字符串传两位小数比如“10.00”。签名逻辑是把所有非空参数按key排序拼接成keyvaluekeyvalue形式用应用私钥做SHA256withRSA签名Base64编码后作为sign参数追加到orderString末尾。客户端拿orderString直接调用SDK拉起收银台// Android 示例 PayTask alipay new PayTask(activity); MapString, String result alipay.payV2(orderString, true); // result.get(resultStatus) 为 9000 表示支付成功注意9000表示支付成功但这只是客户端的即时返回和微信一样最终结果以服务端异步通知为准。resultStatus -1表示失败6001表示用户中途取消。4.3 异步通知验签与“success”应答支付宝异步通知是POST表单处理时取出所有参数去掉sign和sign_type按key排序拼接后用支付宝公钥验RSA2签名。验签通过后还要校验app_id、out_trade_no、total_amount、seller_id等字段和本地支付单一致。处理完成必须原样输出文本“success”全小写支付宝才会停止通知如果输出其他字符串或不输出支付宝会按递增间隔重发13次。微信回调应答是大写“SUCCESS”支付宝是小写“success”这个细节很容易记混。我之前接一个新支付渠道时习惯性把微信那套直接搬过来结果支付宝一直重发通知日志里全是重复回调一查才发现是应答字符串大小写写错了。建议在统一回调处理层里把各渠道的应答规范封装成独立常量。5. 云闪付与众不同的接入路径5.1 TN号模式与控件SDK的工作机制云闪付的APP支付走的是银联“控件支付”模式核心是TN号。服务端调用银联的“交易流水创建”接口传报备商户号、终端号、订单号和金额银联返回一个TN号服务端把TN号返回给客户端。客户端用银联控件SDK传入TN号和模式号发起支付银联控件会接管整个收银台界面用户输入密码、确认付款都在控件里完成。模式号有讲究测试环境传“00”生产环境传“01”。联调时如果传错模式要么验签失败要么收银台直接打不开。客户端支付完成后银联控件会把结果回调给客户端但服务端同样必须等银联的异步通知。云闪付的通知是银联私有报文格式加上证书签名验签方式跟前两家完全不同需要引入银联SDK里的验签工具类来完成不建议自己造轮子。5.2 报备环境与联调注意事项云闪付的联调难在环境而非代码。银联有专门的测试服务器、测试商户号和测试终端号报备通过后会在开发者社区开放测试权限。联调时订单金额通常有约定的测试规则某些特定金额用于模拟成功、失败、超时等场景具体以当期测试说明为准。生产环境必须替换为正式商户号和终端号并且模式号改成“01”。另外云闪付对回调地址的HTTPS证书要求比较严格回调域名变更后要记得在商户平台重新配置否则生产环境会突然收不到通知排查时很容易绕远路。经验是上线前专门做一次“回调域名切换演练”改完配置后主动发起一笔小额支付验证。6. 支付回调的硬核防线验签、对账与兜底6.1 验签与关键字段校验三个渠道的回调第一步永远是验签。但验签通过只说明“这个消息确实是渠道发来的”不代表可以更新订单状态。接下来必须校验四个条件我方支付单号存在、回调金额与本地支付单金额一致、渠道单号与本地记录一致如果有、回调通知的支付结果状态与预期一致。这几个条件缺一不可。真实场景里出过的事回调报文被拦截后重放或者回调金额与下单金额不一致。如果只验签不比对金额就可能把错误金额的订单置为已支付。所以我的处理顺序永远是验签 - 查支付单 - 比对金额 - 条件更新状态 - 落回调流水。顺序不能乱日志也要把每一步打清楚。6.2 状态机保护与重复回调处理渠道侧为了保证通知到达会重复发送。微信支付会重试较长时间支付宝重发13次所以回调接口必须幂等。我的做法是在支付单上建唯一索引(pay_channel, channel_trade_no)回调到来先尝试插入回调流水记录如果冲突说明已经处理过直接应答成功。然后状态流转用条件更新只有INIT和PROCESSING状态才能更新为SUCCESS已终态的订单不会被重报覆盖。还有一个细节回调处理接口和普通业务接口不一样它没有用户会话超时容忍度更低。如果处理逻辑过重渠道侧会因为等待超时而重发加重服务压力。回调接口只做验签、查单、更新状态、落流水后续的发货、短信、消息推送都交给异步任务。6.3 主动查单与日终对账不管回调做得多完善都必须加主动查单和日终对账。回调通知存在丢失、延迟的情况线上偶发“用户确实付了钱但APP没收到结果”的客诉这种问题只能靠查单兜底解决。我的兜底方案是支付单进入PROCESSING后超过设定分钟数未收到回调启动定时任务调渠道订单查询接口查到已支付就本地补单。这三个渠道的查单接口分别是微信/pay/orderquery、支付宝alipay.trade.query、银联的交易查询接口。每天凌晨再跑一次对账任务把当日支付单和渠道侧账单逐笔比对发现单边账立刻报警。查单补单和对账是支付闭环的最后一道防线宁可多做不可少做。7. 多渠道抽象用一份代码适配三家7.1 统一的支付渠道接口设计三家的流程虽然细节不同但骨架是通用的创建支付单、获取支付参数、处理回调、查单、退款。工程上可以把这些动作收敛成一组接口。业务层完全面向接口编程渠道实现内部各自处理差异。Java伪代码如下public interface PaymentChannel { // 创建支付返回客户端所需的支付参数 PayParams createPayment(PaymentOrder order); // 验签并解析回调请求 CallbackResult verifyCallback(String rawBody, MapString, String headers); // 查单 QueryResult queryOrder(String channelTradeNo, String outTradeNo); // 退款 RefundResult refund(RefundOrder refundOrder); }三个渠道分别实现这个接口服务层通过payChannel字段路由到对应实现类。后面如果新增分期、余额等支付方式业务代码基本不用动只加实现。7.2 单据模型与渠道路由配置支付单表建议至少包含以下字段id、business_order_id、pay_channelWX/ALI/UP、pay_sceneAPP/小程序/H5、out_trade_no我方单号、channel_trade_no渠道单号、total_fee分、status、notify_count、notify_time、extra_json。extra_json用来存渠道回传的细节字段排查问题时会非常有用。渠道参数不要硬编码在代码里建议放配置中心或数据库路由表每个环境一套。包括各渠道的appid、商户号、证书路径、回调地址、密钥或私钥。这样换环境、换商户号不用重新发版。我在一个项目里就吃过硬编码的亏测试环境切生产时漏改了证书路径线上支付全部报验签失败排查花了大半天。8. 上线前必须走一遍的问题清单8.1 测试环境覆盖的边界用例支付集成最怕“测试时全成功上线后全翻车”。建议至少把这些场景完整走一遍支付成功、支付取消、网络中断后恢复、0.01元边界金额、用户重复点击支付按钮、同一订单发起两次支付、支付后立即退款、退款后再次发起新支付、回调重复到达、回调参数被篡改、客户端杀进程后重新进入订单页。每个场景都要确认服务端的支付单状态是否符合预期日志是否完整。8.2 最容易在线上翻车的细节列几个我实际踩过的坑。第一个是服务器时钟不准。微信支付第二次签名里的timestamp必须与服务器时间一致服务器时钟偏差超过一定范围微信会直接拒绝。这个问题我连续遇到两次后才在监控里加了NTP同步检查。第二个是回调业务处理过重。notify_url如果同步扣库存、发短信、推送通知处理时间一长渠道侧就超时重发重发又触发新的重复逻辑系统压力飙升。回调接口只做验签和状态更新其他全部异步。第三个是证书和密钥更新。微信API证书、支付宝公钥都有有效期或更换场景证书更新后旧的缓存位置会导致验签失败。运维上要加证书有效期告警而且要确保新旧证书切换窗口内有灰度验证。8.3 日志、监控与告警支付模块必须在日志里记录足够多的上下文支付单号、渠道、金额、状态变化、回调原始报文、验签结果、耗时。线上排查支付问题时没有日志寸步难行。我自己习惯在状态变更的每个节点都打一行结构化日志字段固定方便日志平台检索。监控上至少盯三个指标回调成功率、回调延迟、单边账数量。任何一个指标异常都要第一时间告警。另外要保留手工补单能力对接运营后台或管理接口特殊情况下人工触发查单和纠正状态。附录里再给你一张三个渠道回调行为的对照表方便交接文档直接使用渠道回调格式验签方式成功应答重发策略微信支付XMLMD5/HMAC-SHA256SUCCESS大写多次重试周期较长支付宝POST表单RSA2支付宝公钥success小写递增间隔最多13次云闪付银联私报文证书验签按银联规范返回由银联后台控制支付模块做了这几年我最大的体会是稳定的支付系统靠的从来不是某个环节写得有多巧妙而是把“回调可靠处理”和“查单兜底”这条闭环走扎实。三个渠道的SDK和文档都在变但底层思路几乎不变。希望这篇文章能把链路讲清楚让你少走几个我走过的弯路。如果你们项目里遇到什么奇怪的支付问题欢迎随时来交流。
做了这么多年后端真正让我觉得“离钱最近”的代码就是支付模块。早些年APP内支付基本只考虑微信和支付宝后来云闪付因为银联的营销活动和不少银行的积分补贴也慢慢成了必选项。这篇文章我想把三个渠道从商户申请、服务端下单、客户端拉起、异步回调验签到多渠道统一抽象的完整链路梳理一遍。不管你是第一次接支付还是准备把存量支付逻辑重构一次应该都能从中找到可以直接落地的思路和代码片段。1. 三个渠道的选型逻辑与入驻准备工作1.1 用户场景决定接入优先级微信支付和支付宝是国民级流量入口电商、知识付费、生活服务类APP基本都会同时接。微信的强项是社交关系链带来的支付场景拼单、分享、群聊之后的交易转化明显偏高支付宝强在电商生态和花呗、余额宝这类金融能力客单价高的商品用支付宝的营销工具往往更多。云闪付则靠银联体系和各家银行APP的联动在银行积分兑换、满减活动中被高频使用而且云闪付的费率政策有时候比前两家灵活。如果你们的APP目标用户偏二线城市以下或者业务本身带金融属性云闪付一定不能省。这里有个很实际的取舍经验如果团队资源有限第一版先做微信支付宝云闪付放二期。因为云闪付的商户报备流程需要走线下商务材料周期不可控而技术上三家的抽象模式是基本一致的后期补渠道的成本并没有想象中高。反过来如果产品已经在做银行合作或政务类服务云闪付就应该和微信、支付宝同期上线否则会丢掉一批只习惯用云闪付的用户。1.2 商户号与开放平台的关键配置微信支付需要先注册开放平台账号并创建移动应用拿到AppID后去微信支付商户平台申请商户号。签约APP支付产品之后有几个配置项容易被忽略一是API密钥需要设置为32位随机字符串二是API证书按需下载备用三是APP支付的回调域名和支付目录配置错误会导致客户端拉起时直接报“支付验证签名失败”。曾经遇到一个环境代码完全没问题就是支付目录少配了一个路径前缀线上一直失败最后看商户平台配置才找到原因。支付宝走的是开放平台流程创建移动应用后签约“App支付”产品然后生成应用公钥、应用私钥并上传公钥。需要注意的是支付宝密钥体系分老RSA和新RSA2两套现在新应用一律用RSA2也就是SHA256withRSA生成和验签方式都不要混用。老项目如果还在用RSA建议尽早迁移。云闪付的入驻路径比较特殊需要找银联商务或有资质的机构渠道报备拿到商户号和终端号再到银联开发者社区创建应用并下载控件SDK。这块商务流程通常要预留一到两周时间技术服务联调反而快。如果你发现某一天赶上大促节点务必提前规划报备时间不然就会卡在“程序写完了但商户号还没下来”。2. 从下单到回调支付链路的完整时序2.1 业务订单与支付单据为什么要拆开我强烈建议把“业务订单”和“支付单”分成两个模型。业务订单描述用户买了什么商品、金额多少、处于什么状态支付单记录某笔订单发起的某一次支付行为关联渠道、渠道单号、支付金额、支付状态。为什么要拆因为一个业务订单可能因为超时关闭、用户重试、部分退款等原因发起多次支付每次都要重新落一条支付单。如果不拆把所有信息堆在业务订单表里后期对账和退款会变得非常痛苦。而且支付单据独立之后渠道回调直接更新支付单不影响业务订单的锁状态业务侧再根据支付单成功事件去推进订单状态职责清晰得多。实际项目中常见的问题是两张表互相反查或者状态互相覆盖这通常就是没理清“业务订单是目的支付单是过程”这个关系。2.2 金额、状态机与幂等设计金额处理必须统一原则所有与渠道交互的金额一律用“分”为单位、用整数存储。不管是微信的total_fee支付宝的total_amount还是云闪付的txnAmt最终落库都换算成分。浮点数做支付金额是事故高发区任何语言里0.10.2都可能出现精度问题线上出过一次“多付一分钱”的客诉就是前端传了元、后端转分时用了float导致的。支付单状态机建议按下面这张表设计状态含义允许流转目标INIT已创建待拉起PROCESSING / CLOSEDPROCESSING用户渠道支付中SUCCESS / FAILED / CLOSEDSUCCESS支付成功已确认REFUNDING / REFUNDEDREFUNDING退款处理中REFUNDEDREFUNDED已全额退款终态FAILED支付失败CLOSEDCLOSED超时关闭或主动取消终态状态流转必须由服务端驱动客户端传参不能直接改状态。回调更新时要加条件更新语句比如UPDATE payment SET statusSUCCESS WHERE id? AND status IN (INIT,PROCESSING)防止迟到的重复回调把已经终态的数据覆盖掉。幂等设计主要落在两点一是渠道回调处理接口要天然幂等同一个渠道单号重复回调只生效一次二是退款、关单这类操作要有幂等键渠道侧和自身服务端都做去重。表结构上建议给支付单加上(pay_channel, channel_trade_no)的唯一索引回调先尝试落一条回调流水记录冲突就说明处理过了。3. 微信支付集成实录统一下单与二次签名3.1 第一次签名服务端调起统一下单微信支付的APP支付核心是两步签名。第一步是服务端拿着商户参数调统一下单接口获取prepay_id。接口走的是XML协议地址是/pay/unifiedorder所有参数除了业务项之外还有一个sign。签名规则不复杂把非空参数按key字典序排列拼成key1value1key2value2最后拼接key你的API密钥用MD5计算后转大写。我写了一个可复用的Java签名片段核心思路是先过滤空值再排序拼接最后加密private String sign(MapString, String params, String apiKey) throws Exception { MapString, String sorted new TreeMap(); for (Map.EntryString, String entry : params.entrySet()) { if (entry.getValue() ! null !.equals(entry.getValue()) !sign.equals(entry.getKey()) !key.equals(entry.getKey())) { sorted.put(entry.getKey(), entry.getValue()); } } String content sorted.entrySet().stream() .map(e - e.getKey() e.getValue()) .collect(Collectors.joining()) key apiKey; return DigestUtils.md5Hex(content).toUpperCase(); }统一下单必须传的参数包括appid、mch_id、nonce_str、body、out_trade_no、total_fee、spbill_create_ip、notify_url、trade_type。APP支付时trade_type固定传“APP”。这里的out_trade_no用我方支付单号total_fee是分单位的整数notify_url必须是公网可访问的HTTPS地址回调域名要在商户平台提前报备。3.2 第二次签名客户端支付参数组装拿到prepay_id后不能直接把prepay_id丢给客户端。客户端拉起微信时需要六个参数appid、partnerid就是mch_id、prepayid、package固定值“SignWXPay”、noncestr、timestamp。把这六个参数再走一遍签名算法生成新的sign组装成JSON返回给客户端。注意这里的timestamp是秒不是毫秒。这一步是新手最容易踩的坑。我见过不少同学把第一次签名结果直接当客户端参数用客户端一直报“支付验证签名失败”。其实区分很简单第一次签名是服务端和微信服务器之间的认证第二次签名是客户端和微信SDK之间的认证参数集合不同、签名内容不同必须分开计算。调试时把两次签名的参数字符串分别打日志一眼就能看出问题。3.3 客户端接收支付结果的正确姿势Android端需要注册WXPayEntryActivity在onResp回调里拿errCode0代表成功-1代表错误-2代表用户取消。iOS端通过SDK回调block拿结果。这里有个关键认知onResp的结果不等于最终支付结果必须以服务端收到的微信异步通知为准。客户端回调只能用来刷新界面不能据此把订单置为已支付。微信异步通知是POST到notify_url内容为XML。服务端处理顺序先验签再检查return_code和result_code是否都为SUCCESS然后核对out_trade_no和total_fee是否与本地支付单一致最后更新状态并向微信返回纯文本“SUCCESS”。如果返回其他内容或超过时间不返回微信会按策略自动重试通知。回调接口要做轻验签和状态更新之外的事情尽量丢到消息队列异步处理。4. 支付宝接入密钥体系与orderString组装4.1 RSA2密钥对的生成与公钥上传支付宝接入的核心是RSA2签名。在开放平台创建应用后用官方工具或openssl生成应用公钥和应用私钥把应用公钥上传到支付宝开放平台平台校验后返回支付宝公钥。回调验签用支付宝公钥生成请求参数用应用私钥。私钥务必只放在服务端客户端只拿orderString不要接触任何密钥。用openssl生成密钥对的命令很简单openssl genrsa -out app_private_key.pem 2048 openssl rsa -in app_private_key.pem -pubout -out app_public_key.pem生成后复制公钥内容到开放平台的“应用公钥”配置栏平台会返回对应的支付宝公钥字符串存到服务端配置中心。这里最常见的坑是公钥和私钥填反表现是下单时老报“验签失败”因为支付宝用上传的公钥验签时发现签名不匹配。可以先在开放平台的“沙箱环境”里用相同的密钥跑通再切正式。4.2 服务端生成orderString的参数拼接支付宝的APP支付接口是alipay.trade.app.pay服务端需要组装一个字符串orderString返回给客户端。结构分两部分公共参数包括app_id、method、charset、sign_type、timestamp、version、notify_url业务参数放在biz_content里是JSON格式包含out_trade_no、total_amount、subject等。total_amount单位是元按字符串传两位小数比如“10.00”。签名逻辑是把所有非空参数按key排序拼接成keyvaluekeyvalue形式用应用私钥做SHA256withRSA签名Base64编码后作为sign参数追加到orderString末尾。客户端拿orderString直接调用SDK拉起收银台// Android 示例 PayTask alipay new PayTask(activity); MapString, String result alipay.payV2(orderString, true); // result.get(resultStatus) 为 9000 表示支付成功注意9000表示支付成功但这只是客户端的即时返回和微信一样最终结果以服务端异步通知为准。resultStatus -1表示失败6001表示用户中途取消。4.3 异步通知验签与“success”应答支付宝异步通知是POST表单处理时取出所有参数去掉sign和sign_type按key排序拼接后用支付宝公钥验RSA2签名。验签通过后还要校验app_id、out_trade_no、total_amount、seller_id等字段和本地支付单一致。处理完成必须原样输出文本“success”全小写支付宝才会停止通知如果输出其他字符串或不输出支付宝会按递增间隔重发13次。微信回调应答是大写“SUCCESS”支付宝是小写“success”这个细节很容易记混。我之前接一个新支付渠道时习惯性把微信那套直接搬过来结果支付宝一直重发通知日志里全是重复回调一查才发现是应答字符串大小写写错了。建议在统一回调处理层里把各渠道的应答规范封装成独立常量。5. 云闪付与众不同的接入路径5.1 TN号模式与控件SDK的工作机制云闪付的APP支付走的是银联“控件支付”模式核心是TN号。服务端调用银联的“交易流水创建”接口传报备商户号、终端号、订单号和金额银联返回一个TN号服务端把TN号返回给客户端。客户端用银联控件SDK传入TN号和模式号发起支付银联控件会接管整个收银台界面用户输入密码、确认付款都在控件里完成。模式号有讲究测试环境传“00”生产环境传“01”。联调时如果传错模式要么验签失败要么收银台直接打不开。客户端支付完成后银联控件会把结果回调给客户端但服务端同样必须等银联的异步通知。云闪付的通知是银联私有报文格式加上证书签名验签方式跟前两家完全不同需要引入银联SDK里的验签工具类来完成不建议自己造轮子。5.2 报备环境与联调注意事项云闪付的联调难在环境而非代码。银联有专门的测试服务器、测试商户号和测试终端号报备通过后会在开发者社区开放测试权限。联调时订单金额通常有约定的测试规则某些特定金额用于模拟成功、失败、超时等场景具体以当期测试说明为准。生产环境必须替换为正式商户号和终端号并且模式号改成“01”。另外云闪付对回调地址的HTTPS证书要求比较严格回调域名变更后要记得在商户平台重新配置否则生产环境会突然收不到通知排查时很容易绕远路。经验是上线前专门做一次“回调域名切换演练”改完配置后主动发起一笔小额支付验证。6. 支付回调的硬核防线验签、对账与兜底6.1 验签与关键字段校验三个渠道的回调第一步永远是验签。但验签通过只说明“这个消息确实是渠道发来的”不代表可以更新订单状态。接下来必须校验四个条件我方支付单号存在、回调金额与本地支付单金额一致、渠道单号与本地记录一致如果有、回调通知的支付结果状态与预期一致。这几个条件缺一不可。真实场景里出过的事回调报文被拦截后重放或者回调金额与下单金额不一致。如果只验签不比对金额就可能把错误金额的订单置为已支付。所以我的处理顺序永远是验签 - 查支付单 - 比对金额 - 条件更新状态 - 落回调流水。顺序不能乱日志也要把每一步打清楚。6.2 状态机保护与重复回调处理渠道侧为了保证通知到达会重复发送。微信支付会重试较长时间支付宝重发13次所以回调接口必须幂等。我的做法是在支付单上建唯一索引(pay_channel, channel_trade_no)回调到来先尝试插入回调流水记录如果冲突说明已经处理过直接应答成功。然后状态流转用条件更新只有INIT和PROCESSING状态才能更新为SUCCESS已终态的订单不会被重报覆盖。还有一个细节回调处理接口和普通业务接口不一样它没有用户会话超时容忍度更低。如果处理逻辑过重渠道侧会因为等待超时而重发加重服务压力。回调接口只做验签、查单、更新状态、落流水后续的发货、短信、消息推送都交给异步任务。6.3 主动查单与日终对账不管回调做得多完善都必须加主动查单和日终对账。回调通知存在丢失、延迟的情况线上偶发“用户确实付了钱但APP没收到结果”的客诉这种问题只能靠查单兜底解决。我的兜底方案是支付单进入PROCESSING后超过设定分钟数未收到回调启动定时任务调渠道订单查询接口查到已支付就本地补单。这三个渠道的查单接口分别是微信/pay/orderquery、支付宝alipay.trade.query、银联的交易查询接口。每天凌晨再跑一次对账任务把当日支付单和渠道侧账单逐笔比对发现单边账立刻报警。查单补单和对账是支付闭环的最后一道防线宁可多做不可少做。7. 多渠道抽象用一份代码适配三家7.1 统一的支付渠道接口设计三家的流程虽然细节不同但骨架是通用的创建支付单、获取支付参数、处理回调、查单、退款。工程上可以把这些动作收敛成一组接口。业务层完全面向接口编程渠道实现内部各自处理差异。Java伪代码如下public interface PaymentChannel { // 创建支付返回客户端所需的支付参数 PayParams createPayment(PaymentOrder order); // 验签并解析回调请求 CallbackResult verifyCallback(String rawBody, MapString, String headers); // 查单 QueryResult queryOrder(String channelTradeNo, String outTradeNo); // 退款 RefundResult refund(RefundOrder refundOrder); }三个渠道分别实现这个接口服务层通过payChannel字段路由到对应实现类。后面如果新增分期、余额等支付方式业务代码基本不用动只加实现。7.2 单据模型与渠道路由配置支付单表建议至少包含以下字段id、business_order_id、pay_channelWX/ALI/UP、pay_sceneAPP/小程序/H5、out_trade_no我方单号、channel_trade_no渠道单号、total_fee分、status、notify_count、notify_time、extra_json。extra_json用来存渠道回传的细节字段排查问题时会非常有用。渠道参数不要硬编码在代码里建议放配置中心或数据库路由表每个环境一套。包括各渠道的appid、商户号、证书路径、回调地址、密钥或私钥。这样换环境、换商户号不用重新发版。我在一个项目里就吃过硬编码的亏测试环境切生产时漏改了证书路径线上支付全部报验签失败排查花了大半天。8. 上线前必须走一遍的问题清单8.1 测试环境覆盖的边界用例支付集成最怕“测试时全成功上线后全翻车”。建议至少把这些场景完整走一遍支付成功、支付取消、网络中断后恢复、0.01元边界金额、用户重复点击支付按钮、同一订单发起两次支付、支付后立即退款、退款后再次发起新支付、回调重复到达、回调参数被篡改、客户端杀进程后重新进入订单页。每个场景都要确认服务端的支付单状态是否符合预期日志是否完整。8.2 最容易在线上翻车的细节列几个我实际踩过的坑。第一个是服务器时钟不准。微信支付第二次签名里的timestamp必须与服务器时间一致服务器时钟偏差超过一定范围微信会直接拒绝。这个问题我连续遇到两次后才在监控里加了NTP同步检查。第二个是回调业务处理过重。notify_url如果同步扣库存、发短信、推送通知处理时间一长渠道侧就超时重发重发又触发新的重复逻辑系统压力飙升。回调接口只做验签和状态更新其他全部异步。第三个是证书和密钥更新。微信API证书、支付宝公钥都有有效期或更换场景证书更新后旧的缓存位置会导致验签失败。运维上要加证书有效期告警而且要确保新旧证书切换窗口内有灰度验证。8.3 日志、监控与告警支付模块必须在日志里记录足够多的上下文支付单号、渠道、金额、状态变化、回调原始报文、验签结果、耗时。线上排查支付问题时没有日志寸步难行。我自己习惯在状态变更的每个节点都打一行结构化日志字段固定方便日志平台检索。监控上至少盯三个指标回调成功率、回调延迟、单边账数量。任何一个指标异常都要第一时间告警。另外要保留手工补单能力对接运营后台或管理接口特殊情况下人工触发查单和纠正状态。附录里再给你一张三个渠道回调行为的对照表方便交接文档直接使用渠道回调格式验签方式成功应答重发策略微信支付XMLMD5/HMAC-SHA256SUCCESS大写多次重试周期较长支付宝POST表单RSA2支付宝公钥success小写递增间隔最多13次云闪付银联私报文证书验签按银联规范返回由银联后台控制支付模块做了这几年我最大的体会是稳定的支付系统靠的从来不是某个环节写得有多巧妙而是把“回调可靠处理”和“查单兜底”这条闭环走扎实。三个渠道的SDK和文档都在变但底层思路几乎不变。希望这篇文章能把链路讲清楚让你少走几个我走过的弯路。如果你们项目里遇到什么奇怪的支付问题欢迎随时来交流。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
