简介面向PHP开发者和电商/移动应用团队这份微信支付源码包提供Jsapi支付、二维码支付、刷卡支付、订单查询、退款及退款查询等全套接口可直接对接微信商户平台覆盖网页内无跳转支付、扫码付款、被扫支付等典型业务场景。包内共29个文件核心逻辑由21个PHP脚本承载覆盖统一下单、订单查询、退款处理与异步通知回调另附2个pem证书用于API签名安全认证以及doc说明、readme和示例图片辅助配置与联调。已有573人学习下载。源码封装了微信官方SDK基础类库并拆分为NativePay、JsApiPay、MicroPay等独立模块开发者可对照预支付标识、二维码生成、刷卡支付回调等流程快速修改商户号、API密钥等配置。整体代码结构清晰适合需要快速上线或二次开发微信支付功能的中高级PHP开发者参考复用。1. 微信支付接入前的思路梳理1.1 这套源码到底解决了什么问题很多人一听到“微信支付源码”第一反应是“不就是调一下接口吗”但真正做过支付业务的人都知道从零开始对接微信支付最折磨人的不是接口文档看不懂而是大量“看似简单、实则繁琐”的周边工作证书怎么放、回调怎么验签、订单状态怎么维护、退款怎么处理、接口报错怎么排查。尤其当你用的是PHP又跑在宝塔面板这类环境下网上教程东一篇西一篇版本还新旧混杂光是踩坑就能耗掉两三天。这套源码的价值就是把这些事情一次性封装好。它覆盖了Jsapi支付也就是公众号内支付、二维码支付Native支付、刷卡支付付款码支付以及订单查询四个核心场景。也就是说你拿到手之后不需要再从零折腾签名算法、回调验签、参数组装这些底层逻辑而是直接在现有代码基础上做二次开发把精力放在自己的业务上。1.2 适用场景与选型逻辑在决定使用这套源码之前你需要想清楚自己的业务到底属于哪种支付场景因为微信支付的接口体系是按场景拆分的选错接口类型会直接导致支付流程走不通。Jsapi支付适用于公众号菜单、H5页面内发起支付用户在微信内打开页面完成付款。这是目前公众号电商、知识付费、会员充值最常见的支付方式。二维码支付Native适用于PC网站收银台、线下扫码枪、打印小票扫码等场景。用户用微信扫一扫在手机上完成支付。刷卡支付适用于线下收银系统用户出示微信付款码商家用扫码枪或收银软件主动扫码扣款。订单查询所有支付场景的兜底能力用来确认订单最终状态尤其是回调丢失时订单查询几乎是唯一的补救手段。源码把这四种场景集成在一起本质上是在告诉你一件事微信支付的底层逻辑是统一的只是不同场景下请求参数和交互方式有差异。理解了这一点你后续不管对接小程序支付还是App支付都能举一反三。2. 微信支付的核心流程与原理拆解2.1 支付链路里的三个角色微信支付之所以让很多新手头疼是因为它不像普通接口那样“客户端请求服务端返回结果”这么简单。一次完整的支付涉及三个角色用户、商户后台、微信支付平台。以Jsapi支付为例完整链路是这样的用户在公众号内打开商品页点击“购买”。商户后台收到下单请求生成内部订单号调用微信支付下单接口。微信支付平台返回一个prepay_id预支付交易会话标识以及调起支付所需的参数。商户后台把这些参数返回给前端页面前端通过微信JS-SDK的WeixinJSBridge.invoke或者wx.chooseWXPay拉起收银台。用户输入支付密码完成付款。微信支付平台异步通知商户后台回调告知支付结果。商户后台验签、校验金额、更新订单状态然后返回“处理成功”给微信平台。这里最容易忽略的一点是前端页面显示“支付成功”并不代表你的服务端已经收到通知。回调通知是异步的可能存在延迟甚至可能因为网络问题丢失。所以成熟的支付系统一定要在支付结果页主动调用一次“订单查询”接口用查询结果作为最终判断依据。2.2 签名与验签机制微信支付v2接口使用MD5或HMAC-SHA256签名v3接口使用SHA256-RSA2048签名。这套源码如果基于v2开发签名逻辑相对直观把所有请求参数按字典序排序拼接成keyvaluekeyvalue格式末尾加上商户密钥然后计算MD5并转大写。验签的方向相反收到微信回调时把微信POST过来的XML参数除sign字段外同样排序拼接用商户密钥计算签名对比微信传过来的sign是否一致。如果不一致说明数据可能被篡改必须拒绝处理。很多人在这一步踩坑最常见的错误是拼接格式问题。比如参数值有中文、有特殊字符URL编码处理不当会导致签名校验失败。源码里如果封装了签名工具类建议你先用微信官方提供的“签名校验工具”沙箱环境跑一遍确认工具类本身的正确性再接入业务。2.3 回调处理的正确姿势回调处理是整个支付流程里最考验工程经验的部分。微信支付平台回调同一个通知默认会重试多次直到商户返回xmlreturn_code![CDATA[SUCCESS]]/return_code/xml。如果你在回调里做了耗时的业务操作比如发送短信、生成订单快照超时了微信会认为处理失败继续重试最终导致订单状态重复更新。正确做法是在回调里只做“验签、金额比对、订单状态幂等判断”确认无误后立刻返回SUCCESS。真正的后续业务发货、开通会员等要么通过消息队列异步处理要么在返回SUCCESS之后再执行。源码里如果已经处理了幂等逻辑你只需要关心自己的业务拓展如果没有建议自行加一层订单状态判断防止重复回调造成数据错乱。3. 环境准备与源码部署实操3.1 本地与服务器环境要求这套源码对运行环境的要求其实不高但有几个硬性条件必须满足PHP版本建议7.2以上如果跑的是v3接口则要求PHP 7.1且开启openssl扩展因为v3用到了RSA加密。curl扩展微信支付所有接口调用都依赖curl务必确认php -m里能看到curl。file_get_contents / allow_url_fopen部分老代码会用它替代curl但强烈建议统一用curl超时控制更灵活。HTTPS证书生产环境回调地址必须是HTTPS不能用HTTP否则微信支付平台会拒绝回调。宝塔面板如果你用宝塔在“软件商店-PHP设置-安装扩展”里确认openssl、curl、fileinfo、mbstring等扩展已开启。3.2 获取微信支付商户平台的关键配置在把源码部署到服务器之前你需要先去微信支付商户平台准备好三样东西商户号mch_id在商户平台首页可以查到形如1900000109。API密钥APIv3密钥或v2密钥在“账户中心-API安全”中设置。v2密钥是32位字符串用于MD5或HMAC签名v3密钥用于证书加密解密。API证书v3接口必须v2接口如果用到退款、企业转账也必须。证书在“API安全-申请API证书”里下载通常包含apiclient_cert.pem、apiclient_key.pem和apiclient_cert.p12。注意API密钥和商户密钥千万不要泄露。配置到PHP代码里时建议用环境变量或独立配置文件管理不要硬编码在业务代码中、不要提交到Git仓库。3.3 宝塔环境下快速部署的详细步骤这里以宝塔面板为例走一遍完整部署流程创建站点在宝塔面板“网站-添加站点”里输入你的域名PHP版本选择7.2或更高创建成功后会生成站点根目录一般是/www/wwwroot/你的域名。上传源码把下载的源码压缩包上传到站点根目录解压。注意源码文件权限设为755runtime、log等可写目录设为755或777config目录建议设为755不允许外部访问。配置伪静态如果源码用了ThinkPHP、Laravel等框架需要在“伪静态”里选择对应的规则否则路由无法访问。ThinkPHP一般是location / { if (!-e $request_filename){ rewrite ^(.*)$ /index.php?s$1 last; } }。修改配置文件找到源码里的支付配置文件常见的是config.php或.env填入mch_id、api_key、app_id、app_secret。app_id和app_secret在微信公众平台“开发-基本配置”里获取注意公众号与服务号的权限差异——只有服务号才有微信支付权限。配置回调地址在微信商户平台“产品中心-开发配置”里设置支付授权目录和回调地址。Jsapi支付的回调地址必须和实际请求路径完全匹配通常是https://你的域名/index.php/api/notify这类格式。申请HTTPS证书宝塔面板直接申请Let‘s Encrypt免费证书或者在“SSL”里手动上传证书文件。绑定证书后记得开启“强制HTTPS”否则回调地址容易出问题。完成以上步骤后访问源码自带的测试入口如果能正常返回二维码支付链接或Jsapi调起参数说明配置成功。4. 四种支付功能的核心环节实现4.1 Jsapi支付的参数组装与前端调起Jsapi支付的请求核心是调用/v3/pay/transactions/jsapiv3或/pay/unifiedorderv2并传入openid。这里有一个前置步骤必须先通过OAuth授权获取用户的openid否则无法发起Jsapi支付。源码里一般会提供一个getOpenid方法流程是前端跳转到微信授权链接https://open.weixin.qq.com/connect/oauth2/authorize?appidAPPIDredirect_uri回调地址response_typecodescopesnsapi_basestateSTATE#wechat_redirect用户授权后微信会携带code跳回你的回调地址。后端用code换openid请求https://api.weixin.qq.com/sns/oauth2/access_token接口。拿到openid后组装统一下单参数。v2格式中核心字段包括appid、mch_id、out_trade_no商户订单号、total_fee金额单位是分、body商品描述、notify_url回调地址、trade_type此处为JSAPI、openid。服务端拿到下单返回的prepay_id后需要再生成一份“二次签名”参数返回给前端。这份参数包含appId、timeStamp、nonceStr、package值固定为prepay_idxxx、signType使用同样的签名算法加密后前端才能调起支付。前端代码大致如下function onBridgeReady(data) { WeixinJSBridge.invoke( getBrandWCPayRequest, { appId: data.appId, timeStamp: data.timeStamp, nonceStr: data.nonceStr, package: data.package, signType: data.signType, paySign: data.paySign }, function (res) { if (res.err_msg get_brand_wcpay_request:ok) { // 支付成功跳转到结果页并查询订单 } } ); }注意res.err_msg在iOS和安卓上有细微差异不能完全依赖它判断支付结果最终还是以后端订单查询为准。4.2 二维码支付的两种实现思路二维码支付Native在v2接口里是trade_typeNATIVE在v3里对应/v3/pay/transactions/native。服务端统一下单后微信会返回一个code_url也就是支付链接。拿到这个链接你可以有两种展示方式方式一生成二维码图片用PHP的qrcode库比如phpqrcode直接把code_url转成二维码图片显示在PC收银台页面。用户扫码后微信服务器会回调notify_url通知支付结果。include phpqrcode.php; $codeUrl $result[code_url]; QRcode::png($codeUrl, false, QR_ECLEVEL_L, 8);方式二前端二维码组件生成把code_url返回给前端前端用qrcode.js等库生成二维码这种方式交互更灵活适合异步刷新订单状态。二维码支付的难点在于“支付状态实时刷新”。用户扫完码如果直接关掉页面你根本不知道他有没有付款。所以常规做法是前端生成二维码后开启轮询接口每3-5秒查询一次订单状态一旦变为已支付立即跳转成功页。4.3 刷卡支付与订单查询的细节刷卡支付付款码支付在v2接口里是/pay/micropayv3对应/v3/pay/transactions/coinpay。它和Jsapi、Native最大的区别是不需要用户确认商家主动扣款所以对超时和异常处理要求更高。调用刷卡支付时用户出示付款码18位数字商家把auth_code付款码和订单金额传给微信微信会同步返回扣款结果。需要注意付款码的有效期很短通常1分钟左右过期后需要让用户重新刷新。如果返回SYSTEMERROR或USERPAYING不能直接判定失败需要轮询调用订单查询接口确认最终状态。刷卡支付没有回调通知唯一确认手段就是订单查询。订单查询接口本身非常关键。v3接口为GET /v3/pay/transactions/out-trade-no/{out_trade_no}v2为/pay/orderquery。查询到trade_state为SUCCESS才表示支付真正完成。源码里建议封装一个queryOrder方法统一供Jsapi、Native、刷卡支付调用这样不同场景的订单状态判断逻辑可以复用。5. 常见问题与排查技巧实录5.1 回调地址报错“商户平台配置不匹配”这是新手最常遇到的高频问题表现形式是微信回调时返回“支付失败”或“回调地址错误”。这类问题的根源几乎都在于微信商户平台里的“支付授权目录”和实际请求路径不一致。支付授权目录精确到目录级别不是域名根路径。比如你的回调地址是https://www.example.com/index.php/api/notify授权目录要填https://www.example.com/index.php/api/。如果前端页面路径是https://www.example.com/pay/那么授权目录要填https://www.example.com/pay/这两个目录必须分别配置。授权目录支持域名通配但不支持路径通配配置时要格外仔细。5.2 支付成功后订单状态不更新很多人在本地或测试环境跑通“支付成功”后发现数据库订单状态仍然停留在“未支付”原因主要有三个回调地址是HTTP。微信支付平台强制要求HTTPS你把notify_url配置成HTTP回调请求根本发不进来。回调验签失败代码提前退出。在回调里如果验签失败代码会记录日志并退出但没有返回“SUCCESS”微信会一直重试最终你可能收到几十条重复回调。数据库连接串配错或跨库。特别是用框架自带的ORM回调里的数据库配置和主业务库不一致更新自然不生效。排查技巧在回调入口加日志记录每次请求的时间、参数、验签结果、处理结果。生产环境不要直接var_dump而是用error_log或框架的日志通道便于追踪。5.3 证书与密钥相关的报错v3接口最常见的是“无可用的平台证书”或“证书序列号不正确”这类报错。通常是因为没有在商户平台下载平台证书或者商户证书和平台证书混用。商户证书代表你的身份用于请求签名文件名通常是apiclient_cert.pem和apiclient_key.pem。平台证书代表微信支付平台的身份用于验证微信回调签名和解密敏感信息需要在“API安全-平台证书下载”里获取。两个证书不要搞混更不要把商户私钥当成平台证书使用。源码里如果提供了证书自动更新功能建议开启否则平台证书过期后你还需要手动下载替换。5.4 金额单位不一致导致支付失败微信支付所有金额单位精确到分不是元。如果你把订单金额18.50直接传给微信接口会报“金额格式错误”或签名失败。正确做法是乘以100再传$totalFee (int) round($amount * 100);反过来在订单查询或退款回调里拿到微信返回的金额也要除以100再展示给用户。这个细节虽然简单却是我见过最多的低级错误。5.5 订单号重复导致的幂等冲突有些人在测试时喜欢反复点击“下单”按钮导致同一商户订单号out_trade_no被重复创建。微信支付平台对同一商户订单号不允许重复下单第二次请求会返回ORDERPAID或OUT_TRADE_NO_USED。解决办法是生成订单号时加入毫秒时间戳或随机数例如$orderNo date(YmdHis) . mt_rand(1000, 9999);同时在业务层面保证同一订单支付回调的幂等性判断订单状态如果已经是“已支付”直接返回SUCCESS不再重复处理。6. 源码二次开发与扩展建议6.1 订单状态维护的完整设计源码自带的订单查询功能解决了“能不能查”的问题但在真实业务里你还需要设计一套“怎么维护”的机制。我建议在数据库订单表里增加以下几个字段字段名类型说明order_statustinyint0待支付1已支付2已退款3已关闭transaction_idvarchar(64)微信支付平台交易号prepay_idvarchar(64)预支付会话标识用于前端调起支付notify_timedatetime回调通知处理时间refund_timedatetime退款时间refund_amountint退款金额单位分支付回调成功后更新transaction_id、order_status、notify_time。退款操作后把退款金额和退款时间写入防止用户重复申请退款。6.2 从v2平滑迁移到v3的思路现在微信支付官方主推v3接口v2接口虽然还能用但新功能已经不做了。如果你手里的源码基于v2建议尽早规划迁移。迁移的核心是签名算法和接口路径的变化v2用MD5/HMAC-SHA256加API密钥v3用SHA256-RSA2048加商户私钥。v2用XML格式v3用JSON格式。v2的回调验签是对XML解析后重新签名v3是对请求头部的Wechatpay-Timestamp、Wechatpay-Nonce、Wechatpay-Signature做验签。迁移时不要推翻重写而是抽象一个统一的“支付服务”层把下单、查询、回调、退款四个方法定义成接口分别实现v2和v3两个版本业务层调用接口即可。6.3 容灾与补偿机制的补充建议支付系统最怕的不是“支付失败”而是“支付结果不明”。用户明明扣款了你的系统却显示未支付这种体验非常伤。建议在源码基础上补两个机制主动查询兜底前端支付结果页加载时立即调一次订单查询接口如果查询结果是未支付再等3秒查一次最多查5次。定时对账任务写一个定时脚本每隔10分钟扫描订单表中“创建时间超过30分钟且订单状态为待支付”的订单调用订单查询接口更新状态。这样即使回调全部丢失也能通过主动查询找回支付结果。我在实际项目中就是靠这套对账任务处理过好几起用户反馈“扣了钱但订单没更新”的问题基本都是回调延迟或回调请求被防火墙拦截导致的。7. 我的实操心得与经验总结拿到这套微信支付源码之后我建议你先别急着改业务而是花半天时间把测试环境完整跑通。包括沙箱环境的签名验证、回调模拟、订单查询、退款流程全流程走通一遍你才能真正理解微信支付的每个环节。几个在实战中比较重要的体会日志一定要从第一天就写好。支付相关的日志记录要包含参数全文、验签结果、处理结果否则出问题时排查成本非常高。金额计算用整型分不浮点运算。PHP的浮点运算在金额比较上容易出精度问题订单查询里判断金额是否一致时直接用整型做等于判断最稳妥。证书文件不要放在web可访问目录。把apiclient_key.pem放到站点上一级目录或独立配置目录并设置目录禁止外部访问防止私钥泄露。宝塔环境特别注意PHP版本。有些老源码在PHP 8.0以上会报Fatal error或Deprecated警告建议先用PHP 7.4跑通再逐步升级。最后支付功能上线之前一定要做一次“用户视角”的完整测试从下单、支付、回调、订单查询到退款五个环节全部走一遍确认数据一致、流程闭环再开放给真实用户。这套源码给你打好了地基房子怎么盖、装修什么样最终还是要靠你自己。本文还有配套的精品资源点击获取