justsolutionsWebV2 · plans-plus 真實 API 對接分析

1. 結論速覽（含本次更正）

plans-plus 前端目前依賴 3 條「只讀目錄」端點（editions / plans/catalog / countries）、2 條「交互查詢」端點（agents / tenants/lookup）、1 組單次查詢端點（single-query，新）、2 條「下單提交」端點（subscribe / payments）、以及 1 條「聯絡我們」通知端點（contact——不創建訂單，僅發送訂單摘要），共 4 種訂閱流程：new（新購）、renew（續費）、topup（加購）、single（按次查詢）。

2. 總體架構與調用鏈

justsolutionsWebV2 採「BFF（Backend-for-Frontend）」式：瀏覽器只調用本站 /api/*，由 Node/Express 依 APP_ENV 決定走 mock 還是真實後端，前端代碼零改動即可切換環境。

• 前端封裝 public/js/api.js：api.get('/editions') 實際請求 /api/editions。所有 plans-plus 端點均走此封裝。
• 環境切換 server/config.js：mockEnabled = (APP_ENV==='test')；另有 plansPlusMock（PLANS_PLUS_MOCK）開關——在真實環境下仍讓 plans-plus 這組端點走 mock，其餘 /api/* 透傳後端。真實對接時把它置 false，並在 server/routes/ 補齊業務路由。
• 掛載順序 server/index.js：真實環境依次掛 contact / trial-application / industries / countries 路由，再按 plansPlusMock 決定是否掛 mock，最後掛 proxy 兜底。新增 plans-plus 真實路由就照此在代理之前追加 app.use(apiPrefix, createXxxRouter(config))。
• 鑑權 server/services/auth.js：OAuth2 password 流程取 token 並緩存（提前 5 分鐘刷新），對應旧站硬編碼的門戶訪客憑證，現改為 .env 配置（AUTH_USERNAME/PASSWORD/CLIENT_ID/...）。BFF 每次調後端用 createAuthConfig() 加 Authorization: Bearer。

3. plans-plus 前端依賴的 API 契約

以下是 plans-plus.js 實際讀寫的字段（即 BFF 必須產出/接受的契約，目前由 mock/plans-plus.js 滿足）。真實對接時 BFF 輸出必須與此逐字段一致，否則前端渲染/計價會出錯。

3.1 載入期（頁面初始化並發拉取 loadAll()）

並發請求 /editions、/plans/catalog、/countries、/single-query/options，四者均以 { success:true, data:… } 為成功標誌。

GET /editions     → { success, data:{ editionList:[{id, displayName, nameCN, nameJP}],
                                       jQSeparatedEditions:{ editionIds:[…] } } }
GET /plans/catalog→ { success, data:{ standard:[Plan], cpa:[Plan], addons:{
                       user:{ unitPrice, name* },
                       kyc:{ monthlyPrice, name* },                 // ← 改為「月租」
                       jquota:{ packages:[{id, jq, price, name*}] } } } }
GET /countries    → { success, data:[{code, name, nameTC, nameSC, nameJP, phoneCode}] }
GET /single-query/options → { success, data:{ operations:[
                       {id, nameCN/EN/JP, descCN/EN/JP}] } }  // ← 固定 4 項純展示，不可勾選/取消；price 不再逐項計
// 固定 4 項：證件核驗(V) / 名單篩查ES(E) / AI 增強型篩查(A) / 信貸記錄篩查失信人(D)
// PAYG 收款價 → 取 GetPlanList(countryCode) 的 PAYG(P2G) 方案 price（單一整包價，非分項之和）
POST /amlPortal/plan/portal/GetPlanList  body = {   // ← PAYG 定價來源（沿用旧站請求體 + countryCode）
   pageIndex:0, pageSize:100, filter:"", getAllItems:false,
   tag1List:[], tag2List:[], tag3List:[], countryCode:"JPN" }   // 目前 countryCode 僅日本一國

Plan = { planId, tag2Code, nameCN, nameEN, nameJP, periodMonths,
         price, originalPrice, qCount(-1=無限), userCountLimit,
         bestValue, noteCN, noteEN, noteJP }

3.2 交互期（按需）

GET /tenants/lookup?email=          // ← 只按郵箱；郵箱全局唯一 → 至多命中 1 個租戶
   → { success, match:'none'|'unique', tenant:Tenant|null }
      // 註：前端已不再做「一郵箱多租戶」消歧；舊契約的 match:'multiple' / candidates[] 已廢棄
GET /agents/:code
   → { success, found:bool, data:{ code, name, tiers:[tag2Code…], email, phone }|null }
      // tiers：該推薦人可售的方案級別（P2G/Std/Pre/CPA），前端據此再過濾行業方案集

Tenant = { tenantId, tenantName, editionId, editionName, jurisdiction, br, ci,
           referrer:{code,name}|null,                    // ← 註冊時填寫的推薦人，續費頁展示
           currentSubscription:{ planId, nameCN/EN/JP, periodMonths, price,
             qCount, userCountLimit, startDate, expiryDate, usedQuota,
             addons:{ users:int, kyc:bool, jquotaPackageId:string } } }

3.3 提交期

submit()（在線下單）與 submitContact()（聯絡我們/推薦人）共用 collectPayload() 收集當前表單。本輪支付除外——submit() 只 POST /subscribe，成功即顯示「已提交成功」；submitContact() 不創建任何訂單，把訂單摘要 POST 到聯絡端點（見 5.8），成功後顯示「已收到資料，將盡快聯絡」。（現網代碼仍 POST /subscribe-offline；本次語義調整後應改走 contact us API，見 5.8「與現網代碼的差異」。）

POST /subscribe  body = {
   type:'new'|'renew'|'topup', edition, isCpa, startDate,
   plan:Plan, planPrice, isRenewalRate,
   addons:{ users, userUnitPrice,
            kyc, kycUnitPrice, kycRentalMonths,                    // ← 含租賃月數
            jquotaPackageId, jquotaPackageName, jquotaUnits, jquotaPrice },
   agentCode, subtotal, total,
   // type=new 追加： subjectType('corp'|'individual'), company, jurisdiction, br,
   //                contact, phoneCode, phone, email, address
   //                （個人主體：contact=company，br/address 恒為空）
   // type=renew/topup 追加： tenantId, company, email, currentSubscription
 } → { success, data:{ orderId, status, createdAt } }

POST /contact  body = {              // ← 聯絡我們/推薦人：不創建訂單，僅發送摘要
   name, email, company,            // 客戶聯絡人 / 郵箱 / 公司(租戶/主體)名
   subject:'訂閱諮詢 · {type}',       // 可帶方案名
   message: ,
   agentUserId?                      // 有推薦人時附帶其後端 Guid → 後端解析郵箱、收件人改為該推薦人
 } → { success, data:{ feedbackId } }

POST /single-query body = {
   type:'single', subjectType:'individual'|'company', subject, email,
   operations:[{id, name, price}], total
 } → { success, data:{ orderId, status, createdAt } }

4. 後端真實端點清單（AMLPortal）

1–11 均在 AML_Backend/modules/iCON.Abp.AMLPortal，並已被旧站 justsolutionsWeb/PlanService 使用驗證過。前綴 /api/amlPortal/*（agent 校驗端點在 Identity 模塊 /api/identity/*）。12–13 為單次查詢用到的方法，位於 AML 主模塊 iCON.Abp.AML（/api/aml/ConsumerPortal/*）；但由 AML 後端在支付完成後內部編排調用，V2 BFF 不代理、瀏覽器不直調（見 5.6）。

DTO 位置：Application.Contracts/PlanAppLayer/*（GetPlanListParam、PlanDto、PlanDetailDto）、Application.Contracts/OrderAppLayer/*（CreateOrderParam、SelectPlanItem、TenantRenewalParam、QueryRenewableTenantParam、TenantPropertyDto）。agent 返回 DTO：iCON.Abp.FX.Users/AppUserDto。單次查詢 DTO：iCON.Abp.AML/Application.Contracts/ConsumerPortalAppLayer/*（CreateConsumerLinkParam、CreateConsumerCustomerDto、CreateConsumerLinkDto、CreateConsumerOrderParam、ConsumerLinkDto）+ IndividualAppLayer/CreateIndividualDto、OrgLayer/CreateOrganizationDto。

5. 端點逐一映射與落地方案

每節：前端契約 → 對應後端 → 字段映射 → BFF 轉換要點 → 差異/缺口。新增的 BFF 文件建議放 server/routes/，與 countries.js 同範式（createAuthConfig() + axios + 字段映射 + {success,data} 包裝）。

5.1 GET /editions（所屬行業） 改造

後端返回 { code:0, data:{ editionList:[完整 Edition 實體], jQSeparatedEditions:{ EditionIds:[…], EditionNames:[…] } } }（OrderService.cs:1103 直接把 SaasEdition 實體與 _appConfig.Portal.jQSeparatedEditions 原樣返回）。前端要 editionList:[{id, displayName, nameCN, nameJP}] 與 jQSeparatedEditions.editionIds。

5.2 GET /plans/catalog（方案目錄） 改造

BFF 以旧站同款請求體調 GetPlanList，再復刻旧站 filterPlan() 把扁平 items 按 tag1Code 拆成 5 組，組裝成 {standard, cpa, addons}。

請求體（沿用 PlanService.getAllPlanList）

{ pageIndex:0, pageSize:9999, filter:'', getAllItems:false,
  tag1List:['B','jQ','j','AdlU','KYC'], tag2List:[], tag3List:[], agentUserId:null }
  // 後端 GetPlanList 對 Tag2List/Tag3List：命中或 Tag2Code 為空皆放行（OrderService/PlanService:78-80）

後端返回 { code:0, data:{ totalCount, items:[PlanDto{…, planDetails:[PlanDetailDto]}] } }（PlanService.cs:107 PagedResultDto<PlanDto>）。注意：getAllItems:false 時後端已過濾 Enabled 且僅保留在有效期內的 planDetails（PlanService.cs:99-104）。

後端 items → 前端 Plan 字段映射

addons 拆分（按 tag1Code）

• standard ← tag1Code==='B' && tag2Code!=='CPA'；cpa ← tag1Code==='B' && tag2Code==='CPA'
• addons.user.unitPrice ← tag1Code==='AdlU' 的 planDetails[0].price（並記其 planId/planDetailId 備下單）
• addons.kyc.monthlyPrice ← tag1Code==='KYC' 的 planDetails[0].price（當作月租單價，見下方 KYC 映射）
• addons.jquota.packages[] ← tag1Code==='jQ'||'j'：每項 { id:planId, jq:qCount, price:planDetails[0].price, name* }，並各自記 planDetailId

5.3 GET /countries（註冊地） 已實現

server/routes/countries.js 已實現並可直接用：取 typeCodes:['COUNTRY']，從 categoryTranslations 提 zh-hk/zh-cn/ja/en-us，輸出 {code, name, nameTC, nameSC, nameJP, phoneCode}，正好滿足 plans-plus 的 countryDisplay() 與 phoneCode 自動填充。無需改動（種子含 249 個國家）。

5.4 GET /agents/:code（推薦人代理 + tiers） 改造

前端要 { success, found, data:{ code, name, tiers:[tag2Code…], email, phone } }。後端 SearchUserByCodeAndType 按 UserCode 精確匹配，返回 List<AppUserDto>（{Id, UserName, Email, Name, Surname, PhoneNumber, ExtraProperties}）。BFF 取首條做轉換；無匹配 → found:false。

5.5 GET /tenants/lookup（按郵箱查租戶）需後端新增端點

前端按郵箱查租戶，返回 match:'none'|'unique' 兩態（不再多租戶消歧——註釋明確「租戶名與郵箱均全局唯一 → 一郵箱至多 1 個租戶」）。命中後帶出 currentSubscription + referrer 預填續費/加購表單。

但現有後端 queryRenewableTenant 只接受 {keyword} 且按 TenantName.Contains(keyword) 在 DB 層搜索（OrderService.cs:2362-2364），返回 List<TenantPropertyDto>——TenantAdminEmail 是查完命中租戶後、再 GetAllUsers() 遍歷全庫用戶按 UserName=='admin' && TenantId 逐條回填（:2369-2379），邏輯上「先有租戶、後有郵箱」，無法在 DB 層按郵箱過濾。⇒ 前端「給郵箱、要唯一命中」的查詢維度與現端點根本錯位。

新增端點設計（供後端實作參照）

• 入參 QueryRenewableTenantByEmailParam { string Email }（新 DTO，置於 Application.Contracts/OrderAppLayer/，與 QueryRenewableTenantParam 並列）。鑑權沿用現 queryRenewableTenant 的 [AbpAutoAuth("Portal")]，BFF 免自帶 token（見第 6 章）。
• 反查邏輯（維度反轉，且省掉全庫掃描）：
  ① 禁用多租戶過濾 _dataFilter.Disable<IMultiTenant>()，按郵箱定位租戶管理員用戶——沿用現端點「admin 郵箱 = UserName=='admin' 用戶的 Email」語義：可直接復用現 GetAllUsers() 全庫掃描（與現 queryRenewableTenant 一致），改在內存按 u.UserName=='admin' && u.Email==Email 過濾即可（郵箱全局唯一 → 至多 1 條）。全庫掃描在此可接受——租戶 / 管理員用戶數量少、續費查詢為低頻交互，無需為此下推 DB 過濾或加索引。無命中 → 回空 ⇒ 前端 match:'none'。
  ② 取該用戶 TenantId 對應的 active TenantProperty（IsActive && TargetTenantID==tenantId，按 CreationTime 取最新一條），並校驗其可續費（TenantStatus / EffectiveEndTime——過期仍返回，由前端做「過期/臨期」展示，見 5.7 topup 阻斷）。
  ③ 組裝聚合返回：referrer 直取 AgentorCode/AgentorName；currentSubscription 明細（planId / 名稱 / periodMonths / price / addons）沿用 GetCurrServiceInfo（OrderService.cs:398-418）的 Order → OrderDetails → Plan/PlanDetail 反查思路，區別是它以 CurrentTenant.Id 為基、此處以顯式 TargetTenantID 為基（Portal 上下文 + 禁多租戶過濾）。
• 返回：建議新增聚合 DTO（RenewableTenantDto = TenantPropertyDto 關鍵字段 + referrer + 明細化 currentSubscription），讓 BFF 幾乎直通轉發，不必自己再拼訂單明細。

TenantPropertyDto → 前端 Tenant 映射（可得部分）

5.6 單次查詢 single-query（隨付即用 · Pay-As-You-Go） 後端已支持 · 後端內部編排

職責邊界與調用鏈

後端內部兩步（payload 供參考）

第 1 步 · 建即時檢測鏈接 CreateConsumerLink（ConsumerPortalService.cs:964）：以「結果接收郵箱」upsert ConsumerCustomer，在當前 2C 租戶下建鏈接 → 回 ConsumerLinkDto（含 accessToken）。

{ "createConsumerCustomerDto": { "email":"result@company.com", "name":null, "phone":null, "remark":null },
  "createConsumerLinkDto":     { "functionCodes":"EAVD", "validHours":72,
                                 "validEndTime":"2026-07-09T06:00:47.000Z" } }
// 回：OperationDto.Success(ConsumerLinkDto{ accessToken, functionCodes, expireTime, tenantId, … })

第 2 步 · 建訂單並即時檢測 CreateConsumerOrder（:325）：據 token 定位鏈接與租戶 → 計價(jQ) → 建 Individual/Organization 實體 → 建 ConsumerPortalOrder（直接置 PaymentStatus=Paid、OrderStatus=Pendding，:388）→ 每個 functionCode 建一條 DetectionTask → 發 RabbitMQ 消息，由 ProcessConsumerPortalOrder 異步跑檢測模塊，完成後 SendConsumerLinkResultMail 發結果郵件。

{ "accessToken":"xxx", "objectType":"Individual",
  "individual": { "fullNameEN":"张三", "fullNameZH":"", "dateOfBirth":{"year":0,"month":0,"day":0},
                  "address":"", "addressOfLiving":"", "nationalityCode":null,
                  "documentRequiredFileIds":[], "identityDocumentTypeCode":"", "identityDocumentNumber":"",
                  "gender":"", "phone":"", "email":"", "occupation":"", "entityIdentityDocuments":[] },
  "organization": null,
  "functionCodes": ["E","A","V","D"] }   // ← 固定 4 項（PAYG 檢測內容不可選）
// 回：OperationDto.Success({ entity, order })   // order.Id / order.OrderCode 可作結果查詢鍵

V2 收集字段 ↔ 後端入參映射

V2 通過 POST /single-query（或銜接端點）把下列字段交給後端；後端在內部編排時據此組裝上面兩個 payload。

鑑權（均在後端內部滿足）

結果回取（可選）

• 檢測異步完成後後端自動發結果郵件（滿足 V2「結果將發送至此郵箱」文案），V2 可不輪詢。
• 若 V2 要頁內展示：POST /api/aml/ConsumerPortal/Get2CRecordDetail/{accessToken} 或 /Get2CRecordDetailByOrderId/{orderId}（均匿名）取檢測記錄；/CheckAndGenerateReport 生成 CDD 報告 PDF。（此類只讀回取因匿名，才可能由 V2/瀏覽器直取。）

5.7 POST /subscribe（下單） 改造

BFF 依 body.type 分流；核心是組裝 PlanList（基礎方案 + 各加值項，每項補 planDetailId）。

① type='new' → CreateOrder

② type='renew' → TenantRenewal

續費續價：後端按 planDetail 的 Price 計；前端的「續費續價（沿用上期 price）」屬展示層優惠，後端不認前端傳入的 price。若要真正續價，需後端支持自定義價 / 專屬續費 PlanDetail——本輪按目錄價下單，前端續費折扣僅為展示（待業務確認）。

③ type='topup' → TenantRenewal（僅加值項） 需後端確認語義

純加購（無基礎方案，只買 增加用戶/KYC/jQuota）。後端無專屬端點。候選 A（推薦）：復用 TenantRenewal，PlanList 只含加值項（不含 B 類）。源碼上 TenantRenewal 只對 Tag1Code==='B' 的行設服務起止期（:2300-2314），非 B 行只疊加配額/用戶 ⇒ 理論上「只疊配額不延期」語義成立，但需確認 ProcessTenantEventQueue 下游對「無 B 行的續費單」處理正確。候選 B：後端新增 TenantTopup（可借鑒 admin 的 UpdateTenantProperty :2389，它就是疊 PlanList 重算配額）。

PlanList 組裝（三種 type 共用，核心難點）

PlanList = []
// 基礎方案（topup 不加）
if (type!=='topup') PlanList.push({ PlanId: plan.planId,
                                    PlanDetailId: plan.planDetailId, PCS: 1 })
// 增加用戶：PCS = addons.users
if (addons.users>0) PlanList.push({ PlanId: AdlU.planId,
                                    PlanDetailId: AdlU.planDetailId, PCS: addons.users })
// KYC（設備月租）：PCS = kycRentalMonths（把 KYC planDetail.price 當月租單價；見 5.2）
if (addons.kyc)     PlanList.push({ PlanId: KYC.planId,
                                    PlanDetailId: KYC.planDetailId, PCS: addons.kycRentalMonths })
// jQuota：選中的配套 ×1
if (addons.jquotaPackageId)
                    PlanList.push({ PlanId: jqPack.planId,
                                    PlanDetailId: jqPack.planDetailId, PCS: 1 })

5.8 聯絡我們/推薦人（發送訂單摘要 · 不創建訂單） 復用現有 contact API

訂單摘要下方的「聯絡我們 / 聯絡推薦人」按鈕與付款按鈕同樣的有效性門檻（由 updateSubmitEnabled() 控制），但不創建任何訂單/租戶/線索——只是把用戶當前已填寫的訂單摘要（collectPayload() 產出的 type/行業/方案/加值項/期間/總價與聯絡資料）整理成一段留言，經既有 contact us API 發出，讓管理員（或推薦人）主動跟進。成功後前端顯示「已收到資料，將盡快聯絡」（showOfflineSubmitted()）。

收件人路由：管理員 vs 推薦人

• 未填推薦人（或 type≠'new'）：發給平台管理員——即現有 CreateFeedback 的既定收件邏輯（後端反饋 + ADMIN_EMAIL 通知，contact.js:17）。
• 已填有效推薦人代碼（state.agent 已解析；前端 hasReferrer() 僅在 new 流程為真）：改發給該推薦人。推薦人 email/phone 已由 /agents/:code 帶出（見 5.4），前端可隨摘要一併提交。

5.9 POST /payments/create（支付） 本輪除外

當前 plans-plus.js 的 submit() 已臨時移除支付鏈：/subscribe 成功後直接 showSubmitted() 顯示「已提交成功」，不調 /payments/create、不跳收銀台。⇒ 本輪不實現支付端點。

後端側：在線非 0 元訂單 CreateOrder/TenantRenewal 目前走 MockupPayment(newOrder)（本地佔位、非真實支付方），配合 PaymentWebhook（端點 10）。真實支付（QFPay 收銀台簽名 URL + webhook）留待後續階段；屆時 QFPay 簽名邏輯應在 BFF 服務端完成（API key 不可暴露前端），mock 的 pay-gateway/pay-return//payments/:id 輪詢鏈可作參照。

6. 本地開發環境對接（docker-compose-local-dev）

本地棧（AML_Backend/docker-compose-local-dev/）已把後端 iCON.Abp.FX.HttpApi.Host 起在 http://localhost:44331（Swagger 同址），SQL Server 在 localhost,11433。要把 V2 的 plans-plus BFF 指到它，需三件事：配 .env、對齊 Portal 訪客憑證、補種子數據。

6.1 V2 側配置（把 BFF 指向本地後端）

# 便捷腳本（已加入 package.json）：APP_ENV=dev + 本地後端 + plans-plus mock 兜底 + PORT 8090
npm run start:local
# 等價於：
cross-env APP_ENV=dev API_BASE_URL=http://localhost:44331 PLANS_PLUS_MOCK=true PORT=8090 node server/index.js

6.2 種子數據缺口（對接前必補）

本地庫當前（實測）：

6.3 本輪落地狀態（已實現 · 2026-07 實測通過）

端到端驗證（npm run start:local + 本地 docker 後端）：/editions（10 行業 + CPA 切換）· /plans/catalog（standard/cpa/addons 全對）· /countries（249）· /agents/:code（無數據 found:false）· /subscribe（new 各變體均返回 orderId、訂單入庫）。頁面 GET /plans-plus HTTP 200。

PAYG（single-query）本輪驗證（APP_ENV=test mock 模式）：/single-query/options 返固定 4 項、無單價；POST /amlPortal/plan/portal/GetPlanList{countryCode:"JPN"}→P2G ¥3,000（JPY），{HKG}→空目錄（價格不可用）；抽取 plans-plus.js 實際 extractPaygPlan/paygPlanPrice/fmtMoneyCur 跑真實響應：P2G / 3000 / JPY / ¥3,000 通過、HKG→null/0（禁用提交）。GET /plans-jp HTTP 200、含 ppSqPriceValue 橫幅。（真後端 GetPlanList 對接與 ConsumerPortal 支付後編排見 5.6，仍待後端。）

7. plans-plus 相對旧站的新增需求

8. 實施建議與分期

8.1 新增 / 改動文件清單（justsolutionsWebV2/server）

8.2 可能的後端改動（與後端團隊確認）

• BR/CI 非必填：已定去除 CreateOrder 的 BR/CI 必填校驗（注释 :154/:190，保留唯一性）；請確認已在對接/部署環境應用（當前 working copy 仍 active）。
• 按郵箱查可續費租戶：已定 · 待實現 新增 POST Order/portal/queryRenewableTenantByEmail（入參 {Email}，[AbpAutoAuth("Portal")]）——先按 UserName=='admin' && Email== 定位租戶（可復用現 GetAllUsers() 全庫掃描、改按郵箱過濾，掃描成本可接受），返回聚合 currentSubscription（planId / 上期 price / 已購加值項，反查思路借用 GetCurrServiceInfo）+ referrer（AgentorCode/Name）。詳見 5.5。
• topup 語義：確認 TenantRenewal（PlanList 僅加值項）是否「只疊配額不延期」，或新增 TenantTopup。
• KYC 計費口徑：確認 KYC plan 是否可按 PCS=月數 計月租。
• single-query：已用 ConsumerPortal 即時檢測，兩步由後端內部編排（見 5.6）。檢測內容固定 4 項（V/E/A/D）、定價取 GetPlanList(countryCode) 的 PAYG 方案價。待後端確認：① V2「支付完成」與後端編排的銜接端點/webhook；② 隨付即用專用「2C 租戶」+ AML.ConsumerPortal.Enable 功能 + 實時篩查權限（供後端落上下文，V2 無需持該租戶憑證）；③ op→功能碼映射已定固定 EAVD——僅需確認後端是「V2 固定傳 EAVD」還是「後端寫死」；④ 收款金額對齊已確認：PAYG = 單一整包價；目前 countryCode 僅日本（JPN），僅 /plans-jp 有 P2G 方案，餘國待種 PlanDetail 後再開。
• 聯絡我們送推薦人：待實現 已定方案——後端 CreateFeedback 增 AssignedAgentUserId 收件人字段（DTO + 實體 + 服務解析郵箱 + EF 遷移）：有值發推薦人、否則發平台銷售。
• （可選）Plan 增 bestValue/多語言 note/nameJP；edition 增多語言名稱。

8.3 建議分期

9. 待確認問題清單

1. BR/CI：已定非必填 plans-plus 新購（含個人主體 / 空 BR/CI）可下單。實現＝注释 CreateOrder 的 OrderService.cs:154,190（保留 :191 唯一性，空值安全）。待辦：確認該放開已在對接/部署環境生效（當前 working copy 兩處仍 active）；並知悉全局影響（旧站共用 CreateOrder，空 BR 不再攔截）。
2. 單次查詢：已定方向 後端已支持——ConsumerPortal 即時檢測；調用方＝AML 後端內部編排（支付完成後 CreateConsumerLink→CreateConsumerOrder，V2 只下單+收款，見 5.6）。本輪再定：檢測內容固定 4 項純展示不可選（證件核驗V / 名單篩查ES=E / AI 增強A / 失信D）；收款金額取 GetPlanList 按 countryCode 的 PAYG(P2G) 方案價（/plans-jp→JPN）。待後端確認：① V2「支付完成」與後端編排的銜接方式（後端持單 + 收 webhook，或 V2 支付後調後端專門 2C 觸發端點）；② 隨付即用專用「2C 租戶」+ AML.ConsumerPortal.Enable + 實時篩查權限（供後端落上下文，V2 無需該租戶憑證）；③ functionCodes="EAVD" 由 V2 固定傳、還是後端寫死；④ 已確認 PAYG = 單一整包價（非分項之和）；目前 countryCode 僅日本（JPN），僅 /plans-jp 有 P2G 方案 + PlanDetail，餘國後續再種。
3. 聯絡我們（不下單）：已定方案 復用 contact/CreateFeedback 發送訂單摘要（不創建訂單/線索）；「送推薦人」擬由後端 CreateFeedback.AssignedAgentUserId 承接（待實現，見 5.8）。待辦：後端加字段 + 服務路由 + EF 遷移；前端調用點由 /subscribe-offline 改 POST /api/contact 並透傳 agentUserId；BFF 映為 AssignedAgentUserId。
4. 租戶查詢：已定新增後端端點 queryRenewableTenantByEmail(email) 直接返回「租戶 + currentSubscription（planId/上期價/已購加值項）+ referrer」聚合（見 5.5）。待後端確認：① 「admin 郵箱」是否恆等於 UserName=='admin' 用戶的 Email（現 queryRenewableTenant 即此語義）——若存在非 admin 用戶名的租戶管理員，需改按角色定位；② 過期租戶是否照樣返回（供前端做臨期/過期展示 + topup 阻斷）；③ 聚合 DTO 形態（新 RenewableTenantDto vs 擴 TenantPropertyDto）。
5. topup：純加購走 TenantRenewal（PlanList 僅加值項）後端是否接受、語義是否「只疊配額不延期」？
6. KYC 月租：KYC plan 是否可按 PCS=租賃月數 計費（planDetail.price 當月租單價）？
7. 續費續價：後端 TenantRenewal 是否支持沿用上期價/自定義價？否則前端續費折扣僅展示、實際按目錄價。
8. agent tiers：BFF 經 GetPlanList(agentUserId) 推導 tiers，還是改為服務端直接按 agent 過濾 catalog？
9. agentorId：/agents/:code 響應附帶 agent Guid id，避免下單時二次查詢？
10. 鑑權憑證：V2 BFF 門戶訪客帳號（Portal@iconsz.com，__tenant=Portal）權限是否覆蓋 CreateOrder / queryRenewableTenant / SearchUserByCodeAndType？
11. 本地種子：Plan/Edition 種子走臨時 SQL 還是入 AMLPortalDataSeedContributor？CPA edition GUID 是否同步進 appsettings.local.json？
12. bestValue / note / 多語言：由 BFF 配置維護，還是後端在數據上補字段？