看到“支持v2”，先确认是哪一端

搜索易支付系统源码支持v2，往往是因为现有商户系统要接入支付，或正在替换旧版源码。此时，“v2”可能指易支付平台提供给下游商户的接口版本，也可能指源码对接上游微信支付APIv2。两者处在不同环节：前者关系到商户系统怎样提交订单、查询结果；后者关系到支付平台怎样向微信发起请求。页面上只有“支持v2”几个字，无法确认两项能力都具备。

准备选源码时，把自己要接通的那一端写清楚，再向提供方索取对应接口文档和代码位置。若需求是兼容已有商户程序，就核对下单、回调、查单的字段与签名规则；若需求是继续使用微信支付APIv2，则查看实际调用方式和配置项。演示页能打开收银台，只能证明页面可访问，不能代替订单链路验证。提供方若只展示后台截图，暂时无法确认接口兼容范围。

支付请求发出后提示签名失败

假设一家站点原本通过旧系统调用微信支付APIv2，换用标注“支持v2”的易支付源码后，商户端已经生成订单，后台却记录了上游签名错误。排查集中在这一次失败请求，不急着改收银台页面，也不把“支持v2”直接判为虚假描述。

配置页面可能同时出现易支付商户密钥和微信支付APIv2密钥。前者用于商户系统与易支付平台之间的请求校验；后者用于平台向微信发起相应请求。若把前者填进后者的位置，下游订单仍可能正常到达平台，上游调用却无法通过签名校验。处理时，对照源码中读取配置的位置和接口文档，确认参与签名的参数、所用密钥及请求发送到哪一端。排查记录保留错误码和必要的请求信息，密钥原文不要贴进工单或聊天记录。

如果配置核对后仍失败，就回到失败请求检查参数拼接和签名实现，而不是反复更换密钥。这个情境只是排查路径；没有错误码和请求记录时，不能仅凭“支付失败”认定是密钥问题。测试环境修正配置后，还要用一笔测试订单核对下单响应与异步通知，正式环境的配置暂不跟着改动。

测试能下单后，旧订单还要处理

易支付v2接口能创建新订单，不代表旧系统留下的订单都能在新源码中查询。升级前若已有未完成支付，应核对订单号生成规则，以及旧回调地址是否仍可用。直接停掉旧服务，可能让已经发出的支付请求找不到接收通知的入口；直接沿用旧回调地址，也可能由已不再运行的程序接收，导致新后台没有记录。

这部分取舍取决于旧订单的处理状态和源码实际提供的兼容方式。保留旧回调入口一段时间，或将通知转交给新系统，都要以能核对订单归属为前提。准备切换时，先整理一笔测试订单从发起支付到收到通知的记录，再确认尚未完成的旧订单由哪个入口继续接收通知。