交易、支付与经济系统

Category

system / 通用服务子树。节点定位：交易、支付与经济的账务本质——支付链路的异步不确定性、经济不是背包加减、关键边界与方案取舍。

Definition

支付和经济系统最大的误导在于，很多人会把它们拆成两个问题：支付归平台接入，经济归游戏策划。现实里这两者高度耦合，因为所有充值、发货、消耗、兑换、拍卖、抽卡、返利、退款，最终都会落到同一个核心问题上：资产是否变化正确，是否能说清楚每一笔变化为什么发生。

Problem

交易与资产先看成账务问题：每笔变动都要有流水、可对账。支付真正的难点是异步与不确定性（回调丢失、重复到账），经济系统不是背包加减——产消失衡会把整个付费体系拖垮。

先把交易和资产看成账务问题

只要系统中存在付费货币、稀缺道具、玩家间交换或平台分成，经济系统就不再只是“数值设计”。它首先是账务系统，至少要能回答：

• 某个资产当前余额是多少
• 这笔余额是通过哪些事件累计而来
• 某个订单是否已支付、已发货、已退款、已补发
• 出现投诉或异常时，能否还原完整流水

如果做不到这些，任何“经济平衡”讨论都会失去基础，因为你连真实资产状态都不确定。

支付链路真正难的是异步和不确定性

典型支付链路里，至少会包含客户端下单、渠道支付、服务端验单、订单入账、发货、回执、补单、退款这些阶段。麻烦在于这些阶段几乎都不是原子完成的，而且存在大量重复通知和乱序通知。

因此支付设计必须默认下面这些事实：

• 客户端回调不可信，服务端必须主动验单
• 渠道通知可能重复到达，也可能长时间延迟
• 订单创建成功不代表支付成功，支付成功也不代表发货成功
• 发货成功后仍然可能发生退款、拒付和争议单

成熟系统一般会把订单状态机和资产发货解耦：

• 订单服务负责记录订单主状态、渠道流水、验单结果、回调日志
• 资产服务负责真正的货币和道具变更
• 两者通过幂等发货键、事件或任务补偿协作

这样做的代价是链路更长，但收益是支付和资产可以各自审计，不会因为一次重复通知把货发两遍。

经济系统不是“背包加减”

游戏经济至少有三层：

• 资产层：钻石、金币、体力、道具、券、碎片等具体对象
• 规则层：产出、消耗、兑换、掉落、保底、税费、交易限制
• 市场层：拍卖行、玩家交易、礼包、商城、活动返利、广告变现

不同项目的重点不同。单机化程度高的产品可能只需要保证商城和背包正确；重社交或重交易的产品则必须进一步处理：

• 玩家间转移是否允许，允许到什么程度
• 是否存在绑定币和非绑定币
• 稀缺道具是否允许二级流通
• 抽卡保底和概率公示如何落到真实流水

一旦允许玩家间交易，系统复杂度会明显上升，因为你不仅要关心“系统发了什么”，还要关心“玩家之间搬了什么”“是否有人洗钱、倒卖、刷号、套现”。

设计时最关键的几条边界

订单权威和资产权威分离

订单是否支付成功，由订单服务判断；资产是否真的发到玩家身上，由资产服务判断。不要让任何一个服务同时“既说钱到了，又直接改所有资产”，否则对账和补偿都会很痛苦。

资产变更必须流水化

无论你用数据库事务、事件日志还是双写补偿，只要资产会变化，就应该有可查询的变更流水，至少记录：

• 资产主体是谁
• 改了什么
• 改动前后数值
• 来源事件或单号是什么
• 谁发起、谁批准、谁执行

这不仅为了追账，也为了风控和客服处理争议。

高价值操作必须支持冻结和回滚策略

比如拍卖成交、跨服交易、退款回收、误发补扣，这些都不适合只靠一条即时扣加流水完成。很多场景需要“预扣冻结 -> 条件满足后结算 -> 异常则回退”的三段式流程，否则异常状态很难收敛。

常见方案与取舍

业务服内嵌支付发货

优点是实现快，链路短。缺点是订单记录、渠道回调、资产发放和补单逻辑混在一起，出问题后很难区分到底是支付问题还是业务问题。只适合体量很小、支付形态简单的项目。

统一订单中心加项目资产服务

这是多数中型团队能长期维持的平衡点。统一订单中心负责渠道适配、验单、对账、退款处理；项目资产服务只处理“根据可信订单发放什么”。这样新接渠道和统一审计会轻松很多，但项目仍保留自身经济模型。

经济平台化

更进一步会把商城、礼包、价格表、发货模板、优惠活动、返利规则也平台化。收益是运营效率高、配置统一；代价是业务创新会受限，而且一旦平台规则表达不够，项目会绕平台自己做一套旁路。

常见错误

• 订单状态和发货状态合并成一个字段，导致补单和追账无法精确处理
• 只记最终余额，不记资产流水，出问题后只能靠猜
• 退款链路只对接渠道，不处理游戏内资产回收和负债状态
• 把经济系统当成纯策划配置，不让技术参与账务和风险设计

支付和经济系统真正成熟的标志，不是商城页做得多花哨，而是你能不能在一次投诉、一笔退款、一场活动误发或一次黑产攻击之后，仍然用清晰账本把问题收回来。

Used By

交易与支付链路设计；经济系统边界评审；对账与补偿机制建设。

Related

关系链：账务本质 → 支付异步 → 经济循环 → 关键边界 → 方案取舍 → 常见错误。上游：services/01。下游：numerical/04（经济循环设计侧）、database 树（事务一致性与流水）。

Reference

本页为工程经验归纳。