# [暫緩執行] B650 API (會員/點數/取貨碼驗證) 技術規範與執行指南

本文件定義 B650 API 的技術實作規範，用於處理會員驗證、點數折抵、優惠券兌換、取貨碼驗證以及線上訂單線下結帳等多元功能。

---

## 1. 業務功能與驗證類型 (req6)

根據 API 請求中的 `req6` 欄位，B650 提供以下驗證模式：

| req6 | 說明 | 核心流程 |
|------|------|----------|
| `0` | 點擊商品驗證 | 驗證會員資格與點數餘額 |
| `1` | 會員純驗證 | 僅確認會員身份是否有效 |
| `2` | 會員兌換商品清單 | 撈取該會員可使用的兌換券或贈品清單 |
| `3` | 線上訂單線下結帳 | 驗證取貨碼或訂單編號 |
| `4` | 會員贈品 | 處理行銷活動贈品領取 |

---

## 2. 執行面機制 (Execution Strategy)

*   **高可用性請求**：由於會員驗證通常發生在交易前夕，API 必須具備極速響應能力，建議與第三方系統（若有）採用高效能通訊協議。
*   **Response 狀態碼校驗**：系統必須嚴格遵守 PDF 定義的狀態碼（如 `101` 全額折抵, `104` 線上訂單驗證成功, `30` 會員使用中等）進行前端反饋。

---

## 3. 待確認事項 (To-be-confirmed)

以下議題目前皆列為**待確認**，將於 Phase 2 或後續討論中釐清：

### 3.1 會員系統架構 (Architecture)
1.  **資料主體**：Star Cloud 是直接管理會員資料庫，還是僅作為轉發請求至第三方 CRM 的代理伺服器？

### 3.2 安全與防雙重消費 (Security)
2.  **鎖定機制**：是否需要在 Redis 實作「會員操作 Session」，防止同一帳號在多台機台同時扣點 (狀態碼 30)？
3.  **Token 時效**：回傳之 `userToken` 的有效期與刷新機制。

### 3.3 線上/線下整合流程
4.  **訂單轉換**：驗證取貨碼成功後，雲端是否應自動產出對應的銷售紀錄單？

### 3.4 扣點邏輯
5.  **預扣 vs 實扣**：點數與優惠券應於 B650 驗證時預先鎖定，還是待 B602 出貨成功後才正式扣除？

### 3.5 界面展示需求
6.  **商品資訊**：當 `req6 = 2` 時，回傳的產品清單是否需要包含圖片或詳細描述供機台屏幕顯示？