试算是纯计算 —— 不建单、不冻结、没有 quote_id。成交价在分发那一刻才定。
试算
POST /v1/remit/quotes
不建单、不冻结、不写任何库、不带幂等键。 纯读 + 纯算，可以随用户输入连续调。
⚠⚠ 没有
quote_id，也没有「报价有效期」。这个端点不返回可以拿去下单的凭据 ——
POST /v1/remittances也不收。下单时价格会重新算一遍。
别按「报价 → 锁价 → 用 quote_id 下单」设计你的流程，这条线不是那样的。
（站内兑换才有锁价，见站内兑换。）
两个方向，二选一
| 你给 | 我方算出 |
|---|---|
payout_amount（收款人收多少） | customer_total（会员实付多少） |
source_amount（会员出多少） | payout_amount（反算） |
两个都给或都不给一律 400 —— 静默挑一个会让另一个数字看起来被忽略了。
反方向保证：正向算回来的 customer_total ≤ 你说的那个数（每步向下取整）。反了就是未经同意的多扣。
必读：indicative_rate 与 applied_rate 是两个数
| 字段 | 是什么 | 给谁看 |
|---|---|---|
indicative_rate | 上游此刻报的价 | 留给复盘 |
applied_rate | 实际用来折算到账额的那个价 | 给用户看这个 |
⚠ 只拿
indicative_rate算，你界面上的三个数字推不出到账金额。2026-08-10 实测差 2.37%，而那个差额不出现在任何一项费用里 ——
用户会认为你在偷偷加价。
两个都不是成交价。 成交价在分发那一刻确定，由用户设的滑点上限罩着。
汇率取不到是 200，不是 5xx
rate_available: false + reason 说明为什么，手续费仍然给（那部分本地算得出）。
把汇率那一格标成不可用、其余照常渲染 —— 一起藏起来会让用户以为整个功能坏了。
reason 三种，处置完全不同：
reason | 意思 | 你该说什么 |
|---|---|---|
remit_settlement_unconfigured | 我方配置问题 | 用户等也没用 |
remit_rate_unavailable | 上游暂时取不到 | 「稍后重试」 |
remit_amount_too_small | 伴随 amount_too_small: true | 「金额太小，改一下」 —— 别渲染成「稍后再试」 |
below_min 由我方判，你不要自己再比一次
你手里有 min_amount，但真正的判据在 payout 网格上 ——你算不出来（没有费率、没有折价、没有锚定汇率）。
⚠ 自己比的下场：用户填「我出 10 USDT」而最低额正好是 10，
被你自己的界面挡住 —— 往返换算的量化误差正好落在边界上。
原样回显的两个字段是给你对齐用的
响应会把 line 与你填的那一侧金额（source_amount）原样回显。
⚠ 用它们判断「这份响应是不是我这次输入算出来的」——
响应到达顺序 ≠ 发出顺序。
反方向上这件事没有别的判据：算回来的 payout 与用户填的 source 天然不相等，
而
customer_total也只是 ≤ 输入、不是等于。拿它们去比对永远不匹配，界面就会一直停在「更新中」。
费用明细是给你看的，不一定给用户看
报价里的费用是你要付我方的。你向会员收多少是你自己定的（在商户后台配零售价），两者的差是你的毛利。
界面上给用户看哪个数由你决定 ——但别把我方的批发价当成用户实付展示。