串接金流時,最困難的通常是付款流程設計。分享一個簡單的設計模式。
無論提供五種、十種或更多付款方式,每一種金流最終只需要三個函數:
每種付款方式都建立對應的 Flow 類別,例如 TapPayCreditCard3dsFlow、TapPayApplePayFlow。類別中提供 Start 函數,接收參數後執行該金流的串接邏輯,並將使用者導向付款頁面。
同時,為每個金流建立 Controller,至少包含 Return 與 Notify 兩個 Routing。例如 TapPayCreditCard3dsController 或 TapPayApplePayController,都可以提供這兩個路由。
Notify 用於接收金流商的付款成功或失敗通知;Return 則用於某些需跳轉至外部付款頁面的方式,在付款完成後讓使用者返回系統。
若某種付款方式是同步完成,不需要 Notify,就保留空白即可;若不需要跳回網址,也不必實作 Return。
三個結構都先保留,能讓所有金流維持一致且容易理解。
整體流程很清楚:付款開始時進入 Start;需要跳回時使用 Return;需要非同步通知時使用 Notify。
若採用 OOP,可以建立 PaymentFlowResolver,類似 Strategy + Factory 模式。使用者提交結帳表單時會帶入付款方式參數,Resolver 根據該參數對應到指定 Flow,再呼叫 Flow 的 Start 執行付款流程。
金流設計只要掌握 Start、Return、Notify,以及付款方式與 Flow 的映射關係,就能保持簡潔、統一且易於維護。
順帶一提,開啟 3D 驗證的信用卡流程 vs 沒開啟 3D 驗證的信用卡流程,當成兩種金流流程去寫,比較單純、清楚。