All checks were successful
star-cloud-deploy-demo / deploy-demo (push) Successful in 52s
2.2 KiB
2.2 KiB
[暫緩執行] 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)
- 資料主體:Star Cloud 是直接管理會員資料庫,還是僅作為轉發請求至第三方 CRM 的代理伺服器?
3.2 安全與防雙重消費 (Security)
- 鎖定機制:是否需要在 Redis 實作「會員操作 Session」,防止同一帳號在多台機台同時扣點 (狀態碼 30)?
- Token 時效:回傳之
userToken的有效期與刷新機制。
3.3 線上/線下整合流程
- 訂單轉換:驗證取貨碼成功後,雲端是否應自動產出對應的銷售紀錄單?
3.4 扣點邏輯
- 預扣 vs 實扣:點數與優惠券應於 B650 驗證時預先鎖定,還是待 B602 出貨成功後才正式扣除?
3.5 界面展示需求
- 商品資訊:當
req6 = 2時,回傳的產品清單是否需要包含圖片或詳細描述供機台屏幕顯示?