背景
本文旨在针对游戏内不同的付费场景提供选型指导，以及在开发者构建支付服务中的一些关键细节提供建议，期望与开发者一道共同努力提升玩家的付费体验。
术语定义
道具：游戏内的虚拟道具，用于增强游戏体验或者提供额外的游戏服务。比如：游戏内的武器、装备、资源。
控制台：开发者使用小游戏账号登录后的管理控制台。
流程说明
1. 开发流程
1.1 付费场景
游戏内的付费场景可以分成两大类：游戏币和道具直购。当前仅支持道具直购的场景。
道具直购场景
玩家通过网上支付购买道具的场景。比如购买游戏内的武器、装备、资源等。
1.2 支付能力
道具直购能力
2. 小游戏支付使用建议
2.1 道具直购场景使用道具直购能力
道具直购能力发货由小程序平台（openServer）通知开发者，正常情况下扣费成功后，即会通过服务端消息推送通知到开发者，极端情况下可能有一定的通知延迟。 特别提醒：
1. 同样的发货请求（outTradeNo），可能因为网络原因，会请求多次。我们在有限时间内尽量保证触达一次，直到明确返回发货成功为止。
2. 针对重复的请求，开发者需要自行保证只发货一次，并且回包需要和第一次一样返回发货成功。
3. 通知周期：15s/15s/30s/3m/10m/20m/30m/30m/30m/60m/3h/3h/3h/6h/6h。
4. 小游戏开发者必须要在控制台小游戏商业化-虚拟支付-基础配置中配置发送推送配置，以及在商业化-虚拟支付-道具管理中开启道具发货推送才能收到回调请求。详细流程可查看 控制台小游戏道具直购流程。 必须实现：
发货消息会尽可能及时、尽可能不漏的通知到开发者服务端，若出现网络异常或者非发货成功的应答，我们会进行重试，开发者的服务端可能会收到重复的发货消息，即相同的订单 id 被推送多次。开发者需要确保实现道具发货的幂等，相同的订单 id（outTradeNo）多次被通知发货时只发货一次。
发货消息通道需要做好请求校验及相关密钥的妥善保管，避免因为密钥泄露导致请求来自恶意第三方。
2.2 通用建议
2.2.1 服务端API域名选择
开发者可以根据自己的服务器部署情况，选择最佳的接入域名（延时更低，稳定性更高）。除此之外，可以将其他接入域名用作容灾用途，当网络链路发生故障时，可以考虑选择备用域名来接入。请开发者使用域名进行 API 接口请求，不建议使用 IP 作为访问。对于支付类业务而言，建议考虑就近接入以及做好异地容灾域名切换的策略。
2.2.2 接口调用凭证（access_token）的建议
为了保证安全性，获取 access_token 的 AppSecret 以及 access_token 本身不要泄露到游戏客户端或者游戏服务端以外的其他地方。access_token 获取方式可查看 小程序服务端。 2.2.3 登录态与会话密钥 session_key（signature）的注意事项
支付相关 API 涉及用户签名的地方（signature 参数），都需要用到 session_key，session_key 是玩家在使用小游戏期间由小程序平台服务端（openServer）分配，用于 superapp 后端和游戏服务端之间验证身份、安全通信的一种凭据，是对用户数据进行 加密签名 的密钥。分别存储于小程序平台服务端（openServer）、游戏服务端，在调用 wx.login 时可能触发 session_key 的重新生成，为了保证游戏服务端存储的 session_key 和小程序平台服务端（openServer）的一致，开发者需要使用 wx.login 获得的 code 去换最新的 session_key。 注意事项如下：
开发者实现登录的流程可参考 小程序登录，session_key 主要用于小程序平台服务端（openServer）和游戏服务端之间验证身份。游戏前端和游戏服务端之间的权限验证，开发者应自己实现自定义登录态。当开发者在实现自定义登录态时，可以考虑以 session_key 有效期作为自身登录态有效期，也可以实现自定义的时效性策略。 为了应用自身的数据安全，开发者服务器不应该把会话密钥下发到小游戏，也不应该对外提供这个密钥。
wx.login 调用时，用户的 session_key 可能会被更新而致使旧 session_key 失效（刷新机制存在最短周期，如果同一个用户短时间内多次调用 wx.login，并非每次调用都导致 session_key 刷新）。
session_key 目前失效时间为“天”级别，开发者需要在服务端维护最新换取的 session_key。
wx.login 建议不要频繁进行调用，此类接口一般会调用到平台侧后台系统资源，为保护系统，同时防止用户资源被滥用，开发者需要对此类接口做适度的频率限制，不能无节制的调用。小游戏前端应控制 wx.login 的调用频率，禁止短期内的多次自动重试，可以通过本地存储记录相关调用状态来实现，若检测到多次自动进入重新登录态流程，可以考虑交由玩家决策：弹出对话框提示玩家，重试、重启小程序或者清理缓存后再试。同时，开发者应该针对这类问题增加告警，排查代码逻辑是否有问题。以下任意条件满足则应触发登录（调用 wx.login）：
首次登录
游戏服务端存储的 session_key 失效，例如：调用支付接口返回 -15012（signature 签名错误）和 -15015（session_key 过期）时，应通知游戏前端重走 wx.login 流程。后台可以通过 checkSessionKey 校验。 游戏自定义登录态失效。