明确调用顺序、系统职责，以及重复或超时请求的处理方式。
单一钱包由运营平台持有玩家主余额，游戏侧在下注、派彩等动作时实时调用平台钱包；转账钱包则先把金额转入游戏侧钱包，游戏结束后再按业务流程转回。
单一钱包便于统一余额，但要求平台钱包接口稳定并正确处理并发与幂等；转账钱包降低游戏中的实时回调依赖，却增加转入、转出、余额同步和在途资金对账。选择取决于现有账务架构和故障处理能力。
AG GAME API 同时支持单一钱包和转账钱包，项目应在测试前确定模式，因为两者的端点、状态和验收场景不同。
平台先同步厂商、分类和游戏目录，确认游戏可用后，以商户、玩家、游戏、语言、币种及返回地址等参数创建会话，再把获得的启动结果交给前端打开游戏。
生产前还应验证玩家标识稳定、会话过期、重复启动、设备兼容、维护状态、非法参数和返回平台流程。目录存在不等于会话一定可创建。
AG GAME API v5.0.0 提供统一的厂商、分类与游戏查询和游戏会话能力；确切字段、端点和响应以当前 API 文档为准。
游戏侧先按需要查询可用余额，下注请求经平台校验后扣款，游戏结果产生后再派彩；当原交易需要取消或补偿时，撤销必须引用原交易并形成可追踪的新状态。
平台不能只依赖请求到达顺序，应以交易类型、唯一交易号、原交易关联、游戏局号和最终状态驱动账本。下注与派彩可能分开到达，超时也不等于失败。
AG GAME 的统一钱包协作使用请求追踪号、交易号与游戏局号串联调用；具体请求方向和字段随钱包模式而定。
为每笔业务交易分配稳定且唯一的交易编号，并在账本层建立唯一约束。同一编号再次提交时，应返回第一次处理后的同一业务结果，而不是再次改变余额。
幂等判断应覆盖并发重复、网络重试和服务恢复，不能只在应用内短暂缓存。请求内容若与原交易号不一致，应拒绝并记录异常，而不是覆盖原交易。
AG GAME 钱包回调以 transactionId 支持幂等处理，并用 reqTraceId 追踪请求；客户钱包必须持久化交易状态并对重复请求返回一致结果。
超时只表示调用方没有及时收到确定结果，不能直接当作失败并重新扣款。系统应先按原交易号查询或核对状态，再决定重试、撤销、补偿或等待游戏局结算。
玩家断线不会自动取消已经受理的交易。双方应约定重试次数、退避、最终状态、未完成局处理、人工升级和审计记录，并在测试环境重现这些路径。
AG GAME 转账流程要求超时后先查询原 merchantTransactionId，再判断是否重发；钱包回调的重复提交则按 transactionId 幂等处理。
用统一标识、明确口径和分层测量支持日常运营。
先用唯一交易号定位单笔账务，再用游戏局号汇总同一局的下注、派彩、撤销和补偿，最后按统一币种、时区和状态口径与双方报表核对。
差异排查应保留原始请求与响应、处理时间、金额精度、交易关联和最终状态。不要用页面余额或抽样记录代替完整账本。无法自动匹配的项目进入带责任人与结论的差异清单。
AG GAME 的请求追踪号、交易号、商户交易号和游戏局号承担不同用途；报障时应提供与钱包模式相符的标识和时间范围。
双方应约定币种代码、最小金额单位、小数位、舍入规则和可用范围，并用定点整数或十进制定点处理金额，避免二进制浮点误差。
游戏交易币种与合同结算币种可以不同，此时还必须明确汇率来源、取值时间、转换方向和差额处理。任何币种转换都应可追溯，不能在接口两端隐式完成。
AG GAME 列出的 35 个国家或币种代码是能力范围说明；每个项目实际启用的代码、精度和结算安排需在测试与合同中确认。
接口响应时间测量 API 从请求到响应的耗时；游戏加载时间测量用户从启动到可交互的体验；并发能力测量系统在指定请求量和业务组合下维持正确性与目标延迟的能力。
应分别公布测试地区、网络、设备、端点、样本量、P50/P95/P99、错误率、缓存状态和统计周期。只给一个平均值，无法说明峰值体验或交易容量。
AG GAME 当前公开口径包括平均终端延迟低于 150ms 和每日 1 亿订单容量；两项均需结合地区、网络、业务模型与项目容量验证，不能视为所有请求的固定保证。
CDN 可把图片、脚本等可缓存静态资源放到更接近用户的节点，减少传输距离并改善资源加载；动态会话、钱包交易和厂商服务仍需要访问源站或业务系统。
最终体验还受用户网络、DNS、TLS、设备性能、资源大小、缓存命中、中心服务器、厂商响应和运营平台钱包影响，因此要分层测量，而不是把所有延迟归因于 CDN。
AG GAME 使用 4 个区域中心服务器和 200+ CDN 节点支持全球访问；实际项目仍需从目标地区测试静态加载、会话和钱包链路。
把安全边界和服务恢复要求落实到接入与长期维护。
接口应通过加密签名验证请求来源与内容完整性，限制凭据用途和可访问环境，并把测试与生产的商户、密钥、数据和日志分离。密钥应只进入受控配置，不写入前端或公开仓库。
双方还应约定时间戳容差、随机数防重放、密钥发放与更换、异常访问处理和最小化日志。签名验证不能替代传输加密、服务端授权和账本校验。
AG GAME API 使用 HMAC-SHA256，并将 merchantCode、timestamp、nonce、signType 与请求体纳入当前鉴权流程；生产凭据按项目受控提供。
平台应区分单款游戏、单一厂商、聚合层、钱包和网络故障，按影响范围下架或降级，并通过维护状态、监控和工单同步进展。恢复前先确认交易最终状态，再逐步恢复入口。
服务约定应明确监测方式、通知渠道、响应与恢复目标、责任边界和事后记录。不能在没有架构与事件证据时承诺单一厂商故障一定不会影响其他内容。
AG GAME 提供 7×24H 技术支持，并以秒级发现、分钟级响应为监控目标；实际隔离范围和恢复时间由故障层级与项目条件决定。
先冻结现有接口、字段、游戏与交易映射，建立新旧版本兼容表和回滚条件；再用测试流量验证，分批切换新会话，同时让旧链路继续处理已有会话与未结游戏局。
迁移必须保留玩家、游戏、交易和局号关联，明确停止创建旧会话的时间、未结交易查询期限、报表留存及差异处理。不要在余额或交易状态未知时直接关闭旧接口。
AG GAME 当前公开 API 为 v5.0.0。具体升级、兼容期和迁移方案按项目版本、钱包模式和未结交易清单制定。
从项目所需的厂商、游戏、版本和目标地区清单出发，向合作方确认内容来源链路、可提供范围、有效期和限制，并核对相关合同说明、厂商确认或检测材料是否与清单一致。
技术上能返回游戏列表或启动链接，不等于已经证明所有地区和用途均可用。证明材料的充分性取决于具体项目与适用要求，必要时应由客户的专业顾问复核。
AG GAME 会按目标地区和项目条件确认当前可提供的厂商与游戏；公开目录、语言或币种列表不替代项目级材料核验。
与我们商务团队沟通具体合作方案。
