所有金流交易資料表,都用相同 schema 即可。
如果支援五、六種付款方式,就會有五、六張金流 Transaction Table。你可能會覺得每張都要設計很麻煩,但其實所有金流 Table 都可以用同一種格式。
每張 Table 只需要五個欄位:
連 updated_at 都不需要。
因為這些金流 Table 採用 append only 的方式,也就是只新增資料,不修改舊資料。每次交易就加一筆新的 Row,不要去更新原本的 row。這樣未來除錯時,會更容易找到問題。
如果資源是訂單,[RESOURCE]_ID 就是 order_id。這個欄位主要是方便查詢不同 Model 之間的關聯。
不同金流的流程雖然不一樣,但用 sent_payload 和 received_payload 就能表示同步與非同步的情況。
例如同步付款時,sent_payload 和 received_payload 通常都會有資料。你可以從內容看到付款是否成功。
非同步付款,例如 LINE Pay、ATM 虛擬帳號,使用者可能過幾分鐘,甚至幾十分鐘後才完成付款。金流廠商之後會送 Callback 回來。
收到 Callback 時,可以新增一筆資料:sent_payload 是空的,received_payload 放 Callback 的內容。看到 sent_payload 為空、received_payload 有值,就知道這是一筆非同步 Callback。
有些信用卡付款是同步,有些是非同步。如果需要 3D 驗證,通常就是非同步。非同步的初始回應可能只會提供付款連結、付款碼或付款網址。
反正不同廠商和付款方式已經分成不同 Table,所以在看資料前,大致就知道它是哪一種流程。
記住兩個原則就好:
第一,金流交易紀錄 Table 採 append only,只新增、不修改。
第二,使用 sent_payload 和 received_payload,就足以處理各種同步與非同步的金流情境。
不需要為每張金流 Table 設計很多欄位。大部分資訊就在 sent_payload 或 received_payload 裡,五個欄位就夠了。