用户A在小程序发布一个线下租设备的需求，用户B看到后，需要支付金额后，才能看到用户A的联系方式用户B给平台支付一个包月的金额后，可以在平台上多次看到其他发布需求的的用户的联系方式具体的租赁需求都是线下完成的。

留意到小程序里面不能有虚拟产品支付，设想的方案是 小程序提供除支付以外的产品服务，如果用户触发了支付逻辑，生成一个二维码让用户扫码支付（直接用的微信支付，不是小程序支付）小程序提供除支付以外的产品服务，如果用户触发了支付逻辑，用关联的服务下发消息，让用户用公众号支付。小程序提供除支付以外的产品服务，如果用户触发了支付逻辑，下发短信，用户拉起h5支付（可以是其他形态的第四方支持，不限微信）这些形态哪个符合小程序的审核规定？ 另外虚拟产品支付，有具体的界定文档吗？因为其实我司产品是涉及到线下实体产品的租赁，也不算是一个纯虚拟的内容

https://developers.weixin.qq.com/community/develop/doc/0004c025c584584a70e29fec966400 社区有这个帖子，里面提到的是用腾讯云有解法方案，但是公司已经有接入火山引擎了，有基于这个平台申请成功的吗？

[图片] 以前会有一个【更多资料】现在好像没了？

如题，有没有相关总结过的文章，我看看都有哪些坑，最近被这些坑搞得很无头绪

[图片] 看了一遍video的参数，没有发一能控制这个的，感觉像是自己封装的？

https://developers.weixin.qq.com/community/business/doc/000e28a6f64dd89bf8fddd7765c80d 如题，官方设计得比较简单，比如我的小程序后续迭代，改版了，这里要怎么持续集成？ 我只能想到的是，如果有大改版，完全不能用旧的接口了。只能分两个迭代，一个改小程序端，另外一个是小程序端和服务。 迭代一：在小程序代码里面停止  getBackgroundFetchData  和 onBackgroundFetchData 等接口调用，改为直接调用服务的新接口。联调成功上线。 迭代二：修改小程序后台配置，指向新接口，然后小程序代码重新调用  getBackgroundFetchData  和 onBackgroundFetchData 等。联调成功上线。 一个功能还要拆成两个迭代上线，似乎不太科学

[图片][图片] 默认情况下，会把头部顶到视图外面的

https://developers.weixin.qq.com/doc/offiaccount/Account_Management/Generating_a_Parametric_QR_Code.html 我看了一下这个文档，意思是生成可以跳去公众号的二维码，这个二维码放在小程序里面，然后让用户长按识别，有人做到过吗？

如题，除了自己封装，官方有api可以查这个吗？