支付型的產(chǎn)品與普通的產(chǎn)品類型不同，需求文檔中充斥著大量的業(yè)務(wù)詞匯和場景，導(dǎo)致全局性的需求要更難一些。本文作者分享的這些經(jīng)驗，希望可以成為你的助力。

作為一個文科生轉(zhuǎn)行到IT行業(yè)，我想最大的困難是很多時候我不太適應(yīng)一堆堆技術(shù)術(shù)語組成的文檔。

不過支付系統(tǒng)目前已經(jīng)是很成熟的體系了，很多都是現(xiàn)成的服務(wù)，產(chǎn)品經(jīng)理更多的職責(zé)體現(xiàn)在落地能力。

我所說的落地能力指的是結(jié)合商戶的業(yè)務(wù)場景分析出商戶需要匹配什么樣的解決方案，以及根據(jù)現(xiàn)有系統(tǒng)的情況，需要做怎么樣的改造或者新建。

本篇文章就簡單闡述下，對于一個新業(yè)務(wù)，產(chǎn)品經(jīng)理的工作流程是什么樣的，以及需求文檔如何寫。

基于新業(yè)務(wù)，首先要調(diào)研和分析分析業(yè)務(wù)模式和業(yè)務(wù)痛點，這是產(chǎn)品經(jīng)理的基本技能。

即使有行業(yè)特性，所謂的各行如隔山，產(chǎn)品經(jīng)理也可以通過咨詢相關(guān)業(yè)務(wù)同事或者商戶側(cè)的業(yè)務(wù)人員得到答案。

當(dāng)然，如果產(chǎn)品經(jīng)理在某一或幾個行業(yè)上具備更多的經(jīng)驗視角，專門服務(wù)和拓展某類商戶的話，就可以直接為一些商戶展示解決方案，再根據(jù)商戶的反饋去適配或者升級現(xiàn)有的功能。

做好以上的調(diào)研分析工作后，產(chǎn)品經(jīng)理就需要評估如何能快速提供出符合商戶或者渠道需要的支付解決方案了。

01 需求文檔落地前準備

新業(yè)務(wù)的接入（前提是業(yè)務(wù)合理），第一步首先要考慮商戶的進件以及計費模式。

商戶的進件是一個商戶準入的前提，需要與合規(guī)、風(fēng)控、法務(wù)和財務(wù)等相關(guān)部門梳理出商戶進件所需的材料。

產(chǎn)品經(jīng)理需要將業(yè)務(wù)模式講清楚，為相關(guān)審核同事提供業(yè)務(wù)支撐，必要時可請業(yè)務(wù)同事協(xié)助。

需要注意的是，很多時候業(yè)務(wù)的玩法超出想象，所以對于支付行業(yè)來說，做好必要的保密工作和交易監(jiān)控是非常必要的。

在初始評審業(yè)務(wù)模式時，產(chǎn)品需要對可能存在的業(yè)務(wù)漏洞具備警覺性，以便在系統(tǒng)設(shè)計的各個環(huán)節(jié)上滲透，甚至必要時預(yù)警。

合規(guī)，法務(wù)，風(fēng)控等相關(guān)審核同事評估好后，產(chǎn)品經(jīng)理即可獲取到商戶需要提交的進件材料、計費模式（業(yè)務(wù)的收費項目），還有一些業(yè)務(wù)約束，比如限額等等信息。

一般情況下進件材料三證是必須的，特殊行業(yè)再加相應(yīng)證件，比如物流行業(yè)需要加《道路運輸許可證》等。

還有一些比如說法人代表身份證件，展業(yè)平臺信息，辦公或者營業(yè)場所照片等文件。

業(yè)務(wù)的收費項目做好后，還需要進一步確認記賬規(guī)則，這一步是提前與財務(wù)溝通好的。

財務(wù)會分配記賬科目，不同的業(yè)務(wù)類型有不同的記賬規(guī)則，在支付的過程中會去調(diào)用記賬規(guī)則存儲數(shù)據(jù)，以便后續(xù)財務(wù)區(qū)分業(yè)務(wù)并做相關(guān)統(tǒng)計和分析。

財務(wù)還會有BDCA流程，即Bussiness Data Compliance Assurance ，就是業(yè)務(wù)數(shù)據(jù)合規(guī)安全保障的意思。

最重要的作用是通過各條鏈路數(shù)據(jù)上的比對，在有長短款出現(xiàn)的時候能及時發(fā)現(xiàn)預(yù)警。

BDCA對于有著大量交易的支付公司來說是非常必要的，會避免很多資金風(fēng)險。

可以說，程序員寫的代碼就是個勞力，而BDCA是監(jiān)工，讓他們不要出錯。

獲取到記賬規(guī)則后，后面就要考慮收費項目的配置問題，如果原有的費率系統(tǒng)不支持，那就要改造或者新建費用配置模版。

一般的收費模式會區(qū)分為卡支付和聚合支付。

卡支付一般是以銀行為區(qū)分的，適配于各通道費用成本不同。再加一個默認兜底值，可以看做統(tǒng)一費率配置，既不區(qū)分銀行。

聚合支付起初是按照支付方式區(qū)分的，比如APP支付，公眾號支付、服務(wù)窗支付等等。

后來是按照行業(yè)屬性既MCC計費的，比如大型商超，就屬于線下渠道，電商平臺就屬于線上渠道。

02 準備寫需求文檔

以上的問題有了脈絡(luò)以后，就該落筆需求文檔了。

第一：背景交代。

業(yè)務(wù)場景說明，術(shù)語定義，業(yè)務(wù)流程等都要交代出來，以便研發(fā)和測試同學(xué)理解。

如有交互的，還需要出具交互流程和交互界面，以便研發(fā)和測試同學(xué)直觀的理解前后端的需要如何聯(lián)動。

第二：商戶進件。

在商戶進件時無論是調(diào)用接口還是頁面提單，有相應(yīng)的改造都需要同步，以保障支付產(chǎn)品上線后商戶能順利進件。

第三：產(chǎn)品開通。

商戶接產(chǎn)品必然是有權(quán)限校驗的，那么對應(yīng)的開通環(huán)節(jié)也要同步改造。

第四：支付側(cè)改造，也是最核心的一環(huán)。

一般情況下，如果通道的接口文檔也是新的，那就需要研讀通道接口文檔，這里是指接入銀聯(lián)或者網(wǎng)聯(lián)的渠道接口。

首先看接口文檔支持的交易類型，比如說消費，撤銷，退貨，交易查詢，退貨查詢，交易通知等等。

這些都是需要貫穿在前端的交易場景中的，一般來講，通道的支持情況也決定了產(chǎn)品的體驗。

舉個例子，交易通知，是無論交易成功失敗都通知，還是只支持通知成功的？是通知的最終結(jié)果，還是說有了終態(tài)后就通知一次？

比如云閃付支付，客戶卡余額不足會通知一次支付失敗，客戶換卡支付成功后又通知一次支付成功。

如果只按照交易通知更新交易結(jié)果就會造成長款，既實際交易成功做了失敗處理，資金就會滯留在中間戶，需要給用戶做退款處理。

退貨交易要注意不要發(fā)起重復(fù)退貨，重復(fù)退貨會造成短款，在產(chǎn)品設(shè)計過程中遵循寧可長款，不可短款的原則。

因為長款可退，短款很難追，就會造成資金損失。

如果后端接口不是新啟用的，那么只要關(guān)注現(xiàn)有的流程和接口如何改造即可。

以上摸索完之后就可以畫流程圖了。

支付流程需要明確各個系統(tǒng)如何調(diào)用如何返回，以及如有改造的需要如何改造。

查詢流程主要是補充支付過程中對支付結(jié)果不明確的情況下的需要系統(tǒng)自動調(diào)用查詢獲取結(jié)果，也就是訂單超時處理機制。

當(dāng)然也有商戶主動發(fā)起的交易結(jié)果查詢。

交易結(jié)果通知一般都是異步通知，在系統(tǒng)設(shè)計時，和查詢一樣附在支付流程中。

支付通知和查詢哪個先獲取到了終態(tài)，就依據(jù)哪個變更訂單狀態(tài)，特殊邏輯特殊處理。

比如云閃付的情況，接收到交易通知后不更新訂單狀態(tài)，而是當(dāng)訂單有效期過了以后再次查詢渠道獲取結(jié)果更新。

退款流程要區(qū)分是否支持部分退貨，如支持部分退款還需特意關(guān)注下發(fā)起退款時金額與總金額的比對，以免多退造成資金損失。

退款查詢也是附帶在退回流程中，也是為輔助獲取退款結(jié)果或者支持商戶主動發(fā)起查詢使用。

卡支付還有鑒權(quán)流程，所謂鑒權(quán)和支付，其實可以理解為每次支付行為都要填寫那么多信息你很煩，所以先出了個鑒權(quán)動作。

鑒權(quán)本身沒有消費行為，但是它為后面的消費行為授權(quán)，無需再輸入卡號信息。

鑒權(quán)時要注意是否支持重復(fù)鑒權(quán)，如果不支持，會返回什么信息，針對返回信息做不同的處理。

因為鑒權(quán)也是有有效期的，如果支持重復(fù)鑒權(quán)，就要關(guān)注鑒權(quán)的時間是否會重新計算。

當(dāng)然還有消費鑒權(quán)的場景，就是鑒權(quán)和消費用同一個接口交互，支付功能都是適配于不同的業(yè)務(wù)場景的，所以雖然相對來說消費鑒權(quán)體驗較好，但也不是每個業(yè)務(wù)場景都適配消費鑒權(quán)。

這就是支付產(chǎn)品的特殊之處，并不是每個動作都追求體驗，安全相比體驗會更重要些。

第五：商戶手續(xù)費收取

這里需要先講下清結(jié)算。

支付流程是商戶請求，支付機構(gòu)接收到指令請求到銀行，銀行返回相應(yīng)信息，用戶進行支付，銀行進行扣款，并通知支付公司，支付公司再通知到商戶的過程。

清結(jié)算是在這個流程中算費和結(jié)費的過程。

可以說清分是結(jié)算的數(shù)據(jù)準備階段，結(jié)算才是支付的完結(jié)，他們分別代表著數(shù)據(jù)流和資金流。

清結(jié)算系統(tǒng)會定時或?qū)崟r撈取交易信息，通過查詢商戶費率計算出手續(xù)費費用，刨除時效等不談，需要強調(diào)下是凈額結(jié)算還是全額結(jié)算。

全額結(jié)算顧名思義就是全額結(jié)算給商戶，如基金公司的手續(xù)費都是后收。凈額結(jié)算是去除手續(xù)費后結(jié)算給商戶。

所以，清分就是在獲取各種規(guī)則后計算出一個計費結(jié)果，作為數(shù)據(jù)存儲起來。

結(jié)算就是根據(jù)清分的數(shù)據(jù)生產(chǎn)結(jié)算指令，結(jié)算給商戶，至此支付完結(jié)。

清結(jié)算一般也都是成熟的體系，產(chǎn)品經(jīng)理需要關(guān)注的是，一個商戶入駐后，如何記賬以及收取的各項手續(xù)費在哪里配置，如何配置？

商戶的手續(xù)費配置都是建立在商戶號下，根據(jù)不同的交易類型、支持的業(yè)務(wù)場景進行配置。

至于手續(xù)費是業(yè)務(wù)系統(tǒng)單獨算，還是統(tǒng)一丟給清結(jié)算系統(tǒng)算，退貨退不退手續(xù)費，部分退貨手續(xù)費如何算，是否需要實時結(jié)算等等這些都是結(jié)合業(yè)務(wù)場景考慮并需要配置的 。

第六：對賬。

通過以上信息其實整個支付流程已經(jīng)完結(jié)了。那么商戶對賬也是一個重要的板塊。

首先，對應(yīng)的數(shù)據(jù)落地需要同步到數(shù)據(jù)對賬系統(tǒng)，尤其是新增字段，對賬系統(tǒng)也需要對應(yīng)的改造。

如果支付都做好了，對賬服務(wù)沒提供，商戶接入體驗就會很差，雖然對賬信息，可以通過人工拉取獲取給到商戶。

其實，要明確商戶按照哪些關(guān)鍵字段對賬，比如商戶號+交易時間+交易類型等字段。

經(jīng)常出現(xiàn)的問題是比如用戶是23:58分發(fā)起的支付，但是在00:02分完成了交易，這種情況就要商戶溝通好是以哪個時間為準。

這樣，雙方的賬單才是平的。

當(dāng)然也包含通道側(cè)的對賬，通道側(cè)的對賬信息一般在通道的接口文檔中有規(guī)范，一般情況下都是按照銀行的對賬規(guī)則進行對賬。

第七：注意下應(yīng)用的疊加

比如支付方式下是否支持分賬產(chǎn)品或其他服務(wù)。

這也是在充分溝通商戶場景后判斷的，新產(chǎn)品爭取不要遺漏功能點，免得交付時不滿足商戶多樣的業(yè)務(wù)場景。

第八：監(jiān)控

前文提了一些，業(yè)務(wù)監(jiān)控和系統(tǒng)監(jiān)控都要考慮。

一般業(yè)務(wù)監(jiān)控都是類似商戶余額不足這種業(yè)務(wù)類的預(yù)警以及交易情況異常，需要產(chǎn)品經(jīng)理介入分析和觀測的預(yù)警。

系統(tǒng)監(jiān)控一般是系統(tǒng)異常的報警。

03 上線后的準備

忙活了以上這些后，就要做上線后的準備了。

第一：提交BDCA流程，前文已經(jīng)介紹了BDCA的作用，不再復(fù)述。

轉(zhuǎn)測后測試同學(xué)測的差不多了就應(yīng)該提交財務(wù)流程了，正式上線前是需要財務(wù)審批通過的。

第二：準備合同模版。

一般商戶模版是產(chǎn)品經(jīng)理起草初稿，然后給到法務(wù)同事審核的。需要在產(chǎn)品上線前完成流程審批，以備商戶進件使用。

第三：準備培訓(xùn)資料。

含技術(shù)培訓(xùn)文檔、配置培訓(xùn)文檔以及產(chǎn)品介紹文檔。對應(yīng)不同的角色進行不同的培訓(xùn)，確保商戶接入時各角色就位，接入順滑。

04 上線后的關(guān)注

如果你認為前面產(chǎn)品經(jīng)理貌似忙活了好多，其實那也只是開始，真正上線后才是打響了戰(zhàn)斗。

因為商戶在使用的過程中會提出優(yōu)化點，或者新場景，產(chǎn)品經(jīng)理需要在各個商戶群中活躍。

聽商戶的痛點，看產(chǎn)品邏輯的缺陷，想產(chǎn)品的可拓展性以及準備相應(yīng)的數(shù)據(jù)觀測。

以上，簡單的分享了下支付產(chǎn)品需求文檔的脈絡(luò)，淺薄之處，還望包涵，如有錯誤，也歡迎指正交流。