前言
今天分享一點關於支付相關的內容，也是好早就有粉絲私信提過的，很遺憾，一直拖到現在才寫。
大家比較好奇微信支付、支付寶支付在企業實戰中究竟是什麼樣，就是網上的線上課程學的那些嗎。
因為沒有類似的經驗，所以不少人對支付功能比較好奇。
剛好我所在的公司本身也是支付服務商，我談不上特別清楚，但還算比較瞭解。
先開門見山，本篇沒有支付功能的程式碼實戰，因為這東西沒你想的那麼難，除了微信支付寶提供了原生工具類，其他開源的工具也挺多，你純粹可以當成支付版的CRUD一樣操作。
我將以面試官的角度來提問一些支付相關的問題，並做出回答，讓你對企業中支付的全貌有個大概的認知，這裡面有一個問題是我面試別人問過的，xdm看完了可以猜一猜是哪個。
正文
1、你知道直連模式和服務商模式嗎
網上的課程一般給你演示的都是直連模式，而企業中有不少是申請成為了服務商，因為裡面有佣金提成。
我粗俗地解釋，直連模式，就是說你是一個會做生意的老闆，自己會搞錢，搞到錢存到自己的一個商戶號裡。
服務商模式，就是說你是一個會做生意的老闆，但是自己不搞錢只提供做生意的渠道，其他老闆用你的渠道，搞到錢了讓你洗一洗，你分別轉到他們各自的商戶號裡去，而你收取一點點服務費。
然後我們對照上面的話再稍微專業點解釋，直連模式就是你得自己接入支付功能，啥都要你自己做，服務商模式就是啥都不需要你做，你就提供個商戶號，剩下的支付接入功能服務商給你全部搞定。
如果面試官問你這個問題，你只要意思稍微到了就行，別人就知道你是做過的。
2、服務商模式下，你們如何控制多個子商戶結算和退款的
假如你有自己的一家公司，專門提供支付服務，而且申請成為了服務商，那麼你就有自己的一個appid和mchid，統稱為
服務商賬戶。然後張三和李四也有各自的公司，但他們是做電商的，需要接入支付功能，找到了你，此時他們需要提供自己公司申請的appid和mchid，交給你去配置，這個統稱為
子商戶賬戶。好了，接下來你作為服務商，該如何配置服務商賬戶和子商戶賬戶呢？我這裡貼出一個微信的小例子，你們可以參考下（文中的引數都是模擬的並非真實配置）。
wechat:
pay:
# 服務商
appId: wx49f94d5f00f349f13
mchId: 1550391234
mchKey: miyao145bijv0974kf64833ld8wpi
keyPath: classpath:wx-cert-dev/apiclient_cert.p12
existsSub: false
# 子商戶
subConfigs:
- subAppId: wx50f05d5f11f560h24
subMchId: 1511405678
typeId: zhangsan
- subAppId: wx61g16e6g22d781i35
subMchId: 1623519012
typeId: lisi
# 回撥地址
external:
pay-notify-url: https://xxxx/gateway/pay/api/payOrder/notify
refund-notify-url: https://xxxx/gateway/pay/api/refund/notify
其實配置的方式有很多，我這裡只是展示其中一種，xdm也可以照搬的。
這樣配置了以後，如何讀取呢，很簡單，就用SpringBoot的
@ConfigurationProperties註解來讀取即可。這種方式是在SpringBoot專案啟動時，
讀取yml中服務商和子商戶的配置，載入到map中，然後在支付介面使用時，直接從map中獲取即可，就相當於放到了快取中。而配置中宣告的
typeId就是區分子商戶的標識，xdm可以根據業務場景去自定義即可。這樣，不論是支付下單還是退款，都能直接讀取到對應子商戶的配置，從而支付下單或原路退回。
本篇主要不是講功能的，所以不在這裡面的細節上過多贅述。
如果有面試官問這個問題，你只需要說出配置和讀取的思路就行。
3、先業務下單還是支付下單
如果面試官問了這個問題，就屬於是送分題了。
肯定是先業務下單，因為支付功能是基於業務的基礎上進行的，如果業務訂單不記錄下來，後面整個流程都沒頭沒尾，一些業務相關的資料你也獲取不到，狀態也更新不了。
所以要先記錄下業務訂單，包含訂單號、業務型別、業務狀態等屬性，哪怕支付下單失敗，你也有業務訂單的痕跡可查。
4、下單後不支付怎麼處理
這個問題有多種答案，不同公司會有不同的做法，我這裡分享一下我的做法。
下單後如果不支付，這筆訂單就不做處理，再次下單時生成一筆新的訂單，原來的那個訂單就當做廢訂單。
對於中小企業而言，這種方案我覺得最簡單，廢訂單的量也不會有你想象的那麼多。
另外，微信支付不能用重複的訂單號再次下單，會報錯，所以這個方案也順便規避了這個問題。
如果有面試官問這個問題，可以參考我這個做法來回答，這也是我待過的兩家網際網路公司都用過的方案。
5、你們有支付中心嗎，如何處理回撥的
面試官問這個問題，大機率是想知道你們有沒有對支付服務做解耦。
微信和支付寶下單成功後，都會透過回撥通知返回給你，這種情況下，說明肯定支付成功了。
正常而言，只需要配置回撥地址即可，但是在分散式的環境中，支付服務一般是獨立出來的，也就是會搭建一個支付中心，我們假定是微服務的架構，支付中心是pay服務，那麼其他服務用到支付介面都是調pay服務的介面。
所以回撥介面肯定是要寫在pay服務裡面的，這裡就會有一個問題，pay服務收到了回撥通知，如何告訴其他業務服務呢？
這裡就要引入MQ，比如RabbitMQ，在回撥中更新支付訂單狀態後，要透過它來轉發到其他業務服務，其他業務服務消費MQ之後，繼續處理自己的業務邏輯。
這樣就做到了解耦，只要回答出這一點，也能說明是接入過支付功能的。
6、你們如何處理重複回撥的問題
微信和支付寶是有機率犯病的，雖然很小，但確實有，我就遇到過。
這個時候你可能會想到，我在業務邏輯上做判斷不就好了，如果已經更新過狀態了，就不再處理了。
理論上可以，但實戰的話依然會有很多現實問題。
首先，你如何保證回撥中的業務邏輯處理有多少，真實業務場景下，不單單隻會更新一下狀態，你可能還會做一些入庫、發訊息、rpc呼叫等等一系列操作，這都是基於業務決定的，你很難說每次都能用同樣的辦法解決。
另外，我有在工作中透過日誌平臺觀察過重複回撥的時間間隔，微信或支付寶的重複回撥幾乎都是同1秒發生的，是不是感到有點熟悉，有點類似於處理高併發的問題了對嗎。
如果你們是分散式架構，且業務量達到一定規模，那麼這個問題一旦發生，你單純靠程式碼判斷是不保險的。
所以，最簡單可靠的辦法還是把回撥中處理業務邏輯的程式碼都抽取到一個方法中，然後對這個方法上
分散式鎖。如果面試官問到你這個問題，你就說用分散式鎖即可。
7、回撥中第三方業務處理失敗，如何退款的
這個問題對於完全沒在企業中接入過支付功能的xdm來說，就是比較難回答的了，因為牽扯到第三方，那說明回撥中很可能還要走rpc呼叫來完成某些業務確認操作。
我曾經專門寫過一篇真實發生的關於微信支付退款邏輯不嚴謹導致重大事故的文章，裡面有講過這個流程，有興趣的可以自己找找看。
記住，千萬別張口就說程式自動退款，這是非常不嚴謹的，牽扯到錢的東西，都是要謹慎的，如果是服務商模式，更是如此，因為那都是客戶的錢。
我這裡把其中一些重點羅列出來：
1）、支付時，要先支付下單，回撥中再進行rpc業務確認（先付錢再給票），因為你是服務商，要優先維護客戶的利益，試想如果先給了票，結果人家不給錢直接跑了，那客戶不就虧了麼；
2）、回撥中，如果rpc業務確認失敗，就將這筆訂單記錄到一張異常記錄表中，這張記錄表的作用就是專門處理rpc呼叫失敗需要進行退款的訂單資料；
3）、定時任務掃描異常記錄表，比如15分鐘一次，將這些確認失敗的訂單費用都原路退回；
4）、執行退費邏輯之前，還得先rpc調一下第三方的查詢確認狀態介面，對方沒有那麼你必須要求他們提供，只有保證對方明確可以退，你才能再走微信或支付寶的退費介面，否則可能導致多退。因為會存在一種情況，就是第三方自己其實確認成功了，但是網路問題超時或他們程式漏洞導致返回給你是失敗的，那麼你以為可以退，結果退了後這錢是短款，你就得承擔損失了。
這個流程還是蠻複雜的，不想清楚很容易把自己搞死，所以在接入支付功能時，一定要自己畫一畫，把整個邏輯理清楚，然後再開始編碼。
8、你知道微信支付寶退款的時限嗎
這個很多人反而不知道，因為網上的教程是不會告訴你的，往往是真實企業中維護過支付功能才會知道，因為你經常要處理一些退費，那麼此時就很可能遇到這個問題。
微信和支付寶的政策是不同的，而且可能會變，所以如果要面試的公司是要求懂支付功能的，你最好分別到微信和支付寶的官方文件中檢視下最新的規定。
我這裡找了下分享給各位：
微信支付
支付寶支付
9、你瞭解聚合支付嗎
一般網際網路公司接入支付介面，聚合支付大機率是跑不掉的。
簡單理解就好，以國內目前的情況來說，大多數情況也就是微信和支付寶的聚合。
為了更好理解，我這裡舉個好懂的例子，就是大家去醫院看病的時候，是不是有時候醫生會給你列印出一個憑條，憑條上會有個二維碼，然後你直接掃碼進行支付就可以了對吧。
其實這就是一種聚合支付，這個二維碼本質就是一個連結，連結裡面會有對方提供給你的引數，你掃碼的時候也就是讀取這些引數的過程，拿到引數後就可以去展示訂單詳情，然後進行後續的支付等等。
你不管用微信或支付寶哪個載體去掃碼，實際上就是走的哪個渠道，前端是可以傳遞渠道資訊給服務端的，如果是小程式那更簡單，直接會自動識別並喚起對應的小程式訂單詳情介面。
這裡面微信支付的話，還需要在微信公眾平臺中配置一個轉發連結，除此以外也沒什麼其他操作了，聚合支付其實沒有那麼複雜。
大家以後如果有幸在生活中接觸到聚合支付的場景，完全可以把聚合碼拍下來，然後回去上網搜尋草料二維碼，用解碼器把這個聚合碼解析出來，你就能看見到底是個什麼玩意兒了。
10、對賬你瞭解多少
正常來講，面試官一般不會問這個的，因為沒啥必要，除非這個公司專門招需要懂得對賬的工程師。
如果真問到你了，你可以稍微聊聊，別一問三不知就行。
企業級的支付功能，是肯定要有對賬的，尤其是給客戶提供支付服務，對賬平臺也是其中重要的一環，要幫助客戶財務平賬。
你可以告訴面試官，你們是接入的第三方對賬平臺，這個回答是最簡單的，變相告訴對方你見過用過，這就可以了。
你如果說對賬平臺是你們自己做的，對方若是個懂行的，估計會問你更多細節，所以我不推薦面試中主動這麼回答。
簡單來講，對賬的方法是調微信、支付寶、第三方（如果有）的賬單介面，拉取到賬單然後進行訂單的比對，計算出長款多少，短款多少，財務主要關心的是短款，因為短款表示客戶虧錢了，那麼財務就要追蹤這些款項丟失的原因，如果是長款，財務可問可不問，因為是多收的錢，對於財務來講沒所謂，有人找來就人工退掉，沒人找來不就白賺麼。
總而言之，對賬的目的是為了輔助財務查賬，透過對賬平臺，財務可以清晰直觀地看到每天的對賬結果。
總結
如果哪一天有面試官問你這些東西，你只要回答了，別人立馬就知道你是正兒八經做過支付的。
最後迴歸到開頭我問的那個問題，xdm知道我以前面試別人問的是其中哪個問題麼，我可以透露下，我不會問很複雜的，但是一個問題就能知道對方是不是真的做過。
好了，今天的小知識你學會了嗎？
如果喜歡請點贊+關注↓↓↓，持續分享乾貨哦！