虚拟支付简介
背景
基础支付能力支持道具直购能力。
术语定义
- 道具：游戏内的虚拟道具，用于增强游戏体验或者提供额外的游戏服务。比如：游戏内的武器、装备、资源。游戏币某种情况下也可以看做一种特殊的“道具”。
开通流程
1. 支付进件流程
虚拟支付协议签署指引：虚拟支付开通
2. 开发流程
2.1 付费场景
目前游戏内的付费场景为道具直购。
玩家通过游戏币或者现金购买道具的场景。比如：游戏内的装扮、皮肤等。
2.1.1 直购
玩家通过现金直接购买道具/游戏币，平台通过后端的可靠回调通知开发者发货，由开发者负责道具的发放的一种支付能力。 开发者发起支付扣费成功后平台主动通过回调 pay.notify推送道具发货消息到开发者的服务端，通知开发者发放道具。
3.小游戏支付最佳实践
对于首次接入支付能力的游戏，有如下建议：
3.1 道具直购场景使用道具直购能力
直购能力发货由平台通知开发者，正常情况下扣费成功后，即会通过服务端消息推送通知到开发者，极端情况下可能有一定的通知延迟。 特别提醒
- 同样的发货请求，可能因为网络原因，会请求多次。我们在有限时间内尽量保证触达一次，直到明确返回发货成功为止
- 针对重复的请求，开发者需要自行保证只发货一次，并且回包需要和第一次一样返回发货成功
- 通知周期：15s/15s/30s/3m/10m/20m/30m/30m/30m/60m/3h/3h/3h/6h/6h
必须实现:
- 发货消息会尽可能及时、尽可能不漏的通知到开发者服务端，若出现网络异常或者非发货成功的应答，我们会进行重试，开发者的服务端可能会收到重复的发货消息，即相同的订单id被推送多次。开发者需要确保实现道具发货的幂等，相同的订单id多次被通知发货时只发货一次。
- 发货消息通道需要做好请求校验及相关密钥的妥善保管，避免因为密钥泄露导致请求来自恶意第三方。
建议实现:
- 尽管我们会尽可能保证不漏的推送到开发者服务端，但是若开发者侧有故障，我们不可能一直重试。因此开发者可以增加一定频率的主动发货逻辑： a.下单后按一定间隔，定期查询订单状态pay.orderQuery，越往后间隔建议越大（比如后面可以按1分钟，10分钟查询一次）