当前已知问题
4 项未修复。 遇到下面这些，不是你的接入姿势错了 —— 不用再排查，按「怎么绕」那一列处理。
我方刻意不做「一切正常」式的状态页： 一个观测不到真实故障的绿灯，比没有状态页更坏 —— 你会拿它当判据。 这一页只声称一件事：我方知道下面这些。
修复后会在变更日志里登记，这一页的条目转成「已修复」并保留一段时间
—— 删掉它等于让照着旧行为写过绕行代码的人无从知道可以拆了。
status_version 恒为 0影响：Webhook
表现：事件目录里逐条标注了。受影响的事件里，status_version 不随状态变更递增。
怎么绕：对这几条改用「按到达时间 + 拿 ID 回查确认」，不要只靠版本号向前合并 —— 一个「version 不大于当前值就跳过」的合并器会让它们只有第一条生效。
影响：沙盒
表现：注入 timeout / unknown / unknown_status 会返回 200 并回显你设的值，
但后续每一单仍然打真实上游、用真实凭据。
怎么绕：不要依赖沙盒验证上游异常路径。 需要联调这几条时联系你的客户经理， 我方在受控环境里配合你走一遍。
GET /v1/balances 的响应信封与其余清单端点不同影响：余额
表现：它返回 { balances: [...] }，而其余清单端点是 { data, next_cursor, has_more }。
怎么绕：这一个端点单独取 balances 字段；你的通用翻页器会在这里读到 undefined。
影响：会员
表现：用已属其他商户的 email / 手机号建会员会返回 400 invalid_request
（不是 409 —— 我方不下发「这个人已经存在」这种可被用来探测的信息）。
怎么绕：目前无法绕过，身份层的唯一索引尚未按商户拆分。 如果你的用户群与其他 Zise 商户有重叠，请提前告知你的客户经理。
api_error，而不是 4xx影响：兑换 · 站内转账 · 理财 · 扫码付 · 汇款 · 发卡 · 提现地址
表现：「余额不足」「报价过期」「该方向未启用」「地址校验和不对」这类合法的业务拒绝，
对外呈现成 500 api_error，而不是带明确 code 的 4xx。
成因是内部码没登记进对外码目录，走了缺省分支。
2026-08-12 已修复。 这些拒绝现在返回带明确 code 的 4xx。
如果你之前为此写过「对 500 设重试上限」的绕行代码，可以拆了 ——
但保留一个上限总是对的，upstream_timeout(504) 之外的 5xx 不该无限重。
同时新增了守卫 tools/check-open-error-codes.mjs：内部码没登记、
或登记了却零发射点，提交期就红。
影响：GET /v1/cards/{id}/transactions · GET /v1/earn/products/{id} · POST /v1/cards/{id}/replacements
表现：前两个选了不存在的列；第三个漏了 reason 白名单，任意字符串会撞库级约束。
已修复。 修的过程里还抓到第四个同类：GET /v1/cards/{id} 选的
balance_micro 在全部 127 个迁移里一次都没出现过（真名 upstream_balance）——
它同时是卡详情的全部内容、也是流水端点的门，所以流水就算列名全对也进不去。
卡消费流水现在多了一个 direction 出参：amount 是绝对值，
只看金额的话一笔退款与一笔消费长得一模一样。
GET /v1/remittances/{id} 会回显内部状态，且金额格式与列表不一致影响：汇款
表现：详情端点可能返回 pending_merchant_funds（列表与下单口都会折叠成 pending）；
同一笔单的 source_amount 在详情里是未插小数点的定点整数串，
在列表里是十进制串 —— 两者差 10^ledger_scale 倍，而两边都返回 200。
已修复。 三个出口（下单 / 列表 / 详情）现在走同一个映射函数，
不是三份各自的三元表达式 —— 后者正是这类泄漏复发的成因。
金额统一走十进制串并随行下发 ledger_scale。