加密货币支付集成测试：上线前检查清单

测试加密货币支付集成，要证明的是：只有核实付款后，正确的订单才会且只会履约一次，而不只是支付页面能打开。 将消息投递测试、应用的订单状态测试，以及任何经过授权的真实资金验收分开进行。它们各自回答不同的问题。

这份清单面向准备上线支付流程的开发者和商家，也适用于所选资产和网络确实可用的 USDC 或 USDT 支付。这是一套建议的测试流程，并不表示 Yolfi 已针对你的应用通过这些测试，也不表示 Yolfi 提供完整的测试网支付流程。

先明确正在进行哪一类测试

模拟支付通知不是区块链转账。测试网转账不是生产网络上的支付。浏览器成功跳转也不能证明其中任何一项。

Ethereum 网络指南说明，账户余额和交易历史不会在相互独立的网络之间通用。地址看起来相同，并不意味着测试网资金可以在主网使用。应查阅服务商的最新文档，不要认为通用的钱包测试同样适用于其支付服务。

先以书面形式界定测试范围

发送任何内容之前，记录应用环境、服务商账户、接收端 URL、签名密钥存放位置、订单 ID 和预期副作用。模拟场景应使用可丢弃的客户记录，并禁用真实发货、付费访问权限和客户邮件。

将测试配置与生产配置分开。切勿把签名密钥复制到文章、截图、问题单或聊天记录中。测试证据应标明使用的密钥版本，而不是暴露密钥值。调查测试失败时，不要向买家索要钱包助记词或私钥。

进行真实资金验收前，应就金额、费用、收款地址和负责人获得明确的内部授权。使用企业控制的钱包，金额应在可承受损失的范围内。不要仅因为某个地址或网络出现在旧截图、自动生成的币种页面或非官方测试说明中，就向其转账。

验证订单金额由服务端控制

在 Yolfi API 支付流程中，商家服务端使用最终金额和币种创建 Checkout Session（支付会话）。买家随后选择受支持的网络和代币，并基于该会话生成 Invoice（支付账单）。可重复使用的 Paylink 与服务端定价的动态订单用途不同。

对于动态购物车，在测试资金转移之前，先测试服务端自身的价格计算和会话关联：

• 修改浏览器提交的总金额，确认它不能覆盖服务端确定的订单价格。
• 尝试使用其他客户的订单引用，确认应用拒绝未经授权的访问。
• 刷新或重新打开支付流程，检查重复尝试是否仍关联到预期订单。
• 创建会话后修改购物车，确认应用对替换或拒绝旧支付尝试有明确规则。

这些是应用验收标准，并不表示服务商端点会拒绝所有可能的请求。应将服务端订单引用与返回的会话引用一并保存。不要编造 API 字段，也不要假定浏览器可控的标识符能够证明订单归属。

发送测试 Webhook，但不产生真实销售

当前的 Yolfi Webhook 文档介绍了从控制台发送的测试事件，它与真实事件使用相同的投递路径、适配器和签名请求头。其载荷包含 livemode: false 和以 evt_test_ 开头的事件 ID。该测试不会创建账单、支付事件、订阅或客户记录。

用这个事件检查投递和载荷处理，而不是结算。接收端即使返回 200 OK，仍可能错误地授予访问权限，或悄无声息地丢弃消息。除了投递结果，还应检查由此产生的应用状态。

按照文档所述流程，使用该端点专属的签名密钥验证签名，而不是使用组织 API 密钥。确认线上履约流程不会把测试事件当成已付款订单。如果在隔离测试环境中使用测试数据演练履约，应使用可丢弃记录，并与生产记录分开检查。

Yolfi 要求接收地址为公开可访问的 HTTP 或 HTTPS 地址，且不会跟随重定向。对于本地开发，文档建议使用公开的 HTTPS 隧道。应核对最终接收端的完整 URL；请求另一路径或仅限本地访问的地址成功，并不能证明服务商投递成功。

使用故障矩阵，而不只是正常流程截图

对于服务商测试发送功能无法覆盖的情况，应使用受控测试数据，在自己的隔离测试环境中验证。明确标注这些是应用测试；不要把伪造的服务商事件当成真实支付证据。

在 Yolfi 中，invoice.created 表示支付发起；文档规定的履约触发事件是 payment.confirmed。不要仅因为收到第一条消息，就将订单设为已付款。Webhook 幂等处理指南介绍了持久化去重；本清单重点在于收集证据，证明你的实现确实具备这些行为。

应主动测试恢复能力。流程若在存储事件之前就返回成功，崩溃后可能丢失待处理任务。若在记录完成状态之前交付商品，重试后可能重复交付。先选择可靠的持久化处理方案，再在可能中断的位置开展测试，不要认为单次请求成功就能证明可靠性。

检查买家指引和未解决付款的处理路径

在手机和桌面端打开实际支付流程。检查转账前展示的金额、所选资产、网络、收款地址和有效期信息是否清晰易懂。测试复制功能和二维码扫描，不要假定二维码会自动为所有付款钱包正确设置全部参数。

不要仅为测试错误提示，就发送不受支持的代币、故意选错网络或进行不可逆转账。应改用受控记录演练这些客服处理场景。防止转错网络指南说明了应提供给买家的检查项。

演练订单未付款或已过期的情况：买家应收到清晰的状态说明和安全的下一步操作，而不是没有依据的资金追回承诺。参考过期账单处理流程，确定再次要求付款前需要调查的内容。第一笔支付状态不明时，不应自动要求再付一次。

获得授权后，记录一次真实支付验收

只有确认所选生产资产和网络在实际流程中可用后，才能继续。将所需网络手续费纳入考虑，并确保收款地址由企业控制。服务商测试 Webhook 成功，并不足以证明可以经由未经验证的路径转入真实资金。

记录订单与支付引用、实际资产和网络、金额、观测到的确认情况、收款钱包证据以及最终履约状态。不要承诺通用的确认次数或结算时间。核实实际观测到的结果，而不只是查看钱包截图。

然后，将该笔支付与订单及收据记录进行核对。对账检查清单有助于区分到账资金、订单分配金额和费用。如果计划退回验收款项，应单独授权并验证退款；不要假定它会自动原路撤销。

验收通过，只能证明某一时点观察到的某一条支付路径可行。支付逻辑、接收端部署、密钥或支持的路径发生变化时，应重新进行相关验收测试。切勿将一笔 USDC 支付成功推广为所有 USDT 网络都可用的证明。

保留上线验收记录

保存一份简明报告，列明被测应用版本、环境、场景、预期结果、实际结果和未解决问题。链接到私有日志和订单记录，不要公开客户标识符或完整钱包历史。

若测试事件能触发真实订单履约、重复事件能造成重复交付、无效签名能更改状态，或已确认支付无法安全匹配订单，就应阻止上线。为每个未解决问题指定负责人。绿色的投递成功标记不能替代这些业务结果。

常见问题

Yolfi 测试 Webhook 会转移加密货币吗？

不会。文档所述测试仅验证投递和载荷处理，不会创建账单或支付记录。它不能证明真实区块链支付已经成功。

测试网支付等同于支付服务沙箱吗？

不等同。测试网是独立的区块链网络；服务商沙箱是该服务专用的环境。应核实服务商是否支持你需要的特定模式；本文并不证明 Yolfi 提供测试网支付流程。

支付页面成功跳转后就可以上线吗？

仅凭这一点还不行。应验证服务端支付处理、订单匹配、重复防护和故障恢复。买家可能在任何返回页面打开之前就关闭浏览器。

是否必须用真实资金测试每一种故障？

不必。应使用隔离的应用测试和文档规定的服务商模拟功能来验证故障处理。任何真实支付验收都需要授权，并确认路径受到支持，而不是故意向错误网络转账。

结论：上线前先验证业务结果

先明确范围，验证服务端订单处理，并区分模拟事件与已核实到账的资金。适合固定价格的商品或服务可使用 Yolfi 支付链接，动态订单则使用文档所述 API 流程；随后保留证据，证明控制履约的是支付处理，而不是浏览器跳转。