结论先行

Slots API 项目最容易出现的误解，不是某个术语完全没人知道，而是不同团队用同一个词表达不同对象。例如，“可用”可能只指目录已收录，也可能指 staging 已连通、production 已启用或目标市场已核验。稳定的短定义能让采购问题、接口设计、测试证据和上线决定指向同一个事实范围。

本页只给可跨页面复用的定义。需要选型、验收、可靠性或市场核验步骤时，请进入对应专题，不在术语表重复教程。

核心角色与目录

术语 稳定短定义 不能自动推出
Provider / 游戏提供商 提供游戏内容、游戏服务或相关接口的一方。 不自动代表 AG 拥有分发权，也不代表任一市场可用。
Aggregator / 聚合器 在平台与多个 provider 之间统一或协调接入的集成层。 不自动消除厂商差异、商务条件、认证或市场核验。
Platform / 平台 面向玩家账户、钱包、运营或前端体验的业务系统。 不等同 provider、RGS 或监管意义上的运营主体。
Operator / 运营主体 在指定项目或市场范围内承担运营责任的实体；准确含义取决于合同与法域。 不因接入 API 自动获得授权。
RGS / Remote Game Server 承载或协调远程游戏运行、状态及相关交易交互的系统组件。 不等于聚合器，也不因名称相同而具有相同认证范围。
Catalog / 游戏目录 带来源、身份、版本、状态和复核信息的游戏记录集合。 目录收录不等于实时库存、production 上线或市场准入。
Catalog Record ID 用于稳定追踪一条目录记录的内部标识。 不应替代厂商游戏代码或交易 ID。
Provider Game Code provider 或上游接口用于唯一识别游戏的代码。 不能从游戏名称或页面路径猜测。
Game Version 某个游戏软件或内容构建的可识别版本。 不一定等同数学模型版本。
Math Model Version 决定游戏概率、奖项与理论统计特性的数学模型版本。 不应因界面未变化而假定模型未变化。

会话、轮次与交易

术语 稳定短定义 不能自动推出
Launch / 启动 平台按约定参数请求并进入指定游戏的过程。 成功获得启动结果不代表完整游戏流程或目标市场已通过。
Launch URL 为特定启动上下文生成的游戏入口地址或令牌承载地址。 不应视为永久公开链接，也不能泄露或复用超出约定范围。
Game Session / 游戏会话 玩家进入游戏后，在指定身份、游戏和环境下的一段有界交互上下文。 不等同玩家账户、登录会话、钱包或单个 round。
Round / 游戏轮次 按游戏规则关联一次或一组投注与结果事件的业务单位。 一个 round 不一定只对应一条 transaction。
Transaction / 交易 对余额或业务状态产生可审计影响的一次业务记录。 API 返回成功不一定等于所有系统已最终一致。
Bet / 投注 在指定 round 中请求或确认扣减投注金额的交易类型。 不应仅凭客户端动画判断交易成功。
Win / 派彩 根据已确认结果增加余额或形成应付金额的交易类型。 不代表玩家在其他 round 或长期必然盈利。
Refund / 退款 按规则返还一笔既有交易的全部或部分影响。 不应通过删除原交易实现。
Rollback / 冲正 以可追踪方式抵消既有业务影响的处理。 不等于任意重放退款请求；必须关联原对象并保持幂等。
Balance / 余额 在指定账户、币种和时间点可用于业务判断的金额状态。 单次读取不能证明所有异步记录已完成对账。
Currency / 币种 金额展示、下注、结算或报表使用的货币单位及精度规则。 技术支持某币种不等于目标市场许可。

钱包与可靠性

术语 稳定短定义 不能自动推出
Single Wallet / 单一钱包 玩家余额由平台侧统一管理，游戏交易通过实时 API 与平台钱包协作。 不代表没有超时、重复请求、状态不明或对账需求。
Transfer Wallet / 转账钱包 资金在平台侧与游戏侧钱包之间按流程转入、转出并分别记账。 不代表两边余额天然实时一致。
Callback / 回调 一方主动向约定地址通知事件或请求业务处理的服务端交互。 到达顺序、唯一性和一次成功送达都不能未经协议假定。
Idempotency / 幂等 同一个业务请求被重复处理时，不产生重复业务效果。 不只是“返回相同响应”；还要识别同一业务意图并保存结果。
Idempotency Key 用于识别同一业务请求的稳定键。 不能随每次重试重新生成，也不能脱离业务范围无限复用。
Retry / 重试 在限定条件、次数和退避策略下再次发起尚未确定完成的请求。 超时不等于失败；盲目重试可能造成重复效果。
State Unknown / 状态不明 请求方无法仅凭当前响应判断业务是否已完成的状态。 不能直接按成功或失败入账，应查询、幂等重试或进入对账。
Correlation ID / 关联 ID 用于把跨系统请求、回调、日志和记录串联起来的追踪标识。 不应替代业务交易 ID或幂等键。
Reconciliation / 对账 比较相互独立的交易、轮次或余额记录，识别并处置差异的过程。 不能替代实时幂等、状态查询和异常控制。
Final State / 最终状态 按协议确认不会再因正常流程改变的业务状态。 HTTP 成功响应不一定就是业务最终状态。

环境、版本与市场证据

术语 稳定短定义 不能自动推出
Staging / 预发布环境 用于集成、验证和验收的非生产环境及其配置集合。 staging 通过不等于 production 已部署或真实业务已验证。
Production / 生产环境 承载真实获准业务流量和数据的运行环境。 有生产地址或凭据不等于所有游戏、市场和版本都已批准。
API Version 一组接口契约、字段与行为的可识别版本。 API 版本相同不代表游戏或数学模型版本相同。
Integration Version 平台、聚合层、RGS 与 provider 之间指定拓扑和配置的版本化记录。 任何关键组件变化后不应默认旧证据仍覆盖。
RTP / 理论返还率 在明确游戏规则和数学模型下，经大量事件形成的理论平均返还比例。 不保证单次、短期或任何具体玩家的结果。
RNG / 随机数生成器 为游戏结果或相关随机过程提供随机值的组件或机制。 提到 RNG 不等于其实现、版本或认证已完成核验。
Certification / 认证或符合性证据 指定机构针对指定对象、版本、要求和范围形成的测试或符合性证据。 不等于全球通用许可，也不自动覆盖运营主体、品牌、域名或新版本。
Integration Certification / 集成认证 针对平台、RGS、聚合器、provider 等特定组件组合与交互范围的符合性证据。 不能替代单个游戏或运营主体所需的其他核验。
Test Body / 测试机构 按明确认可范围执行测试或出具报告的机构。 机构被某监管方认可不代表其所有服务和报告都在认可范围内。
Standard / 标准 描述技术、测试或控制要求的规范。 采用 GLI-19 等实验室标准不自动等于任一法域准入。
Market Availability / 目标市场可用 在指定市场、运营主体、游戏与版本、认证、币种、语言、权利和项目决定下形成的范围化状态。 不能由目录收录、语言、币种或 API 连通单独推出。
Language Support / 语言支持 在指定界面、规则、帮助或沟通范围内经过核验的语言能力。 不等于翻译完整、认证有效或市场可用。

关于 RTP 0–1000 的适用说明 这一数值范围不是本术语表给出的 RTP 定义；还需要结合单位、数值含义、数学模型版本、调用权限、测试与认证资料、目标市场和展示方式理解，不应将其解释为已验证的性能、收益或市场合规主张。

常见混淆

容易混淆的说法 应拆开的事实
“目录里有，所以可用” 已收录、staging 已验证、production 已启用、商务可供和目标市场已核验
“请求超时，所以失败” 传输结果未知、业务状态未知、最终失败、可安全重试与需对账
“一个 round 就是一笔交易” round 是游戏业务单位；bet、win、refund 或 rollback 可形成多笔交易
“支持 BRL 和葡语，所以巴西可上” 币种、语言、游戏版本、集成拓扑、认证、运营主体、品牌或域名与市场规则
“有认证，所以全球通用” 测试机构认可范围、依据标准、对象、版本、法域、有效状态和项目条件

当前可用于项目评估的范围

  • 公开 API 参考使用目录、启动、单一钱包、转账钱包、记录与集成流程等概念。
  • 相关技术专题强调重复请求、超时、回调失败、状态不明与对账需要共同设计。
  • 本术语表给出供全站引用的短定义，不新增端点、签名、凭据或生产协议事实。
  • 游戏目录展示 11 个厂商、1,194 个游戏名称；它们仅是名称级快照，不是实时供货、生产开通、内容授权、版本、认证或目标市场可用结论。

使用这些信息时需要注意什么

  • 不承诺具体 API 字段、生产协议、钱包实现、性能、SLA 或上线时间。
  • 不承诺任一游戏、provider、证书、语言或币种在目标市场当前可用。
  • 不把术语的一般定义替代合同定义、接口规范、监管规则或项目审批。
  • 保留 RTP 0–1000 业务口径，但不把它解释成已验证的数值定义、普遍适用能力、玩家结果或市场准入事实。

FAQ

Provider 和 aggregator 是同一类公司吗？

不是同一个角色。Provider 主要提供游戏内容或游戏服务；aggregator 主要协调多个 provider 与平台之间的接入。现实中一家公司可能承担多个角色，但项目记录仍应按实际职责拆分。

Callback、transaction 和 round 应使用同一个 ID 吗？

通常不应混成一个 ID。Callback 是交互方式，transaction 是业务状态变化，round 是游戏业务单位；它们需要各自稳定标识，再用关联 ID 建立追踪关系。最终规则以项目接口契约为准。

RTP 是否表示玩家每次都会按该比例拿回？

不是。RTP 是在明确规则和数学模型下的理论长期统计指标，不保证单次或短期结果。任何具体数值还需关联游戏与数学模型版本、测试证据和展示范围。

延伸阅读与下一步

前七篇专题可分别承接定义以外的完整问题：

  1. 什么是多厂商 Slots API：定义聚合层连接的对象与边界。
  2. 聚合 API 与逐厂商直连如何选择：比较两条接入路线。
  3. 如何评估 Slots API 供应方：组织采购证据与问题。
  4. 从 staging 到 production 的验收清单：定义上线通过证据。
  5. 幂等、重试和对账为什么要一起设计：处理失败、重复和状态不明。
  6. 游戏目录数据治理：建立字段、状态、版本和责任链。
  7. 市场 × 游戏 × 版本 × 认证矩阵：逐层核验目标市场范围。

相关页面：公开 API 参考、游戏目录、集成流程。

统一下一步：联系我们时，请尽量使用本页术语描述目标市场、目录范围、钱包模式、环境和版本。AG 将先确认双方术语与证据范围，再进入项目讨论；这不构成供货、认证或上线承诺。

参考资料与适用说明

使用说明：监管与标准资料用于解释相应术语，不证明任何具体项目已经满足其要求。用于具体项目时，应确认定义是否与当时接口、合同和目标市场规则一致。

需要把指南转成项目方案？

文章用于帮助团队梳理采购和接入问题，不替代技术、合同、认证或当地法律确认。

联系我们