微信支付

WeChat Pay

让用户在微信里点一下就把钱付了;商家要做的,是收到通知后确认钱真的到账。

平台与商业出现时间 · 2013 年前后按行业类目对应的费率收取交易手续费,一般约在千分之几的量级,具体以商户平台公示为准。移动支付收款商户接入异步通知
看官方文档

01 它是干嘛的

微信支付是把支付能力开放给商户的一套服务。对用户来说,它是扫码或点一下就能完成付款;对商家和开发者来说,它是一组接口,用来发起收款、接收付款结果通知、查询订单与对账。它的价值在于把「收钱」这件本该复杂的金融流程,变成了几行接口调用。

02 为什么会有它

在收银台前,为什么「付钱」曾经是件麻烦事

在移动支付普及之前,顾客要么付现金、要么刷卡。现金要备零钱、要防假钞、要对账;刷卡需要一台专用终端,还要走银行通道、付手续费,小商户往往办不起也不愿办。线上收款就更麻烦,得单独对接银行的支付网关,技术门槛高得让很多小团队望而却步。

微信支付出现后,用户那一侧变得极其简单:打开微信、扫一下、确认,几秒钟完成。真正的复杂被转移到了商家与开发者这一侧——但这恰恰是好事,因为它意味着复杂度可以被标准化、被封装,商家不必重复造轮子。

绕不开的一点是:支付这件事「不能只看表面」。用户手机上显示付款成功,并不意味着商家真的收到了钱,中间还隔着银行与清算。因此微信支付在工程上有一条被反复强调的铁律——前端回调只能用来改善体验,真正判定「这笔钱到账了」必须以后台收到的异步通知为准。这条纪律,是所有支付系统稳定运行的地基。

03 它怎么工作

完整链路是:商户服务端统一下单 → 拿到支付参数 → 交给用户确认支付 → 微信异步通知商户服务端 → 商户查询与对账,其中最后两步才是判定交易成败的依据。

支付:扫码成功只是第一步,钱到账要经过三段① 申请授权② 日终对账③ T+1 到账收到通知再发货用户付款扫码 / 指纹确认令牌化卡号换成一串一次性令牌授权问发卡行:这笔钱能冻住吗清算把各家账算清楚结算钱真正打到商户账户异步通知给商户服务器回调结果商户发货以回调为准,不信前端工程铁律:不要只相信前端返回的「支付成功」,必须等服务端收到异步回调再发货。资金授权资金真实到账
这张图请重点分辨两条回传路径:前端那条只是「用户操作完成」的提示,后台那条异步通知才是「钱到账」的权威结论。看图的重点是它们方向相同、意义完全不同——把订单状态挂在后台通知上,是接入微信支付时最重要的一条纪律。

一笔支付从下单到对账走了哪几段路

  1. 1
    ① 商户服务端统一下单

    用户点击购买后,商户后台向微信支付发起「统一下单」请求,带上商品描述、金额、订单号与通知地址,这一步决定了这笔交易的参数。

  2. 2
    ② 拿到支付参数并交给前端

    微信返回一个预支付标识,商户服务端把它签名后交给前端,前端凭这组参数调起微信的支付界面。

  3. 3
    ③ 用户在微信里确认支付

    用户看到金额与收款方信息,输入密码或验证指纹完成付款,此时前端会收到一个「看起来成功了」的回调。

  4. 4
    ④ 微信异步通知商户服务端

    与此同时,微信会向商户下单时填写的通知地址推送一条结果,这才是判定「钱是否真的到账」的权威信息。

  5. 5
    ⑤ 商户处理订单并返回确认

    商户收到通知后先校验签名与金额,确认无误再更新自己的订单状态,最后给微信一个表示已成功接收的应答,否则微信会重复通知。

  6. 6
    ⑥ 主动查询与对账

    为了应对通知丢失或延迟,商户还要定期主动查询订单状态,并按日导出账单与自己的记录比对,把账目核对清楚。

04 谁在用它

电商与小程序商城

用户在商城下单后直接用微信付款,从浏览到支付不必跳出微信。

线下门店扫码收款

柜台贴一张收款码,顾客扫码即付,商户省掉刷卡终端与备零钱的麻烦。

会员充值与合作分成

储值、订阅、服务续费等,用支付接口完成收款并记录到账户体系。

自动续费与订阅扣款

视频会员、软件订阅等定期扣费场景,可申请相关能力实现自动扣款。

企业发放与报销

结合企业付款能力,用于发放佣金、报销与合作伙伴结算。

05 怎么用

需要一台有公网地址的服务器来接收异步通知,并按官方文档完成签名与证书配置,属于有一定门槛的技术接入。

  1. 01在微信支付商户平台注册并完成主体认证,获得商户号。
  2. 02申请 API 证书与相关密钥,妥善保管,服务端签名会用到。
  3. 03在服务端实现统一下单接口,为用户生成待支付的订单。
  4. 04把下单返回的支付参数交给前端,由前端调起微信支付界面。
  5. 05实现一个公网可访问的通知接口,接收并校验微信的异步通知,据此更新订单状态。
  6. 06建立定时对账任务,每天拉取账单与自己的订单记录逐笔比对,处理差异。
统一下单请求示例(JSAPI 下单)http
POST /v3/pay/transactions/jsapi HTTP/1.1
Host: api.mch.weixin.qq.com
Content-Type: application/json

{
  "appid": "wxYourAppId",
  "mchid": "1900000000",
  "description": "测试商品",
  "out_trade_no": "ORDER_20260101_0001",
  "notify_url": "https://your-domain.com/pay/notify",
  "amount": { "total": 100, "currency": "CNY" },
  "payer": { "openid": "USER_OPENID" }
}

避坑提示

  • !以异步通知为准,不要只信前端返回:前端回调可能被伪造,也可能因为用户中途退出而根本没有。订单状态的最终判定必须落在后台收到的通知上。
  • !通知接口要能重复接收同一条消息而不出错,因为微信在没收到你的确认应答时会重复推送,处理逻辑必须做成「处理过一次就不再重复入账」。
  • !收到通知时必须校验签名并核对金额是否与自己的订单一致,防止有人伪造通知骗取虚拟物品。
  • !把所有请求与通知的原始内容都完整记录下来,线上对账出问题时,这些日志是唯一能还原事实的依据。

06 关键概念

统一下单
商户向微信支付发起的一次收款请求,这一步会确定金额、订单号与通知地址等关键信息。
异步通知
支付结果确定后,微信主动推送给商户服务端的一条消息,是判定交易成功与否的权威依据。
对账
把微信提供的账单与商户自己的订单记录逐笔比对,找出多收、少收或状态不一致的订单。
签名
用密钥对请求或通知内容计算出的校验值,用来确认消息确实来自微信、且中途没有被篡改。

07 容易混淆的对比

支付宝同为国内主流的移动支付方式,用户覆盖与生态各有侧重,很多商户会同时接入以便用户自行选择。
第三方聚合支付一次接入即可同时支持多种支付方式,省去逐一对接的功夫,但会多一层中间环节与费率。
图软件图鉴

纯静态站点,无后端、无追踪。内容为中文原创撰写,用于帮助非技术读者理解主流软件产品。

关于本站

全部内容在构建时生成
产品名称与商标归各自公司所有

© 2026 软件图鉴Nuxt 4 · Vue 3 · Tailwind 4 · 纯静态