付款前後流程

其實越簡單、多選擇、且安全的付款流程，往往更加吸引使用者選擇購買。

所以我花費兩天時間，說明了一下 Medusa.js 付款流程，讓身為管理者更加了解流程，自行增加安全性、多樣化性支付等等。

今天就小整理一下，付款前後流程以及需要什麼：

Step 1 填寫資料

Cart 要進入付款程序時，預定只會先需要一項數據，就是運輸設定，是 Pick up(自取)還是 Shipping(運送)，就只有這樣，名字、地址、電話等等基本資訊並沒有嚴格規定。若是各管理者需要嚴格規定，請自行擴充。

Step 2 建立 Payment Collection

真的如果簡單想的話，Payment Collection 真的很像 去大型商場，當你要結帳時，把商品放上輸送帶上這個動作，表示確定這項產品是要購買的。

Step 3 初始化 Payment Session

Payment Session 任務就是負責去跟 第三方金流或者銀行方溝通，將購買資訊傳送出去並且請錢回來，這是最重要的也是最需要嚴格保密的地方，不可以洩漏一點 資訊出去，否則大難臨頭。

Step 4 建立Payment

Payment Session 完成溝通後，從第三方金流或者銀行方取得授權，就是已完成我們的購物車，建立我們的 Payment，表示這筆交易已是雙方成立的狀態。
在我的感覺就很像發票，一種證明。

訂單與履約

建立 Payment 時候，也會建立 Order(訂單)，訂單可以追蹤 退貨、換貨、送貨進度等等。
這些東西就會干涉到 Payment、Fullfillment，
Payment 會去處理退換貨金流的控制。
Fullfillment 會去處理 退換貨物流的監控與控制。

在訂單行程時候，管理者就可以去點選 Capture(獲取)，將金錢納入囊中，什麼時候點選因人而異，有些老闆喜歡 送出去才領錢、有些是成功授權即領。

但是，要退貨、換貨的前提之下，是需要老闆已經 Capture 這筆資金才可以對這筆資金做往下的用途。
這是一個流程，總不能是資金還沒落入口袋就授權換貨，這樣對於金錢控制會太過雜亂。

發現以及接下來....

這幾天的整理，發現到其實，我們還有許多看起來是小地方，其實還蠻重要的地方還沒去了解，例如：

• 運輸設定檔
• 履約設定檔
• 銷售通路設定檔

還有還沒實作的地方，因為這些建立可能不是前面討論的一般基本電商主要的模組與項目，或者是需要程式碼擴充，例如：

• Notification 模組
• 第三方金流 串接
• 第三方履約 串接
• 促銷及活動
• 分級定價

接下來，我們就自己去製作需求，然後更加了解的 MedusaJS 的魔力。
明天我們先建立故事與需求。
(昨天一個感冒直接睡死！！忘記更文了)