Stripe-Account
金鑰商店與 Stripe 帳號的關係PaymentMiddleware退款mweb CompleteForNewCartV2 流程後台帳號設定Secret Key 設定位置
📁
設定檔路徑：MachineConfig/Frontend/AppSettings.QA300.config
檔案結構：
設定項目說明範例
CustomAcctLiveSecretKeyCustom 帳戶正式環境金鑰sk_live_...
CustomAcctTestSecretKeyCustom 帳戶測試環境金鑰sk_test_...
StandardAcctLiveSecretKeyStandard 帳戶正式環境金鑰sk_live_...
根據帳戶類型取得 API 金鑰123456789101112131415161718192021222324private string GetStripeApiKey(long shopId, string accountType){ return accountType switch { // Cus ...
Stripe-Fee
.pf-hero {
background: linear-gradient(135deg, #4a3fb0, #635bff 70%); color: #fff;
padding: 34px 32px 28px; border-radius: 16px; margin: 0 0 26px;
}
.pf-hero .pf-hero-eyebrow {
font-size: 0.78rem; letter-spacing: 3px; text-transform: uppercase; opacity: 0.85;
display: flex; align-items: center; gap: 8px;
}
.pf-hero .pf-hero-mark {
display: inline-flex; align-items: center; justify-content: center;
width: 20px; height: 20px; border-radius: 6px; background: #fff; color: #635bff;
font-weight: 800; ...
Cybersource-Refund
整體流程GroupingProcess（分群 Job）Finish Job（逐筆退款）Cybersource PaymentMiddleware API退款狀態機（整體視角）序列圖（End-to-End）已知風險 / 異常情境
.cyb-banner {
display: flex; align-items: center; gap: 12px;
background: #eef2fb; border-left: 4px solid #1b2a4a;
padding: 10px 18px; margin: 30px 0 16px; border-radius: 2px;
}
.cyb-banner .cyb-num {
font-family: 'Courier New', Consolas, monospace; font-weight: 700; font-size: 0.82rem;
color: #fff; background: #1b2a4a; border-radius: 50%;
width: 26px; height: 26px; flex-s ...
Cybersource-Query
雙路徑設計ExtendInfo 怎麼決定Form-Data 快速路徑（Callback 情境）怎麼判斷付款狀態路徑 A：Create Search API（ReCheck Job 情境）QueryPaymentResponseExtendInfo 欄位對照完整流程圖情境分析雙路徑設計是對 Create Search API 的妥協路徑 B 的 `TransactionId` 來自 Cybersource form-data 的 `transaction_id`WaitingToPay 語義過載ESYSTEM 白名單過於保守路徑 B 缺少 `decision` 非預期值的告警Cybersource QueryPayment 有兩條完全不同的執行路徑，由 request.ExtendInfo 是否包含 TradesOrderGroupCode 決定。
12345QueryPayment 入口│├── ExtendInfo 有 TradesOrderGroupCode？│ ├── YES → 【路徑 A】Create Search API 查詢（ReCheck Job 路徑）│ └─ ...
Cybersource-Pay
表單導向，無直接 API 呼叫兩套認證體系流程概覽Pay 行為概覽Cybersource Callback 兩跳機制Secure Acceptance 托管頁模式：Pay() 不知道結果transaction_type 固定為 `"sale"`兩條 QueryPayment 路徑summaryCybersource 的 Pay 設計與多數金流根本不同。PMW 不呼叫 Cybersource 任何 API，他的做法是
組建一份已簽名的 HTML 表單（FormPost）
前台讓瀏覽器直接將這份表單 POST 到 Cybersource 托管頁
消費者在 Cybersource 頁面完成付款後，Cybersource 將結果 POST 回前台 callback URL
12345678910111213141516mweb 前台 └─ POST /api/Pay → PaymentMiddlewareService └─ PMW CybersourcePlugin.Pay() └─ 組建 CybersourcePaymentFormEntit ...
2C2P-Refund
問題總覽完整鏈路解析Grouping 與 Finish 兩階段案例時間軸改善設計方案
.medchart-wrap { display: flex; flex-direction: column; gap: 28px; margin: 24px 0; }
.medchart {
background: #fbfaf6;
border: 1px solid #c9c3ae;
border-radius: 4px;
position: relative;
font-family: 'Courier New', 'Consolas', 'PingFang TC', monospace;
box-shadow: 0 1px 3px rgba(0,0,0,0.08);
padding-bottom: 4px;
}
.medchart::before {
content: ''; position: absolute; left: 0; top: 0; bottom: 0; width: 6px;
background: repeating-linear-gra ...
QFPay — QueryPayment 付款查詢流程深度分析
流程概覽API 呼叫細節TransactionId 的完整生命週期簽名機制（SHA256）查詢邏輯判定成功訂單機制SuccessCount 統計與告警機制情境 Q1：正常查詢成功情境 Q2：付款中（真正 WaitingToPay）情境 Q3：付款失敗（被誤判為 WaitingToPay）⚠️情境 Q4：重複付款告警情境 Q5：URL 組裝錯誤導致無訂單紀錄缺陷分析QFPay 採用 Hosted PayPage 模式：Pay 只是純 URL 組裝（不呼叫 QFPay API），消費者導向 QFPay 托管頁完成付款後，系統才透過 QueryPayment 主動查詢確認付款結果。
因此 Query 是 QFPay 整個金流中真正的網路呼叫，也是決定訂單最終狀態的關鍵步驟。
Pay 完成後，QFPay 給你的是一個包含該 TGCode 所有交易記錄的陣列，可能同時有付款成功、付款失敗、重試紀錄混在一起。Query 要從這堆資料裡正確判斷這筆訂單究竟有沒有成功。
API 規格12345POST /trade/v1/queryContent-Type: application/x-www-fo ...
QFPay - Pay 設計
Pay() 是純計算函式 — 整個流程沒有任何網路 IO雙金鑰認證設計 — appcode（公開識別）vs apiKey（私密簽名）雙 Payload String 設計 — Raw（簽名用）vs UrlEncoded（URL 用）Spec與 Cybersource 類似，QFPay 的 Pay 不直接呼叫 API。PMW 只負責組建帶有 SHA256 簽名的付款頁 URL，並回傳 Redirect action 讓前台導向。
sequenceDiagram
participant FE as 前台
participant PMW as PMW
participant QF as QFPay 付款頁
FE->>PMW: POST /Pay
PMW->>PMW: 組建 QFPay 付款頁 URL（含 SHA256 簽名）
PMW-->>FE: Redirect Action（WebPaymentUrl + AppPaymentUrl）
FE->>QF: 導向 QFPay 付款頁
QF-->>QF: 用戶完成付款
a ...
ThirdPartyPaymentReCheck — 背景補撈 Job
觸發Job 資訊PSP 路由改善策略設計缺點分析消費者付款後，若路線一（PayChannelReturn）沒有成功回打（或回打時金流仍是 WaitingToPay），由 SQL 排程定期觸發 NMQ Job 在背景主動去查詢第三方付款狀態。
觸發機制1234SQL 每 3 分鐘執行排程，傳入金流清單字串並觸發 csp： csp_GenerateThirdPartyPaymentReCheck └─ 撈取所有 WaitingToPay 狀態的 TradesOrderThirdPartyPayment └─ 每筆塞一個 NMQ Job 進 Task Table
flowchart LR
A["SQL 排程\n每 3 分鐘"] --> B["csp_GenerateThirdPartyPaymentReCheck"]
B -->|"每個 PayType × 2 PSP"| C["NMQ Task Table"]
C --> D["ThirdPartyPaymentReCheckProcess\nNMQ Job"]
D --> E{"Flo ...
CreditCardGatewayType — 信用卡閘道路由機制
CreditCardGatewayType 是什麼？決定邏輯：Cart → mwebPipeline 分流影響PMW（PaymentMiddleWare）的具體行為完整流程總覽設計缺點改善策略CreditCardGatewayType 是一張路由票，決定這筆信用卡訂單要讓哪個 Gateway 執行實際授權。
1234567891011121314public enum PayProcessCreditCardGatewayTypeEnum{ /// <summary>聯卡中心（台灣本地信用卡，舊版主流）</summary> NCCC = 0, /// <summary>TapPay SDK（帶 Prime Token）</summary> TapPay = 1, /// <summary>九一金流（帶 CardToken + IssuerBankCode）</summary> Nine1Payment = 2, /// <summary>PMW 跨國金 ...
