微信支付默认开启了自动提现，且在产品中心无法关闭，提示： 为保证该账户资金使用合理性，不支持关闭自动提现 需要修改为手动提现，请为如何操作，或谁能解决该问题 商户号：1701997235

服务商的小程序审核“加速机制”为不少服务商已经尝到了审核加速的“幸福”。但普通开发者要临时上线、遇到突发情况需要紧急调整的小程序，那该怎么办呢？我们为普通开发者打造了“高速直达通道”。 加急审核的“高速直达通道”，有以下几点需要注意： 1、加急次数限制： 为了合理分配审核资源，不同主体类型的小程序也配置了不同的加急机会： --非个人主体类型：每个自然年有3次 --个人主体类型：每个自然年有1次 提审勾选加急后，如在审核前撤回申请，机会将不会被消耗。 选择了加急审核，但审核单被驳回了。开发者可以在12小时内重新整改并在驳回站内信内的【前往反馈页面】重新提交审核，即可获得相应加急的队列。否则将会直接浪费了一次加急机会。 加急额度有限，开发者也要确保加速版本的小程序符合法律法规和平台规则，避免浪费有效加急机会。 2、审核时段及时长： 审核时段： 非个人主体类型审核时间：9:00-24:00 个人主体类型审核时间：9:00-21:00 （如遇重大节假日、“高速直达通道拥堵”、小程序代码的逻辑比较复杂等特殊情况，会相对延长审核时间。） “高速直达通道”上线后，审核时间从原来的1~7天内完成审核，缩短到最快2小时内完成。在申请加急审核时，开发者可以根据审核的工作时间和等待时长进行提单。开发者如需在当天完成加急审核，非个人主体的请在22:00前、个人主体的请在19:00前完成加急申请的提交。 3、申请指南： 符合条件开发者在审核页面中找到【加急】的选项，填写相对应的说明后即直达“高速直达通道”。 [图片] 4、未开放类型： 目前“高速直达通道”对以下情形的代码提审单暂不开放： [图片] 选择国内主体的以上类目或选择海外主体后首次提交代码审核，需报属地网信部门复核，预计审核时长在7天左右，建议开发者预留充足的审核时间。

背景 小程序模板消息能力将于2020年1月10日正式下线，并全量切换为订阅消息。详情点击查看 具体有两个变化需注意： 1月11日起，发布的新版本小程序仅支持订阅消息，模板消息不可用；1月11日起，没有发布新版本且没有将模板消息调整为订阅消息的小程序，在4月10日24时前仍可使用模板消息。但接口调用额度会调整：未开通支付能力的小程序调至5万/日，已开通支付能力的小程序调至50万/日。为更好帮助合作伙伴完成切换，下文将针对订阅消息的机制、规范及操作流程进行说明及建议，仅供参考。合作伙伴可根据自身小程序业务需求，在遵循《小程序订阅消息接口运营规范》的前提下，灵活调整。 本文主要以行业合作伙伴视角阐述订阅消息的接入指引，也提供了第三方服务商批量接入订阅消息的文档，请根据需要灵活阅读。 01  订阅消息整体介绍 订阅消息是需要用户主动订阅，开发者才可以面向用户发送的消息，其路径示意如下： [图片] 关键要素如下： 订阅消息推送位置：服务通知订阅消息下发条件：用户自主订阅订阅消息卡片跳转能力：点击查看详情可跳转至该小程序的页面另外，订阅消息可分为一次性订阅消息及长期性订阅消息，且两者均无时间限制。 一次性订阅消息，即用户订阅一次后，可下发一条消息，能满足小程序的大部分服务场景需求，如在备餐完成后，发取餐消息。 长期性订阅消息，即用户订阅一次后，可长期下发多条消息。为了便于公共服务场景需求，如航班延误，需根据航班实时动态来多次发送消息提醒。 目前长期性订阅消息仅向政务民生、医疗、交通、金融、教育等线下公共服务开放，后期将逐步支持到其他线下公共服务业务。 02  订阅消息的接入流程 接入订阅消息的步骤，可简述为： 1）进入小程序后台，根据小程序类目选择/申请订阅消息模板，获取模板ID； 2）将订阅消息的触发埋入用户交互流程中，用户点击触发（或在支付完成时自动触发）； 3）调用接口，下发订阅消息发送申请弹窗。 以下将逐点介绍： 1）进入小程序后台，根据小程序类目选择/申请订阅消息模板，获取模板ID 登录小程序后台，在左侧功能栏中，选择“订阅消息”，选择“添加” [图片] 你可直接在现有的公共模板库中，选择合适的模板，或者申请新模板（申请新模板须审核后才可使用）； [图片] 订阅消息的模板与小程序所属类目直接挂钩，建议商家根据小程序类目及小程序提供的实际服务申请对应模板（如提供点餐服务的小程序，可根据餐饮服务场所类目，申请取餐通知等），以便更快通过审核。 单个小程序每个月有5次申请新模板的机会，请珍惜剩余次数。 另外，如果删除小程序类目，该类目对应的订阅消息模板也将一并删除，请特别留意。 2）将订阅消息的触发设计到用户交互流程中，用户点击触发订阅申请弹窗 申请发送订阅消息，需要用户手动触发（以示意图为例，用户点击领券后才可触发“申请发送优惠券到期提醒”的订阅消息弹窗）。 如用户完成支付后，可自动触发，无须用户再次手动触发。 针对不同场景下的订阅消息发送需求，用户触发的场景也可以多样化，以餐饮行业为例（以下场景仅示例，商家可灵活配置）： [图片] 注：同一场景下，一次触发最多可发送3条模板订阅申请 开发指引内容较长，建议使用电脑详细查阅。点击打开文档 3）调用接口，下发订阅消息发送申请弹窗 调用接口subscribeMessage.send下发订阅消息发送申请。开发指引内容较长，建议使用电脑详细查阅。点击打开文档 用户勾选同意下发的模板，点击允许后，即可完成下发； [图片] 03  重点问题Q&A Q：如果每次用户使用同一个服务，都需要让他确认接收这个订阅消息，用户会不会很烦？以餐饮为例，商家接入自助点餐的小程序，每次用户下完单后都需要下发取餐提醒，在使用一次性订阅消息的情况下，如何引导用户，降低操作成本？ A：可以引导用户勾选“总是保持以上选择，不再询问”。为方便用户对同一条消息多次订阅，商家可引导用户勾选“总是保持以上选择，不再询问”的按钮，再点击“允许”按钮，后续用户在触发订阅消息时，将自动为用户勾选（即用户不需要再次选择模板并点击“允许”按钮），商家可直接下发相应订阅消息。 [图片] 建议：餐饮类商家可通过线下物料、店员话术等方式，引导自助点餐用户勾选，降低用户操作成本，提升点单效率。 注：此项功能设计仅为方便用户操作，根据《小程序订阅消息运营规范》，商家不允许以任何形式诱导，或强制用户点击“允许”或勾选“总是保持以上选择，不再询问”按钮（包括但不限于订阅有礼，或者强制用户点击允许或勾选后，才可进行下一步操作等），违规的商家小程序将根据违规程度采取删除订阅消息或短期、长期或永久封禁小程序的订阅消息接口能力处理。 Q：假设用户在订阅消息申请下发框中，不小心点了“取消”，如何引导用户重新订阅？ A：可引导用户点击小程序右上角“···”，进入设置页，点击消息订阅-点击接收订阅消息。 [图片] 注：在一次性订阅消息的场景，假设用户某次不小心点了取消，下次触发订阅消息申请时，商家可以再次推送订阅消息申请。 只有当用户在勾选了“总是保持以上选择，不再询问”的情况下，点击了“取消”按钮，才需要引导用户按照如上流程重新订阅，不然商家将无法再次推送订阅消息申请。 04  第三方服务商如何批量接入 为方便第三方服务商帮助旗下商家快速接入订阅消息，我们提供了第三方批量接入接口，开发指引内容较长，建议使用电脑详细查阅。点击打开文档

[图片]

微信支付做测试的时候 连续支付多个  0.01 元听说要被封号是真的吗？最低需要支付2元？

微信支付统一下单qps最大能达到多少？有没有具体的限制？或者通过什么方式能提高最大qps限制？

背景: 在开发一款小程序,目的是给多个商家提供支付能力,但小程序是属于服务商的,即与服务商同主体 1 我已经创建了微信服务商("开发者""非"外包收单机构") [图片] 2 完成了特约商户进件 [图片] 3 完成了特约商户绑定小程序的appid与服务商绑定小程序的appid [图片] [图片] 问题: 小程序中的微信支付里的商户管理里,依然没有该特约商户的信息,导致我没办法在微信开发者工具里配置商户号,也就没办法调通支付接口 [图片] [图片] 想问下是啥原因,文档已经查吐了,还是没找到为啥,是我漏了哪里的流程吗？？？比较急，感谢

[图片]

点击输入框弹出键盘、此时点击跳转、目标页面的fixed元素显示不出来。

什么内容或服务的小程序需要补充商家自营相关类目？ [图片] 1、百货：小程序主体公司综合零售商，在线售卖多种日用品，需补充商家自营-百货类目。预包装食品定义： 预包装食品，指预先定量包装或者制作在包装材料和容器中的食品；包括预先定量包装以及预先定量制作在包装材质和容器中并且在一定量限范围内具有统一的质量或体积标识的食品。 所需资质(3选1)： (1)《食品经营许可证》 (2) 仅销售预包装食品提供：《预包装食品销售备案凭证》 (3)口岸商店提供：《国境口岸卫生许可证》 案例：下图小程序涉及某综合零售商在线售卖拖把、零食等商品，需补充商家自营-百货类目。另外该小程序也涉及线售卖酒类商品，也需补充商家自营-酒/盐类目。 [图片] 2、食品：小程序涉及在线售卖鲜切蔬果加工预包装食品、饮料产品食类等食品，需补充商家自营-食品类目。预包装食品定义： 预包装食品，指预先定量包装或者制作在包装材料和容器中的食品；包括预先定量包装以及预先定量制作在包装材质和容器中并且在一定量限范围内具有统一的质量或体积标识的食品。 所需资质(4选1)： (1)《食品经营许可证》 (2)《食品生产许可证》 (3)仅销售预包装食品提供：《预包装食品销售备案凭证》 (4)口岸商店提供：《国境口岸卫生许可证》 案例：下图小程序涉及在线售卖糕条、鱼豆腐等预包装食品，需补充商家自营-食品类目。 [图片] 3、初级食用农产品：小程序在线售卖种植业、畜牧业、渔业未经过加工的初级农产品，需补充商品自营-初级食用农场品类目。 所需资质：《企业营业执照》 案例：下图小程序涉及售卖土鸡鸡蛋类农产品需补充商品自营-初级食用农场品类目。 [图片] 4、酒/盐：小程序涉及提供酒、盐在线销售配送服务，需补充商家自营/盐类目。预包装食品定义：预包装食品，指预先定量包装或者制作在包装材料和容器中的食品；包括预先定量包装以及预先定量制作在包装材质和容器中并且在一定量限范围内具有统一的质量或体积标识的食品。 所需资质(4选1)： (1)盐：《食品经营许可证》（含“预包装食品销售”） (2)酒：《食品生产许可证》（经营项目需包含酒类）/《食品经营许可证》（含“预包装食品销售”） (3)仅销售预包装食品提供：《预包装食品销售备案凭证》 (4)口岸商店提供：《国境口岸卫生许可证》 案例：下图小程序涉及在线售卖啤酒、红酒酒类商品，需补充商家自营/盐类目。 [图片] 5、保健品：小程序涉及提供保健品在线销售配送服务需补充商家自营-保健品类目。 所需资质（3选1） （1）《国产保健食品批准证书》 （2）《进口保健食品批准证书》 （3）《食品经营许可证》（经营项目须包含保健食品销售） 案例：下图小程序涉及在线维生素等保健类商品，需补充商家自营-保健品类目。 [图片] 6、成人用品：小程序涉及提供成人用品在线销售配送服务，需补充商家自营-成人用品类目。 所需资质：《营业执照》经营范围含“成人用品或避孕套或计生用品”等相关内容 案例：下图小程序涉及在线售卖安全套等成用品，需补充商家自营-成人用品类目。 [图片] 7、图书报刊/音像/影视/游戏/动漫：小程序涉及提供书籍报刊音像等在线销售配送服务，包括书店、影像店为主体提交的相关服务，需补充商家自营-图书报刊/音像/影视/游戏/动漫类目。 所需资质（2选1）： （1）批发：省级出版行政主管部门合法的《出版物经营许可证》 （2）零售：县（区）级出版行政主管部门合法的《出版物经营许可证》 案例：下图小程序涉及提供付费纸质书籍服务，并支持送书到家，需补充商家自营-图书报刊/音像/影视/游戏/动漫类目。 [图片] 8、成品油：小程序涉及提供汽油、煤油、柴油及其他符合国家产品质量标准、具有相同用途的乙醇汽油和生物柴油等成品线下销售服务，需补充商家自营-成品油类目。 所需资质（2选1）： （1）批发或仓储，提供《危险化学品经营许可证》，且许可范围明确包含“汽油 或 柴油”项目 （2）零售业务，提供《成品油零售经营批准证书》 案例：下图小程序涉及在线展示柴油价格相关信息服务，并引导至线下购买需补充商家自营-成品油类目。 [图片] 9、纪念币发售/兑换：小程序涉及国家纪念币在线销售配送服务需补充商家自营纪念币发售/兑换类目 所需资质：银行机构或银行机构的授权发售文件 案例：下图小程序涉及世界军运会纪念币在线售卖服务需补充商家自营纪念币发售/兑换类目 [图片] 10、电话卡销售：小程序涉及境内电话卡销售服务，需补充商家自营-电话卡销售类目。可以申请电商平台类目和IT科技-电信运营商类目代替。 所需资质：两个及以上的市级及以上运营商合作协议，并加盖公司公章或合同专用章；与省级及以上运营商授权认证的《网络销售与实名制授权书》；与运营商统一配发的授权防伪二维码标识（中国移动除外） 案例：下图小程序涉及在线销售靓号号码卡，需补充商家自营-电话卡销售类目。 [图片] 11、预付卡销售：小程序涉及在线售卖储值卡消费卡，或代售知名品牌储值卡/消费卡，需补充商家自营-预付卡销售类目。 所需资质： （1）、发行方（二选一）： ①《单用途预付卡》备案公示材料；②《支付业务许可证》含有“预付卡业务”。 （2）、预付卡代售（同时符合）： ① 发行方合规材料：《单用途预付卡》备案公示材料或《支付业务许可证》含有“预付卡业务”； ② 授权材料：经公证的授权代为销售的文件（协议、授权书等）。 案例：如下图小程序涉及在线代售超值加油卡服务，需补充商家自营-预付卡销售类目。 [图片] 12、汽车/其他交通工具的配件：小程序涉及在线销售汽车或其他交通工具配件需补充商家自营-汽车/其他交通工具的配件类目。 案例：下图小程序涉及在线展示汽车配件，及引导购买服务，需补充商家自营-汽车/其他交通工具的配件类目。 [图片] 13、服装/鞋/箱包：小程序涉及提供服装/鞋/箱包等商品在线销售配送服务，需补充商家自营-服装/鞋/箱包类目。 案例：下图小程序涉及在线售卖上衣短裤等服务室类商品，需补充商家自营-服装/鞋/箱包类目。 [图片] 14、海淘：小程序涉及在线销售海淘商品，需补充商家自营-海淘类目。若小程序涉及电商平台类、商家自营类（有资质要求的）销售内容的，也需补充相应资质类目。 案例：下图小程序涉及提供护肤品、手表配饰等海淘商品，需补充商家自营-海淘类目；该小程序也涉及在线售卖保健品相关商品，也需补充商家自营-保健品类目。 [图片] 15、玩具/母婴用品(不含食品)：小程序涉及儿童玩具/母婴用品销售在线销售配送服务，需补充商家自营-玩具/母婴用品(不含食品)类目。 案例：下图小程序涉及在线售卖宝宝柔软牙胶商品，需补充商家自营-玩具/母婴用品(不含食品)类目。 [图片] 16、家电/数码/手机：小程序涉及提供家电/数码/手机产品销售在线销售配送服务，需补充商家自营-家电/数码/手机类目。 案例：下图小程序涉及在线售卖空调、冰箱、洗衣机等家电商品，需补充商家自营-家电/数码/手机类目 [图片] 17、美妆/洗护：小程序涉及提供美妆/洗护用品在线销售配送服务，需补充商家自营-美妆/洗护类目。 案例：下图小程序涉及在线售卖面膜、洗面脸等护肤品，需补充商家自营-美妆/洗护类目。 [图片] 18、珠宝/饰品/眼镜/钟表：小程序涉及提供珠宝/饰品/眼镜/钟表产品在线销售配送服务，需补充商家自营-珠宝/饰品/眼镜/钟表类目。 案例：下图小程序涉及在线售卖太阳镜镜片等眼周边商品，需补充商家自营-珠宝/饰品/眼镜/钟表类目。 [图片] 19、运动/户外/乐器：小程序涉及提供运动/户外/乐器产品线上销售配送服务，需补充商家自营-运动/户外/乐器类目。 案例：下图小程序涉及在线销售吉他、尤克里里等乐器商品需补充商家自营-运动/户外/乐器类目。 [图片] 20、鲜花/园艺/工艺品：小程序涉及提供鲜花/园艺/工艺品线上销售配送服务，需补充商家自营-鲜花/园艺/工艺品类目。 案例：下图小程序涉及在线销售包装玫瑰花束，需补充商家自营-鲜花/园艺/工艺品类目。 [图片] 21、家居/家饰/家纺：小程序涉及提供家居/家饰/家纺用品线上销售配送服务，需补充商家自营-家居/家饰/家纺类目。 案例：下图小程序涉及在线销售床上四件套等家居商品，需补充商家自营-家居/家饰/家纺类目。 [图片] 22、汽车内饰/外饰：小程序涉及提供汽车内饰/外饰产品线上销售配送服务，需补充商家自营-汽车内饰/外饰类目。 案例：下图小程序涉及在线售卖汽车座套、汽车方向盘把套等汽车周边装饰商品，需补充商家自营-汽车内饰/外饰类目。 [图片] 23、办公/文具：小程序涉及提供办公/文具用品线上销售配送服务，需补充商家自营-办公/文具类目。 案例：下图小程序涉及在线销售铅笔笔芯、计算器等学习文具用品，需补充商家自营-办公/文具类目。 [图片] 24、宠物/农资：小程序涉及提供宠物/农资产品线上销售配送服务，补充商家自营-宠物/农资类目。 案例：下图小程序涉及在线销售复合肥微生物菌等农资产品，需补充商家自营-宠物/农资类目。 [图片] 25、五金/建材/化工/矿产品：小程序涉及提供五金/建材/化工/矿产品线上销售配送服务，补充商家自营-五金/建材/化工/矿产品类目。 案例：下图小程序涉及在线售卖焊接大小头等五金商品，需补充商家自营-五金/建材/化工/矿产品类目。 [图片] 26、机械/电子器件：小程序涉及提供机械产品/电子器件线上销售配送服务，需补充商家自营-机械/电子器件类目。 案例：下图小程序涉及在线售卖挖掘机等其他机械配件类商品，需补充商家自营-机械/电子器件类目。 [图片]

尊敬的微信支付商户： 为保障商户资金安全、优化商户体验，商家转账到零钱产品将于11月25日起对现有产品能力逐步调整，主要包括： 1、批次转账的明细数量上限调整； 2、商户基于转帐场景提交资料，平台将基于不同场景确定商家转账限额及使用方式； 3、支持下载5年内账单并优化业务账单格式，同时支持下载2年内电子回单。 详情请参考：商家转账产品文档  特别提示：其中使用转账给员工、付款给合作伙伴的场景，需要在商户平台-商家转账到零钱添加收款用户openid及姓名，仅可向列表中已添加且姓名一致性校验通过的用户转账。 为了不影响您的使用，请尽快在商户平台添加需要付款的用户openid及姓名，否则调用转账接口会返回报错信息“未配置收款用户列表，请前往商户平台-产品中心 - 商家转账到零钱 - 转账场景中添加”或“该openid不在收款用户列表中，请前往商户平台-商家转账到零钱-转账场景中添加”。 财付通支付科技有限公司 2022年11月25日

各位开发者： 下发统一消息 接口曾支持小程序与公众号统一的模板消息下发。由于小程序模板消息能力已于 2020 年 1 月下线（详见 小程序模板消息能力调整通知），当前下发统一消息能力仅限于公众号范畴。为了优化开发体验，避免多个同一功能接口对开发者造成困扰，微信团队将对下发统一消息接口进行如下调整： 自 2023 年 9 月 20 日起（以下简称 “生效期”），下发统一消息接口将被收回。自生效期起，调用下发统一消息接口将会显示 “45109” 错误码，无法下发小程序模板消息与公众号模板消息。如业务需下发公众号模板消息，请使用 公众号模板消息能力 满足能力需求，具体适配操作可参考下方适配指引。 注意点： 1、下发统一消息接口与公众号模板消息接口的差异对比如下： [图片] 2、本次接口回收仅影响使用旧的下发统一消息接口的方式下发模板消息的情况，不代表公众号模板消息能力被收回，使用 公众号模板消息接口 下发公众号模板消息的能力不受影响。例如小程序 A、B 当前正使用不同接口下发公众号模板消息： [图片] 3、小程序订阅消息能力不受本次接口回收的影响。 4、请已使用下发统一消息接口的开发者尽快适配。若 2023 年 9 月上旬仍未适配，官方团队将分阶段通过站内信、微信开发者工具通知等方式同步告知指引修改。 适配指引： [图片] 检查当前调用下发统一消息接口的用户身份信息： 1、若当前下发模板消息的用户身份信息为公众号 openid，按照 公众号模板消息接口文档 适配 2、若当前下发模板消息的用户身份信息为小程序 openid，检查 微信开放平台 是否将小程序与公众号绑定在同一个主体 a) 若小程序与公众号绑定在同一个主体下，按照 公众号模板消息接口文档 适配 b) 若小程序与公众号没有绑定在同一个主体下，先完成绑定工作，再按照 公众号模板消息接口文档 适配 微信团队 2023年8月22日

请问各位大佬，为啥有些商户号支付成功后可以跳转知道页面，有些支付成功后是直接关闭页面了，有什么办法补救么。还有，WeixinJSBridge.invoke是不是被停用了，文档里吗搜不到。 [图片]

为什么两个商户号，一个商户号的验证微信支付身份是“微信支付公钥”，另一个是“平台证书”？是什么原因导致的？无论在文档中还是百度搜索，都无法找到“微信支付公钥”相关的详细说明，都是说的“平台证书”。该如何从“微信支付公钥”切换到“平台证书”？因为使用“微信支付公钥”的账号现在发起支付失败，不兼容现有的支付接口。谢谢！ [图片] [图片]

写在开头： 其实微信支付侧在很早～很早～～很早～～～之前就打算将平台证书抛弃改换公钥模式进行敏感信息加密和回调签名验证了，平台证书只有5年有效期，现在的开发者只会管当下“能run就行”，哪会考虑到5年之后平台证书过期的事情，导致在首次平台证书过期时间点（2023年末2024年初）很多线上平稳运营多年的系统就突然炸了，还一时不容易定位问题。 在解决平台证书问题上，微信支付推出了新的公钥模式，由于前期一直在各种线下会议上宣传，没有给出正式通知和明确的使用指引，高估了大部分开发者的情况，再加上很突然的线上灰度，盲猜内部没协调好引发新申请商户号调用“获取平台证书”接口出现已读乱回的情况，社区因此出现大量此类报错提问，可以看出很多开发着开始迷茫了：“我是谁？我在哪？为啥同样代码其他商户号都正常？为啥我’差不多‘时间申请的商户号其他的能有，就这不能用？”。 出于作为“用爱发电的热心网友”，就简单写个让大家能看得懂的说明吧。 PS：其实我们要感谢微信支付团队，给各位开发者多找点事情做，避免大家被“毕业”，要感谢他们的良苦用心～！ 吐槽两句 真不知道负责这块接口设计的人是咋想的，在不知情需要获取公钥的情况下，你获取平台证书接口提示个“证书不存在”是写给谁看？写的报错提示谁能直接看得出来你想表达的意思？脑回路清奇，建议拉出去弹吉他十分钟！！！ 问题说明 微信支付对于新申请商户号以及平台证书过期商户已不再签发平台证书，需要更换使用微信支付平台公钥进行敏感信息加密、通知回调签名验证，因此此类商户号调用获取平台证书接口时会出现报错“证书不存在”或者“系统繁忙”的情况。 解决方案 目前会存在两种情况，一种是新申请商户号商户后台没有“平台证书”管理入口，另一种为存量商户存在有在有效期的平台证书和平台证书过期没有签发，第一种可以直接在商户后台->账户中心->API安全->启用“微信支付公钥”，下面教程主要以存量商户切换公钥进行说明（懒得申请新商户号了，拿个白名单商户来写的）。 1.1获取商户对应的平台公钥 商户后台->账户中心->API安全->申请“微信支付公钥“，在点击申请的时候会提示你查看指引，要点查看才可以进行公钥申请！！！ [图片] 下载公钥 [图片] 点击“下载公钥”后会自动下载文件名为’pub_key.pem’的公钥并在后台生成“PUB_KEY_ID”开头的公钥ID（丢了也没事，后台可以重复下载，公钥ID不变） [图片] 1.2 接口开发 下面所写示例说明均使用官方sdk，仅供参考 PHP 同时支持平台证书和平台公钥两种方法，在返回的wechatpay-serial值，在certs里有定义，就会自动匹配 [代码]// 从本地文件中加载「微信支付平台证书」或者「微信支付平台公钥」，用来验证微信支付应答的签名,这里直接使用前面从后台获取的微信支付平台公钥; $platformCertificateOrPublicKeyFilePath = 'file:///path/to/wechatpay/certificate_or_publickey.pem'; $platformPublicKeyInstance = Rsa::from($platformCertificateOrPublicKeyFilePath, Rsa::KEY_TYPE_PUBLIC); // 「微信支付平台证书」的「证书序列号」或者是「微信支付平台公钥ID」 // 「平台证书序列号」及/或「平台公钥ID」可以从 商户平台 -> 账户中心 -> API安全 直接查询到,这里直接写前面从后台获取的微信支付平台公钥ID，注意要带上'PUB_KEY_ID_' $platformCertificateSerialOrPublicKeyId = 'PUB_KEY_ID_0114232134912410000000000000'; [代码] java 将原“RSAAutoCertificateConfig.Builder”配置改为使用“RSAPublicKeyConfig.Builder”，publicKeyId填写前面从后台获取的微信支付平台公钥ID，注意要带上’PUB_KEY_ID_’ [代码]// 可以根据实际情况使用publicKeyFromPath或publicKey加载公钥 Config config = new RSAPublicKeyConfig.Builder() .merchantId(merchantId) .privateKeyFromPath(privateKeyPath) .publicKeyFromPath(publicKeyPath) .publicKeyId(publicKeyId) .merchantSerialNumber(merchantSerialNumber) .apiV3Key(apiV3Key) .build(); [代码] go 仅可使用微信支付的公钥验证应答和回调的签名,使用公钥ID初始化 [代码]var ( wechatpayPublicKeyID string = "PUB_KEY_ID_0114232134912410000000000000" // 微信支付公钥ID ) wechatpayPublicKey, err = utils.LoadPublicKeyWithPath("/path/to/wechatpay/pub_key.pem") if err != nil { panic(fmt.Errorf("load wechatpay public key err:%s", err.Error())) } // 初始化 Client opts := []core.ClientOption{ option.WithWechatPayPublicKeyAuthCipher( mchID, mchCertificateSerialNumber, mchPrivateKey, wechatpayPublicKeyID, wechatpayPublicKey), } client, err := core.NewClient(ctx, opts...) // 初始化 notify.Handler handler := notify.NewNotifyHandler( mchAPIv3Key, verifiers.NewSHA256WithRSAPubkeyVerifier(wechatpayPublicKeyID, *wechatPayPublicKey)) [代码] 1.3以上是使用sdk的参考，不使用sdk的情况下，可以参考下面链接内的示例（应该能跑，没测试）：点我查看 1.4 开发对接完成后，在商户后台更换验签方式 此操作可在灰度完成之前操作终止，操作需要超管进行操作并进行安全验证，更换以后回调灰度进度由平台控制在7天内完成，应答进度由商户请求参数控制，更换完成后才可以进行平台证书作废操作。 [图片] 就这样吧，有什么问题跟帖回复

各位开发者： 由于内部网络设备裁撤，api.weixin.qq.com(sz.api.weixin.qq.com)需要更新部分接入点IP，详细如下： 上海电信VIP变更：101.227.162.120;101.226.212.27 -> 180.97.7.108;101.226.212.27 上海联通VIP变更：140.207.119.12;58.246.220.31 -> 116.128.163.147;58.246.220.31 上海CAP VIP变更：182.254.92.124;182.254.88.157 -> 121.51.90.217;182.254.88.157 深圳联通变更为：163.177.83.164;58.251.80.204 -> 58.251.82.216;58.251.80.204 此次变更不影响直接使用DNS解析微信域名的业务，如有业务仍在尝试旧的接入IP（通过代码写死或防火墙配置），请及时更新至新的接入IP，裁撤截止日期2020年10月15日，届时旧IP会停止服务，返回指引文档信息。 请不要通过配置hosts的方式访问api.weixin.qq.com，以免微信侧后续更新出口IP时出现接口访问失败。 特殊情况如配置防火墙等，请改造成通过接口获取api.weixin.qq.com当前所有出口IP(同一时间不会所有IP都变更，请尝试可用IP)，并更新至hosts或防火墙等。 获取api.weixin.qq.com当前所有接入IP请参考官方文档。 微信团队  2020.09.24

需求是我们公司自己可以收款，也可以帮其它主体收款，然后我采用服务商和特约商户的模式，我想把自己公司也作为一个特约商户可以吗？ 服务商的主体是企业A，在服务商的特约商户管理界面添加特约商户时，也选择企业A，就是相同主体，这种情况可以审核通过吗？

为保障用户体验，小程序的提审及发布需须是一个完成品，要求可以打开，可以运行，且不可以是一个测试版。 建议开发者在提审前先自查验服务可用性及完整性后在提交代码审核，有利于提高审核通过率。   常见驳回场景，如 1、页面运营内容/数据不完整： 小程序仅有页面title、底部button， 但中间无具体运营内容。包括但不限于页面提示“无任何商品”“加载完了”或页面中间为空白。 示例： [图片]优化建议：建议开发者上传有效商品/运营数据后，再重新提交代码审核。 2、页面加载不出来： 2.1 进入服务页面一直提示“加载中”或“无法加载”等情形，无法加载出现完整页面内容信息，无法正常体验小程序服务内容。 示例： [图片] 2.2 页面白屏：打开页面空白，无任何内容报错信息，无法正常体验小程序功能服务。 示例： [图片] 优化建议：建议开发者自行排查代码进行性能优化，确保服务可流畅稳定运行加载/无白屏等异常情况后再重新提交代码审核。 4、功能报错： （1）页面提示“获取用户信息报错”、加载后，仍提示获取信息失败 （2）打开页面提示：无法打开业务域名 （3）网络异常 （4）请求失败、验签失败等 示例： [图片][图片][图片][图片][图片] 优化建议：建议开发者自行排查报错原因并对其进行修复，自查无问题后再重新提交代码审核代码进行优化。 5、控件无响应： 小程序页面点击“主业务控件无响应”等，无法进一步体验小程序服务内容。 示例： [图片] 优化建议：建议开发者自行排查代码进行优化，确保服务核心功能可用及不存在严重bug后再重新提交代码审核。   6、Demo、测试内容服务： （1）小程序以官方demo提审，打开仅有“hello world”、官方功能组件、示例图等”无实际运营功能内容。 示例： [图片] （2）小程序上传内容为测试数据（非正式运营数据），不建议上传以“测试商品、测试版块、测试服务”等字眼内容。 示例： [图片] 优化建议：建议开发者自查确认所提交的小程序是完成品完整可用的，不应提交未经开发的demo或非正式运营数据内容。   7、体验有账号登录或测试环境、体验配置限制（1）有特定账号密码登录要求，注册流程不对外开放，需使用特定账号及密码才能登录体验服务，提审时未提供有效测试账号、密码示例：[图片][图片] （2）页面无特定账号输入入口，但服务体验有测试环境、体验配置要求（如：内部鉴权、关联蓝牙设备、地理位置体验有要求等情况）。示例：[图片][图片][图片] 优化建议：建议开发者在在提交代码审核时在【在提审页面】中填写有效测试帐号及密码保证审核者可以体验所有功能或上传小程序截图、运行视频协助完成审核。

https://developers.weixin.qq.com/miniprogram/dev/framework/https://developers.weixin.qq.com/miniprogram/product/record_guidelines.html

小程序微信认证完了，备案和上线发布前审核能同时进行吗？

我们服务只是使用地图里面的线路规划和地址逆解析，平常没有什么量只是偶尔会有高峰期，他们这个不能做成云服务那种按量计费就很恶心，有的月份我们一个月才用不了十几块钱的，一年最多用2000左右，买一个5W的商业授权一点也不划算。所以我想对于量小的公司或者团队一起购买一个均摊下来，接口通用这样成本会小很多。有的话可以留言

换了各种文案, 就是审核不通过, 到底是什么原因, 能不能给我说清楚... appid: wx95b0afb1012820a7 [图片]

之前同样的代码发了20多套，隐私保护指引只写了简单的4至6个字，都是1次过，这次新的小程序怎么改都不给我通过，隐私保护指引审不过，拉不起来手机号授权，导致注册登录无法使用，代码也审核失败，急死了，不知道该怎么办了。[图片][图片][图片]

请官方回答下，由于服务迁移，迁移后服务会使用ipv6地址 [图片]

支付服务部署在内网，只能通过正向代理访问支付api，所以后端访问微信api的地址是http://ip+端口，再通过nginx转发到可以访问互联网的服务器，访问微信的域名https的api地址是要带上证书，使用http://ip+端口带上的证书是不起作用的，这时候可以在nginx中配置所有微信的正向代理加上微信api的证书，这种情况是只有一个商户是可以实现调用微信支付接口，但是现在就是有多个微信商户，就是有多个api证书，这种情况该怎么办？

手机号在日常生活中被广泛使用，是重要的用户个人信息，小程序开发者应在用户明确同意的前提下，依法合规地处理用户的手机号信息。 而部分开发者在处理用户手机号过程中，存在不规范收集行为，影响了用户的正常使用体验，此类情况涉及收集用户隐私违规。 《微信小程序平台运营规范》15. 用户隐私和数据规范 对此规范如下： 除非相关法律要求，或经用户同意，否则不得要求用户输入个人信息（手机号、出生日期等）才可使用其功能，或收集用户密码或者用户个人信息（包括但不限于，手机号、身份证号、生日、住址等）。 在小程序运行中，用户未触发需使用权限或用户个人信息的相关功能或服务时，不得提前向用户弹窗申请权限或收集用户个人信息。 平台汇总了常见违规收集情形，示例如下： 1、一进入小程序即收集用户手机号 [图片] 违规案例 一进入小程序就跳转到手机号登录页面。 [图片] 用户一进入小程序后页面内容不显示，需用户提供手机号后才能正常访问。 [图片] 2、小程序内浏览时要收集用户手机号 [图片] 违规案例 用户浏览小程序商品页面，提示需绑定手机号码才能查看商品详情内容。 [图片] 小程序内点击浏览各个版块，用户需提供手机号后才能浏览版块详情。 [图片] 小程序点击浏览商品信息，需输入手机号获取验证码，登录后才能浏览。 [图片] 3、小程序内部分操作强制或诱导收集用户手机号  3.1 小程序到店点餐/取餐业务场景下强制收集用户手机号  [图片] 违规案例 餐饮类小程序，需绑定手机号入会才能获得下单自提/堂食等服务。 [图片] 3.2 小程序停车缴费场景下强制收集用户手机号  [图片] 违规案例 小程序在停车缴费相关服务过程中需提供手机号才可进行查看缴费。  [图片] 3.3 小程序页面分享场景下强制收集用户手机号 [图片] 违规案例 用户浏览商品页面时，点击分享按钮需要提供手机号码，才能继续操作。  [图片] 3.4 小程序通过利益诱导的方式收集用户手机号 [图片] 违规案例 小程序通过获得积分奖励的方式，提示用户授权手机号。 [图片] 小程序日常运营过程中，如何避免此类问题呢？ 为了保护用户的个人信息，并确保小程序良好的使用体验，平台整理了调整指引供开发者参考： 1、用户一进入小程序，应当可以体验浏览小程序业务内容，不应该在未展示任何信息的情况下，通过弹窗或跳转的页面来收集用户手机号； 2、用户进入小程序以后，应该可以正常浏览小程序页面或版块，不应要求用户提供手机号才能浏览，应保证用户正常的浏览体验； 3、在部分业务使用场景，手机号不是提供服务所必需时，应当让用户正常操作，不强制收集用户手机号，如到店点餐/取餐、停车缴费、页面分享等； 4、在小程序业务使用场景中，手机号为提供服务所必需的，应明确向用户说明收集的必要原因，并提供用户隐私协议由用户主动同意； 5、 小程序业务场景中，手机号为提供服务所必需的，而用户可能会拒绝提供，应当为用户提供显著拒绝操作方式，且在用户拒绝后，不得频繁向用户询问、要求提供手机号。 平台收集了部分开发者反馈的问题，相关评估情况也供参考 1、小程序到店点餐场景不能强制收集用户手机号，餐饮外卖场景是否也不能让用户提供手机号? 不是的，餐饮外卖需要联系点外卖的用户，属于合理收集使用场景。 ①在需要用户手机号才能正常提供服务的必要情况下，仍然可以正常指引用户授权或填写手机号； ②而不需要手机号也能正常提供服务的非必要情况下，不得强制用户授权或填写手机号。比如到店点餐类场景，用户需要到店，无需手机号进行联系，应当可以正常点单。 2、小程序未使用手机号快速验证组件，采取用户手动输入的方式进行收集，是否可以？ 无论是使用手机号快速验证组件、还是让用户手动输入，涉及在非必要场景下去收集的，都涉及违规收集用户个人信息、并且同样影响正常的用户体验，都应当进行调整。 3、小程序属于企业等内部职工使用，页面信息不便对外展示，应当如何调整？ ①在可能的情况下，建议开发者放开可浏览的版块或页面信息，给予用户一定的使用预期； ②如果确因企业内部等原因无法提供对外可公开浏览的内容，应该在页面清晰标注该小程序使用场景及使用人群； ③如果不是小程序的使用人群，在用户验证手机号时需要对用户有明确的拒绝提示，且用户应该可以退出当前流程； ④在提审代码发布更新时，应提供使用说明材料，包括但不限于小程序服务内容录屏、页面截图、体验账号等，以便核实验证。 合理收集与使用用户手机号码，是保护用户隐私和用户体验的重点之一，也是所有开发者需要履行的责任。 平台日常核查持续进行中，如发现小程序通过限制用户操作的方式，在不必要的场景下收集用户手机号，平台将提醒开发者自查调整，如到期未调整，将根据违规程度限制相关能力。 希望开发者们参考以上内容及时调整，共同维护良好的用户使用体验。

[图片] 用的python后端，minibear大佬开源的wechatpay包，偶尔会出现下单超时的情况，排查出来是域名解析的问题。 解析的这几个ip，ipv4的可以ping通，但是ipv6的ping不通。现在发现：每次出故障 ping api.mch.weixin.qq.com都是解析成ipv6的地址来ping，一直丢包；无故障的时候是解析成ipv4的，而ping ipv6显示如下：[图片] 所以ipv6就是一直用不了，是不是能固定不让它解析成ipv6就行了。请问该怎么做？

备案材料准备 在提交备案前，请务必提前准备好备案所需材料，以免由于材料更新问题，导致备案需延期提交。下面将会带大家详细了解备案材料的要求，这样后续在提交时就能避免因为材料问题而导致失败。 材料示例及注意事项 [图片] 注：所有上传材料大小应不超过2M，分辨率不低于720* 1280 ，仅支持JPG、JPEG、PNG 格式 若想查看更多小程序备案材料示例，详情可查看文档 备案信息填写 备案材料准备好后，就可以前往【小程序管理后台-设置-小程序备案】提交备案申请了。下面将会详细教大家如何进行备案信息的填写，一共分为五个部分：主办单位信息填写、主体负责人信息填写、小程序信息填写、小程序管理员信息填写和上传其他信息材料。 1.主办单位信息填写 [图片] [图片] 填写说明 常见报错/问题 解决方案 ①选择地区：选择与证件地址相一致的省市区信息 该主体已在XX完成备案，请修改备案省份或注销备案主体重新备案 请核实该主体是否有在其他省份备案过，由于同主体在所有平台的备案省份必须保持一致，需修改备案省份或注销备案主体重新备案 ②主办者性质：默认与小程序主体认证信息相一致 / / ③证件类型：默认与小程序主体认证信息相一致 / / ④上传证件：按要求提供最新版证件 营业执照有效期不足 请联系工商部门更新证件有效期 ⑤企业名称：填写证件相对应名称信息 主办者与小程序主体不一致 请核实填写企业名称是否与小程序主体名称、上传营业执照名称相一致 ⑤企业名称：填写证件相对应名称信息 营业执照名称为空或者* 号 请联系工商部门更新企业名称信息 ⑥证件住所：填写证件相对应经营场所信息 【主体证件住所】工商数据对比不通过 请参考文档进行排查 ⑦证件号码：填写证件相对应统一社会信用代码信息 未查询到企业信息，请检查主体证件号是否有误 请核实填写的是否为统一社会信用代码，若无，请联系工商部门更新证件信息，不能填写其他如工商注册号等 ⑧通讯地址：填写当前主体所在的实际通讯地址（无需填写省、市、区） 通讯地址未能精确到门牌号 若无具体门牌号，需要在备注中说明情况 ⑨备注（选填）：针对主体信息进行补充说明，如有可填写 / / 注：若为新建企业或近期有做信息变更，可能会存在企业工商数据更新延迟的情况，建议过段时间（5~15个工作日）再进行重试，否则无法正常发起验证流程。 2.主体负责人信息填写 [图片] 填写说明 常见报错/问题 解决方案 ①证件类型：选择主体负责人证件类型信息 / / ②上传证件：按要求提供最新版证件 / / ③负责人名称：通过上传证件自动识别，有误可自行修改 主体负责人与法定代表人不一致，且备案所在地不支持法定代表人授权 请核实填写的主体负责人是否为法人，需与营业执照信息一致，由于所属地区不支持授权，只能填写法人信息 ④负责人证件号：通过上传证件自动识别，有误可自行修改 【主体负责人证件号码】企业工商四要素核验失败 请核实填写的主体负责人名称、证件号信息是否正确 ⑤证件有效期：通过上传证件自动识别，有误可自行修改 / / ⑥手机号：主体负责人手机号码 【主体负责人手机号码】不允许被多人使用 请核实填写的手机号是否为其他人的信息，仅在同一主体下，同一个人允许为多个小程序备案，可提交一致的手机号、应急手机号及邮箱信息，否则不能出现个人信息混用的情况 ⑦验证码：主体负责人手机号码收到的对应验证码 验证码不正确 请核实验证码是否已失效，验证码有效期为10分钟 ⑧应急手机号：主体负责人的应急电话 【主体负责人应急联系方式】不允许被多人使用 请核实填写的应急手机号是否为其他人的信息，仅在同一主体下，同一个人允许为多个小程序备案，可提交一致的手机号、应急手机号及邮箱信息，否则不能出现个人信息混用的情况 ⑨邮箱地址：主体负责人的电子邮箱 / / 3.小程序信息填写 [图片] 填写说明 常见报错/问题 解决方案 ①服务内容标识：根据小程序实际运营内容选择合适的即可 小程序服务内容类型数目不能超过5个 服务内容标识是通信管局对各个行业的分类，平台部分行业类目与管局行业类目名称不完全不一致，建议根据备案小程序实际运营内容尽可能选择对应的服务内容标识，最多选择5个。 ②互联网信息服务前置审批项：根据小程序实际运营内容判断是否需要进行前置审批 如从事XXX业务，请上传前置审批文件 小程序实际运营内容涉及前置审批项，需上传对应的审批文件 ②互联网信息服务前置审批项：根据小程序实际运营内容判断是否需要进行前置审批 前置审批项必须选择“以上都不涉及” 小程序实际运营内容不涉及前置审批项，需要选择"以上都不涉及” ③备注（必填）：具体描述小程序实际经营内容，主要服务内容 请在小程序备注按格式填写 请核实是否有根据备注格式进行填写，仅自行补充带星号内容即可。 4.小程序管理员信息填写 [图片] 填写说明 常见报错/问题 解决方案 ①证件类型：选择小程序负责人证件类型信息（目前仅支持身份证） / / ②上传证件：按要求提供最新版证件（目前仅支持身份证） / / ③负责人名称：通过上传证件自动识别，有误可自行修改 【小程序负责人姓名】负责人与小程序管理员不一致 请核实小程序是否未完善管理员实名信息，需参考指引文档进行补充 ④负责人证件号：通过上传证件自动识别，有误可自行修改 【小程序负责人证件号码】负责人与小程序管理员不一致 请核实小程序是否未完善管理员实名信息，需参考指引文档进行补充 ⑤证件有效期：通过上传证件自动识别，有误可自行修改 / / ⑥手机号：小程序负责人手机号码 【小程序负责人手机号码】不允许被多人使用 请核实填写的手机号是否为其他人的信息，仅在同一主体下，同一个人允许为多个小程序备案，可提交一致的手机号、应急手机号及邮箱信息，否则不能出现个人信息混用的情况 ⑦验证码：小程序负责人手机号码收到的对应验证码 验证码不正确 请核实验证码是否已失效，验证码有效期为10分钟 ⑧应急手机号：小程序负责人的应急电话 【小程序负责人应急联系方式】不允许被多人使用 请核实填写的应急手机号是否为其他人的信息，仅在同一主体下，同一个人允许为多个小程序备案，可提交一致的手机号、应急手机号及邮箱信息，否则不能出现个人信息混用的情况 ⑨邮箱地址：小程序负责人的电子邮箱 / / ⑩负责人人脸核身：小程序管理员（小程序负责人）需使用微信APP扫码，完成人脸核身 当前场景仅支持居民身份证 核实小程序管理员证件是否为大陆居民身份证，目前港澳台管理员无法进行人脸核身，建议先更换小程序管理员为中国大陆地区的人员，作为备案小程序负责人。 5.上传其他信息材料 [图片] 填写说明 常见报错/问题 解决方案 互联网信息服务承诺书：1. 广东地区：下载页面提供的模版文件，填写完整后上传提交；2. 非广东地区：点击阅读确认后提交 承诺书需加盖公章，但个体户没有公章 若个体工商户无公章，需要主体负责人手写日期+签名+盖手印+身份证号码，同时请在主体备注处备注“个体工商户无公章”。注：江苏、宁夏、福建地区，须刻章后提交备案，不接受负责人手印。 以上信息都填写完毕，就可点击提交，后续的备案审核流程可参考： [图片] 如有其他相关疑问，欢迎随时参与社区讨论。

一、 注册上限 1.同一个邮箱只能申请1个小程序； 2.同一个手机号码可绑定5个小程序； 3.同一身份证注册个人类型小程序数量上限为5个； 4.同一企业、政府、媒体、其他组织资料注册小程序数量上限为50个； 5.同一个体工商户注册小程序数量上限为5个。 二、绑定上限 1.同一身份证可绑定5个小程序； 2.同一手机号可绑定5个小程序； 3.同一微信号可绑定5个小程序。 温馨提示： 1.主体注册次数不占公众号次数限制； 2.个人类型主体身份证与管理员或项目成员绑定的微信号独立计算（不与其他类型重合）。 关联问题： 1.如何查询身份证、手机、微信号、企业绑定的小程序？ 查看身份证、手机、微信号、企业绑定的小程序，请关注微信公众号“公众平台安全助手”（mphelper），通过公众号底部菜单“绑定查询”进行查看。 2.如何查询主体绑定的小程序？ 登录该主体的任意一个小程序，在“设置-基本信息-主体信息-详情-主体绑定账号-查询”查询该主体绑定的账号信息。

我在平台配置了回调地址，但是支付成功之后没有看到回调的日志，平台回调有记录吗？在哪里可以看

1. 背景介绍 微信开放平台使用 HTTPS 协议来确保通信的安全性。在开发者调用微信开放平台 API 的过程中，需要在其操作系统或执行环境（如 JRE 等）中部署权威机构的根证书，以验证微信开放平台服务器证书的真实性，进而验证微信服务器及其域名的真实性。 受 Mozilla 信任库的最新根证书信任策略影响（全球所有 CA 的可信根证书需每15年更换一次，超过此时间的可信根将逐渐失去 Mozilla 的信任），DigiCert 将逐步停止使用旧的根证书体系（G1）来颁发 TLS/SSL 证书，转而采用新的根证书体系（G2）。 当前微信开放平台服务器证书的颁发根 CA 是 Digicert Global Root CA (G1)，微信开放平台计划于 2024年10月22日 0:00 开始，逐步启用采用 DigiCert Global Root G2 根 CA 颁发的新服务器证书，开发者应仔细阅读本指引，并完成相关验证和修正，以免影响正常服务。 注意： 1）所有通过 api.weixin.qq.com 调用的 API 都可能受影响，开发者需要在 2024年10月22日 0:00 之前参考指引完成相关验证和修正。 2）大多数操作系统和执行环境都默认内置了 DigiCert Global Root G2 根证书，因此大多数系统无需改动即可兼容新服务器证书。但如果开发者的服务器未内置 G2 根证书，或程序代码指定使用旧的 G1 根证书，则会受到影响，将出现服务中断的问题。我们建议及时移除指定旧根证书代码，采用系统自带的信任库进行验证，同时确保系统内置有 DigiCert Global Root G2 根证书。 3）新的 G2 根体系采用更高安全性的 SHA256 签名算法，且依然兼容当前主流的操作系统和移动设备，主流环境兼容情况如下： [图片] 对应的根证书文件请参考： Baltimore CyberTrust Root：Download PEM、Download DER/CET Digicert Global Root CA：Download PEM、 Download DER/CRT Digicert Global Root G2：Download PEM、 Download DER/CRT 2. 开发须知 开发者需确认与微信开放平台对接的服务器系统可兼容新的服务器证书，并参考“验证指引”章节的方法，在 2024年10月22日 0:00 之前完成验证： • 如果验证结果正常，开发者不需要做其它任何事情 • 如果验证结果异常，开发者需要修改相关的系统实现或配置，且需最晚于 2024年10月22日 0:00 之前前完成修正，否则开发者的业务系统与微信开放平台系统之间将不能正常进行 HTTPS 通讯，将影响业务正常运行。 开发者在验证和修正过程中遇到问题，可在小程序专区发帖咨询，我们会有专人进行解答回复。 3. 验证指引 验证方式：绑定 host，请求已部署新证书的微信开放平台服务器 开发者可通过修改操作系统的 hosts 文件来绑定 IP，例如，可在 hosts 文件中新增一行如下内容，实现将域名"api.weixin.qq.com"绑定到新证书环境： 81.69.216.137 api.weixin.qq.com 在 Linux 系统下，hosts文件的完整路径为"/etc/hosts"，在Windows系统下，hosts 文件的完整路径为"C:\Windows\System32\drivers\etc\hosts"。 注意： 1、host 环境可以访问的接口与正式环境完全一致，且真实生效，被视为生产正式业务。在验证之前，请充分评估对贵司业务系统以及业务的影响 2、验证完成后，请及时恢复服务器上的 host 配置，微信开放平台服务器证书更新完成后，此处使用的 IP 会被关停。 3、需要用和生产环境相同的操作系统、执行环境、开发语言及程序逻辑进行验证。使用 curl 等命令行工具验证成功，并不代表你的系统支持了新的服务器证书。 4、逐一验证所有正在调用的微信开放平台接口，如果均能正常使用，说明系统支持微信开放平台新的服务器证书。反之，则需要根据修正指引排查问题并修正。 4. 修正指引 大部分情况下，验证失败是以下两种情况导致的： 情况一：程序中指定了根证书，但是指定的根证书中仅包含了旧的 G1 根证书。 情况二：服务器上没有部署新的 G2 根证书。 可通过以下两个方案修正: 方案一：删除指定根证书的代码。当程序中不指定根证书时，会使用系统自带的根证书。绝大部分系统中已内置了新的 G2 根证书，所以删除指定根证书的代码，不会影响到你的现有业务。 方案二：更新根证书。往 truststore 或者根证书信任文件中追加新的 G2 根证书（注意：追加新的根证书时，需要保留老的G1根证书）。 推荐使用“方案一”来修正，该方案的兼容性更好。原因是：新的 G2 根证书将于 2029年4月15日不再被 Mozilla 信任，到时候同样要更换新的根证书。使用方案一修复，你的系统中很可能已内置了后续需更换使用的根证书，从而不受影响。如果使用方案二进行修复，在 2029年4月15日仍可能需安装新的根证书。 下面介绍各种开发语言可能碰到的问题及解决方法： JAVA常见错误 javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target 可能原因: 代码中设置了 javax.net.ssl.trustStore 。 可以在代码中搜索关键字“trustStore” 或者 “TrustManager” 来确认 解决方法: 方法一、删除掉指定[代码]javax.net.ssl.trustStore[代码]的代码 方法二、安装新的根证书, 往指定的trustStore 中添加新的根证书。操作命令：keytool -importcert -keystore cacerts -storepass changeit -noprompt -file ./DigiCertGlobalRootG2.crt -alias digicertglobalrootg2 C++常见错误 cURL error 60: SSL certificate: unable to get local issuer certificate. CURLE_SSL_CACERT (60) peer certificate cannot be authenticated with known CA certificates. 可能原因: 代码中设置了[代码]CURLOPT_CAINFO[代码]。 可以在代码中搜索关键字“CURLOPT_CAINFO”来确认 解决方法： 方法一、删除掉[代码]curl_easy_setopt(pCurl,CURLOPT_CAINFO,"./rootca.pem")[代码]相关的代码 方法二、更新rootca.pem。用libcurl官网最新的 https://curl.haxx.se/ca/cacert.pem 替换即可 PHP常见错误 cURL error 60: SSL certificate: unable to get local issuer certificate. CURLE_SSL_CACERT (60) peer certificate cannot be authenticated with known CA certificates. 可能原因: 使用libcurl时设置了[代码]CURLOPT_CAINFO[代码]。可以在代码中搜索关键字“CURLOPT_CAINFO”来确认。 解决方法： 方法一、删除掉类似[代码]curl_setopt(pCurl， CURLOPT_CAINFO， "./rootca.pem");[代码]的代码 方法二、更新rootca.pem。用libcurl官网最新的https://curl.haxx.se/ca/cacert.pem 替换即可 C#常见错误 RemoteCertificateValidationCallback 设置的回调函数返回 false 可能原因: 操作系统中没有新的根CA 解决方法: 安装新的根证书 Python常见错误 SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) 可能原因: 代码中用 verify 指定了根证书文件。 可以在代码中搜索关键字“verify”来确认。类似的代码如: [代码]response = requests.post( "https://api.mch.weixin.qq.com/secapi/pay/refund"， verify="./rootca.pem", …… ); [代码] 解决方法： 方法一、删除verify参数 方法二、更新[代码]rootca.pem[代码]。用libcurl官网最新的https://curl.haxx.se/ca/cacert.pem 替换即可 go常见错误 x509: certificate signed by unknown authority . 可能原因: 发起https时， 用 RootCAs指定了根证书文件。 可以在代码中搜索关键字 “RootCAs” 来确认。类似的代码如: [代码]roots.AppendCertsFromPEM([]byte(rootPEM)) tr := &http.Transport{ TLSClientConfig: &tls.Config{RootCAs: roots}， } client := &http.Client{Transport: tr} [代码] 解决方法： 方法一、删除配置项RootCAs 方法二、更新[代码]rootca.pem[代码]。用libcurl官网最新的https://curl.haxx.se/ca/cacert.pem 替换即可 Ruby常见错误 SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed 可能原因: 发起https时， 用[代码]ssl_ca_file[代码]或者[代码]cert_store[代码]指定了根证书文件。 可以在代码中搜索关键字“ssl_ca_file” 或者 “cert_store” 来确认。类似的代码如: [代码] "https://api.mch.weixin.qq.com/secapi/pay/refund"， :ssl_client_cert => OpenSSL::X509::Certificate.new(File.read("./apiclient_cert.pem "))， :ssl_client_key => OpenSSL::PKey::RSA.new(File.read("./apiclient_key.pem "))， :ssl_ca_file => "./rootca.pem"， :verify_ssl=>OpenSSL::SSL::VERIFY_PEER).post(data); [代码] 或者 [代码]sock.cert_store.add_file('/usr/lib/ssl/certs/weixin/rootca.pem') [代码] 解决方法： 方法一、删除 [代码]ssl_ca_file[代码]及 cert_store 指定的参数 方法二、更新rootca.pem。用libcurl官网最新的https://curl.haxx.se/ca/cacert.pem 替换即可 NodeJs常见错误 Caught exception: Error: CERT_UNTRUSTED 可能原因: 代码中用 ca 指定了根证书文件。 可以在代码中搜索关键字“ca” 或者 “rootca” 来确认。类似的代码如: [代码] hostname: api.mch.weixin.qq.com ', pfx: await readFile('./apiclient_cert.p12'), ca: await readFile('./rootca.pem'), }; const req = https.request(options, (res) => { …… [代码] 解决方法： 方法一、删除ca指定的参数 方法二、更新[代码]rootca.pem[代码]。用libcurl官网最新的https://curl.haxx.se/ca/cacert.pem 替换即可 其它语言请参考对应的TLS/SSL库相关手册。 5. 常见问题 Q1：什么是服务器证书？ A：服务器证书通常又叫“SSL 证书”、“HTTPS 证书”，它由权威 CA 机构颁发，用于对网站进行身份鉴定，并使客户端与网站之间通过 TLS/SSL 协议建立起安全传输通道。微信开放平台的服务器证书是由权威机构 DigiCert 颁发，开发者调用微信开放平台 API 时，能通过该证书来认证微信服务器身份。 Q2：什么是根证书？ A：根证书是权威 CA 机构给自己颁发的证书，是信任链的起始点，是证书颁发机构（CA）与用户建立信任关系的基础。操作系统、浏览器、TLS/SSL 开发库通常随软件发行包预置其信任的权威机构的根证书。 Q3：微信开放平台为什么要更换服务器证书？ A：根证书存在有效期，根证书到期后无法继续被用来校验服务器证书。 因此，微信开放平台向权威机构（CA）申请了新的服务器证书。避免在老的根证书过期后，开发者调用微信开放平台 API 时出现问题。 Q4：微信开放平台更换服务器证书，需要开发者配合做哪些事情？ 一、验证你的系统是否兼容微信开放平台新的服务器证书。 二、若支持的话，不需要做任何操作。若不支持，需要参考修正指引排查原因并修正。 注意： a）开发者按指引进行验证或安装新的根证书, 不会产生任何费用。 b）开发者正在使用的其它 HTTPS 证书不需要更换或者升级。 Q5：开发者如何核实服务器上是否已内置了G2根证书？ A： 以 Linux 系统为例。Linux 系统信任根证书库的保存位置因发行版本不同而有所差异：Debian/Ubuntu：/etc/ssl/certs/ca-certificates.crt CentOS/RHEL/Fedora/TencentOS：/etc/pki/tls/certs/ca-bundle.crt 开发者可以使用以下命令来核实系统是否已内置了G2根证书 [代码]grep "DigiCert Global Root" /etc/pki/tls/certs/ca-bundle.crt # DigiCert Global Root CA # DigiCert Global Root G2 [代码] 备注：示例显示系统已内置了G1和G2根证书 Q6：微信开放平台更换证书前，可以提前安装根 CA 证书吗？ A： 必须提前安装，且建议在 2024年10月22日 0:00 之前提前安装。因为从 2024年10月22日 0:00开始，微信开放平台会在生产环境逐步灰度启用新服务器证书，以校验开发者的系统是否兼容新证书。微信开放平台在更换新证书的过程中，会同时使用新老两个服务器证书，开发者要能正常处理这种情况。因此，开发者的服务器上需要包含新老两个根证书。 Q7：开发者需在什么时候完成验证和修正？不验证会有什么影响？ A： 开发者应在 2024年10月22日 0:00 之前完成验证和修正。如果开发者侧系统的实现方式已能兼容新的服务器证书，那么不会影响业务；如果开发者侧系统的实现方式不能兼容新的服务器证书，那么会导致开发者的系统与微信开放平台的系统不能正常交互，影响业务。 Q8：如果开发者无法按时完成兼容性修正，在微信开放平台灰度新证书时遇到异常应如何处理？ A： 如果开发者的系统经验证是不能兼容新证书的，开发者应在 2024年10月22日 0:00 之前完成修正。如果无法按时完成修正，我们届时可提供仍使用旧证书的临时环境，开发者可通过 host 绑定 IP 的方式使用，以临时规避证书更换产生的影响。请务必在2024年10月22日 0:00 之前完成系统修正，并取消绑定临时环境IP，恢复以正常的方式对接微信开放平台的生产正式环境。 6. 特别提醒 1）为提前发现开发者“是否会受到证书更换的影响？”“有没有升级完根证书？”，微信开放平台将于 2024年10月22日 0:00 开始，把开发者的部分请求转发到部署了新证书的服务器上，并逐步提升灰度比例。当开发者不支持新的服务器证书时，会出现 SSL 相关的错误，通常情况下重试即可恢复。 2）根证书升级仅跟服务器和应用程序相关，与 APPID 没关系。只要在同一台服务器升级完成后，该服务器上使用的所有 APPID 都可以正常使用的。 3）如果你是通过代理服务器向微信开放平台发起请求，那么需要修改代理服务器的配置。 7. 联系我们 如果开发者在验证或者修正问题的过程中遇到困难，可在小程序专区发帖咨询，我们会有专人进行解答回复。 8. 附录 DigiCert 原文公告 ：DigiCert root and intermediate CA certificate updates 2023

1. 背景介绍 微信支付使用HTTPS来保证通信安全，商户与微信支付服务器通信前，要在客户端的操作系统或者执行环境(如JRE等)中部署权威机构的根证书。 商户调用微信支付API的过程中，会用根证书来校验微信支付服务器及域名的真实性。 受Mozilla信任库的根证书最新信任策略（全球所有 CA 的可信根证书生成后最少 15 年更换一次，超过时间的可信根会逐渐被 Mozilla 停止信任）影响，DigiCert 将逐步停用旧根体系（G1）颁发 TLS/SSL 证书，并开始使用新根体系（G2）颁发 TLS/SSL 证书。 当前微信支付服务器证书的颁发根CA是Digicert Global Root CA (G1)，微信支付计划于2024年8月5日0:00开始，逐步启用采用DigiCert Global Root G2根CA颁发的新服务器证书，商户的技术开发人员应仔细阅读本指引，并完成相关验证和修正，以免影响正常交易。 注意： 与微信支付系统直接对接（自行开发、外包开发）通信的商户可能受影响，商户需在2024年8月5日0:00之前参考指引完成相关验证和修正。服务商下属特约商户等间接对接微信支付的商户不受影响； 大多数操作系统和执行环境都默认内置了DigiCert Global Root G2根证书，因此大多数系统无需改动即可兼容新服务器证书。但如果商户的服务器/终端设备未内置G2根证书，或程序代码指定使用旧的G1根证书，则会受到影响，将出现服务中断的问题。请及时移除指定旧根证书操作，改用系统自带的信任库进行验证，并确保有DigiCert Global Root G2根证书； 新的 G2 根体系采用更高安全性的 SHA256 签名算法，且依然兼容当前主流的操作系统和移动设备，主流环境兼容情况如下： [图片] 对应的根证书文件请参考： Baltimore CyberTrust Root：Download PEM、Download DER/CRT Digicert Global Root CA：Download PEM 、Download DER/CRT Digicert Global Root G2：Download PEM、Download DER/CRT 2. 商户须知 商户需确认与微信支付对接的系统或终端设备可兼容新的服务器证书，并参考“验证指引”章节的方法，在2024年8月5日0:00日之前完成验证： 如果验证结果正常，商户不需要做其他任何事情 如果验证结果异常，商户需要修改相关的系统实现或配置，且需最晚于2024年8月5日0:00之前完成修正，否则商户的业务系统与微信支付系统之间将不能正常进行HTTPS通讯，将影响业务正常运行。 商户在验证和修正过程中遇到问题，可在证书与密钥专区发帖咨询，我们会有专人进行解答回复。 3. 验证指引 验证方式：绑定host，请求已部署新证书的微信支付服务器 商户可通过修改操作系统的hosts文件来绑定IP，例如，可在hosts文件中新增一行如下内容，实现将域名"api.mch.weixin.qq.com"绑定到新证书环境： 43.142.224.50 api.mch.weixin.qq.com 在linux系统下，hosts文件的完整路径为"/etc/hosts"，在Windows系统下，hosts文件的完整路径为"C:\Windows\System32\drivers\etc\hosts"。 商户应根据当前实际对接使用的域名来修改hosts文件配置，已部署新服务器证书的验证环境host和IP对应关系如下： [图片] 注意： 1. host环境可以访问的接口与正式环境完全一致，且真实生效，被视为生产正式业务。在验证之前，请充分评估对贵司业务系统以及业务的影响; 2. 验证完成后，请及时恢复服务器上的host配置，微信支付服务器证书更新完成后，此处使用的IP会被关停; 3. 需要用跟生产环境相同的操作系统、执行环境、开发语言及程序逻辑进行验证。使用curl等命令行工具验证成功，并不代表你的系统支持了新的服务器证书; 4. 逐一验证所有正在使用的微信支付接口，如果均能正常使用，说明你的系统支持微信支付新的服务器证书。反之，则需要根据修正指引排查问题并修正。 4. 修正指引 大部分情况下，验证失败是以下两种情况导致的： 情况一：程序中指定了根证书，但是指定的根证书中仅包含了旧的G1根证书； 情况二：服务器上没有部署新的G2根证书。 可通过以下两个方案修正: 方案一：删除指定根证书的代码。当程序中不指定根证书时，会使用系统自带的根证书。绝大部分系统中已内置了新的G2根证书，所以删除指定根证书的代码，不会影响到你的现有业务 方案二：更新根证书。往truststore或者根证书信任文件中追加新的G2根证书（注意：追加新的根证书时，需要保留老的G1根证书） 推荐使用“方案一”来修正，该方案的兼容性更好。原因是：新的G2根证书将于 2029年4月15日不再被Mozilla信任，到时候同样要更换新的根证书。使用方案一修复的话，你的系统中很可能已内置了后续需更换使用的根证书，从而不受影响。如果使用方案二进行修复的话，在 2029年4月15日仍可能需安装新的根证书。 下面介绍各种开发语言可能碰到的问题及解决方法： JAVA常见错误： [代码]javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target [代码] 可能原因：代码中设置了[代码]javax.net.ssl.trustStore[代码]， 可以在代码中搜索关键字[代码]trustStore[代码]或者[代码]TrustManager[代码]来确认。 解决方法： 方法一：删除掉指定[代码]javax.net.ssl.trustStore[代码]的代码 方法二：安装新的根证书, 往指定的[代码]trustStore[代码]中添加新的根证书。操作命令：keytool -importcert -keystore cacerts -storepass changeit -noprompt -file ./DigiCertGlobalRootG2.crt -alias digicertglobalrootg2 C++常见错误： [代码]cURL error 60: SSL certificate: unable to get local issuer certificate. CURLE_SSL_CACERT (60) peer certificate cannot be authenticated with known CA certificates. [代码] 可能原因：代码中设置了[代码]CURLOPT_CAINFO[代码]， 可以在代码中搜索关键字[代码]CURLOPT_CAINFO[代码]来确认。 解决方法： 方法一：删除掉[代码]curl_easy_setopt(pCurl,CURLOPT_CAINFO,"./rootca.pem");[代码]相关的代码 方法二：更新rootca.pem，用libcurl官网最新的替换即可 PHP常见错误： [代码]cURL error 60: SSL certificate: unable to get local issuer certificate. CURLE_SSL_CACERT (60) peer certificate cannot be authenticated with known CA certificates. [代码] 可能原因：使用libcurl时设置了[代码]CURLOPT_CAINFO[代码]，可以在代码中搜索关键字[代码]CURLOPT_CAINFO[代码]来确认。 解决方法： 方法一：删除掉类似[代码]curl_setopt(pCurl,CURLOPT_CAINFO,"./rootca.pem");[代码]的代码 方法二：更新rootca.pem，用libcurl官网最新的替换即可 C#常见错误： [代码]RemoteCertificateValidationCallback[代码]设置的回调函数返回[代码]false[代码] 可能原因：操作系统中没有新的根CA 解决方法：安装新的根证书 Python常见错误： [代码]SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581) [代码] 可能原因：代码中用[代码]verify[代码]指定了根证书文件，可以在代码中搜索关键字“verify”来确认。类似的代码如： [代码]response = requests.post( "https://api.mch.weixin.qq.com/secapi/pay/refund"， verify="./rootca.pem", …… ); [代码] 解决方法： 方法一：删除[代码]verify[代码]参数 方法二：更新rootca.pem，用libcurl官网最新的替换即可 go常见错误： [代码]x509: certificate signed by unknown authority . [代码] 可能原因：发起https时， 用[代码]RootCAs[代码]指定了根证书文件，可以在代码中搜索关键字[代码]RootCAs[代码]来确认。类似的代码如： [代码]roots := x509.NewCertPool() roots.AppendCertsFromPEM([]byte(rootPEM)) tr := &http.Transport{ TLSClientConfig: &tls.Config{RootCAs: roots}， } client := &http.Client{Transport: tr} [代码] 解决方法： 方法一：删除配置项[代码]RootCAs[代码] 方法二：更新rootca.pem，用libcurl官网最新的替换即可 Ruby常见错误： [代码]SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed [代码] 可能原因：发起https时， 用[代码]ssl_ca_file[代码]或者[代码]cert_store[代码]指定了根证书文件，可以在代码中搜索关键字[代码]ssl_ca_file[代码] 或者[代码]cert_store[代码]来确认。类似的代码如： [代码]response = RestClient::Resource.new( "https://api.mch.weixin.qq.com/secapi/pay/refund"， :ssl_client_cert => OpenSSL::X509::Certificate.new(File.read("./apiclient_cert.pem "))， :ssl_client_key => OpenSSL::PKey::RSA.new(File.read("./apiclient_key.pem "))， :ssl_ca_file => "./rootca.pem"， :verify_ssl=>OpenSSL::SSL::VERIFY_PEER).post(data); [代码] 或者 [代码] sock.cert_store.add_path('/usr/lib/ssl/certs/weixin') sock.cert_store.add_file('/usr/lib/ssl/certs/weixin/rootca.pem') [代码] 解决方法： 方法一：删除[代码]ssl_ca_file[代码]及[代码]cert_store[代码]指定的参数 方法二：更新rootca.pem，用libcurl官网最新的替换即可 NodeJs常见错误： [代码]Caught exception: Error: CERT_UNTRUSTED [代码] 可能原因：代码中用[代码]ca[代码]指定了根证书文件。 可以在代码中搜索关键字[代码]ca[代码]或者[代码]rootca[代码]来确认。类似的代码如： [代码]const options = { hostname: api.mch.weixin.qq.com ', pfx: await readFile('./apiclient_cert.p12'), ca: await readFile('./rootca.pem'), }; const req = https.request(options, (res) => { …… [代码] 解决方法： 方法一：删除[代码]ca[代码]指定的参数 方法二：更新rootca.pem，用libcurl官网最新的替换即可 其它语言请参考对应的TLS/SSL库相关手册。 5. 常见问题 Q1：什么是服务器证书？ A：服务器证书通常又叫“SSL证书”、“HTTPS证书”，它由权威CA机构颁发，用于对网站进行身份鉴定，并使客户端与网站之间通过TLS/SSL协议建立起安全传输通道。微信支付的服务器证书是由权威机构DigiCert颁发，商户调用微信支付API时，能通过该证书来认证微信支付的身份。 Q2：什么是根证书？ A：根证书是权威CA机构给自己颁发的证书，是信任链的起始点，是证书颁发机构（CA）与用户建立信任关系的基础。操作系统、浏览器、TLS/SSL开发库通常随软件发行包预置其信任的权威机构的根证书。 Q3：根证书和API证书是同一个吗？ A：不是，两者没有关系。“根证书”是用来校验微信支付的域名及服务器的真实性， 通常内置在操作系统或者执行环境（如JRE等）中;“API证书”是用来证实商户身份的，通常在调用微信支付v2的出资金类接口（如：退款、企业红包、企业付款等）或v3接口时，才会使用到API证书。 Q4：微信支付为什么要更换服务器证书？ A：根证书存在有效期，根证书到期后无法继续被用来校验服务器证书。 因此，微信支付跟权威机构（CA）申请了新的服务器证书。避免在老的根证书过期后，商户调用微信支付API时出现问题。 Q5：微信支付更换服务器证书，需要商户配合做哪些事情？ A：需要商户的开发技术人员做以下事情： 验证你的系统是否兼容微信支付新的服务器证书。 若支持的话，不需要做任何操作。若不支持，需要参考修正指引排查原因并修正。 注意： 商户按指引进行验证或安装新的根证书, 不会产生任何费用； 商户平台的API证书也不需要更换； 商户正在使用的其它https证书不需要更换或者升级。 Q6：商户如何核实服务器上是否已内置了G2根证书？ A：以Linux系统为例。Linux系统信任根证书库的保存位置因发行版本不同而有所差异：Debian/Ubuntu：/etc/ssl/certs/ca-certificates.crt CentOS/RHEL/Fedora/TencentOS：/etc/pki/tls/certs/ca-bundle.crt 商户可以使用以下命令来核实系统是否已内置了G2根证书： [代码]grep "DigiCert Global Root" /etc/pki/tls/certs/ca-bundle.crt # DigiCert Global Root CA # DigiCert Global Root G2 [代码] 备注：示例显示系统已内置了G1和G2根证书 Q7：微信支付更换证书前，可以提前安装根CA证书吗？ A：必须提前安装，且建议在2024年8月5日0:00之前提前安装。因为从2024年8月5日0:00开始，微信支付会在生产环境逐步灰度启用新服务器证书，以校验商户的系统是否兼容新证书。微信支付在更换新证书的过程中，会同时使用新老两个服务器证书，商户要能正常处理这种情况。因此，商户的服务器上需要包含新老两个根证书。 Q8：商户需在什么时候完成验证和修正？不验证会有什么影响？ A：商户应在2024年8月5日0:00之前完成验证和修正。如果商户侧系统的实现方式已能兼容新的服务器证书，那么不会影响业务；如果商户侧系统的实现方式不能兼容新的服务器证书，那么会导致商户的系统与微信支付的系统不能正常交互，影响业务。 Q9：如果商户无法按时完成兼容性修正，在微信支付灰度新证书时遇到异常应如何处理？ A：如果商户的系统经验证是不能兼容新证书的，商户应在2024年8月5日0:00之前完成修正。如果无法按时完成修正，我们可提供仍使用旧证书的临时环境，商户可通过host绑定IP的方式使用，以临时规避证书更换产生的影响。请务必在2024年11月30日0:00之前完成系统修正，并取消绑定临时环境IP，恢复以正常的方式对接微信支付的生产正式环境。 临时环境host和IP对应关系如下： [图片] 6. 特别提醒 为提前发现商户“是否会受到证书更换的影响？”“有没有升级完根证书？”，微信支付将于2024年8月5日0:00开始，把商户的部分请求转发到部署了新证书的服务器上，并逐步提升灰度比例。当商户不支持新的服务器证书时，会出现SSL相关的错误，通常情况下重试即可恢复； 根证书升级仅跟服务器和应用程序相关，与商户号没关系。只要在同一台服务器升级完成后，该服务器上使用的所有商户号都可以正常使用的； 如果你是通过代理服务器向微信支付发起请求的话，那么需要修改代理服务器的配置。 7. 联系我们 如果商户在验证或者修正问题的过程中遇到困难，可在证书与密钥专区发帖咨询，我们会有专人进行解答回复。 8. 附录 DigiCert 原文公告：DIGICERT ROOT AND INTERMEDIATE CA CERTIFICATE UPDATES 2023

各位开发者： 大家下午好。 现有“小程序跳转小程序”功能调整及国庆审核安排通知如下，请大家仔细阅读。 一、“小程序跳转小程序”功能调整 我们始终坚信，开放与合作才能创造更大的价值。为此，我们提供了“小程序跳转小程序”的能力，让小程序之间也能信息互通，而不至于成为一个个孤岛。目前，通过绑定至同一个公众号，两个小程序就能便捷地互相访问，方便用户使用更多服务。 随着小程序间连接规模的不断增长，产生了很多优秀的合作场景，但是也陆续暴露出一些问题。 如很多中长尾的小程序缺少合作沟通渠道，而寻求公众号绑定的门槛较高；部分开发者利用“小程序跳转小程序”的便捷性，在打开页面时就自动跳转其他小程序，给用户的正常使用带来困扰；个别开发者利用该功能进行流量互导，影响小程序生态的健康。 为此，我们将尽快弥补该功能设计上的缺陷，调整相关规则。 具体措施如下： 1、需要用户触发跳转 即日起，若用户未点击小程序页面任意位置，则开发者将无法调用 wx.navigateToMiniProgram 接口自动跳转至其他小程序。 2、需要用户确认跳转 在跳转至其他小程序前，将统一增加弹窗，询问是否跳转，用户确认后才可以跳转其他小程序。该功能预计10月中旬发布。 3、源小程序与目标小程序不再需要绑定至同一个公众号 小程序可以跳转至任意其他小程序，无需任何关联或绑定。 4、每个小程序可跳转的其他小程序数量限制为不超过10个 指定日期后，开发者提交新版小程序代码时，如使用了跳转其他小程序功能，则需要在代码配置中声明将要跳转的小程序名单，限定不超过10个，否则将无法通过审核。该名单可在发布新版时更新，不支持动态修改。对于未更新版本的小程序，届时将由微信统一计数并限制，跳转的不同小程序数量超过10个后，将无法打开更多不同小程序。 本次调整涉及：wx.navigateToMiniProgram 接口及 navigator组件。详细开发文档及开发者工具，将于10月中旬发布，请开发者及时关注并做好适配。 全部策略预计于10月中下旬正式生效。 二、国庆假期审核安排通知 此外，有很多开发者询问小程序审核安排的情况。在国庆放假期间，小程序上架审核及名称、类目审核照常。大家可以正常提审小程序。   微信团队 2018.09.30

您好，该问题需要开通授权，具体的授权方法可参考以下步骤: 1、打开微信商户平台 2、点击【产品中心】 3、点击【我授权的产品】查看是否授权 4、未授权的情况请联系服务商去发起授权

为了能让C端用户更快速直接了解小程序的功能及内容，以及基于部分行业的法律法规、平台管理的需要，小程序提供的服务需要与小程序所选的类目一致。 一、类目的选择 （1）类目根据主体的不同，开放范围分为个人、组织、境外。 （2）基于法律法规、平台管理的需要，部分类目需要提交相关的资质并经过审核后，才能申请成功。无资质要求的类目选择后即刻生效。 （3）建议开发者根据小程序自身服务内容对照类目适用范围申请相应的类目，以避免后期提交代码审核/小程序上架后出现类目不符等问题被驳回或按违规处理。 （4）小程序类目对应资质、部分示例模板等内容详情可参考：点击查看。 二、小程序类目配置指引 （1）初始化类目配置介绍： 登录【微信公众平台】 ->【点击立即注册】 ->【选择账号类型：小程序进入注册详情页】 ->【填写账号信息，点击注册】 ->【点击登录邮箱，进行账号激活】 ->【激活后进行用户信息登记】 ->【小程序发布流程】 ->【小程序类目，点击去补充，添加类目】 ->【提交】 [图片] [图片] [图片] [图片] [图片] [图片] [图片] [图片] （2）小程序类目后台配置介绍： 登录【微信公众平台】 ->【小程序发布流程】 ->【小程序类目，点击查看详情】 ->【选择添加服务类目并上传类目资质】 ->【提交】 [图片] [图片] [图片] 三、提前准备小程序类目资质 小程序不同类目对应的资质不同，建议开发者可根据微信开放的“小程序开放的服务类目”表查看对应资质，并提前做好申请相关资质准备，且资质需在有效期内，避免提交类目审核时因资质不符或过期等情况被驳回。 四、类目审核常见问题 1.一个小程序可选 5个 服务类目，且一个月有 5次 修改类目机会； 2.为满足部分开发者业务拓展的诉求，小程序类目已达5个且满足一定条件的账号可以申请【更多类目】。 更多类目申请条件（同时满足）： （1）小程序的5个类目中至少有1个资质类目。类目资质可见开放的服务类目表； （2）小程序近7天每天访问人数100人及以上； （3）小程序近3个月无违规行为； （4）本月仍有添加服务类目的次数。 申请方法：登录【微信公众平台小程序】 ->【小程序发布流程】 ->【小程序类目，点击查看详情】 ->【申请更多类目】 ->【提交】 [图片] 3.类目审核时长：一般情况为1 - 7天，如出现审核量大、内容复杂等特殊情况可能延长；如有紧急申请需求，且有加急额度情况下，在选择需提交资质的类目时，可同时勾选【审核加急】按钮，详情参考：【小程序类目审核加急通道开放】 4.部分常见驳回原因： 情况1： 提交资质主体与小程序注册主体不一致 案例：小程序（主体为123）申请【医疗服务-其他私立医疗机构】类目，提交资质主体为345，即为主体不一致 建议：以有资质的主体申请小程序 或 用小程序主体申请相关资质 情况2：提交资质已过期 案例：小程序申请【医疗服务-其他私立医疗机构】类目，提交《医疗执业许可证》，许可有效期为2016.09.12，即为过期 建议：提交许可资质在有效期内且有效期大于3个月及以上 情况3：提交资质模糊 案例：小程序申请【社交-社区/论坛】类目，提交的《非经营性互联网信息服务备案核准》资质模糊，审核无法辨别 建议：请确保提交资质清晰，可供审核辨别 情况4：提交虚假资质 案例：小程序（主体为123）申请【社交-社区/论坛】类目，提交主体一致的《非经营性互联网信息服务备案核准》资质，审核人员经可信渠道核实其资质主体为456，将判断小程序提交虚假资质 建议：以有资质的主体申请小程序 或 用小程序主体申请相关资质 温馨提醒： 审核中如发现小程序提交虚假资质，平台将视违规情节采取限制、甚至停止提供相关功能服务等措施，如涉及违法行为，可能追究其民事、刑事等相关法律责任，请各位开发者勿在“危险”的边缘试探哦~

为提高微信开放平台生态安全性，针对小程序开发过程中的安全问题，如代码易被反编译，核心业务逻辑被破译，算法易被二次打包等，导致小程序存在被破解、核心代码被盗取的风险，平台在微信开发者工具上线了代码加固功能，协助开发者保护小程序安全。 一、功能介绍 小程序代码加固是提供给开发者对小程序前端代码进行加密的功能，以防止代码暴露。该功能可将 JavaScript 文件传递给加密工具，从而实现字符串加密、属性加密、调用转换、代码混淆等多项保护措施，提高攻击者阅读前端代码逻辑的难度。 二、解决方案 微信开放平台通过在微信开发者工具中提供插件的方式，以便开发者进行功能的使用。同时还提供了Sourcemap代码加固调试工具，来帮助开发者对于加固后的文件进行错误分析。 三、功能使用 1、首先需在微信开发者工具选择代码加固插件进行安装； 2、选择需要加固的文件并进行配置操作，建议加固小程序中的敏感数据信息、核心算法逻辑、关键执行路径、接口（签名算法、协议、密钥等）。  另：界面操作和渲染、引用的第三方开源库等非必要安全保护内容可不进行加固，避免过多影响小程序体积及性能。 3、最后加固成功后可进行后续页面的预览，具体使用说明详见 功能介绍文档。 四、常见问题 Q1: 加固后显示编译结果失败？ A1: 表示所加固的小程序内容，在小程序编译结果中没有对应的代码，所以导致替换失败，可以根据失败的提示信息，进行具体排查 [图片] Q2: 如果想一次性批量进行代码加固，应该如何操作呢？A2: 若需要批量进行代码加固，可直接修改[代码]code_obfuscation_config.json[代码]中的[代码]configs[代码]字段即可 [图片] 代码示例如下： [图片] Q3: 使用 Sourcemap 代码加固调试时，为什么查找不到报错路径？A3: srcMiniprogramRoot目录下不存在该报错文件所对应的源文件 [图片] Q4: 代码加固后会对产品性能有影响吗？A4: 产品性能影响与代码加固的内容、大小和数量有关，可能会影响代码体积，产品初始化耗时和执行速度，可通过 性能说明文档 作进一步了解。 如有其他相关疑问，欢迎随时参与社区讨论。

最近开发了一个小程序前端开发前端和后台花了1个多月时间开发，结果被人轻松的把微信小程序前端代码破解出来。而且完整一个字不差截图给我看了。 小程序是前后端都分离的，如果后端不作验证，别人把你的小程序前端扒了接口也暴露了，随便可以复制你的前端去换成自己appid上线后调你的接口。这显然是不安全的。 在想为什么微信官方不限制指定appid才能调用指定域名接口。这样接口才是安全的。 最后找了一圈，微信开发者工具里只能对前端代码进行混淆加固，只能做到这步，让人破解出来后 看不懂逻辑，但还是一样能破解出来。只能做到基础的保护作用。 微信小程序演示： [图片] 目前按官方想方法： 微信代码加固方法：打开微信开发者工具，在菜单栏选择"工具-插件-编辑器扩展"或"设置-扩展设置-编辑器扩展"，找到 “代码加固” 点击"获取"进行安装。安装成功后，即可使用该插件功能。右键js文件加固。 [图片] 目前此方法只能是对js加固混淆，wxml 样式等没法加密，人家要偷还是一样能随便反编译出来。 请教大佬们微信小程序如何做好加密？微信官方有没有指定小程序访问接口？后端接口如何做安全防护，不给别人随便调用？否则别人知道你的api地址就可以随便用了

[图片][图片][图片][图片][图片][图片][图片][图片][图片] [图片] 微信支付面向商户推出了“安全医生”服务， 免费为商户使用微信支付的网站进行全面诊断， 并提供专业诊断说明和修复建议， 为商户资金安全保驾护航。 完全免费：本服务不收取任何费用，请放心使用。 持续监控：周期性自动检测系统，保证漏洞被及时发现。 安全放心：安全检测不会对商户应用系统造成影响。 详情可参考👉开通指引👈 更多安全案例及文章详见：商户安全文章专区

什么内容或服务的小程序需要选择公益相关类目？ [图片] 1、公益慈善：小程涉及提供虚拟众筹（筹钱、股权）服务，需选择公益-公益慈善类目 所需资质（二选一）： （1）民政部《基金会法人登记证书》 （2）《慈善组织公开募捐资质证书》 案例：如下图小程序涉及公开为贫困学生筹集助学款，需选择公益-公益慈善类目 [图片] 2、基金会：小程序涉及爱心用户提供公益捐赠、献爱心的通道，以从事公益事业为目的非营利性组织需选择公益-基金会类目 所需资质：民政部《基金会法人登记证书》 案例：下图小程序涉及为贫困听障儿童提供公益捐款渠道，需选择公益-基金会类目 [图片]

appid:wx8ca60bc4d3414a31; 今天审核，突然提示：小程序内的支付请选择官方的接口（https://pay.weixin.qq.com/wiki/doc/api/wxa/wxa_api.php?chapter=7_3&index=1）接入支付方式。我想问下，到底是微信支付本身的api我使用错了，还是说不给使用【支付宝支付】这种方式（我们只是返回一个支付宝链接，也不是直接打开支付宝app）；[图片]

现在小程序支付使用的是直连支付模式,就是在小程序后台绑定了一个商户号，现在因为要改动些业务，需要走服务商模式。如果走服务商模式原来的支付是否还能继续使用，因为就一个主体公司，不知道同一个主体开通服务商模式支付和现在使用的普通支付模式是否有冲突？？

同一个小程序想实现绑定多个不同主体的商户号，请教一下有没有个数限制？我看文档里描述的商户号是可以绑定50个appid，反过来同一小程序绑定商户号也是50个商户号吗？[图片]

代码审核环节，将会对小程序运营的内容与所选类目是否相符进行核实，当小程序涉及提供交通票务、旅游门票等信息展示、购买等服务，需要补充【生活服务-生活缴费】类目合规提审，否则代码审核环节将面临因类目不符被驳回情形。 场景示例与整改指引： 违规案例：小程序涉及提供水费、电费、电视费、煤气等生活费用缴纳服务 示例： [图片] 整改建议（2选1）： 1、补充选择：生活服务-生活缴费类目。 2、或自查代码，确保移除水费、电费、电视费、煤气等生活费用缴纳服务及相关分类标签。 本文档为生活服务-生活缴费类目的介绍说明，如存在上述问题应及时调整、修整，避免后续存在上诉问题审核失败；若仍有其他疑惑，可以通过以下咨询入口反馈： 1、微信开放社区-交流专区-小程序发帖咨询-提出问题-运营相关问题 2、代码审核驳回站内信通知-客服咨询入口（客服咨询入口目前正在测试开放阶段，若无客服入口，建议前往开放社区发帖咨询） 我们会根据新出现的问题、相关法律法规更新或产品运营的需要及时对其内容进行修改并更新，制定新的规则，保证微信用户的体验。建议开发者反复查看以便获得最新信息，定期了解更新情况。

为进一步保障小程序平台用户的合法权益，督促开发者向用户提供更好的服务，平台将针对小程序交易投诉处理规则做出以下更新： 1、和解环节开发者处理时效由72h改为48h，执行环节开发者处理时效由72h改为48h 2、和解环节开发者超时未处理，平台将判定开发者责任并做出相应处理，包括但不限于采取扣除保证金、先行垫付、扣减交易体验分等措施。 该时效调整将在2024年3月25日正式生效，请开发者及时关注。 一、一、交易类纠纷处理通知机制 1、为便于小程序开发者及时获知小程序交易投诉情况，平台将于每天早上10:00向小程序的管理员及运营者推送通知，通知内容为截至前一天24时该小程序账号内待开发者处理的投诉单详情。 2、通知查看路径： 1）小程序管理后台：右上角「通知」查询通知记录； [图片] 2）微信移动端：通知下发给小程序管理员与运营者，可搜索「微信公众平台」查看通知记录。 [图片] 二、二、交易类投诉处理操作指引 1、登陆小程序管理后台并核实投诉 登录小程序管理后台—功能—交易保障—交易投诉；查看待处理的投诉单，并尽快完成投诉单详情的核实与处理。 [图片] 2、和解环节：同意和解/拒绝和解 核实投诉后，若同意与用户和解，请在时效内上传与用户的沟通说明、物流信息或者退款凭证等，平台将推送和解详情给用户。 核实投诉后，若双方未达成和解，请选择拒绝和解并上传相关凭证，平台将推送不和解详情给用户。 若开发者未在处理时效内作任何处理，纠纷单将自动流转至平台介入处理状态，平台将判定开发者责任并做出相应处理，包括但不限于平台先行垫付，扣除开发者保证金，扣减交易体验分等措施。 [图片] [图片] 注：开发者和解时效为72h。选择同意和解或拒绝和解后，用户会收到确认投诉处理结果的通知，若用户认可开发者的处理结果，投诉将完结；若不同意，用户可申请平台客服协助处理。（2024年3月25日后发起的投诉单和解时效更改为48h） 3、平台处理环节：下发举证&判定责任 若用户不认可开发者投诉处理结果并申请平台介入，平台将根据现有纠纷凭证是否有效，要求开发者/用户补充相关凭证；若平台要求开发者补充纠纷凭证，投诉单状态将流转至【待开发者补充凭证】，处理时效为48h（特殊场景为24h），请务必如实填写并上传沟通说明、物流信息或退款凭证等信息；开发者/用户补充凭证后，平台将根据已有材料与凭证进行判责。 [图片] [图片] 4、开发者执行环节：上传处理凭证 若平台判为开发者责任，投诉单状态流转为【待开发者上传处理凭证】，处理时效为72h（特殊场景为48h），请尽快提交微信支付退款单号、交易流水、转账单号或物流单号等凭证，供平台核实是否已执行平台判责。（2024年3月25日后发起的投诉单处理时效更改为48h） [图片] [图片] 5、平台核实环节 若平台根据开发者上传的处理凭证判断开发者已执行平台判责，该投诉单将完结； 若开发者上传的处理凭证信息不准确，平台无法判断其已执行平台判责/超时未上传处理凭证，平台将根据实际情况对开发者进行交易体验分的扣减，对用户进行先行赔付等措施。 6、商家申诉环节 若平台判定商家责任后，开发者不认可平台的判责结果，可在投诉单完结后的72h内发起申诉，平台会根据申诉环节上传的相关材料进行申诉判定；每个投诉单仅支持一次申诉，申诉超时/申诉失败后不支持再次发起申诉。 若申诉成功，则开发者无需按照《微信小程序交易服务违规管理规则》中的第三章违规处理措施缴纳违约金； 若申诉失败，则开发者仍需按照《微信小程序交易服务违规管理规则》中的第三章违规处理措施缴纳违约金。 [图片] [图片] 三、小程序实物交易纠纷处理规则 平台介入处理争议时，开发者应遵守以下约定： 开发者及用户就订单产生交易争议时，双方可以选择自行协商。如用户向平台提起交易投诉，双方协商未果或开发者未作处理，平台有权根据本规则及相关法律法规介入对争议的处理。 当开发者因自身系统、管理、人力等原因出现异常大量维权或舆情事件，且开发者不具备及时处理能力，为保障双方交易安全，平台可主动介入处理。 平台处理交易争议期间，开发者及用户应当按照平台下发的站内信、模版消息、短信、电话或邮件通知及时提供凭证。 平台处理争议期间，若任何一方无正当理由，未按照举证要求提供凭证的，平台有权按照实际收集到的凭证做出处理。 平台做出判责后，开发者应当按照要求及时履行相应义务。 如开发者行为违反相关法律法规或平台规则，因此而可能产生的用户损失或额外赔偿费用将由开发者自行承担。 详情可查看微信小程序实物交易争议处理规则 四、常见问题 1、用户交易投诉的入口在哪？ 小程序—页面右上角“…”—反馈与投诉—交易投诉 [图片] 2、如何更改通知接收者？ 目前，交易投诉待处理通知会发送给当前小程序的管理员及运营者。若希望取消或者增加推送成员，可登录微信公众平台­—管理—成员管理，更换或添加管理员及运营者。 [图片] 3、上传凭证需要注意什么？如果超时未处理怎么办？ 上传前务必确保提交的证据材料的真实性、完整性、及时性和准确性；平台处理争议期间，请按照举证要求的内容提供凭证。 为保障用户的体验，请在规定时间内完成核实和处理；否则，开发者应承担超时未处理、举证超时的后果，平台有权按照实际收集到的凭证做出判责，同时根据平台规则对开发者进行扣减交易体验分等措施。 4、除了在小程序管理后台处理投诉，是否有其他方式处理交易投诉？ 若开发者在网页端登陆小程序管理后台处理投诉存在困难，平台提供移动端工作台—小程序助手处理投诉，投诉处理流程与PC端一致；同时平台提供线上接口，开发者可通过接口接入自己内部系统处理投诉。 移动端工作台：微信主页搜索「小程序助手」—登陆小程序—管理功能—交易投诉 [图片] 接口文档：可点击查看交易投诉处理接口文档：投诉信息推送 | 微信开放文档 5、交易体验分是什么？为什么被扣分了？扣分后会受到什么处罚？ 为保障小程序平台用户的合法权益，平台将对开发者在其小程序的违规行为进行判定，根据违规行为的严重程度对该小程序扣减不同分值的交易体验分，并在小程序交易体验分扣减至相应节点时，对开发者采取相应违规处理措施。 具体规则与案例解析可点击《微信小程序交易服务违规管理规则》、微信小程序交易体验分常见问题指引查看。 6、申诉需要提供哪些凭证才算有效凭证？哪类申诉不支持通过？ 开发者需针对用户投诉问题的有效反驳凭证，建议同时提供相关图片进行佐证。 开发者在投诉单处理环节中，包含和解环节/举证环节/商家执行环节，若任意一环节存在未回复或以话术、无效字符回复的情况，不予申诉通过；用户投诉开发者服务态度问题，被平台判定问题属实，不予申诉通过；用户投诉开发者服务意愿类问题，如强制退款、或未按订单页面承诺进行服务履约（如配送超时，商品无货强制退款等），被平台判定投诉属实，不予申诉通过。 7、为什么要收取违约金？ 当开发者存在违反《微信小程序交易服务违规管理规则》的行为，需要按规则3.1缴纳违约金；开发者有申诉的权利，可在投诉单完结后的72h内发起申诉，平台要求缴纳的违约金来源为"已过申诉时效或平台认定申诉不成立的违规投诉单"。 8、不缴纳是否有限制措施？ 若开发者未按期足额支付违约金的，平台将采取限制小程序搜索、限制支付能力等处理措施。请参考《微信小程序交易服务违规管理规则》的违规行为及对应处理措施。 9、违约金是否可以开具发票？ 小程序mp后台（mp.weixin.qq.com-功能-交易保障-消费者资金保障-违约金）模块，支持对单笔缴纳流水进行发票开具，请开发者仔细阅读开票的注意事项并填写准确信息。

a:官方的人脸核身接口是否有使用次数限制？接口暂无上限要求，普通用户人脸识别每天次数是在3-50次不等，针对部分高安全级别的业务的要求和配置，也会降低限制次数。b:官方的人脸核身接口是否收费，后台显示收费调用次数是什么作用？官方的人脸核身接口目前免费，后续是否收费请留意官方渠道。 人脸核身是有成本的，这里展示的是我们付费成本，也是希望告诉用户，我们协助承担了成本。 c:为什么人脸核身没有申请入口？人脸核身是有资质要求的，资质不符的暂时无法开通。具体请参考（注：一二级类目需完全符合）https://developers.weixin.qq.com/community/business/doc/000442d352c1202bd498ecb105c00d d:人脸识别返回90100|90105|90107|100102|90199|90101什么原因？ 这是客户端的错误，请求没到后台的，有几点建议： 1、确认摄像头等权限是授予了；2、杀掉微信重启试试；3、下载更新微信客户端版本 e:getimage接口返回48001，提示没权限？ 获取图片接口已经停止申请 f：小程序可以接入腾讯云的人脸核身吗？ 可以的 

一、能力背景 近年来，国家在医疗挂号、APP注册、快递收寄、客运、运营商等多领域规定，需要用户实名才可办理业务，预计后续也会有越来越多的此类法规。因此，微信参照公安部“互联网+”可信身份认证服务平台标准，依托腾讯公司及微信的生物识别技术，建立微信“实名实人信息校验能力” ，即通过人脸识别+权威源比对，校验用户实名信息和本人操作（简称微信人脸核身）。 目前接口限定主体及行业类目开放公测，提供给资质符合要求的业务方，在合适的业务场景内使用。目前仅支持持二代身份证的大陆居民。 由于人脸核身功能涉及到用户的敏感、隐私信息，因此调用此接口的小程序，需要满足一定的条件。即：小程序的主体以及类目，需要在限定的类目范围内，且与小程序的业务场景一致。开展的业务也需要是国家相关法规、政策规定的需要“实名办理”的相关业务（其他未在范围内的业务，则暂不支持）。 以下为接口接入及开发的详细内容。如开发中遇到任何疑问，可以点击此处通过社区反馈，将有工作人员跟进回复。 文档第四部分【再次获取核验结果api】，有助于提高业务方安全性，请务必接入！ 现阶段微信人脸核验能力，针对小程序，开放的主体类目范围包含： 小程序一级类目 小程序二级类目 小程序三级类目 使用人脸核验接口所需资质 物流服务 收件/派件 / 《快递业务经营许可证》 物流服务 货物运输 / 《道路运输经营许可证》（经营范围需含网络货运） 教育 学历教育（学校） / （2选1）：1、公立学校：由教育行政部门出具的审批设立证明 或 《事业单位法人证书》；2、私立学校：《民办学校办学许可证》与《民办非企业单位登记证书》 医疗 公立医疗机构 / 《医疗机构执业许可证》与《事业单位法人证书》 医疗 互联网医院 / 仅支持公立医疗机构互联网医院（2选1）：1、卫生健康部门的《设置医疗机构批准书》；2、 《医疗机构执业许可证》（范围均需含“互联网诊疗”或名称含“互联网医院”等相关内容 医疗服务 三级私立医疗机构 / 仅支持三级以上私立医疗机构，提供《医疗机构执业许可证》、《营业执照》及《医院等级证书》 政务民生 所有二级类目 / 仅支持政府/事业单位，提供《组织机构代码证》或《统一社会信用代码证》。 金融业 银行 / （2选1）：1、《金融许可证》； 2、《金融机构许可证》。 金融业 信托 / （2选1）：1、《金融许可证》； 2、《金融机构许可证》。 金融业 公募基金 / （4选1）：1、《经营证券期货业务许可证》且业务范围必须包含“基金”；2、《基金托管业务许可证》； 3、《基金销售业务资格证书》；4、《基金管理资格证书》。 金融业 证券/期货 / 《经营证券期货业务许可证》 金融业 保险 / （8选1）：1、《保险公司法人许可证》；2、《经营保险业务许可证》；3、《保险营销服务许可证》；4、《保险中介许可证》；5、《经营保险经纪业务许可证》；6、《经营保险公估业务许可证》或《经营保险公估业务备案》；7、《经营保险资产管理业务许可证》 ；8、《保险兼业代理业务许可证》。 金融业 消费金融 / 银监会核准开业的审批文件与《金融许可证》与《营业执照》。 金融业 非金融机构自营小额贷款 / 仅支持省金融办监管的网络小贷主体，同时提供：1、《小额贷款公司经营许可证》或《小额贷款机构经营许可证》或省金融办批准文件；2、申请主体资质承诺函。 金融业 汽车金融/金融租赁 / 仅支持汽车金融/金融租赁主体，同时提供：1、《营业执照》（公司名称包含“汽车金融” /“金融租赁”；营业范围包含“汽车金融”/“金融租赁”业务）；2、《金融许可证》或银保监会及其派出机构颁发的开业核准批复文件。 交通服务 网约车 快车/专车/其他网约车 （自营性网约车）提供《网络预约出租汽车经营许可证》。（网约车平台）提供与网约车公司的合作协议以及合作网约车公司的《网络预约出租汽车经营许可证》。 交通服务 航司服务 / 提供《公共航空运输企业经营许可证》 交通服务 机场服务 / 提供《民用机场使用许可证》或《运输机场使用许可证》 交通服务 公交/地铁 / 提供公交/地铁/交通卡公司《营业执照》 交通服务 水运 / （船企）提供《水路运输许可证》。（港口）提供《港口经营许可证》 交通服务 骑车 / 仅支持共享单车，提供共享单车公司《营业执照》 交通服务 火车/高铁/动车 / 仅支持铁路局/公司官方，提供铁路局/公司《营业执照》 交通服务 长途汽车 / （2选1）：1、《道路运输经营许可证》（经营范围需含客运）；2、官方指定联网售票平台（授权或协议或公开可查询文件）。 交通服务 租车 / 运营公司提供《备案证明》与对应公司《营业执照》，且营业执照中包含汽车租赁业务 交通服务 高速服务 / 仅支持ETC发行业务，（2选1）：1、事业单位主体，需提供《事业单位法人证书》；2、官方指定的发行单位（一发单位），需提供“官方授权或协议，或公开可查询的文件”； 生活服务 生活缴费 / （供电类）提供《电力业务许可证》与《营业执照》，且《营业执照》且经营范围含供电。（燃气类）提供《燃气经营许可证》与《营业执照》，且《营业执照》且经营范围含供气。（供水类）提供《卫生许可证》与《营业执照》。（供热类）提供《供热经营许可证》与《营业执照》，且《营业执照》且经营范围含供热。 IT科技 基础电信运营商 / （2选1）：1、基础电信运营商：提供《基础电信业务经营许可证》；2、运营商分/子公司：提供营业执照（含相关业务范围）。 IT科技 转售移动通信 / 仅支持虚拟运营商，提供《增值电信业务许可证》（业务种类需含通过转售方式提供移动通信业务） 旅游服务 住宿服务 / 仅支持酒店，提供《酒店业特种行业经营许可证》 旅游服务 旅游管理单位 / 仅支持政府/事业单位，提供《组织机构代码证》或《统一社会信用代码证》 商业服务 公证 / 仅支持公证处，提供《公证处执业许可证》或《事业单位法人证书》 社交 直播 / （2选1）：1、《信息网络传播视听节目许可证》；2、《网络文化经营许可证》(经营范围含网络表演）。 如对以上类目或资质有疑问，可点击参考小程序“非个人主体开放的服务类目”，详细了解小程序开放的服务类目及对应资质。 二、准备接入 （请在小程序发布后，再提交人脸核身接口申请） 满足第一节中描述的类目和主体的小程序，可申请微信人脸核验接口。目前微信人脸核身接口已改为线上自助申请方式，需按照如下图例指引，进行接口申请： 第一步：请通过mp.weixin.qq.com登录小程序账号在后台“功能-人脸核身”的路径，点击开通按钮—— [图片] 第二步：仔细查阅《人脸识别身份信息验证服务条款》后，点击“同意并下一步”—— [图片] 第三步：请正确填写服务信息，并上传该小程序类目下所要求的资质—— [图片] 第四步：请按照业务实际需求填写使用人脸接口的场景和用途—— [图片] 第五步：请完善测试信息和联系人—— [图片] 第六步：提交后请耐心等待1-3个工作日的审核期，审核结果将以站内信通知—— 如申请期间遇到问题，可联系腾讯工作邮箱 wx_city@tencent.com，将会有相关工作人员进一步指引。 三、接口文档： (一)接口描述 名称: wx.startFacialRecognitionVerify(OBJECT) 功能：请求进行基于生物识别的人脸核身 验证方式：在线验证 兼容版本： 一闪：android 微信7.0.22以上版本, iOS 微信7.0.18以上版本 建议在微信官网升级至最新版本 (二)参数说明 1、OBJECT参数说明： 参数 类型 必填 说明 name String 是 姓名 idCardNumber String 是 身份证号码 success Function 否 调用成功回调 fail Function 否 调用失败回调 complete Function 是 调用完成回调（成功或失败都会回调） 2、CALLBACK返回参数 参数 类型 说明 errMsg String 错误信息 errCode Number 错误码 verifyResult String 本次认证结果凭据，第三方可以选择根据这个凭据获取相关信息 注 1：传递用户姓名和身份证有两种方式 业务方没有用户实名信息，用户需要在前端填写身份证和姓名，那么前端直接通过jsapi 调用传递 name 和 idCardNumber。 业务方已经有用户实名信息，后台通过微信提供的 api（详情见文档后面“上传姓名身份证后台 api”）上传用户身份证姓名和身份证，api 返回 user_id_key 作为凭证传给前端，前端再调用 jsapi，用户姓名、身份证信息不需要经过前端，参数只需要传递 userIdKey。Tips：使用该功能需要小程序基础库版本号>=1.9.3。 3、回调结果说明 回调结果请参考以下释义： [图片] [图片] [图片] 4、示例代码 [图片] [图片] (三)上传用户姓名身份证的后台api 1、API说明 1.1说明 业务方上传用户姓名和身份证，获取用户凭证，把凭证给到前端通过 jsapi 调用。 Tips ：使用该功能需要小程序基础库版本号>=1.9.3。 1.2请求URL https://api.weixin.qq.com/cityservice/face/identify/getuseridkey?access_token={ac cess_token} 1.3请求方式 POST 2、请求数据格式 [代码]Json { "name" : “张三”, "id_card_number" : "452122xxxxxxx43215" } [代码] 请求示例 [代码]#!/bin/bash TOKEN='xxxxxxxxxxxx' URL='https://api.weixin.qq.com/cityservice/face/identify/getuseridkey' JSON='{ "name": "张三", "id_card_number": "452344xxxxxxxxxxxxx234"}' curl "${URL}?access_token=${TOKEN}" -d "${JSON}" [代码] 参数说明 json 字段 中文显示 是否必传 name 姓名 是 id_card_number 身份证号码 是 out_seq_no 业务方唯一流水号 否 3、返回数据 参数 类 型 说明 errcode int 错误码 errmsg string 错误信息 user_id_key string 用于后台交互表示用户姓名、身份证的凭证 expires_in uint32 user_id_key 有效期，过期需重新获取 [代码]{ "errcode" : 0, "errmsg" : "ok", "user_id_key" : "id_key_xxxx", "expires_in": 3600 } [代码] 4、后台消息推送 如果业务方传入out_seq_no，核身完成后会通过消息推送回调给业务方的服务器，如果回调业务方失败，会在5s尽力推送，超过5s不再推送。 参数说明 参数 类 型 说明 ToUserName string 小程序原始ID FromUserName string 事件消息openid CreateTime uint32 消息推送时间 MsgType string 消息类型 Event string 事件类型 openid string 核身用户的openid out_seq_no string 业务方唯一流水号 verify_result string 核身返回的加密key（凭据） 返回示例 [代码]{ "ToUserName": "gh_81fxxxxxxxx", "FromUserName": "oRRn15NUibBxxxxxxxxx", "CreateTime": 1703657835, "MsgType": "event", "Event": "face_identify", "openid": "oRRn15NUibBxxxxxxxxx", "out_seq_no": "test1234", "verify_result": "XXIzTtMqCxwOaawoE91-VNGAC3v1j9MP-5fZJxv0fYT4aGezzvYlUb-n6RWQa7XeJpQo0teKj8mGE4ZcRe1JI3GqzADBYORBu613rKjKAFfEXTXw_bu1bs7MnmPOpguS" } [代码] 四、再次获取核验结果api 此接口是前端完成人脸核身后，基于前端返回的凭据，通过后台api再次进行核验结果和身份信息的校验，有助于提高安全性，请务必接入！ 前端获取结果不可信，存在被篡改的风险，为了保障请求结果安全性，请务必对identify_ret、id_card_number_md5、name_utf8_md5字段进行校验！ (一)API说明 1、说明 人脸核身之后，开发者可以根据jsapi返回的verify_result向后台拉取当次认证的结果信息。 2、请求URL https://api.weixin.qq.com/cityservice/face/identify/getinfo?access_token={access_token} 3、请求方式 POST 4、请求格式 json (二)请求数据说明 1、请求 参数 类型 是否必填 描述 verify_result String 是 jsapi返回的加密key（凭据） 2、数据返回 HTTP 头如下 Date: Mon, 06 Feb 2017 08:12:58 GMT Content-Type: application/json; encoding=utf-8 Content-Length: 85 Connection: close json示例 [代码]{ "errcode" : 0, [代码] [代码]"errmsg" : "ok", "identify_ret" : 0, "identify_time" : 1486350357 "validate_data": "8593" [代码] [图片] (三)返回参数说明 1、返回参数 注：errcode和identify_ret同时为0，代表本次认证成功。 参数 类型 描述 errcode int 错误码, 0表示本次api调用成功 errmsg string 本次api调用的错误信息 identify_ret int 人脸核身最终认证结果 identify_time uint32 认证时间 validate_data string 用户读的数字（如是读数字） openid string 用户openid user_id_key string 用于后台交互表示用户姓名、身份证的凭证 finish_time uint32 认证结束时间 id_card_number_md5 string 身份证号的md5（最后一位X为大写） name_utf8_md5 string 姓名MD5 2、错误码对应信息 errcode 备注 84001 非法identity_id 84002 用户信息过期 84003 用户信息不存在 五、小程序辅助接口：检查设备是否支持人脸检测 1、接口名称 接 口 ：wx.checkIsSupportFacialRecognition(OBJECT) 功能：检查设备是否支持人脸检测 2、接口说明和使用 小程序调用该接口，可以检测当前手机设备是否具备支持人脸检测的能力，可与以上接口分开使用，为了用户体验，建议调用后对手机设备不支持的用户做对应功能处理。 3、接口说明和使用 01 OBJECT 参数说明： 参数 类型 是否必填 描述 success Function 否 调用成功回调 fail Function 否 调用失败回调 complete Function 是 调用完成回调（成功或失败都会回调） checkAliveType Number 否 人脸核验的交互方式，默认读数字（见表 2） 表 2：checkAliveType 的值和对应的解释： 参数 解释 2 先检查是否可以屏幕闪烁，不可以则自动为读数字 02 CALLBACK 返回参数 参数 类型 说明 errMsg Boolean 错误信息 errCode Number 错误码 03 回调结果说明 回调类型 ErrCode 说明 sucess 0 支持人脸采集 fail 10001 不支持人脸采集：设备没有前置摄像头 fail 10002 不支持人脸采集：没有下载到必要模型 fail 10003 不支持人脸采集：后台控制不支持 回调结果说明仅对Android生效，iOS不返回errcode。 04 示例代码 [图片] 六、安全性说明 为保障业务可用性以及安全性，请详细研读微信人脸核身接口相关基础说明及安全说明文档：https://docs.qq.com/doc/DTFB0YWFIdGV6amly 备注：如开发中遇到任何疑问，可以点击此处通过社区反馈，将有工作人员跟进回复。 七、案例展示及补充说明 安徽医科大学第二附属医院，微信人脸核验登录： 安徽医科大学第二附属医院，是三级甲等综合医院。其小程序为用户提供挂号、门诊费用、住院费用、检查报告、体检等医疗服务，同时也提供停车、餐饮等便民服务，是医疗小程序中完整的案例。 小程序使用了微信人脸核验能力作为登录的核验。满足医院管理要求，也满足国家对于实名就医的管理规则。 案例实现的截图效果如下： [图片] [图片] 针对近期少数小程序方面反馈的两类问题，也在本课程进行补充说明。 1、本接口的开放范围，即：可支持的主体类目，是否可以扩大？ 说明：基于本接口整体使用范围的评估、相关法规的参考、监管策略的理解执行等，暂时未立刻进行扩大开放范围的工作。 但我们会持续基于不同行业的法规、政策及监管要求等，逐一进行研究考量，以便确认如何扩大开放范围。 2、小程序如果涉及用户本人的生物特征采集，（如本人人脸照片、人脸视频），或涉及采集用户本人生物特征信息并开展人脸核验功能，则存在被驳回的情况？ 说明：近两年“人脸识别”技术在社会上掀起了热潮。人脸识别虽然作为摆脱“中间媒介”或“承载载体”的一种直接技术手段，解决了部分政务、交通、医疗、零售等证明“操作者是本人”的问题，但也因此，引入了新的更大的安全风险。 一是，虚假安全风险。 身份认证领域的安全三因素包括“我知道什么”、“我拥有什么”、“我的特征是什么”，通用的安全做法，是要双因素认证（2FA），人脸识别技术如仅凭“我的特征是什么”这一个因素，则容易被攻破或利用。表象给用户以安全的感觉，但实际并不能达到安全效果。 二是，信息泄漏的风险。 越来越多的组织或个人，在并非必需用户敏感信息、生物特征的情况下，采集并存储此类信息。在信息加密、传输、存储过程中，容易暴漏更多的网络节点，使得此类信息有更大的风险被网络黑客拦截、窃听、窃取，或直接被脱库。 三是，消除风险的难度大。 以往基于“中间媒介”或“承载载体”的方式，如出现丢失、被冒用、恶意盗用等风险，可以通过挂失、更换、使用新载体或新媒介等方式，快速排除一定的风险。C端主动，B端主动，都能解决一部分问题。但人脸识别做为更直接的方式，一旦出现冒用、盗用，受害者将面临更大的财产及人生安全风险，且C端用户更多时候无法主动消除风险。 基于以上问题风险，加之国家出台《网络安全法》、《用户隐私保护条例》等法律法规标准，网信办、公安部、工信部及市场监管总局等四部委发起的app获取隐私整治，结合平台安全、用户敏感隐私信息保护要求及监管，针对部分暂无相关法规或要求，需要采集或生物认证方式进行身份核验的，或以“追热点”或“尝鲜”为目的，采集用户生物特征或进行身份核验的，进行严格审核，必要时不予以支持。

关于高分账比例申请的渠道，可通过以下的流程进行咨询： 1、微信关注"腾讯客服"公众号，在公众号内进行提问或输入'人工'转人工解答 2、拨打微信支付服务热线（95017转2）

我司开发H5页面，需要调用微信支付功能，用户付款成功后，是否有语音播报功能接口可以调用？

文档地址：「请求分账（直连）」、「请求分账（服务商）」 Q1：调用请求分账接口返回”非分账订单不支持分账“是什么原因？ A1：请按照以下几点检查： 微信订单号填写错误，请检查确认统一下单时未上传分账标识（profit_sharing=Y）的订单，是不支持分账的 Q2：调用请求分账接口返回”分账金额不足“是什么原因？ A2：请按照以下几点检查： 该订单已全额退款，没有资金可以分账在微信支付中，实际收款之后微信支付会收取一定的结算手续费，在减去手续费后剩余的钱才能分账，详情可参考订单结算手续费说明该订单已解冻，已无分账资金（普通商户分账订单默认冻结期是30天; 电商分账订单默认冻结期是180天）超过订单剩余可分账金额或者该订单已无可分账金额，请检查确认（可调用查询订单待分账金额API确认剩余可分账金额） Q3：调用请求分账接口返回”分账接收方关系不存在，请检查参数中每个接收方的关系“是什么原因？ A3：未添加分账接收方，分账接收方在分账之前需要调用“添加分账接收方接口”添加，请添加接收方后再调用请求分账接口。 Q4：调用请求分账接口返回“分账金额超出最大分账比例”是什么原因？ A4：请检查分账的金额是否超出在商户平台设置的允许分账的最大比例，设置路径如下： 普通直连商户设置分账比例路径：登陆商户平台-产品中心-分账-分账管理比例普通服务商商户设置分账比例路径：需要特约商户可以登录商户平台-产品中心-授权的产品-分账授权中进行设置比例。电商收付通商户设置分账比例路径：登陆服务商商户平台-产品中心-我的工具箱-电商收付通-供应链分账设置里设置连锁品牌分账商户设置分账比例路径：登陆服务商平台-产品中心-合作工具箱-连锁品牌工具箱-品牌专区-品牌交易-品牌供应链分账-供应链分账管理设置 Q5：调用请求分账接口返回”无分账权限“是什么原因？ A5：请按照以下几点排查： 1、未开通分账权限，请开通后再调用分账接口，可参考开通指引 2、请求参数错误，服务商用了普通商户的开发文档提交参数，检查确认 服务商模式请求分账文档 普通商户分账文档 Q6：分账调用“添加分账接收方接口”返回：微信用户姓名与实名不一致 A6：请求中传了字段“个人姓名name”，该字段传了之后会校验用户实名是否正确，请填写正确的用户实名（查看用户实名认证路径：微信-我-服务-右上角三点-实名认证-姓名） Q7：分账调用“请求单次分账接口”返回：分账接收方列表格式错误 A7：receivers中的参数amount类型错误，amount类型是int，请检查确认 Q8：分账接收方类型包括哪些？ A8：有以下几个类型： MERCHANT_ID：商户ID PERSONAL_OPENID：个人openid（由父商户APPID转换得到）PERSONAL_SUB_OPENID: 个人sub_openid（由子商户APPID转换得到） Q9：分账调用“请求单次分账接口”，为什么不返回分账结果 A9：分账是异步的，需要调用“查询分账结果”接口查询确认 Q10：分账调用“请求分账接口”返回：订单处理中，请稍后重试 A10：请按照以下几点检查： 请在订单支付成功1分钟后再调用分账接口未结算的订单，请在结算后再调用分账接口请求分账。查看结算周期路径：超级管理员使用电脑登录商户平台（pay.weixin.qq.com），通过【账户中心】->【商户信息】->【结算信息】进行查看老资金流商户的订单，不支持分账（旧资金流流水介绍、新资金流流水介绍）商户开通了收支分离但手续费账户余额不足（手续费账户最低余额要求是100元以上，在充值手续费账户1小时后，订单会正常结算，即可正常调用分账接口） Q11：分账调用“请求分账接口”返回：分账接收方与原请求不一致 A11：商户分账单号填写错误，调用“请求分账接口”多次分账，要生成新的“商户分账单号”，不能使用已经分过账的商户分账单号 Q12：分账调用“请求单次分账接口” A12：请按照以下几点检查： 签名类型错误，分账接口签名类型目前只支持HMAC-SHA256普通商户的分账订单，请使用普通商户分账接口，不能使用服务商分账接口系统超时，请使用原参数尝试再次掉调用API Q13：调用分账接口是否有额外的手续费 A13：没有，商户的交易订单，平台会正常的收取结算手续费。商户使用分账功能没有额外的费用 Q14：分账调用“请求分账接口”返回：分账接收商户全称不匹配 A14：请按照以下几点检查： 分账接收商户全称填写错误，请填写正确的商户全称，商户全称对应进件接口中的字段“商户名称merchant_name”字段值没有加密，该字段值需要加密后上传，请正确加密后再提交。上传的中文全称乱码，请检查接口编码是否正确，接口需要使用UTF-8编码 Q15：分账调用“添加分账接收方接口”返回：账户不存在 ，请先点击充值 A15：账户未开通，请接收方商户在商户平台点击“充值”创建账户（商户平台-交易中心-充值） Q16：分账如果有退款怎么处理，是否可以回退？ A16：需注意以下几点： 已分出去的资金，在商户接收方同意的情况下，可以发起分账回退。（接收方可在“商户平台-交易中心-分账-分账接收设置”中开启同意分账回退） 更多分账订单退款逻辑，请查看文档说明 [图片]   Q17：分账调用“请求单次分账接口”返回：签名错误 A17：请按照以下几点检查： 使用签名检查工具校验签名算法是否有误确认秘钥是否有误（服务商模式使用服务商商户号秘钥，秘钥是在商户平台配置，如果同一商户号调用其它接口成功可排除是秘钥问题）确认接口实际的请求参数与生成签名原串的参数一致，不能增加或缺少参数（可通过打印签名原串进行排查）确认参数的大小写，参数名与接口文档一致签名原串的参数值使用原始值，不需要encode接口需要使用UTF-8编码 Q18：分账添加接收方接口，是在分账前添加一次，如果接收方无变化，后续是否还需要调用接口再添加 A18：是的，如果接收方没有变化，只需要添加一次即可 Q19：分账调用“查询分账结果接口”返回的分账单状态有几种 A19：有以下几点状态： ACCEPTED—受理成功 PROCESSING—处理中 FINISHED—处理完成 CLOSED—处理失败，已关单  Q20：在商户平台设置了分账动账通知url，为什么收不到通知 A20：请按照以下几点排查： 未设置动账通知url，该链接是通过商户平台【交易中心-分账接收设置】中配置的通知url，必须为https协议。如果链接无法访问，商户将无法接收到微信通知。必须为直接可访问的url，不能携带参数。示例：notify_url：https://pay.weixin.qq.com/wxpay/123456789商户未设置加密的密钥，请登录商户平台操作！请参考什么是APIv3密钥？如何设置？只有分账接收方才能收到分账动账通知，分账方是不会有通知的 Q21：分账调用“请求分账接口”返回：对同笔订单分账频率过高 A21：同笔订单多次分账频率是1秒1次，请降低频率后重试 Q22：分账后资金到可提现是否有中间状态 A22：没有中间状态 Q23：分账后的资金什么时候可提现 A23：分账后钱已经到商户的账户了，可以立刻提现 Q24：分账调用“完结分账接口”的作用是什么 A24: 调用该接口，可以将不需要进行分账的订单金额解冻给商户，解冻后的资金商户可自行发起提现 Q25：分账调用“分账回退接口”返回：参数不正确，请检查参数 A25：return_account与mch_id不能填写为相同的商户号，分账方与接收方商户号一致时，不需要回退 Q26：分账订单调用“申请退款接口”返回：申请退款金额大于剩余未分账金额，请等待分账完成后再试 A26：订单有过部分分账，退款金额不能大于剩余未分账金额，请调用“完结分账接口”解冻剩余资金后再发起退款 Q27：查询分账结果接口里面分账单状态（status）字段，当值为ACCEPTED时是表示分账成功了吗 A27：分账单的状态是表示分账单是否受理成功，并不代表分账是否成功。查看分账是否成功，需要调用查询分账结果接口，查看返回参数“分账接收方列表”里面的字段“分账结果result=SUCCESS”才是分账成功。 Q28：调用“添加分账接收方接口”一次可以添加多个接收方吗 A28：不可以，一次只能添加一个 Q29：请求分账接口返回：分账接收方不允许为分账出资方 A29：请按照以下几点检查： V2接口，“请求单次分账接口”分账接收方不允许为分账出资方，“请求多次分账接口”分账接收方可以为分账出资方V3接口，finish为true的情况，“请求分账接口”分账接收方不允许为分账出资方（这种场景，直接调完结分账API就好）。finish为false的情况，“请求分账接口”分账接收方可以为分账出资方 Q30：调用“请求分账接口”，分账分给多个接收方，会出现分账既有成功又有失败的情况吗 A30：同一次分账请求，会出现有的成功，有的失败的情况。具体请调用“查询分账结果接口”，查看返回参数“分账接收方列表”里面的字段“分账结果result=SUCCESS”才是分账成功。 Q31：“请求分账接口”分账接收方列表中的参数description会体现在分账账单里面吗 A31：在分账方分账账单和资金账单、分账接收方的资金账单里面都会体现 Q32：分账调用“添加分账接收方接口”返回：请求正在处理中，请稍后重试 A32：商户请求并发导致，重新再请求一次即可 Q33：分账调用“添加分账接收方接口”返回：商户已添加的分账接收方个数过多。请先删除多余的分账接收方，并在24小时之后再尝试添加 A33：添加分账接收方的个数限制是2W个，超过这个限制，请按照提示处理 Q34：电商收付通分账调用“请求分账回退接口”返回：可用余额不足，请充值后重新发起 A34：“回退商户号”的账户可用余额不足，需充值后再原单重试才能回退成功。（充值指引：登陆商户平台【交易中心】->【资金管理】->【充值/转入】，根据指引充值即可） Q35：电商收付通分账调用“请求分账回退接口”返回：可用余额不足，请充值后重新发起。这个时候，调用“查询分账回退结果API”却返回：PROCESSING（处理中），这个逻辑是正常的吗 A35：是正常的，逻辑就是这样的。这种情况，商户可以按照提示要求，提醒“回退商户号”充值后再原单重试即可回退成功 Q36：电商收付通分账调用“请求分账回退接口”返回：PROCESSING（处理中），什么情况会返回这种状态 A36：请参考以下几点： 网络抖动导致请求中断商户账户资金转账频繁，导致回退在排队时超时 Q37：电商收付通分账调用“查询分账回退结果接口”返回：TIME_OUT_CLOSED A37：TIME_OUT_CLOSED是fail状态了，也就是处于最终态，是不需要重试的。状态是SUCCESS也同理，也是最终态，不需要重试。返回TIME_OUT_CLOSED时可更换一个回退单，重新分账回退一次即可 Q38：电商收付通分账调用“请求分账接口”返回：分账补贴还未到账，不能受理分账 A38：报这个错误，是因为支付的订单在统一下单里面传了参数“补差金额：subsidy_amount”，传这个参数后，需要调用“请求补差API”完成补差，然后再调用“请求分账接口”即可正常分账 Q39：一笔交易在分账完成之后，将接收方和分账账户的绑定关系解除（删除分账接收方），然后进行分账回退，会成功吗 A39：会回退成功，不受删除分账关系的影响 这里的逻辑有两个： 这笔单曾经分给过了这个商户，且分账成功这个商户开通了分账回退 Q40：分账调用“分账回退接口”返回：PROCESSING A40：过一分钟后原单重试即可 Q41：分账回退有时间限制吗 A41：从订单创建的时间算起，现在分账回退限制180天以内的分账请求 Q42：分账方添加接口，如果相同的分账方重复提交，会返回添加失败，还是覆盖之前的分账方信息 A42：如果系统检测到已经绑定，那么会保留原来的数据，不更新数据，直接返回成功 Q43：在商户平台-管理分账接收方中手动添加分账接收方报错：系统错误，请稍后再试 A43：这个报错的原因是：账户未开通，请接收方商户在商户平台点击“充值”创建账户（商户平台-交易中心-充值） Q44：免充值和预充值的代金券，分账的时候，可分账的金额判断逻辑是一样的吗？比如10-5，使用了免充值代金券，可分账金额是5，使用了预充值代金券，可分账金额是10元还是5元呢 A44：不一样，使用了免充值代金券，可分账金额是5，使用了预充值代金券，可分账金额是10 Q45：电商收付通请求分账接口返回：appid与openid不匹配 A45：请求分账接口里面的APPID必须传电商平台服务商的APPID，所以商户在添加分账接收方时获取的openid，也必须是这个电商平台服务商APPID获取的openid Q46：请求分账回退接口返回：分账指令不存在，请检查是否有对应的分账单 A46：请按照以下几点排查： 分账回退里面的商户分账单号out_order_no，必须是请求分账接口的商户分账单号out_order_no请先调用查询分账回退结果API确认分账是否成功，分账成功的分账单才能调用回退接口正常回退。从订单创建的时间算起，分账回退限制180天以内的分账请求，超过180天不支持回退 Q47：查询订单待分账金额返回：记录不存在 A47：请按照以下几点排查： 记录不存在，可能是单号拼错了，请检查确认订单未结算，请在订单结算后再查询非分账订单，请检查订单支付时是否传了分账标识，传了分账标识的订单，才能正确查询 Q48：商户号能正常完结分账，但是查询分账结果却提示“无分账权限”。是什么原因？ A48：分账权限被冻结，请登陆商户平台查看站内信，按照指引申诉处理。 能正常完结分账的原因是：完结分账，就是将这笔订单的剩余的可分账的钱，都解冻给自己，由于这笔钱本来就是自己的，所以分账完结是一个安全的操作（钱没有给其他人，也没有给服务商，给了自己），所以是不会做权限校验的。当前要分出去给到别人时，就会做相关的权限校验了。 Q49：请求分账接口，当提交请求后返回报错SYSTEM_ERROR，这个时候调用查询分账结果接口查询，每10分钟查询一次，共查询3次（共30分钟）。这样的情况下，是否可以不用原单重试？查询后是否可以换单再提交？ A19：请求分账返回SYSTEM_ERROR时，调用查询分账结果接口3次（30分钟）后，查询结果仍然是不存在的情况：如果商户能保证在30分钟的窗口期内都不会重试，这样做是安全的。 但我们建议在返回SYSTEM_ERROR 情况下，商户还是原单重试，这种最安全，也不用查询和等待一个窗口期。 Q50：一个微信支付单被退完款，还可以继续分账吗？ A50：不可以了，分账是针对该订单冻结的金额进行分账，如果退完款，就不能再分账了。 Q51：比如一个订单支付金额是100.1元，假如手续费是0.1元。分账前先退款了30元，默认分账比例是30%，现在可以分账的金额还是30元，这样理解没有问题吧？ A51：没有问题 Q52：比如一个订单支付金额是100.1元，假如手续费是0.1元。分账前先退款了30元，默认分账比例是30%，现在可以分账的金额还是30元，那就是说，可能出现100退了80，分出去30这种情况？ A52：不会， 两个相加不会超过订单金额的， 也就是说退款没有超过70元的话，可分账金额是30，超过70，可分账金额是剩下的钱。 Q53：普通服务商分账，添加分账接收方这个APPID，如果服务商商户号绑定了两个APPID“B”和"C"，需要分账的订单统一下单中传的APPID是B，这个时候，添加分账接收方中的这APPID可以是“C”吗？还是说必须是“B”？ A53：请注意以下两点： 添加分账接收方的时候，B下的openid，C下的openid都可以但是执行分账的时候，一次分账请求里，只能是同一个appid下的openid，不支持一次分账请求里的openid分别是俩appid下的 Q54：查询分账结果接口返回：记录不存在 A54：请按照以下几点排查： 记录不存在，可能是单号拼错了，请检查确认订单未结算，请在订单结算后再查询非分账订单，请检查订单支付时是否传了分账标识，传了分账标识的订单，才能正确查询订单未分账，所以没有记录，请在订单分账后再查询