01 / 流程
让业务引用贯穿每个事件
从一开始让付款、玩家或订单以及结算记录共享引用，集成会更便于运营。
- 01
创建会话
按照当前文档规定的请求结构，发送所需金额、币种、业务引用和返回上下文。
- 02
展示付款体验
将客户引导至为该会话返回的已配置收银台或付款路径。
- 03
处理已记录事件
验证并处理当前 API 文档所述的事件类型和字段。
- 04
入账并对账
使用付款引用关联事件、目标玩家或订单、入账金额和结算记录。
02 / 运营
影响运营的集成选择
有用的集成不只是打开收银台，还会保留上线后运营方所需的引用、状态和失败路径。
引用设计
选择稳定的玩家、订单或发票引用，确保在运营方系统和 Payfux 记录中都能找到。
事件处理
只处理文档规定的事件字段和状态，并保留收到的引用用于审计和对账。
返回行为
把客户返回视为界面导航，而不是付款或结算已经完成的最终证据。
对账路径
在运营方自己的系统中连接付款和结算记录，以便按引用调查差异。
03 / 要求
以当前文档为准
营销示例说明集成流程，但不定义生产端点、载荷、签名、重试、状态值或服务级别。
- 仅使用针对客户环境提供的当前 API 文档中规定的身份验证方式和请求字段。
- 不要把浏览器返回视为权威付款证据；应使用文档规定的服务器端状态和事件模型。
- 根据集成文档规定的行为测试失败、重复、延迟和状态变化处理。
04 / 问题
运营商常见问题
当前 Payfux API 数据结构在哪里？
当前数据结构、身份验证要求和请求字段均在 Payfux API 文档中。产品页面上的代码示例只用于说明，不能替代正式文档。
浏览器返回时应将付款标记为已完成吗？
不应。客户返回只是导航。运营方应使用文档规定的服务器端付款状态和事件证据进行入账和对账。
Payfux 是否承诺特定的事件重试时间表？
本页没有声明任何重试时间表。请实施当前客户文档中规定的事件和恢复行为。
运营方应发送哪个业务引用？
使用文档所述集成要求的稳定玩家、客户、发票或订单引用，并在运营方系统中保留该引用。
测试记录和生产记录可以混用吗？
不可以。不同环境的凭据、端点、记录和对账必须分开，并遵循文档规定的环境控制。