结论先行
评估 Slots API 供应方，不能只看演示站、游戏数量或“一个 API 即可接入”的表述。更可靠的方法，是要求供应方针对八个问题提供能核验、能追溯、能注明适用范围的证据：目录从哪里来、版本如何变化、钱包边界是什么、异常如何处理、记录如何对账、测试如何验收、故障由谁响应，以及特定游戏和版本能否用于目标市场。
证据不足不等于供应方一定不可用，但意味着采购方不应把营销表述直接升级为上线事实。对于尚未得到材料支持的项目，最准确的结论是“待验证”，而不是“默认通过”。
八类采购证据
| 证据类别 | 最低应取得的材料 | 需要追问的问题 | 常见风险信号 |
|---|---|---|---|
| 1. 游戏目录与授权范围 | 带日期的目录快照、厂商与游戏标识、状态字段、素材使用范围及来源说明 | 当前可展示、可测试、可生产使用的范围是否相同？目录由谁更新？ | 只报总数；没有快照日期；无法区分演示、技术可见与商业可用 |
| 2. 版本与变更管理 | API 或游戏版本说明、变更记录、弃用规则、通知与责任人 | 不兼容变更如何识别？旧版本保留到什么条件？双方由谁确认升级？ | 只有当前文档；没有版本号、变更记录或影响范围 |
| 3. 钱包与集成适配 | 钱包模型说明、资金与记录边界、关键标识符、流程图和责任矩阵 | 单钱包与转账钱包分别由谁记账？现有平台需要哪些适配？ | 把两种钱包说成完全等价；承诺任何平台无需改造 |
| 4. 异常与一致性 | 超时、重复请求、断连、部分成功和状态不明的处理原则 | 请求超时后如何判断是否已生效？哪些操作允许重试？ | 把 HTTP 成功等同于业务成功；用无限重试代替状态确认 |
| 5. 记录、对账与审计 | 稳定业务标识、查询或导出能力、对账字段、差异处理与保留范围 | 能否从请求追到交易、局和账变？差异由谁处理和关闭？ | 只能看到最终余额；无法关联请求、交易与局记录 |
| 6. 测试与验收 | 明确的 staging 范围、测试用例、通过标准、缺陷记录和签署证据 | 除了打开游戏，是否覆盖钱包、异常、记录和权限？ | 只展示正常路径；没有失败证据、验收人或候选版本 |
| 7. 运行支持与责任 | 联系路径、故障升级方式、变更通知机制、职责边界和合同附件 | 出现资金或状态差异时，谁先响应、谁提供证据、谁做决定？ | 只有销售联系人；技术、运营和商务责任互相替代 |
| 8. 市场与合规适用性 | 目标市场、游戏、版本、认证或测试报告的对应关系及有效范围 | 技术可接入是否等于该版本可在目标市场上线？证据是否仍有效？ | 只有徽标或证书截图；没有主体、版本、市场、日期和适用范围 |
1. 游戏目录：先核验“是什么”，再讨论“有多少”
目录证据应当能够回答某个游戏由哪个厂商提供、使用哪个稳定标识、当前是什么状态、快照日期是什么，以及哪些素材被允许用于展示。游戏总数如果没有去重规则、状态定义和更新时间，不能独立支撑采购决策。
建议把“演示可见”“测试环境可用”“商业范围已确认”“目标市场可用”分开记录。四者可能重合，也可能完全不同。
2. 版本管理：确认未来变化如何被发现和处理
采购方不仅要阅读当前 API 文档，还应核验版本号、变更记录、弃用条件、影响评估方式和通知责任。对于游戏内容，还要确认目录变化、版本变化和市场适用性变化是否由同一机制管理。
没有明确的变更证据时，不应自行承诺固定兼容期或无中断升级。
3. 钱包模型：比较责任边界，而不只是接口名称
单钱包通常强调平台侧实时记账，转账钱包通常涉及平台钱包与游戏钱包之间的资金划转。评估重点不是哪一个名词更先进，而是哪一方保存权威账本、如何关联请求与账变、失败后如何确认状态，以及现有系统需要改造什么。
现有产品页面介绍了单钱包与转账钱包两类流程，但具体项目采用哪一类、字段是否适配、是否需要新增流程，仍需结合平台架构确认。
4. 异常处理：供应方要能解释“状态不明”
超时或连接中断只能说明调用方没有得到完整结果，不能自动证明服务端没有执行。供应方应提供异常分类、业务结果判定、唯一标识、查询或对账路径，并说明哪些请求可安全重试。具体算法属于实施设计，应在集成协议中确认，而不是从营销页推断。
5. 记录与对账：要求从业务意图追到最终结果
有效的记录证据，应让双方用稳定标识关联请求、交易、局、金额、币种和最终状态。还要明确查询范围、数据保留、导出、时区以及差异升级流程。只有余额截图，通常不足以判断一次异常是否已经入账、重复入账或仍处于未知状态。
6. 测试与验收：演示成功不是上线验收
测试证据至少要覆盖约定目录、启动与返回、钱包主流程、异常路径、记录查询、对账和权限边界，并保留候选版本、环境、用例、结果、缺陷与签署人。具体执行步骤见《从 staging 到 production 的验收清单》。
7. 运行支持：把“有人联系”变成明确责任
供应方应说明技术问题、目录问题、账务差异、安全事件和商务范围分别由谁接收，升级需要哪些证据，变更通过什么渠道通知。响应目标、可用性或赔偿只有在双方正式约定后才成立，本文不替代合同或 SLA。
8. 市场与合规：建立可追溯的适用矩阵
市场判断应落到“市场 × 游戏 × 版本 × 认证或测试证据”的组合，并记录主体、来源、日期和适用范围。监管或测试要求因市场而异；例如英国赌博委员会将远程博彩技术标准与合规测试要求分别公开，这类官方材料可以说明目标市场需要哪些证据，但不能替代对具体供应方、游戏和版本的核验。
技术可连接、演示可打开或存在一张证书图片，都不等于某个产品已获准在所有市场使用。
建议的采购结论格式
每类证据可以使用以下三种结论，避免用缺乏依据的总分掩盖关键缺口：
- 已核验：材料有来源、日期、适用范围和责任人，并与目标项目一致；
- 有条件通过：已有部分证据，但上线前仍需完成明确的验证或合同条件；
- 待验证：证据未提供、无法追溯，或只存在不带范围的营销表述。
任何涉及资金一致性、生产权限、目标市场适用性或关键责任边界的“待验证”，都应当进入上线阻断项，而不是被其他项目的高分抵消。
当前可用于项目评估的范围
- 公开 API 参考列出 17 个接口，覆盖游戏、会话、钱包与记录等主题；
- 接口示例介绍单钱包与转账钱包两类模式，并展示请求、交易、局等可用于追踪的标识；
- 集成流程将需求确认、技术范围、测试验收和生产前协调分开；
- 页面内容用于前期评估；实际接口、环境和生产验收范围以双方项目文件为准。
使用这些信息时需要注意什么
- 不承诺目录中的游戏均已获得商业授权、持续可用或适用于任一目标市场；
- 不承诺现有 API 版本、接口数量或字段会永久不变；
- 不承诺任何平台零改造接入、固定时间上线、固定性能、SLA 或绝对安全；
- 不把 staging、演示页或公开文档视为生产准入证据；
- 不代替法律、监管、合同、安全或生产技术审查。
常见问题
游戏数量越多，供应方就越好吗？
不一定。总数必须与去重规则、状态、更新时间、商业范围和目标市场适用性一起看。可追溯的小目录，可能比无法证明来源和状态的大数字更有采购价值。
能在演示站打开游戏，是否足以证明可以上线？
不能。演示只能证明某个受控路径当时可访问，不能独立证明钱包、异常、对账、生产权限、商业授权或目标市场适用性。
供应方展示认证徽标，是否还要索取文件？
要。至少应核验认证主体、游戏、版本、市场、签发或测试机构、日期、有效范围和可验证来源。孤立徽标不足以形成适用矩阵。
八类证据是否必须一次全部完成？
尽调可以分阶段，但进入生产前应明确每个缺口的负责人、截止条件和阻断级别。尤其不能把资金一致性、生产访问和市场适用性的未知项默认为通过。
延伸阅读与下一步
如需评估具体项目，可通过“联系我们”提交目标市场、钱包模式、现有平台边界和希望核验的证据范围；AG 再根据已确认材料说明下一步，不预先承诺生产准入或上线时间。
参考资料与适用说明
产品范围可参考 Slots API、集成流程和公开 API 参考。
市场证据示例参考英国赌博委员会的远程博彩与软件技术标准与合规测试策略。这些官方材料只用于说明“目标市场证据需要核验”的方法，不构成对 AG 或任何游戏在英国或其他市场可用的确认。
公开接口版本、目录状态、市场证据和联系流程仍需由相应的技术、商务、运营与合规角色按项目复核。
需要把指南转成项目方案？
文章用于帮助团队梳理采购和接入问题，不替代技术、合同、认证或当地法律确认。