Unity接入微信与支付宝SDK全流程指南

简介：Unity 项目中集成微信登录、微信分享、微信支付与支付宝支付的 SDK 整合资源包，面向需要快速接入第三方能力的 Unity 开发者，解决多平台 SDK 导入、配置与调用的重复劳动问题。压缩包共 7322 个文件，包含 3000 余个 C# 脚本、114 个动态链接库、13 个 AAR 与 12 个 JAR 等 Android 平台组件，以及 JSON/XML/MD/TXT 配置说明与 Unity 资源文件，整体约 464.91MB，目录结构能够覆盖从基础配置到接口调用的完整链路。资源中可见微信登录、分享、支付和支付宝支付的完整代码实现，包括 WDLoginManager、WDShareManager、WDPayManager、AlipaySDK 等关键类调用示例，以及回调结果处理、跨平台差异适配等实战经验。目前已有 2236 人学习下载，适合有一定 Unity 基础、希望直接参考现成方案完成 SDK 接入或排查集成问题的开发者，可直接基于代码改写或检查编译配置。 做Unity开发的，只要你的项目想在国内上架、想接微信登录或者做应用内支付，基本绕不开微信开放平台和支付宝开放平台这一整套东西。微信登录、微信分享、微信支付、支付宝SDK这四件套，表面看起来都是“照着文档调API”，但实际接起来每一步都有坑：AppID申请审核、包名签名校验、WXEntryActivity配置、code换token、支付签名、回调验签……任何一环出错，界面就卡在“授权失败”或者“支付结果未知”。

这篇文章把我从零接入这套SDK的完整过程写出来，涵盖环境准备、微信登录、微信分享、微信支付、支付宝接入，以及联调阶段高频踩坑的排查记录。不管你是刚被安排接SDK的新人，还是正在为某个回调问题熬夜的老手，应该都能在对应章节里找到有用的解决思路。

1. 接入前的环境准备与整体思路

1.1 先理清四个SDK的依赖关系

这件事如果没想清楚，后面会反复返工。微信登录、微信分享、微信支付，三个功能都在微信开放平台下管理，它们共用同一个AppID、同一个应用签名配置，也就是说你在微信开放平台创建一个“移动应用”，把这个应用的AppID填到Unity工程里，登录、分享、支付三类接口就都能用了。这是一个很关键的认知，很多新手会在微信开放平台里创建三个应用，分别配三个AppID，结果登录用A、支付用B，回调乱成一团。

支付宝则是完全独立的一套体系。它有自己的开放平台、自己的AppID、自己的SDK，和微信没有任何关联。所以整条集成的核心思路可以概括为：微信系共用一套AppID和SDK初始化，支付宝单独走一套流程。在Unity里建议把这两套SDK封装成独立的C#管理类，比如WXManager和AliPayManager，避免代码混在一起。

// 统一入口示例 public class SDKManager : MonoBehaviour { public static WXManager WX; public static AliPayManager Ali; void Awake() { WX = gameObject.AddComponent<WXManager>(); Ali = gameObject.AddComponent<AliPayManager>(); } }

这样后续做功能开关、渠道分包，都只需要在SDKManager层面控制，不用改业务代码。

1.2 平台账号与AppID申请

微信开放平台注册账号后，进入“移动应用—创建应用”，需要填应用名称、简介、图标、下载链接等资料，提交后审核时间一般1到3个工作日。审核通过后拿到AppID和AppSecret，AppSecret务必只保存在服务端，绝对不要写进Unity客户端里，这个后面讲登录和支付时会再次强调。

支付宝开放平台的流程类似，创建“移动应用”后拿到AppID，但支付宝不需要应用审核这种环节，创建完就能配置密钥、进入开发状态。支付宝需要提前准备好RSA2密钥对，可以在开放平台的“密钥管理”里生成，也可以自己用openssl生成后上传公钥。私钥保存好，用来在服务端给支付订单签名。

1.3 Android包名与签名配置

这是Unity接微信SDK最容易翻车的地方，没有之一。微信在Android端会校验“包名+签名MD5”，两者必须和微信开放平台配置完全一致，否则回调时直接报错，错误码通常是WXErrCodeAuthDeny或者干脆不回调。

具体操作有两步准备：

• 确定Unity打包用的包名，这个包名和开放平台填的包名必须完全一致。
• 获取发布签名的MD5值。微信提供了一个“签名生成工具”App，安装到手机上输入包名就能得到MD5；也可以用keytool命令对签名文件算MD5。如果同时维护debug和release两个签名，建议在开放平台把两个签名都加进去，否则开发时能登录、发布后登录失败的问题会非常隐蔽。

支付宝也有包名校验，但没有那么严格，正常配置即可。

1.4 Unity工程基础配置

拿到AppID之后，Unity工程要做几件事：

• 导入官方Unity SDK包。微信官方提供了UnitySDK，支付宝也有AliPay-Unity的接入包，也可以直接用Android原生AAR自己封装，但复杂度会高很多，建议优先用官方Unity包。
• 将AppID填入SDK初始化代码。微信的WXApi.RegisterApp(appId, universalLink)必须在启动时调用，而且只需要调一次。
• Android导出时，需要在AndroidManifest.xml中注册WXEntryActivity和WXPayEntryActivity，这两个Activity的包名有硬性要求：必须是“你的应用包名.wxapi.WXEntryActivity”和“你的应用包名.wxapi.WXPayEntryActivity”。很多接入失败的教程案例，问题就出在这个包名路径上，路径写错一个字母都无法回调。

在这个阶段我还习惯在Player Settings里的Scripting Define Symbols中加上自定义宏，比如SDK_WECHAT和SDK_ALIPAY，方便在代码里按平台裁剪逻辑，也方便以后接其他渠道时做条件编译。

2. 微信登录：从授权到换token的完整链路

2.1 客户端负责的事：发起授权、接收code

微信登录的移动应用流程，客户端做的事情其实非常少：构造一个SendAuth.Req请求，调用WXApi.SendReq拉起微信授权页面，然后等用户在微信里确认授权，最后在WXEntryActivity的OnResp回调里拿到一个code。

// 发起微信登录 public void Login() { if (!WXApi.IsWXAppInstalled()) { // 未安装微信，提示用户 return; } SendAuth.Req req = new SendAuth.Req { scope = "snsapi_userinfo", // 固定值 state = GenerateRandomState() // 建议随机，防止CSRF }; WXApi.SendReq(req); }

这个code是有时效性的，只能用一次，有效期大概五分钟。拿到之后，客户端要做的唯一一件事就是把code传给自己的服务器，由服务器去微信接口换取access_token和openid。这里有一个绝对不能做的事：把AppSecret放在客户端里，用客户端直接请求微信接口。因为AppSecret一旦被打进包里，用解包工具就能翻出来，任何人都能冒充你的应用做授权操作。

2.2 “两个code”的误解

网上时不时有人问“微信授权登录是需要两个code吗”，这个问题在移动应用场景下其实不存在。移动应用登录完整链路只有一次授权、一个code：客户端拿`code → 发给服务端 → 服务端请求微信接口换token → 返回登录态给客户端。服务端换token的请求大概是这样：

https://api.weixin.qq.com/sns/oauth2/access_token?appid=APPID&secret=SECRET&code=CODE&grant_type=authorization_code

那“两个code”的说法是从哪来的？常见情况是把小程序登录的code和移动应用登录的code混在一起了。小程序的wx.login也会返回一个code，服务端通过jscode2session接口换取openid和session_key，代码里确实只有一个code，不存在双code。另一个混淆来源是部分第三方聚合登录SDK，它们为了兼容多个平台，会让客户端先拿自己的“临时code”，再转成微信的code，这是聚合层自己定义的流程，不是微信标准流程。所以如果是自己直接接微信官方SDK，只处理一个code就行，不要被“双code”绕晕。

2.3 用户信息的获取与新规限制

服务端拿到access_token和openid后，可以通过用户信息接口获取昵称、头像、性别等资料。这个流程在微信调整用户信息授权策略之前是好用的，但近几年微信收紧了移动应用的用户信息获取能力，直接调用userinfo接口，返回的昵称可能是“微信用户”，头像可能是默认灰头像。这不是你代码写错了，而是微信平台策略变更，移动应用已经不再像以前那样能直接拿到真实昵称头像。

解决方案是在自己的产品里做一套资料补全流程：登录成功后，如果发现昵称为空或为“微信用户”，就弹出资料编辑页，让用户手动填昵称、选头像。虽然多了一步交互，但这是目前最稳妥的做法。类似的限制在小程序里也一样，很多开发者遇到“小程序获取登录后的微信用户失败:wx1cb4398e1413dce7”这类报错，本质上就是还在用旧的getUserInfo接口，这类接口在新规则下已经拿不到真实用户信息了，需要改为wx.getUserProfile或头像昵称填写能力。App端的处理思路相同，不要指望SDK自动帮你拿到用户资料。

2.4 扫码登录的边界场景

如果你的产品有PC端或网页端，还会遇到微信扫码登录。网页扫码登录和移动应用登录不是一回事：移动应用走的是SendAuth流程，网页扫码走的是开放平台的“网站应用”或“公众号网页授权”流程，生成一个带redirect_uri的二维码链接，用户扫码后在手机微信确认，浏览器回调带上code，再以这个code去换token。

Unity开发者如果只是做双端同步需求，建议在服务端统一处理扫码登录，客户端只需要接收服务端登录成功的结果即可，不要在Unity里再维护一套网页授权逻辑，否则会平白多出一堆回调页和状态同步问题。我之前就因为想在Unity里直接展示扫码页面，折腾了一周RedirectUri白名单，后来换成服务端生成二维码、客户端轮询登录状态，一下就清爽了。

3. 微信分享：图片、链接、小程序的实现与限制

3.1 分享类型怎么选

微信分享在Unity中通过WXMediaMessage来实现，按内容类型可以粗略分为三类：

• 网页链接分享：最常用，分享出去是一条带标题、描述、缩略图的卡片消息，点击后跳转到指定URL。适合分享活动页面、游戏排行榜、宣传页。
• 图片分享：纯图片消息，适合分享海报、战绩截图。
• 小程序分享：分享出来的卡片可以直接打开微信小程序，常用于App引导小程序、社交裂变场景。

// 网页链接分享示例 WXMediaMessage message = new WXMediaMessage(); message.title = "游戏邀你一起来闯关"; message.description = "我已经打到第12关了，快来挑战我"; message.thumbData = bytes; // 缩略图，必须小于32KB WXWebpageObject webpage = new WXWebpageObject { webpageUrl = "https://yourgame.example.com/share" }; message.mediaObject = webpage; SendMessageToWX.Req req = new SendMessageToWX.Req { message = message, scene = SendMessageToWX.Req.WXSceneSession // 分享给好友 }; WXApi.SendReq(req);

3.2 缩略图和图片大小的坑

分享的缩略图thumbData有严格限制，不能超过32KB，这个数值藏在文档角落，但非常致命。如果你直接把一张高清截图转成byte[]塞进去，微信会直接返回参数错误，连分享面板都不会弹出来。处理方式是在客户端先用Texture2D.Compress做一次压缩，把图片缩放到128x128左右再转JPG。

分享图片消息时还要注意，微信要求图片数据不超过10MB，并且不支持直接传本地文件路径，必须把图片读成二进制再传给SDK。在Unity里如果分享的图片是异步从服务器下载的，务必先等下载完成再发起分享，不要在DownloadHandlerTexture还没回调时就构造分享消息。

3.3 回调判断：用户取消和发送成功要分清

分享结果通过WXEntryActivity的OnResp回调返回，errCode为0代表用户点击了发送且微信接收成功，-2代表用户取消分享，-4代表发送失败。很多开发者习惯用resp == null作为成功判断，这是错误的，应该在分发回调时判断resp is SendMessageToWX.Resp，然后读取errCode。

还有一个细节：errCode == 0只能说明消息发出去了，微信好友是否真的点击了链接、图片是否加载出来，是没法感知的，也不需要感知，分享数据的统计都靠服务端链接里的埋点。

4. 微信支付：下单、签名、回调与到账校验

4.1 完整支付流程拆解

微信支付是所有支付里最容易让客户端开发者懵的模块，因为客户端只是整个支付链路里最末端的一环，真正的核心逻辑都在服务端。完整流程是：

1. 客户端向自己的服务端发起“预下单”请求，携带订单号、商品名、金额等信息。
2. 服务端调用微信支付的统一下单接口，传入appid、mch_id、body、out_trade_no、total_fee、notify_url等参数，签名后发送，微信返回一个prepay_id。
3. 服务端拿到prepay_id后，再生成客户端拉起支付所需的参数：partnerId、prepayId、package=Sign=WXPay、nonceStr、timeStamp、sign。这里的sign需要商户密钥重新签名。
4. 服务端把这些参数返回给Unity客户端，客户端构造PayReq调起微信支付。
5. 用户在微信里完成付款，微信服务器向notify_url发送异步通知，同时客户端WXPayEntryActivity也会收到一个支付结果回调。
6. 客户端和服务端各自更新订单状态。

这中间客户端要传的只有那一组服务端生成的支付参数，其他事情一概不用管。所以Unity端写支付，代码量其实很小：

public void Pay(string jsonParams) { PayReq req = new PayReq(); req.appId = wxAppId; req.partnerId = json.partnerId; req.prepayId = json.prepayId; req.packageValue = "Sign=WXPay"; req.nonceStr = json.nonceStr; req.timeStamp = json.timeStamp; req.sign = json.sign; WXApi.SendReq(req); }

4.2 APIv2和APIv3的选型与密钥问题

微信支付接口有APIv2和APIv3两个版本。v2用MD5或HMAC-SHA256做签名，商户平台密钥是一个32位字符串，接入门槛低、资料多，很多老项目都跑在v2上。v3全面升级为RSA签名，用证书和公钥做加密，安全等级更高，但接入成本也明显上升，服务端要做证书管理。

如果你是个人开发者或者公司内部系统，v2足够用；如果涉及资金安全合规，建议直接上v3。这里有一个高频问题：申请v2时设置的32位密钥忘记查看怎么办？微信支付商户平台里，v2密钥是“只可重置，不可查看”的，一旦忘了不能找回，只能重新设置。重置之后，所有依赖旧密钥的签名逻辑都会失效，服务端、客户端如果缓存了之前的密钥，必须同步更新，否则下单、支付回调全部会报签名错误。很多线上支付事故就是改密钥只改了一半导致的，强烈建议密钥重置后写一个“下游系统同步清单”，把所有接入方一个个更新到位再正式切流量。

4.3 客户端回调为0，不代表支付成功

这是支付接入里最重要的一条经验，我在第一次接入时差点因此出事。微信支付完成后，WXPayEntryActivity会收到一个onResp回调，很多人看到errCode == 0就直接给玩家发道具，这是极其危险的做法。客户端回调的0只能代表“微信客户端内支付流程走完了”，不代表“钱已经到商户账户”。

标准做法是：客户端收到回调后，把支付结果转发给自己的服务端，由服务端根据微信服务器发来的notify_url异步通知为准来处理发奖逻辑。服务端收到通知后要验签、校验订单金额和商户订单号是否一致，全部通过后更新订单状态。整个流程里，客户端回调仅作为UI提示用，真正决定发不发奖的，永远是服务端收到的那个异步通知。

4.4 服务商模式多商户的扩展

如果公司业务是平台型的，比如一个App里同时承载多个商家的商品交易，就会遇到“服务商模式”。微信支付服务商模式下，服务商替特约商户发起下单，客户端拉起支付时使用appid和mch_id的组合，同时可以传入sub_appid和sub_mch_id指定具体商户。这种情况下，Unity客户端的PayReq多了一个subAppId字段，其他参数构造逻辑和服务商普通模式没有本质区别，真正的复杂度都集中在服务端如何管理多个商户的证书和密钥上。

5. 支付宝SDK接入：与微信支付的对比实践

5.1 支付宝的接入思路有什么区别

支付宝App支付和微信支付的整体思路很像：服务端生成订单字符串，客户端拉起支付，异步通知确认结果。但有几个关键差异值得单独说。

首先，支付宝SDK不需要像微信那样在AndroidManifest里注册一个专门的Activity来做回调分发，SDK内部会自己处理。因此Unity接入支付宝，门槛比微信低不少。其次，支付宝的支付参数是一个字符串orderString，服务端把订单信息、签名都拼好后返回给客户端，客户端直接把这个字符串丢给SDK：

// Unity端调起支付宝 public void Pay(string orderString) { AliPay.DoPay(orderString); }

支付宝SDK会在支付完成后返回一个结果码，其中9000代表支付成功，8000代表支付结果确认中，6001代表用户中途取消，4000代表系统异常。这里和微信同理：9000不能作为最终发奖依据，必须等服务端收到支付宝的异步通知并验签通过后，才能更新订单状态。

5.2 验签逻辑的差异

微信v2的验签逻辑依赖商户密钥，而支付宝在客户端拉起支付时用的是RSA2签名，验签时需要把支付宝公钥放在服务端。客户端本身不需要关心验签细节，因为支付宝SDK在返回9000之前已经做过一次基础校验。真正要关心的验签节点是服务端接收支付宝异步通知时，要对通知参数做RSA2验签，确认消息确实来自支付宝，再核对total_amount和out_trade_no。

很多初接触支付宝的开发者会忽略一个细节：如果服务端验签不通过，支付宝会反复发送异步通知，直到商户返回“success”为止。如果服务端一直没处理，通知会不断重发，容易造成重复发奖。所以服务端必须做好幂等判断，同一笔订单处理成功之后，后续重复通知直接返回“success”不再重复处理。

5.3 沙箱环境的价值

支付宝开放平台提供了完整的沙箱环境，可以创建沙箱应用、沙箱账号，甚至能模拟支付成功和支付失败。这个对联调非常有价值，我强烈建议Unity开发者在支付联调阶段先切沙箱环境，把整个支付链路跑通，再切换到正式环境。微信支付没有真正意义的沙箱，只有一个“真实小额测试”的现实方案，所以可以先接支付宝把联调流程走熟，再接微信时踩坑就会少很多。注意切换环境时，除了服务端切换支付宝网关和密钥，客户端下单地址也需要同步切，不然会出现App连上了沙箱，但订单实际是正式单的诡异情况。

6. 联调排查与真机测试的实战记录

6.1 高频报错速查

把我在接入过程中和帮别人排查时遇到的高频问题整理成一张速查表，这些问题几乎覆盖了90%的接入失败原因：

6.2 微信开发者工具“一直登录中”的误区

网上经常有人把Unity接入SDK和微信开发者工具的问题混在一起。微信开发者工具登录一直转圈，通常是开发工具本身的缓存或本地服务问题，和你在Unity里写的代码没有任何关系。排查思路很简单：先看微信开发者工具能否单独登录，如果能，再排查Unity侧是否有调用占用了本地端口；如果工具本身都登录不了，关掉重开、清理缓存，比反复改代码有效得多。这个场景和Unity接入SDK的真正交集点只有一个：微信开发者工具里扫码登录的code和移动应用中获取的code是两个体系，不要拿着工具里的code去换移动应用的token。

6.3 真机测试的几条独家心得

第一，微信SDK的所有回调都依赖真实的微信App环境，Android上务必用真机调试，模拟器上微信的登录和支付流程会出现各种奇怪问题。我踩过一次模拟器上报-18000的坑，换真机后一切正常。

第二，微信开放平台配置签名后，微信客户端会有一定时间缓存，改了签名不生效时，清理微信App缓存或者重新安装微信，比去开放平台反复核对更快。

第三，Unity和Android原生层交互时，注意回调线程。微信的OnResp回调发生在Android主线程，但Unity的API很多需要在主线程调用。如果发现回调里操作Unity UI没反应，用UnityMainThreadDispatcher把逻辑切回主线程。

第四，如果是公司接手别人的Unity工程，拿到工程后第一件事就是用解包工具把APK解开，确认当前的包名和签名是否和开放平台一致。很多历史项目是前同事随便配的签名，等你上线后才发现支付调不起来，那代价就大了。

最后的一点个人建议

说了这么多，其实最想表达的一件事情是：接SDK这件事，耐心比技术重要。微信登录、微信分享、微信支付、支付宝SDK，每一块的文档都写得算清楚，但真正坑人的地方往往藏在配置细节里——包名多一个下划线、签名少一位MD5、回调Activity路径写错层级，任何一个都能让你折腾半天。

我在实际项目里的处理方式是：把所有第三方SDK的接入做成一份“配置手册”，把AppID、包名、签名MD5、商家号、服务端下单接口地址、回调地址全部写清楚，每换一个包名或签名就更新一次。这套手册后来帮我省了很多时间，也避免了好几次因为人员交接导致配置断层的问题。

如果你正在接这套SDK，建议先从支付宝开始练手，它的沙箱环境和异常提示比微信友好很多；把链路跑通了再上微信，遇到问题也更容易定位。祝接入顺利。

本文还有配套的精品资源，点击获取