平屋慢生活

三種走向Redirect URL 如何傳到前端IsFinish 機制後段 Processor 執行時機完整結帳流程總覽第三方金流（PMW 系列）在結帳時，付款結果有三種走向： 結果 說明 Pipeline 後段 Redirect 需要導向金流頁面付款（如 QFPay 掃碼、Stripe 3DS） ❌ 中斷，等 Callback Success（同步） PMW 當下回傳成功 ✅ 繼續執行 Fail PMW 當下回傳失敗 ❌ 中斷，執行取消流程 **context.IsFinish**：控制 Pipeline 是否繼續執行後段 Processor **context.ThirdPartyPaymentInfo**：存放 Redirect URL，Pipeline 結束後由 Controller 讀取回傳前端 URL 不透過 return value 傳遞，而是寫入 context 物件，Pipeline 結束後 Controller 統一讀取。 1234567ProcessPayment() → 寫入 context.ThirdPartyPaymentIn ...

兩條失敗路徑路徑一：建單時 PMW 失敗路徑一：前端顯示機制路徑二：PayChannelReturn 失敗路徑二：各金流 GetErrorMessage 差異PMW 系列金流的付款失敗，分為兩個完全不同的入口 路徑一：建單時直接失敗 路徑二：PayChannelReturn 失敗 觸發時機 CompleteForNewCartV2 → PMW 當下回 Fail 第三方付款頁完成後 redirect 回 mweb 訂單狀態 訂單從未成立，立即回滾 訂單已成立（進入 WaitingToPay） ErrorCode ThirdPartyPayReserveFail 無 errorCode，顯示翻譯後文字 前端機制 XState useErrorAction.tsx errorCode Map payChannelCallback/index.tsx 直接渲染 用戶看到的文案 泛用「付款方式付款失敗」 各金流自訂文案（Stripe 最細緻） 適用金流以下金流共用同一套 PMW 架構： Stripe（CreditCardOnce_Stripe） Razer ...

PaymentProcessingMethod在說什麼？計算時機：ArrangeDataProcessor用哪個 API 帳號資料流向ERP 怎麼用這個欄位？發票、直代收、Stripe 的三角關係發票、直代收、Stripe 的三角關係 這筆錢，是先流過 91APP 的信託帳戶，還是直接進商家的銀行？ 12345678public enum PaymentProcessingMethodEnum{ /// <summary>直收付 — 錢直接進商家銀行</summary> DirectToBank, /// <summary>代收付 — 錢先進 91APP 信託帳戶</summary> ThroughPSP} 這個決策影響的不只是金流 API 的選擇，更影響到發票開立方、財務對帳範圍，以及整個 ERP 的付款單計算邏輯 兩條路的核心差異 維度 ThroughPSP（代收付） DirectToBank（直收付） 錢的流向 消費者 → 91APP 信託 → 商家 消費者 → 商家銀行（ ...

FlowType 是什麼？FlowType 在哪裡被決定？為什麼 PaymentMiddleware 的金流都走同一個 ThirdPartyProcess為什麼其他金流反而有自己獨立的 FlowType？summaryPayProcessFlowType 是 mweb 下單流程的 Pipeline 路由鍵 用戶按下確認下單後，CompleteForNewCartV2 做的第一件事就是讀取 context.PayProcessFlowType，然後決定要跑哪一套 Processor Pipeline flowchart TD A["用戶確認下單"] --> B["CompleteForNewCartV2"] B --> C{"讀取 PayProcessFlowType"} C -->|ThirdPartyProcess| D["ThirdPartyProcess Pipeline\n34 個 Processors\n走 PMW 付款"] C -->|CreditCardProcess| E["CreditCardProcess Pipeline\n台灣信用 ...

大局觀兩條回來的路線四種 ReturnCode 處理Expired vs Failed 深度對比設計解析summary table付款流程分為三個階段，本文聚焦 Phase 3：FinishPayment flowchart TD P1["Phase 1\nCreateTradesOrderProcessor\n建單時決定初始狀態\n決定是否需要 Phase 3"] P2["Phase 2\nProcessPayment\n同步呼叫 PaymentMiddleware\nRedirect/Pending → 進入 Phase 3\nSuccess/Fail → 不進入 Phase 3"] P3["⭐ Phase 3\nFinishPayment\n非同步付款的最終裁決\n→ 所有非同步訂單的收尾點"] P1 -->|"Group B（WaitingToPay）\n完全略過 Phase 2，直接等 Phase 3"| P3 P1 -->|"Group A"| P2 P2 -->|"Redirect / Pending\n存 context ...

大局觀ProcessPayment 四種回應路徑Cache 橋接設計ProcessPayment Fail 的取消流程設計解析付款流程分為三個階段，本文聚焦 Phase 2：ProcessPayment flowchart TD P1["Phase 1\nCreateTradesOrderProcessor\n建單時決定初始狀態\nGroup A → 直接進 Phase 2\nGroup B → WaitingToPay 停在這等"] P2["⭐ Phase 2\nProcessPayment\nmweb 在同一 Request 內\n主動呼叫 PaymentMiddleware\n→ 依同步回應決定走哪條路"] P3["Phase 3\nFinishPayment\n非同步 Callback 或 ReCheck Job\n付款最終結果回來時處理"] P1 -->|"Group A：同步呼叫"| P2 P1 -->|"Group B：直接略過 Phase 2"| P3 P2 -->|"Success → 同步完成"| ERP P ...

大局觀本質為什麼需要三個狀態維度？為什麼預設值是 WaitingToTrans？初始狀態對照分組邏輯定期購自動建單：「同一張卡，不同的情境」CustomOfflinePayment：倉管為何需要在建單就知道？付款流程分為三個階段，本文聚焦 Phase 1：CreateTradesOrderProcessor flowchart TD P1["⭐ Phase 1\nCreateTradesOrderProcessor\n使用者按下結帳\n→ 訂單寫入 DB，初始狀態決定往後走哪條路"] P2["Phase 2\nProcessPayment\nmweb 在同一 Request 內\n同步呼叫 PaymentMiddleware"] P3["Phase 3\nFinishPayment\n非同步 Callback 或 ReCheck Job\n付款最終結果回來時處理"] P1 -->|"Group A：建單即有憑證，立刻進 ProcessPayment"| P2 P1 -->|"Group B：WaitingToPay，等使用者外部付款"| P3 ...

背景架構全貌Layer 1：Pod 層Flagger Canary 層Layer 3：Ingress 層Layer 2 : Service / Endpoints 層Layer 4：Nginx + AWS ALB 層table服務部署到 K8s 後，Pod 內部健康檢查（/_hc）回傳 200，但從外部網路呼叫 API 時，全部回傳： 12HTTP/2 403Routing error 本次記錄如何一層一層排查，最終找到真正的根本原因 外部請求從前到後經過以下每一層 flowchart TD U["👤 外部使用者 / Bitbucket Webhook"] ALB["☁️ AWS ALB（公用）\nLayer 5：最外層"] NGINX["🔀 Nginx Ingress Controller\nLayer 4"] ING["📋 K8s Ingress 物件\nLayer 3"] SVC["🔌 K8s Service（Apex / Canary）\nLayer 2"] POD["📦 Pod（App 程式）\nLayer 1：最內 ...

整體架構全貌現況架構與設計動機MQ + Consumer 並行Streaming 分批讀取單一 Job 自迴圈summary系統邊界與角色BatchUpload 橫跨三個系統與四張 DB 表，各自負責不同的職責： 12345678910111213141516171819202122232425262728293031323334353637383940414243444546┌─────────────────────────────────────────────────────────────────────┐│ （商店後台） ││ ││ ① 商店操作員上傳 Excel ││ ② 建立 BatchUpload 主記錄（Status: In ...

EKScontrol managementetcd 備份與還原etcd Kubernetes 版本升級憑證管理網路插件設定summaryElastic Kubernetes Service 就是 AWS 幫我們 Kubernetes 的核心管理層顧好，讓我們把力氣放在「部署服務」和「管理應用」，不要一開始就被cluster維護、升級、控制平面穩定性卡住。先理解 Kubernetes 是用來管理容器化應用的系統，例如幫你處理服務部署、擴容、重啟、流量導向等事情。而 AWS 上的 Kubernetes 讓我們想在 AWS 裡跑 Kubernetes 時，可以自己從零架一套，也可以使用 AWS 提供的託管服務。Kubernetes 裡最關鍵、最麻煩維護的控制平面，例如 API Server、cluster 狀態管理等，會由 AWS 負責。使用 EKS 時，開發者或 DevOps 團隊通常把重點放在部署 Pod、Service、Ingress、Node、IAM、網路設定與應用維運上。 假設我們有一個 API 服務，原本只跑在一台 EC2 上 當流量變大時，可能會遇到這些問題 要怎麼自動開更多 ...