微信支付

渠道集成的痛：微信和支付宝处处不一样 聚合支付系统要同时对接支付宝和微信支付。初看两边的官方文档，觉得差不多——都是「下单→拿凭证→前端拉起→回调通知」这个流程。真到写代码的时候才发现，每一步都不一样，甚至同是微信生态，App 和小程序之间还有差异。 这篇文章把两渠道在 SDK 选型、下单参数、签名机制、回调处理、退款流程、对账单格式六个环节的具体差异整理出来，顺便也记录微信 App 和小程序之间那几处让人想砸键盘的细节。 一、SDK 选型和核心对象 先看 SDK 本身的差异，这决定了后面所有代码怎么组织。 支付宝 微信支付 Maven artifact alipay-sdk-java:4.40.308.ALL wechatpay-java:0.2.17 核心对象 DefaultAlipayClient （就是 HTTP 客户端） RSAAutoCertificateConfig （配置 + 签名 + 证书管理） HTTP 层 自带老版 HttpClient 自带 OkHttp，可注入自定义实例 证书管理 无（公钥手动配） AutoCertificateService 自动下载平台证书 + 后台线程轮换 Service 封装 无，裸调 client.execute(request) AppService / JsapiService / RefundService 封装请求-响应对映 ⚠️ 新手提示：支付宝的 DefaultAlipayClient 就是个 HTTP 客户端，一行 new 就行。微信的 RSAAutoCertificateConfig 是重量级对象——创建时会初始化证书下载、后台轮询线程，要通过工厂 + Caffeine 缓存复用，别每次请求都 new。 两者最大的思维差异：支付宝把 SDK 当 HTTP 工具用，微信把 SDK 当基础设施用。 ...

支付后端从 0 到 1：流程、幂等和那位备胎 提起微信支付，不少后端新同学的第一反应是"这不就是调个 API 嘛"。真上手才发现，光一个异步回调就能把人折腾到怀疑人生：明明用户付了钱，订单状态却一直不更新；回调来了两次，积分发了双份；个人主体小程序连商户号都申请不下来，只能对着文档干瞪眼。 这篇文章把 wx.pay 的后端流程从头到尾拆开：登录拿 openid、统一下单换 prepay_id、二次签名、异步回调验签与解密，再到怎么用乐观锁把幂等做扎实。最后用一点篇幅聊聊"备胎信使"理论——搞明白客户端在支付里到底说了不算什么，很多困惑会迎刃而解。 📌 前置知识：会写 Spring Boot 接口，看得懂 SQL，理解基本的 HTTP 与 JSON。不需要任何支付经验，本文的代码保证从空项目能直接搭起来。 第 1 步 目标说明：这一篇到底讲什么 1.1 为什么写这篇文章 支付是少数几个"看起来简单、出错要命"的领域。某开发者的第一版支付代码只有一百多行，跑起来却发现三个大坑： 客户端调起支付后立刻回调了 success，后端却还没收到微信的异步通知，订单一直挂在"待支付"； 通知重试机制下同一个回调被处理了两次，用户积分翻倍； 本地调得好好的，上线后微信的回调根本进不来——因为内网地址微信访问不了。 这三件事分别对应流程、幂等、回调三个话题，也是本文的主线。提前把这些想明白，能省下大把试错时间。 1.2 小程序开发的"三驾马车" 一个完整的小程序业务，后端主要跟三样东西打交道： 能力 前端 API 后端职责 类比 身份识别 wx.login 用 code 换 openid，建立用户账号 进门刷脸 交易闭环 wx.requestPayment 统一下单、签名、回调处理 柜台结账 消息触达 wx.requestSubscribeMessage + 服务端发送 存 access_token，发订阅消息 售后电话 三者独立又协作：登录建立身份，支付产生交易，订阅消息把交易结果送达用户。 1.3 本文核心议题 围绕上面三驾马车，重点回答四个问题： wx.pay 的完整后端流程是什么？预支付、二次签名、异步回调各是干什么的。 如何保证支付幂等，防止重复扣款、重复加积分？ 客户端在支付中到底扮演什么角色？哪些事它说了不算？ 个人开发者没有商户资质，怎么照样把后端逻辑练熟？ 1.4 阅读本文的收获 读完你会得到一份可以直接抄的 Java 实现：登录接口、统一下单、二次签名、回调处理器，以及一套幂等的三层防御。还会得到一个重要认知：支付后端的核心逻辑与商户号无关，没资质也能先把逻辑写对，拿到商户号只是替换一个 API 地址的事。 ...