测试模式

一条模拟链，包括三种用其他方式无法演练的故障。

使用 sk_test_ 密钥时，每次调用都针对一条模拟链。端点相同，响应结构相同，事件也相同——唯一的区别是一切都不花钱，而且链会按你的指令行事。

为什么是密钥前缀，而不是单独的主机

因为这样一来，上线到生产环境的代码就是你测试过的代码。单独的沙箱主机意味着有一个必须有人记得去修改的基础网址，以及有人忘了改时出现的那一类错误。

测试数据与正式数据相互隔离；测试密钥看不到正式对象，正式密钥也看不到测试对象。

无需任何 USDT 即可付款

curl -X POST $PAYGATE/v1/test/payments/{id}/pay \
  -H "Authorization: Bearer $KEY" -H "Idempotency-Key: $(uuidgen)" -d '{}'

支付部分金额，即可进入 underpaid 状态：

curl -X POST $PAYGATE/v1/test/payments/{id}/pay \
  -H "Authorization: Bearer $KEY" -H "Idempotency-Key: $(uuidgen)" \
  -d '{"amount_decimal":"10.00"}'

推进链

有区块产生才会有确认。手动推进区块：

curl -X POST $PAYGATE/v1/test/advance \
  -H "Authorization: Bearer $KEY" -H "Idempotency-Key: $(uuidgen)" \
  -d '{"blocks":12}'

最重要的三种情况

链重组。撤销一笔已确认的付款。paid 变为 reversed，并发出 payment.reversed：

curl -X POST $PAYGATE/v1/test/payments/{id}/reorg \
  -H "Authorization: Bearer $KEY" -H "Idempotency-Key: $(uuidgen)" -d '{}'

逾期付款。让一笔付款过期，然后再支付。它会被完成而不是丢失，并触发 payment.late_payment。

少付。见上文。然后再用第二笔部分付款补足，观察付款完成。

如果你的集成从未经历过这三种情况，那它就不算经过测试——只能算做过演示。

测试模式下的扣款授权

定期付款需要客户在链上授权，而在测试模式下，这是一次调用，而不是一次钱包签名：

# 为模拟客户注入资金
curl -X POST $PAYGATE/v1/test/mandates/{id}/fund \
  -H "Authorization: Bearer $KEY" -H "Idempotency-Key: $(uuidgen)" \
  -d '{"amount_decimal":"500.00"}'

# 然后签名
curl -X POST $PAYGATE/v1/test/mandates/{id}/authorize \
  -H "Authorization: Bearer $KEY" -H "Idempotency-Key: $(uuidgen)" -d '{}'

模拟的授权会像真实授权一样触发 mandate.authorized——否则测试模式就会完成扣款授权却不通知任何人，而这个事件是你得知客户已签名的唯一途径。

测试模式不是什么

它不是第二个网关。在构建时未包含模拟链的部署上，/v1/test/* 会返回 501——这是诚实的做法，而 404 会让人以为这个端点从来就不存在。