|
|
@@ -30,7 +30,7 @@
|
|
|
- **渠道不符不用管**：「微信扫不了支付宝的码，反过来也是一样，不用管」⇒ 不做硬拦、不做提示（落点 §4.2）
|
|
|
- **收银台域名与 `notify-url` 同源**（落点 §5.3）
|
|
|
- **开放接口不改**：「一般人不会抓包，就算抓包也抓不到什么有用的信息」⇒ 原「`codeUrl` → `cashierUrl`」提案作废（落点 §4.7）
|
|
|
- - **金额下限 `0.01` 元**（落点 §5.3）；**上限仍缺一个数**，见 §11.1 第 6 条
|
|
|
+ - **金额范围**：下限 `0.01` 元、**上限不额外限制**（落点 §5.3）
|
|
|
|
|
|
---
|
|
|
|
|
|
@@ -378,7 +378,7 @@ GET /payment/cashier/{codeNo}/auth
|
|
|
|---|---|
|
|
|
| `leshouying.cashier-base-url` | 拼收银台地址（二维码内容 + 授权回跳）用。**用户 2026-09-22 裁定：与 `notify-url` 同源**（`https://qcsj88888.com`） |
|
|
|
| `receive.amount-min` | 顾客可输的最小金额，**用户 2026-09-22 裁定：`0.01` 元**（`1` 分） |
|
|
|
-| `receive.amount-max` | 顾客可输的最大金额，**待用户给数**（见 §11.1 第 6 条） |
|
|
|
+| `receive.amount-max` | 顾客可输的最大金额。**用户 2026-09-22 裁定：不额外限制** ⇒ 默认取上游技术上限 `999999.99` 元（`99999999` 分，`total_amount` 是 `string(8)`）。**这是我们不加闸，不是上游说商户真能收这么多**——真上限由上游按商户资质控制，超了会由上游拒。 |
|
|
|
|
|
|
不新增：二维码尺寸、颜色、容错级别。
|
|
|
|
|
|
@@ -575,9 +575,9 @@ CREATE INDEX IF NOT EXISTS idx_receive_code_mch ON pay_receive_code (merc
|
|
|
5. ~~渠道不符怎么办~~ → **不用管**（用户逐字：「微信扫不了支付宝的码，反过来也是一样，不用管」）。落点见 §4.2：不做硬拦、不做提示，`channel` 不参与服务端判断。**已落地文档。**
|
|
|
7. ~~收银台对外域名~~ → **与 `notify-url` 同源**（用户答「可以」）。落点见 §5.3。**已落地文档。**
|
|
|
|
|
|
-**仍待用户给数：**
|
|
|
+**已裁定：**
|
|
|
|
|
|
-6. **金额上限**：下限已定 `0.01` 元。上限还差一个数——上游 `total_amount` 是 `string(8)`，理论上限 999,999.99 元。**这个值在仓库里没有任何依据可推，我不编**，等你给。
|
|
|
+6. ~~金额范围~~ → 下限 **`0.01` 元**，上限 **不额外限制**（取上游技术上限 `999999.99` 元）。落点见 §5.3。
|
|
|
|
|
|
**仍待决定（不阻塞本地开发，阻塞上线）：**
|
|
|
|
alphaH