游戏聚合 API 如何对接厂商

统一聚合层负责什么

统一游戏聚合层,标准化对接多家 Slots / 真人 / 体育厂商,一键上下架。标签包括：统一聚合、钱包转账、一键上架、对账核验。意思是大厅不必为每一家厂商各写一套登录、余额和注单页面，而是先进入聚合层，再由聚合层按厂商协议转发。

运营侧可以一键上下架。后台管理本身就覆盖厂商，和会员、财务、风控、内容放在同一个控制台里，并有权限与操作审计。因此下架一款游戏，是后台配置，不是临时改前端硬编码。

PG 电子 API 对接、JILI API 都落在这条聚合层上，而不是两套互不相干的源码。PG SOFT 和 JILI 都在已对接厂商名单里。公开网站不提供可直接调用的密钥、签名算法或测试环境地址，这些属于「游戏、支付及第三方接口说明」，随源码或包网交付。

单一钱包和转账钱包

这是两种常见模型，用来理解聚合层里的钱包转账，并不表示每一家厂商都已做成同一种。

单一钱包

玩家在平台保留一个余额。进入游戏后，下注和派彩由平台钱包实时记账，厂商侧更多是通知结果。优点是玩家不用先划转一笔金额，离开游戏时也不等待转回。对账时要以注单和余额变动能对上为准。

转账钱包

进入某一家厂商之前，先把一部分余额转入该厂商钱包，离开再转回平台。聚合层包含这种钱包转账。它和厂商的既有接口更贴近，但玩家会看到转入转出，失败时要有补单。

两种模式可以在不同厂商上并存。源码买断包含游戏及第三方接口说明，用来标明实际对接采用哪一种。在文档交付之前，不能把演示后台里的示意注单当成接口已经按某种钱包模式上线。

对账核验和上下架

聚合层的标签写了「对账核验」。实际要核对的是：玩家看到的余额、平台账本、厂商注单是否一致。Kafka 等异步消息用来在跨服务时做最终一致，Redis 用来扛读多写少的余额查询。钱包模块还要求峰值时投注和钱包实时一致，所以对账不是月底才第一次看。

一键上架之后，游戏出现在 H5 大厅。大厅有多套模板、导航和活动位，可以可视化装修。厂商仍在后台的厂商管理里。上下架决定能不能进游戏，装修决定入口放在哪个位置。

加密货币充值与游戏扣款分开。充值模块是 USDT/TRC20/ERC20 等多链充提,自动归集与对账,支持第三方支付通道。 充值到账进入平台钱包，再按单一钱包或转账钱包进入游戏。不要把充值通道和厂商钱包混成同一个接口。

已列出的厂商

已对接厂商页面列出：PG SOFT、PRAGMATIC PLAY、EVOLUTION、JILI、CQ9、HABANERO、SPRIBE、PLAY'N GO、NETENT、MICROGAMING、BGAMING、JDB。注脚写明 PG、PP、EVO 等主流厂商已对接，完整接入清单以授权交付文档为准。名单里的缩写和全称对应关系：PP 即 Pragmatic Play，EVO 即 Evolution。

按站点选择厂商组合，是多租户配置的一部分，详见多站点说明。某个厂商能否在某一国家提供游戏，还取决于该厂商和运营方的许可，不是买了聚合层就自动具备当地经营资格。

PG 电子 API 对接是否已包含在系统里？

PG SOFT 在已对接厂商名单中，通过统一游戏聚合层接入。接口字段、密钥和环境以授权交付文档为准，这里不公开。

JILI API 是单独一套源码吗？

不是。JILI 与其他厂商一样进入统一聚合层，支持一键上下架和对账核验，而不是每个厂商一份独立后台。

单一钱包和转账钱包哪个是默认？

聚合层包含钱包转账和对账。单一钱包是另一种常见模型。某一家厂商用哪一种，要看交付文档。

厂商名单是否就是全部？

不是。公开名单包括 PG SOFT、Pragmatic Play、Evolution、JILI、CQ9、Habanero、Spribe、Play'n GO、NetEnt、Microgaming、BGaming 和 JDB。完整清单以授权交付文档为准。