商户完成链上出款后确认

Scope withdrawals:write 商户自身需 x-idempotency-key 动钱 · 会员 withdrawing 清零，merchant.custody 同额减少

这个端点会动钱

失败处置见下方响应表。超时（504）用同一把幂等键重试——我方可能已经处理完；业务失败要换新键，同键会原样返回那次失败。

withdrawing 清零，merchant.custody 同额减少（你欠会员的少了）。

这是终局，没有撤销接口 —— 只有在链上交易真的成功之后才调它。

以商户主体调用，不需要 x-on-behalf-of（会员是从订单行读出来的）。

并发与重复调用

状态认领在数据库里做（撞 CHECK 回滚整批），不是「先查一次再改」。

所以你可以放心重发：

这单已经是 settled → 200 + replayed: true，不会再记一次账；
这单已经是 failed → 400 order_not_cancellable，

说明另一条路径先赢了，去 GET /v1/withdrawals/{id} 看当前状态；

两个请求同时打进来 → 只有一个真的过账，另一个拿到回放。

⚠ merchant_custody_shortfall 是一个独立于余额不足的错误：

它表示确认这一笔会把你在我方账上的托管余额（该资产）打成负数 ——

也就是你上报的入金总额小于你正在确认的出款总额。

处置不是去充预付，是先把漏报的入金补上报。

前置条件

该单当前状态是 locked（已是 settled 则幂等回放，已是 failed 则拒绝）
你在我方账上该资产的托管余额足够（否则 merchant_custody_shortfall）

路径参数

字段	类型	必填	说明
`id`	string	必填	提现单号，带不带 `wdr_` 前缀都认。

字段	类型	必填	说明
`x-idempotency-key`	string	必填	UUID。

响应

200已确认（replayed: true 表示这次没有再过账）

{
  "id": "wdr_9f1c0b2a-4d33-4a51-9f2e-7c1b0a5d6e88",
  "status": "settled",
  "replayed": false
}

400order_not_cancellable 该单已推进到另一档（多半已 failed） · merchant_custody_shortfall 托管余额不足，先补上报入金

404not_found 不存在 / 属于别的商户

409idempotency_key_reused · idempotency_in_progress

调用样例

curl -X POST 'https://api.zise.com/v1/withdrawals/{id}/confirm' \
  -H 'authorization: Bearer $TOKEN' \
  -H 'x-zise-merchant: $MERCHANT_ID' \
  -H 'x-idempotency-key: $(uuidgen)'

const res = await fetch(
  "https://api.zise.com/v1/withdrawals/{id}/confirm",
  {
    method: "POST",
    headers: {
      "authorization": "Bearer $TOKEN",
      "x-zise-merchant": "MERCHANT_ID",
      "x-idempotency-key": "crypto.randomUUID()"
    },
  },
);
// 金额一律按字符串读，不要 JSON.parse 成 number
const data = await res.json();

import requests

res = requests.post(
    "https://api.zise.com/v1/withdrawals/{id}/confirm",
    headers={
        "authorization": "Bearer $TOKEN",
        "x-zise-merchant": "$MERCHANT_ID",
        "x-idempotency-key": "$(uuidgen)"
    },
)
# 金额用 Decimal(str(...))，不要 float
data = res.json()

商户完成链上出款后确认

前置条件

路径参数

请求头

响应