导语：对网游的设计来说，往往需要进行设计商城系统这一步骤，在《以组件化思维为出海游戏设计商城系统——规划篇》中，作者提到了针对公司游戏产品现状进行优化的三个方案。这三个方案并不是割裂的，可以同时进行。但是，方案三落地难度过大，因此实际上作者本人也没有实操经验。本篇作者对方案一和方案二的落地实操经验进行复盘，供大家一起参考。

总结方案一与方案二，最终的用户交易流程应当为：

1. 游戏客户端内提供商城组件入口
2. 用户通过该入口跳转至商城进行商品（虚拟商品、实物商品）浏览、挑选
3. 提交订单后，跳转至游戏币支付组件完成游戏币支付

从实现层考虑，需要引入分发层、游服SDK等其他节点进行配合。实现层逻辑图如下：

特别需要注意的是：游戏币的充值和数据存储对于游戏项目业务来说过于核心敏感，建议各游戏业务方自行保留处理，不交付给服务提供方——游戏币支付组件

也就是说，用户在游戏币支付组件内的账户仅可做余额的显示，最终的扣减、充值指令需要交给游戏服务端完成。

接下来根据实操经验，作者列举一下实现上述流程，功能端和表现端需满足的能力、需特别注意的点。

01 商城组件能力清单

（本文仅列举相对于其他跨国电商需特别注意的点）

1. 后端

（1）商品发布

• 需支持为商品设定“限定供货地区”
• 在实际业务中，实体商品通常在各地区就近采购、就近发货，由于同一个商品在不同地区的采购价不同，因此需支持为不同地区用户设定不同的价格，包括普通价、活动价

（2）订单管理

• 支持用2种货币单位展示订单

（3）物流管理

• 出海业务下，若物流外包给各国经销商，则物流管理端需能够获取各经销商信息
• 若商品支持游戏币购买，则运费也需要支持游戏币支付

2. 前端

（1）商品展示

• 特别注意需支持同一个商品的2种标价方式（游戏币、现金货币）
• 由于同一个商品的标价货币类型不同，因此商品的按价格排序、价格区间搜索、搜索结果排序逻辑需加入货币类型因素。

• 考虑到体验上的统一、 数据安全两个因素，游戏客户端内的商城通常以内嵌页的形式呈现，然而内嵌页的尺寸小于客户端尺寸。若商城支持交易实物商品，那么，小尺寸的页面对商城的前端表现（UI\交互）有非常高的要求。 ps.作者在实操时，被限定的商城内嵌页分辨率为980*630，这个规格下，整个页面只能排2排商品，体验起来远逊于网页商城，产品上线后都没有得到较好的解决，只能后续专门优化。
• 为了规避法务风险，实物商品仅支持特定地区用户购买。因此，用户在浏览商品、下订单时，系统都需要根据收货地址或IP进行筛选，对不符合条件的用户进行提醒、阻断。

• e 在实际业务中，实体商品通常在各地区就近采购、就近发货，由于同一个商品在不同地区的采购价不同，因此需支持为不同地区用户显示不同的购买价格，包括普通价、活动价

（2）物流

需支持邮寄、自提两种收货方式：支持“游戏币购买实体商品”的海外地区绝大多数为发展中国家，部分国家基础设施建设落后、政治不稳定，导致物流条件差。因此，支持货物自提尤其重要。用户购买时，需允许自由选择收货方式。货物自提意味着公司在当地需要有业务处，这个建议通过外包解决。

（3）客服

由于业务涉及不同国家、地区，因此前端客服需提供多种通用渠道，例如Facebook、邮箱、跨国电话、在线IM

02 游戏币支付组件能力清单

1. 运维端

（1）游戏注册

• 若某个游戏计划接入商城组件和游戏币支付组件，最终实现“在游戏商城内以现金、游戏币购买实体、虚拟商品”，则需提前进行游戏注册。注册时需提供该游戏的名称、编码、APPID、游戏币名称、游戏币ID等必要信息
• 游戏管理：可对具体游戏做停用处理

（2）商户注册

• 商户一般主要为钱包、UC（方便租户隔离），依据具体的业务流程来定
• 注册时提供该商户的名称、ID、秘钥

2. 运营后台

（1）区服注册

• 游戏在运维端注册后，运营人员在运营后台自主决定本游戏哪些区服接入商城组件和游戏币支付组件。新增区服时，需提供该区服的名称、ID、服务器IP、机器码、私钥等信息
• 区服管理：可对具体区服做停用禁用操作，方便配合游戏进行合服、关服

（2）账户管理

• 在此查看、管理用户在游戏内的游戏币余额、交易情况
• 账户安全相关操作，包括账号冻结、找回

（3）订单管理

• 在此查看、管理前端发生的所有支付订单

（4）支付安全设置

• 包括支付密码错误次数设置、自动锁定时长

（5）区服汇率设置

由于同一个游戏，基于历史因素，不同区服内已发放的游戏币总额不同，那么单位游戏币的购买力也不同（游戏币多的区游戏币贬值）。这种购买力的差异是以“区服”为分隔单位的。

又由于同一商品在发布时，定价不受区服影响，不同区服共用同一个价格。

那么，需要引入“区服汇率”的概念，对各个区服内的商品游戏币定价做干预，使得不同区服内的商品价值与货币购买力一致。

最终同一个商品在不同区服内的最终游戏币定价计算公式为：商品基础定价（商品发布时价格）*区服汇率

举例来说：荣耀笔记本在游戏内发布时定价为6000钻石，区服A的区服汇率为1.1，区服B的区服汇率为0.9，则区服A内商城展示的价格为6600金币，区服B内商城展示的价格为5400钻石

3. 前端

1. 账户管理：支持用户账户、支付密码的注册、修改等基础操作
2. 支付能力：查询账户余额、输入支付密码、安全验证等

03 其他能力

上述游戏支付组件和商城组件能力理论上已能够完成整个业务逻辑流程，但是一个商业系统的建立必须有一些超脱于具体组件的基础能力：

1. 对账

用户的整个交易流程横跨游戏客户端、商城组件、游戏币支付组件3个系统（实际技术实现时，还会有额外的分发层、游服SDK层等进行配合），

在数据流转过程中，任何外部攻击、数据丢包都会导致链条出错。因此需要设计对账系统进行核查。此外，由于商城组件、游戏币支付组件是服务提供方，不对具体业务结果负责，因此建议有独立的第三方对账系统实现跨组件对账。

对账系统的设计需要特别注意各系统的时间延迟处理、坏账预警、自动报警、数据冻结、异常订单揪出

2. 日志

一旦对账出现问题，日志系统就会成为问题定位及后续处理方式的唯一依据。

（1）功能日志

记录整个后台发生的所有功能点使用情况。功能日志主要是记录运营人员在操作系统时发生的错误。

（2）通道日志

异常原因排查：记录各业务节点收到的支付订单数据。若某节点开始与其他节点出现数据冲突，则说明该节点为问题节点。开发人员凭借支付订单号到此节点进行详细排查，即可摸清异常订单的产生原因。

平账功能：通过通道日志定位出异常订单及产生原因后，运营人员需要对异常订单做出平账处理，否则该异常订单会导致账对不上。

举例来说：若排查发现，在游服扣款节点从用户的账户内多扣了10个金币，那么平账时需要向用户账户内返还10个金币，同时将该笔异常订单标记为“已平账”。平账后，该笔异常订单将不再被对账系统重复统计。

（3）平账日志

记录所有已被执行的平账操作及订单详情，方便后续二次核查。

3. 隐私保护

数据隐私：在当今的保守主义浪潮下，数据的跨国传输、用户隐私数据保护越来越受到各国重视，而电商系统和支付系统不可避免地需要采集用户个人数据（地址、联系方式等）。为了规避法律风险，从产品设计方面考虑，需要注意以下方面：

1. 后台数据脱敏：所有管理后台，涉及用户账户部分都需要做脱敏处理。
2. 管理员权限分级：查看数据的权限、使用功能的权限
3. 协议告知：需设计协议告知系统，在用户初次进行个人隐私数据上传时（例如注册账户时）做提示，要求用户进行授权。

特别注意协议内容需根据用户所在地区做自适应显示。

#相关阅读#

《以组件化思维为出海游戏设计商城系统——规划篇》

本文由 @十万号子手 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash，基于CC0协议。