大家是否有这样的痛点？每当服务商想引入新的开放平台能力时，就需要商家二次授权。服务商的商户数量越多，二次授权作业成本越高。而商户也会被频繁打扰，影响商户体验。
在本月的开发者日上，支付宝开发者日讲师剑羽给我们推出了一种全权委托授权模式《支付宝开放平台授权模式更新》，可以大大降低授权压力，全面了解服务商-商家之间新的授权模式并快速应用，通过全权委托授权方式，降低服务商作业成本。
此处为语雀视频卡片，点击链接查看：12月29日.mov
在分享结束后，剑羽讲师针对线上的开发者提出的问题也进行了一一解答：
Q：商户首次授权是有授权回调的，为什么重新授权没有？
A：授权回调地址是商户在做完授权后，授权平台会给服务商颁发一个授权的令牌，这个颁发令牌就是通过授权的回调地址向服务商传递一个授权码，服务商再通过API去换取授权令牌，之后就可以做代调用了。授权回调是授权过程中必不可少的一个环节，不管是首次授权还是说二次授权，授权回调都是会触发的行为，如果服务商的授权回调没有触发，可以检查一下授权邀约链接中是否定制化了这个回调地址，是否跟开放平台里配置的回调地址是一致的。
Q：请问小程序插件授权在哪里授权？
插件其实也是一种独立的一个研发模式，与代开发模式和模板开发模式有所区别，需要服务商首先在开放平台里完成插件的开发，并把插件上架到服务市场后，商户通过服务市场来完成插件的订购。服务市场订购的同时也会完成一个小程序和小程序插件的授权。
Q：授权给服务商的应用怎么取消对服务商的授权？
通过商家平台的账号中心-授权管理中心进行解除，也可以在开放平台的小程序管理中，进行第三方授权管理的解除。
Q：第三方授权，用户接受授权后的回调能否带自定义的token（参数）
服务商需要在授权发起以及在授权执行之后做一个业务信息的一个关联。授权链路提供了一个扩展参数，就是刚才接口里面有一个叫state这么一个参数。这个参数其实就是为了让服务商做这个授权回调的时候，实现业务参数的一个透传。state参数有一个长度限制，如果说服务商要透传的这个字段比较短的话，可以直接把要透传的内容放在这个state参数中。如果透传的信息比较长的话，那么一般的处理方式是服务商先把这个信息序列化保存在自己的缓存或者是数据库中，然后生成一个key，把这个key作state的参数，进行一个透传。最终再回调之后，拿到这个key之后再从缓存或者数据库中还原业务信息。
Q：这种授权对商家是一次的授权，还是每一次都需要授权？
如果说商户跟服务商已经建立了这样的全权委托授权，那后续服务商在新绑定产品的时候，如果这个产品属于绝大部分的支持全权委托的，那这种情况下是不需要再授权的。但是服务商如果绑定的是涉及资金的转出、数据安全等敏感产品，那这种情况下是需要商户强感知，需要强制进行二次授权。
相信大家在接入能力时，会看到一些错误码，面对这些错误码，常常不知该怎么进行处理，我们推荐的一个方式就是直接在开放平台官网右上角的搜索框进行搜索，结果页会显示常见错误码的原因及解决方案，本次开发者日我们也邀请了支付宝开发者日讲师翌风给大家带来分享《支付宝开放平台搜索升级&常见错误码解读》。
此处为语雀视频卡片，点击链接查看：12月29日(1).mov
在分享结束后，翌风讲师针对线上的开发者提出的问题也进行了一一解答：
Q：错误码的返回值是int类型INT还是字符串？
A：因为不同的错误码，它是不一样的，还是要去查看一下对应的这个接口，然后对应的这个错误码，然后相应的这种文档的一个介绍，它会有比较完善的这种介绍的。
Q：错误码是递增维护的吗？
A：从开发的规范上来讲是这样的，就是我的错误码定义肯定不断的在增多的，遇到的场景，遇到的报错肯定不断在增多的。但是在增多的前提上，一般是对那些老的错误码肯定是有兼容的。
Q：旧版服务端的API返回的错误码和新版服务端API返回的错误码是一致的吗？
A：目前是我们在做V3协议的升级。这个升级的过程中，新版肯定是对老版是在错误码上肯定是做好兼容的，它升级的内容可能是有一些调用方式的不同，但是针对一些错误码的定义不会有明确的改变。
