更新：以下内容适用于微信8.0.6版本前的设备，微信8.0.6版本后的设备详见指引 一、视频号关联商店的作用 [图片][图片] 二、关联条件 「小商店」 当前视频号的超级管理员为小商店的超级管理员当前视频号的超级管理员为小商店的成员「小程序」 当前视频号和小程序的主体一致当前视频号和小程序的超级管理员一致视频号的管理员为小程序的推广者（可在mp后台交易组件模块设置）三、如何上架直播 请完成视频号关联小商店/小程序步骤后，前往查看视频号直播关联小商店/小程序指引 四、视频号关联小商店/小程序步骤的详细说明 [图片][图片] 更多资讯，欢迎到【交流专区】微信小商店主页发帖和寻找答案。

文档地址：「请求分账（直连）」、「请求分账（服务商）」 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：请按照以下几点排查： 记录不存在，可能是单号拼错了，请检查确认订单未结算，请在订单结算后再查询非分账订单，请检查订单支付时是否传了分账标识，传了分账标识的订单，才能正确查询订单未分账，所以没有记录，请在订单分账后再查询

微信支付商户手续费计算说明一、名词解释： ◆结算：微信支付将结算分为正向结算和反向结算 正向结算：商户的交易款项转到商户的基本账户并扣除支付手续费的过程。 反向结算：商户发起退款后，微信支付将退款资金从商户的基本账户反向退给用户的过程。 ◆本次结算额：包含正向结算额与反向结算额。正向结算为正值，反向结算为负值。 ◆费率：交易发生时商户在微信支付平台签约的实际生效费率 ◆已结金额：正向结算的交易款金额。 ◆已结已退金额：已经正向结算后发生退款的交易款金额。 ◆已收手续费：正向结算已经收取的手续费金额。 ◆已收已退手续费：已经正向结算的交易发生退款，退还的手续费金额。 二、手续费计算逻辑 ◆对于交易收款： 应收手续费=ROUND  （ 本次结算额 *费率  ） ◆对于交易退款： [图片] 说明： 1.ROUND（x），指对x做四舍五入，精确到分； 2.计算结果不满0.01不收取、退还手续费。 三、举例说明 一笔订单，金额是1,214.00元，商户手续费费率为0.6%。 1.交易收款（正向结算） 应收=ROUND  （ 本次结算额 *费率  ）      =ROUND ( 1,214.00 *0.6% )       =ROUND ( 7.284 )      =7.28（元） 2.交易退款（反向结算） 1)全额退款 [图片] 2)部分退款 结算时间 结算金额（元） 手续费金额（元） 第一次结算 -798.00 -4.79 第二次结算 -218.00 -1.30 第三次结算 -198.00 -1.19 具体计算方式： [图片]

此问题可按下面几个步骤排查问题： 1，请在订单支付成功1分钟后再调用分账接口 2，未结算的订单，请在结算后再调用分账接口请求分账 3，老资金流商户的订单，不支持分账 4，商户开通了收支分离但手续费账户余额不足（手续费账户最低余额要求是100元以上，在充值手续费账户1小时后，订单会正常结算，即可正常调用分账接口）

请注意以下几点： 1） 签名与生成Authorization用的同一个时间戳跟随机串。 2） 构造签名串时，里面的url不需要ToLowCase()，不用UrlEncode()，商户请求的url后缀是什么，签名用的url后缀就是什么。 3） 查询订单使用的是GET，构建签名串时，里面用的请求报文为空（但是那个换行符还是要有哈）。 4）检查证书和商户号是否正确，如是服务商模式，需使用服务商的相关证书。 更多签名相关内容可以查看这里： https://pay.weixin.qq.com/wiki/doc/apiv3/wechatpay/wechatpay7_1.shtml#part-2

使用更新指令（如 inc、mul、addToSet）可以对云数据库的一条记录和记录内的子文档（结合反范式化设计）进行原子操作，但是如果要跨多个记录或跨多个集合的原子操作时，就需要使用云数据库的事务能力。 12.6.1 更新指令的原子操作关系型数据库是很难做到通过一个语句对数据强制一致性的需求来表示的，只能依赖事务。但是云开发数据库由于可以反范式化设计内嵌子文档，以及更新指定可以对单个记录或同一个记录内的子文档进行原子操作，所以通常情况下，云开发数据库不必使用事务。 比如调整某个订单项目的数量之后，应该同时更新该订单的总费用，我们可以设计采用如下方式设计该集合，比如订单的集合为 order： { "_id": "2020030922100983", "userID": "124785", "total":117, "orders": [{ "item":"苹果", "price":15, "number":3 },{ "item":"火龙果", "price":18, "number":4 }] } 客户在下单的时候经常会调整订单内某个商品比如苹果的购买数量，而下单的总价又必须同步更新，不能购买数量减少了，但是总价不变，这两个操作必须同时进行，如果是使用关系型数据库，则需要先通过两次查询，更新完数据之后，再存储进数据库，这个很容易出现有的成功，有的没有成功的情况。但是云开发的数据库则可以借助于更新指令做到一条更新来实现两个数据同时成功或失败： db.collection("order") .doc("2020030922100983") .update({ data: { "orders.0.number": _.inc(1), total: _.inc(15), }, }); 这个操作只是在单个记录里进行，那要实现跨记录要进行原子操作呢？更新指令其实是可以做到事务仿真的，但是比较麻烦，这时就建议用事务了。 12.6.2 事务与 ACID事务就是一段数据库语句的批处理，但是这个批处理是一个 atom（原子），多个增删改的操作是绑定在一起的，不可分割，要么都执行，要么回滚（rollback）都不执行。比如银行转账，需要做到一个账户的钱汇出去了，那另外一个账户就一定会收到钱，不能钱汇出去了，但是钱没有到另外一个的账上；也就是要执行转账这个事务，会对 A 用户的账户数据和 B 用户的账户数据做增删改的处理，这两个处理必须一起成功一起失败。 1、ACID一般来说，事务是必须满足 4 个条件（ACID）： Atomicity（原子性）、Consistency（稳定性）、Isolation（隔离性）、Durability（可靠性）： 原子性：整个事务中的所有操作要么全部提交成功，要么全部失败回滚，对于一个事务来说，不可能只执行其中一部分操作，一致性：事务的执行不能破坏数据库数据的完整性和一致性，一个事务在执行前后，数据库都必须处于一致性状态。换句话说，事务的执行结果必须是使数据库从一个一致性状态转变到另一个一致性状态。比如在执行事务前，A 用户账户有 50 元，B 用户账户有 150 元；执行 B 转给 A 50 元事务后，两个用户账户总和还是 200 元。隔离性：事务的隔离性是指在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间事务之间，互不干扰。比如在线银行，同时转账的人虽然很多，但是不会出现影响 A 与 B 之间的转账；可靠性：即使发生系统崩溃或机器宕机等故障，只要数据库能够重新启动，那么一定能够将其恢复到事务成功结束时的状态，已提交事务的更新不会丢失。 2、云函数事务注意事项01不支持批量操作，只支持单记录操作 在事务中不支持批量操作（where 语句），只支持单记录操作（collection.doc, collection.add），这可以避免大量锁冲突、保证运行效率，并且大多数情况下，单记录操作足够满足需求，因为在事务中是可以对多个单个记录进行操作的，也就是可以比如说在一个事务中同时对集合 A 的记录 x 和 y 两个记录操作、又对集合 B 的记录 z 操作。 02云数据库采用的是快照隔离 对于两个并发执行的事务来说，如果涉及到操作同一条记录的时候，可能会发生问题。因为并发操作会带来数据的不一致性，包括脏读、不可重复读、幻读等。 脏读：指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据；不可重复读：在一个事务内两次读到的数据是不一样的，受到另一个事务修改后提交的影响，因此称为是不可重复读幻读：第一个事务对表进行读取，当第二个事务对表进行增加或删除操作事务提交后，第一个事务再次读取，会出现增加或减少行数的情况云开发的数据库系统的事务过程采用的是快照隔离（Snapshot isolation），可以避免并发操作带来数据不一致的问题。 事务期间，读操作返回的是对象的快照，而非实际数据事务期间，写操作会：1. 改变快照，保证接下来的读的一致性；2. 给对象加上事务锁事务锁：如果对象上存在事务锁，那么：1. 其它事务的写入会直接失败；2. 普通的更新操作会被阻塞，直到事务锁释放或者超时事务提交后，操作完毕的快照会被原子性地写入数据库中 12.6.3 事务操作的两套 API云开发数据库的事务提供两种操作风格的接口，一个是简易的、带有冲突自动重试的 runTransaction 接口，一个是流程自定义控制的 startTransaction 接口。通过 runTransaction 回调中获得的参数 transaction 或通过 startTransaction 获得的返回值 transaction，我们将其类比为 db 对象，只是在其上进行的操作将在事务内的快照完成，保证原子性。transaction 上提供的接口树形图一览： transaction |-- collection 获取集合引用 | |-- doc 获取记录引用 | | |-- get 获取记录内容 | | |-- update 更新记录内容 | | |-- set 替换记录内容 | | |-- remove 删除记录 | |-- add 新增记录 |-- rollback 终止事务并回滚 |-- commit 提交事务（仅在使用 startTransaction 时需调用） 1、通过 runTransaction 回调获得 transaction以下提供一个使用 runTransaction 接口的，两个账户之间进行转账的简易示例。事务执行函数由开发者传入，函数接收一个参数 transaction，其上提供 collection 方法和 rollback 方法。collection 方法用于取数据库集合记录引用进行操作，rollback 方法用于在不想继续执行事务时终止并回滚事务。 const cloud = require("wx-server-sdk"); cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV, }); const _ = db.command; exports.main = async (event) => { try { const result = await db.runTransaction(async (transaction) => { const aaaRes = await transaction.collection("account").doc("aaa").get(); const bbbRes = await transaction.collection("account").doc("bbb").get(); if (aaaRes.data && bbbRes.data) { const updateAAARes = await transaction .collection("account") .doc("aaa") .update({ data: { amount: _.inc(-10), }, }); const updateBBBRes = await transaction .collection("account") .doc("bbb") .update({ data: { amount: _.inc(10), }, }); console.log(`transaction succeeded`, result); return { aaaAccount: aaaRes.data.amount - 10, }; } else { await transaction.rollback(-100); } }); return { success: true, aaaAccount: result.aaaAccount, }; } catch (e) { console.error(`事务报错`, e); return { success: false, error: e, }; } }; 事务执行函数必须为 async 异步函数或返回 Promise 的函数，当事务执行函数返回时，SDK 会认为用户逻辑已完成，自动提交（commit）事务，因此务必确保用户事务逻辑完成后才在 async 异步函数中返回或 resolve Promise。 2、通过 startTransaction 获得 transactiondb.startTransaction(),开启一个新的事务，之后即可进行 CRUD 操作;db.startTransaction().transaction.commit()，提交事务保存数据，在提交之前事务中的变更的数据对外是不可见的；db.startTransaction().rollback(),事务终止并回滚事务，例如，一部分数据更新失败，对已修改过的数据也进行回滚。const cloud = require("wx-server-sdk"); cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV, }); const db = cloud.database({ throwOnNotFound: false, }); const _ = db.command; exports.main = async (event) => { try { const transaction = await db.startTransaction(); const aaaRes = await transaction.collection("account").doc("aaa").get(); const bbbRes = await transaction.collection("account").doc("bbb").get(); if (aaaRes.data && bbbRes.data) { const updateAAARes = await transaction .collection("account") .doc("aaa") .update({ data: { amount: _.inc(-10), }, }); const updateBBBRes = await transaction .collection("account") .doc("bbb") .update({ data: { amount: _.inc(10), }, }); await transaction.commit(); return { success: true, aaaAccount: aaaRes.data.amount - 10, }; } else { await transaction.rollback(); return { success: false, error: `rollback`, rollbackCode: -100, }; } } catch (e) { console.error(`事务报错`, e); } }; 也就是说对于多用户同时操作（主要是写）数据库的并发处理问题，我们不仅可以使用原子更新，还可以使用事务。其中原子更新主要用户操作单个记录内的字段或单个记录里内嵌的数组对象里的字段，而事务则主要是用于跨记录和跨集合的处理。

服务号模板消息能力的设计初衷，旨在帮助开发者实现及时通知，但存在一些问题，如： 1. 部分开发者在用户无预期的情况下，发送与用户无关的信息，对用户造成了骚扰。 2. 模板消息是用户触发后的通知消息，不支持营销类消息，不能满足部分业务需求。 为提升微信用户体验，我们开始灰度测试服务号订阅通知功能。 能力说明 开发者可在服务号图文消息、网页等场景设置订阅功能，用户自主订阅后，开发者可按需求下发一条对应的订阅通知。 [图片] 用户可在图文订阅通知 [图片] 用户可在网页订阅通知 灰度测试计划 服务号订阅通知功能即日上线，已认证的境内主体服务号可前往 MP 后台开通使用，详见说明。 1. 服务号订阅通知灰度测试期自2021年1月27日0:00至4月30日24:00，期间服务号模板消息可正常使用；灰度测试期结束后服务号订阅通知的策略将另行公布，届时以官方信息为准； 2. 开发者使用订阅通知功能时，需遵循运营规范，不可用奖励或其它形式强制用户订阅，不可下发与用户预期不符或违反国家法律法规的内容。具体可参考文档：《微信公众平台运营规范》 微信团队 2021年1月27日

功能介绍： 为帮助小程序快速迭代更新，新增插件快速更新功能。小程序开发者可在移动端便捷体验、快速更新小程序内插件的版本，无需修改代码或重新提交审核。   适用范围： 适用于不需要小程序改动原有代码逻辑或针对插件做适配，只更新插件内服务内容的插件版本更新。   使用流程： 1、插件开发者发布新版本时，选择快速更新。并选择要给正在使用哪些版本的小程序发送通知。 [图片] [图片]   2、选择快速更新后，使用低版本插件的小程序开发者管理员会收到通知 [图片]   3、在移动端选择体验最新版插件。系统将会以小程序线上版本+插件最新版本，生成体验版小程序。小程序开发者可在移动端体验该版本。 [图片]   4、体验确认服务预期后，小程序开发者可在移动端操作发布。操作后无需提交审核、直接发布现网，更新小程序版本。 [图片]  

在小程序生态中，基于苹果运营规范，小程序内暂不支持iOS端虚拟支付业务。为此小编为大家整理了一份虚拟支付业务指南，希望大家在做虚拟业务时有所帮助： [视频] 那么，到底什么是虚拟支付业务呢？ 虚拟支付业务是指购买非实物商品。比如：VIP会员、充值、录制课程、录制音频视频等虚拟产品。目前iOS端暂不支持虚拟支付业务。   我们常见iOS虚拟支付的不合规示例有哪些呢？ 示例一 ：小程序内存在付费购买虚拟内容或道具。商品多体现为提前编辑好的、录制好的虚拟商品。如录制视频课程、游戏道具。 整改建议 ：建议去除小程序内所有付费购买虚拟服务，并根据提示修改相关内容及文案，文案可参照“由于相关规范，iOS功能暂不可用”。 [图片]   示例二 ：付费解锁优质服务。多体现为提供虚拟商品的小程序可通过支付购买、开通虚拟会员等形式，体验小程序付费服务。比如：支付阅读章节小说、同城生活服务平台付费发帖/付费置顶等。 整改建议 ：建议可以关闭iOS端虚拟支付通道，并将【马上充值】更改为【由于相关规范，iOS功能暂不可用】，并不再提供iOS端会员服务。 [图片]   示例三 ：关闭iOS端虚拟支付功能后，虚拟商品页面仍然保留货架价格标签展示、购买/付费/订阅等功能或按钮。 整改建议 ：建议去除小程序中的虚拟商品的价格展示，并更改为【免费】；并将【订阅 ¥128】更改为【由于相关规范，iOS功能暂不可用】，并不再提供iOS端虚拟商品购买服务。 [图片]   示例四 ：关闭iOS端虚拟支付功能后，提供引导用户前往其他支付的路径/文案，完成虚拟支付闭环。 整 改建议 ：建议去除iOS端小程序内引导用户前往其他支付路径/文案，并不再提供iOS端虚拟商品购买服务。 [图片]   示例五 ：小程序含需要付费的虚拟商品，并设置限时免费的服务，限时免费结束后需付费才能继续提供服务。 整改建议 ：建议将iOS端小程序中所有虚拟付费内容更改为免费，并不再提供iOS端虚拟商品购买服务。 [图片]   示例六 ：关闭iOS端虚拟支付功能后，小程序中虚拟产品页面不可以含有付费性质的关键字（如：购买、已购、付费、支付等），包括但不限于功能按钮、功能页面、支付提示及任何商品介绍等。 整改建议 ：建议将小程序iOS端虚拟产品页面中的文案/按钮/功能tab含有限制的关键字更改为【免费】或删除。并不再提供iOS端虚拟商品购买服务。 [图片] 如小程序内存在以上不合规的虚拟支付内容，请开发者重视并及时整改。对于首次违规的小程序，平台将下发站内信整改通知，并给予三天整改时间，请开发者按照提示在限期内完成整改。平台将会对到期未完成整改的小程序进行搜索策略调整，并在小程序功能使用上进行一定的限制，直到小程序完成内容整改。

不知道大家是否有这样经历... 铁哥们儿的萌娃参加了英语才艺比赛，发来投票小程序让我助力一把，我当然义不容辞！ 领导的闺女参加了钢琴大赛，发来链接让我点赞，我必须秒赞！ 当表妹参加舞蹈比赛让我帮忙拉票时，我已经轻车熟路了.... 如今投票已成为一种社交互动的方式，但最近小编发现小程序中的有偿投票模式，让我对投票有了新的认识。有偿投票模式是指强制或吸引用户以有偿的方式进行投票或影响投票结果的行为，包括但不限于直接线上支付，可直接或间接获得奖品、积分、兑换券、折扣券等实物或虚拟物品，或者直接或间接先行购买礼品、票券等实物或虚拟物品后才能获得投票资格或不同可投票数。 平台认为投票方式旨在不受外力作用的前提下公平地选出最优秀的作品。但有偿投票不仅破坏公平性，也令投票活动失去其本身的意义，因此平台内暂不支持有偿投票。 在小程序中，有偿投票通常以如下几类形式出现： 1、明星打榜类有偿投票 小程序涉及提供打榜服务，当免费打榜次数使用完毕后，可付费购买打榜次数，打榜次数越多，对应明星的排名越高，即可通过付费改变排名结果。 [图片] 2、直播类有偿投票 小程序内提供选手直播服务，支持观众付费购买虚拟商品服务，购买的虚拟商品可获得对应“人气”用于支持参赛选手，在指定时间内“人气”数量最高的选手将获得最终胜利。 [图片] 3、线下活动有偿投票 小程序内提供线下实体活动投票平台服务，需为参赛选手购买虚拟礼物才可以获得可投票数。 [图片] 如小程序内存在以上几类或其他形式的有偿投票内容，请开发者重视并及时整改。首次发现将限期3天整改，到期未整改将封禁“小程序支付”功能。 如已整改后续仍直接或间接再有类似行为的，将对小程序永久封禁处理。 若同一主体下多个帐号均存在类似违规行为的，将根据违规程度对该主体下所有小程序采取限制功能直至拒绝再向该主体提供任何注册或认证服务。