跳转只意味着用户的浏览器回到了你的网站。它永远不是支付成功的证明。 支付结果的权威来源是 Webhook 通知，Order Inquiry API 作为对账兜底。
用户已经跳回我的网站了，支付是不是成功了？
不一定。successRedirectUrl 只是 UI 导航。请通过以下任一方式确认结果，按优先顺序：
- Webhook 通知——支付完成或失败时，Waffo 会把支付结果推送到你的
notifyUrl。 - Order Inquiry——需要对账时，调用
/api/v1/order/inquiry主动查询订单。
用户在跳转前就关了浏览器，支付是不是失败了？
不是。支付在支付方式一侧仍可能完成。无论用户的浏览器做了什么，Webhook 通知都会触发。如有疑问，调用 Order Inquiry。webUrl 和 successRedirectUrl 有什么区别？
它们的方向相反：
failedRedirectUrl 和 cancelRedirectUrl 以同样方式覆盖失败和用户取消的返回。
每个 orderStatus 值是什么意思？
只有
PAY_SUCCESS 和 ORDER_CLOSE 是终态。
订单超时了，TIMEOUT_CLOSE 和 TIMEOUT_CHANNEL_CLOSE 有什么区别？
两者都是因超时关闭的订单上的失败码。它们告诉你用户在哪里流失了：
用这个区分来分析你的转化漏斗：
TIMEOUT_CLOSE 表示在授权开始前流失，TIMEOUT_CHANNEL_CLOSE 表示流程开始后停滞。当 Waffo 无法判断是否发起过请求时，订单回退为 TIMEOUT_CLOSE。该区分适用于所有支付方式；较早的订单保留其原有的码。
银行转账/柜台支付：为什么有两次通知？
用户在收银台会话之外付款的支付方式——银行转账/虚拟账户（VA）和柜台支付（OTC）——分两个阶段报告：- 受理——订单创建后你会收到一个受理结果。这不是最终支付状态：用户尚未付款。
- 支付结果——只有在用户在其银行、ATM 或柜台完成付款后，最终通知才会到达。
PAY_SUCCESS / ORDER_CLOSE 视为终态。
我没收到Webhook 通知，应该检查什么？
notifyUrl必须是 HTTPS（TLS 1.2+），且可从公网访问。- 用 Waffo 公钥验证
X-SIGNATURE头——并确保你的端点没有拒绝合法请求。 - 处理完成后返回
{"message": "success"}。如果 Waffo 收到failed或unknown，Waffo 会在随后一天内按退避计划重试通知——计划见 Webhook 通知重试。 - 排查期间，用 Order Inquiry 获取订单状态，以免阻塞你的业务流程。
什么时候应该主动调 Order Inquiry 而不是等？
- 在你预期的窗口内没有收到Webhook 通知时，作为对账兜底。
- 当某个请求收到
Exxxxx未知错误时——重试查询直到拿到最终的PAY_SUCCESS或ORDER_CLOSE。 - 在批量对账任务中。
订单创建失败了，我还会收到通知吗？
会。PAYMENT_NOTIFICATION 在支付完成或失败时发送——失败的订单和成功的订单一样会被通知，所以不要只依赖同步的创建响应来构建流程。
通知的内容也比该响应更丰富：
所以被拒绝订单的失败原因可以在通知中和通过 Order Inquiry 获得，而不在创建响应中。用
paymentRequestId 或 merchantOrderId 把通知与你自己的记录匹配；两者都会原样回传。像任何其他Webhook 通知一样进行确认——见 事件类型列表。
我创建订单后，客户还能付多久？
orderExpiredAt 是可选的。若省略，则应用你商户合约中的默认过期时间。它控制的范围比看起来更窄：
- 它决定客户可以在收银台页面提交订单的窗口（必须为 UTC+0）。
- 一旦订单已提交到支付方式，过期时间就由该支付方式决定，而不是你的值。少数支付方式接受商户传入的渠道侧过期时间——商户 Portal 的 Payin 页面显示每个支付方式的过期行为。
- 传入已经过去的时间会在创建时以
A0034（“the order expiry time provided by the merchant has expired”）被拒绝。
一笔线下或银行转账订单已经挂了好几个小时，我要不要取消？
不要。对柜台支付（OTC）和虚拟账户/银行转账支付，客户是在收银台会话之外付款的，所以长时间待支付是正常的，而不是失败的征兆——且自动关闭时间因支付方式而异。 不要根据经过的时间推断失败，也不要在订单仍开放时在你这一侧释放或作废该购买：等待最终通知，或轮询 Order Inquiry。只有PAY_SUCCESS 和 ORDER_CLOSE 是终态。
我同时发了两次相同的请求然后报错了，有哪一次成功了吗？
并发拒绝是保护机制，不是业务失败。用两个并行请求创建同一订单会返回A0040（“the order cannot be created concurrently”），而不是创建两个订单。
这样处理：
- 按订单串行化调用——每个订单同一时刻只有一个在途请求，而不是并行重试。
- 查清状态，不要猜。 在做任何决定之前调用 Order Inquiry 查看订单的实际状态。
- 重试原请求时，复用相同的
paymentRequestId——它是幂等键。A0011和E类未知状态的处理见 错误码速查。
用户说已经付了，但订单显示失败或超时
偶尔会出现支付在支付方式一侧完成，而 Waffo 订单已经因超时被关闭的情况（「先失败、后成功」）。处理方式：- 绝不要凭用户的付款截图发货。 只有当Webhook 通知或 Order Inquiry 报告
PAY_SUCCESS时才发货。 - 把该情况连同订单 ID 报给 Waffo 支持。Waffo 会与支付方式一侧核对该订单；之后要么向你确认该支付，要么把扣款金额退还给用户。
- 用户可能会被要求提供更多细节以定位该交易，所以请收集他们能提供的信息——付款时间、金额，以及支付方式的交易参考号。