胖局提醒：请各位开发者留意生效时间，并及时调整适配。

开发者你好，平台将对《用户信息获取》和《小游戏支付方法》作出如下调整，辛苦知悉！

一、用户信息获取调整

调整背景

在小游戏内，开发者可以通过 login 接口直接获取用户的 openId 与 unionId 信息，构建游戏的账号体系，同时，为了满足部分小游戏展示用户的昵称与头像的诉求，平台提供了 getUserInfo 接口，支持在用户授权的前提下，快速获取用户的基本信息。

随着小游戏平台对用户隐私保护的加强，为减少不合理授权情况，对部分超范围信息（如性别、地区等），非用户使用小游戏的必要信息作出如下调整。

调整说明

自 2022 年 10 月 20 日 0 时后（以下统称 “生效期” ），用户头像昵称获取规则将进行如下调整：

自生效期起，小游戏 getUserInfo方法，调整返回的数据，以下信息均返回空值，请已使用 getUserInfo 接口的小游戏开发者尽快适配，避免影响线上逻辑。

二、支付方法调整

调整背景

目前小游戏支付方法tt.requestGamePayment ，支持开发者能够传入自定义的唯一订单号 cp_order_no（前端传入为 customID 字段） ，在支付成功后通过服务端回调获得，初衷是便于开发者灵活管理账单数据。

但在盘点支付方法的整体过程中，平台侧发现了一些问题：

• 脏数据较多：开发者侧订单ID未进行唯一性校验，导致数据库中存大量重复订单，资源被无效占用；
• 掉单问题优化困难：因为 cp_order_no 不唯一，对于有对账等高级需求开发者，无法保证实时对账、优化链路的准确性。目前 支付服务端回调接口 中的queryPayState 接口引入了下游查询，以解决掉单问题，但由于 cp_order_no 未进行唯一性校验，降低了该接口的有效性；

因此，开发者侧需要确保每笔订单都带上cp订单号，且具有唯一性，以减少脏数据的产生，为有高级需求的开发者提供功能保障。平台由此提高 queryPayState 接口的有效性，降低整体掉单率。提高用户侧体验的同时，也能减少开发者联系用户、补发用户的运营成本。

调整说明

自 2022 年 11 月 7 日 0 时后（以下统称 “生效期” ），tt.requestGamePayment 将进行如下调整：

自生效期起，customid为必传参数，且会进行唯一性校验；

若不传或传入的订单号已传输过，会进行报错。

最佳实践

1. 建议开发者自查支付方法，提前调整内部可自定义订单号的生成规则，将其作为唯一标识在请求支付的方法中传入；
2. 在 支付服务端回调接口 中，善用queryPayState方法，回查订单状态，及时为用户做补发操作；

如有更多问题，可加入抖音小游戏-技术交流群 或 在小游戏开发者社区发技术帖 提问

获取抖音小游戏更多资讯，可关注官方公众号：Mini游戏情报局