Lyft donation system

jinniw43805 发表于 2024-2-1 18:56
理論上應該是不存 Credit Card 詳細訊息的，通常應該是 Service or Consumer 呼叫 Payment Service （如 ...

听上去，好像从client端提交request到 third party的UI显示，这个过程是同步的。是么？  third party ui 提交payment也是直接talk to third parity PSP，成功了会redirect 到 callback url ，你这个设计也挺好， 但是好像和楼主的不太一样。楼主这个是payment的request 提交到服务器的mq 里，然后就return client，update status to pending。 然后异步 call third party PSP，还可以retry。 success 之后call notification 给client。

是的，這個機制主要是依賴內部 Service 先呼叫PSP產生nonce token，然後產生完成後吐回前端讓 User 在表單付錢，之後付完錢的 Request 都會夾帶這個產生完的 nonce token。
怎麼區分是錯誤重複點還是想捐很多次：
錯誤重複點：我們後端都會收到同一個 nonce token, 也因為這個 nonce token 是 idempotent 的，所以我們呼叫 PSP 一次還是好多次，結果都一樣，我們都能保持只扣款一次或是一直失敗
想捐很多次：我們後端會每次都收到不一樣的 nonce token

我覺得樓主的設計也行，如果需求是想要馬上返回 pending 的 status，那無論是呼叫到 PSP 還是 接收 PSP 的回應都可以中間搭 broker。
但是應該需要考慮至少兩種問題：
1. 如果扣款失敗了？我們怎麼通知 User
2. 如果 PSP 中間一直沒有回應，我們怎麼確定 PSP 已經扣款但傳回來調包，還是根本 PSP 沒扣，我們是不是要用那個 nonce token 定義一個時間之後再去 Query & Update Status?

另外這種 payment service 如果搭 Kafka 一定要考慮到 broker 會突然壞的問題，所以這是為啥每個 Payment system 都會要去定義 retry queue & retryable classfication 去處理重試 （保證 at most once)，還有就是 Kakfa 是 log-based broker, 所以我們還是可以透過 persistent log 去做對帳還有偵測錯誤

基本上 PSP 應該每天還需要傳一份 audit log 回來跟我們的 Transaction log 去對帳去找錯

另外也有可能我們如果是在設計一個電商，這個 nonce token 是要我們自己的 Service 生成，中間可能會需要一些 Transaction & 加鎖 去保護非常搶手而且便宜的商品 ，這個地方可以看怎麼生成 unique ID & 高流量電商是怎麼處理搶手商品的 Transaction 加鎖部分

Payment System 兩篇必看文章
https://medium.com/airbnb-engine ... system-2981f6b070bb

https://underhood.blog/uber-payments-platform

请问一下楼主表结构是怎么设计的？

问一下楼主面的T4 or T5?

需不需要把钱先转到系统账户。我觉得直接打到收钱方说不通吧。 就说你提到的交易高峰的问题。 如果真有每秒1000个人给某一个人捐钱，难道你要开几百万个payout的交易吗？

这题可参考alex xu 第二本书11章 PSP integration 用nounce token，用webhook实现payment status云云