你的两个会员之间转账：一步到账，没有待审态，且不能跨商户。

站内转账

GET  /v1/transfers/recipient-types  ← 收款人能用什么标识
POST /v1/transfers/resolve          ← 解析成一个会员
POST /v1/transfers                  ← 转

先读配置，再画界面

GET /v1/transfers/config

限额、费率、备注长度、收款人标识白名单、要不要强认证 —— 全在这里。一个数都别在你那侧写死：我方后台一改，你的界面就与实际不一致，而不一致的表现是「用户填了个合法金额，提交被拒」。

GET /v1/transfers/recipient-types 是它的子集，保留是为了不改已经接了的商户。

fee_payer 决定确认页显示哪两个数

试算

POST /v1/transfers/quotes

不动钱、不建单、不占额度，与 POST /v1/transfers 共用同一份算法 ——各算一份的下场是确认页显示 5、实际扣 8，而两边都 200。

⚠ 限额闸在试算这一步就会拒。在确认页上就告诉用户「超日限额」，比让他按下确认再被拒好。用的是与提交同一组错误码。

⚠ 这不是报价锁定。站内转账没有报价单 —— 它是原子的、即时的，费率来自配置而不是行情。

收款人标识由服务端下发

先问 recipient-types，再渲染输入框。 不同商户开的标识方式不同。

当前可能出现的三种：

开了哪几种由这个端点说了算，不要按上表硬编码。

⚠ 这条约定有来历：旧工程的客户端给了「手机号」这个选项而后端只认

uid / email —— 用户选了它、输入了、必然失败，

而每一次失败还会留一条 rejected 记录。

先解析，再转

POST /v1/transfers/resolve   → { "display_name": "张**" }

解析返回脱敏昵称，给用户二次确认用。

⚠ 这一步不是可选的。 转账一步到账、不可撤销 ——

二次确认是用户唯一一次发现「我把号填错了」的机会。

不能跨商户

只能转给同一个商户下的会员。转给别的商户的会员会解析不到 ——这是隔离，不是故障。

一步到账，没有待审态

成交那一刻钱已经是对方的可用余额了。所以：

• 没有撤销、没有追回、没有代发起
• 要挡就用金额上限直接挡住（大额阈值只打标不拦截）

⚠ 加一道审核就得有钱等在某个桶里，而那是一整套解冻纪律。

这条线刻意不走那条路。

相关端点

• GET /v1/transfers/recipient-types
• POST /v1/transfers/resolve
• POST /v1/transfers