整體分為交易系統（OMS）、支付系統、清結算系統、對賬系統、會計報表（非必須）等幾個部分。
支付系統是負責電商系統收款和出款的子系統，需要支持電商平臺與外部渠道間，所有收款和出款的功能，以及電商平臺內部賬戶間轉賬的功能。簡單來說，支付平臺需實現充值、提現、轉賬、退款四方面的功能。
壹般來說，支付系統由以下幾個功能組成。
第三方支付：微信和支付寶占據國內移動支付的絕大部分份額，因此是壹定要接入的。
按照結算類型來分，收款類壹般有即時到賬、擔保交易兩種，出款類有轉賬、銀行卡代付等。
如果電商平臺有支付牌照，可以自己分賬，或者收款類型為年費等無需分賬的交易，那麽可以選擇即時到賬方式收款。
如果電商平臺沒有支付牌照且需要給實現二級商戶分賬，則可以選擇微信的收付通或支付寶的直付通等產品。但用戶通過微信支付的訂單才能通過微信的產品來分賬結算，支付寶支付的訂單才能通過支付寶的產品來結算，對於平臺對接、商戶收款皆有不便之處，因此電商平臺很少選用這種方式。
銀行卡支付
壹般來說，電商平臺接入了微信和支付寶後，已經可以滿足大部分支付需求，無需再接入銀行卡支付。而對於購買了支付牌照的大型電商平臺，想要打造自己的支付工具，才會對接各大銀行，接入快捷支付功能。或者有壹定規模的電商平臺也可以直接與銀行簽約，開通快捷支付接口。
和第三方支付不同的是，銀行卡收單、退款，壹般都不是實時結算的。而支付公司與電商商戶的收單交易，是實時結算的，實際是支付公司提前墊資。
快捷支付
現在市面上大部分電商app中，銀行卡支付功能都是使用的快捷支付方式。對於電商平臺，如果需要接入銀行卡快捷支付功能，有兩種方式：
例如電商平臺在工行開通了快捷支付接口，用戶簽約了工行卡快捷支付，用戶付款後，資金扣款成功結算後，會進入電商平臺在工行的結算賬戶。註意快捷支付是有經營業務種類限制的，只允許在簽約經營範圍內的業務收款，即MCC碼。
如果是第三方支付公司，因為不允許與銀行直連，需使用銀聯或銀行提供的網聯接口，用戶支付後，網聯結算後，金額會轉移到支付公司在銀行開設的備付金賬戶。
對於電商平臺，與銀聯對接要方便快捷得多，壹次接入即可搞定大多數銀行卡的快捷支付；而對於有支付牌照的電商平臺或第三方支付公司，為了更低的手續費，才會選擇與銀行直接對接。
銀行卡快捷支付，需要先綁卡簽約，後續則無需任何驗證完成扣款，而為了安全性，電商平臺會加上指紋、人臉、短信或支付密碼驗證，僅小額支付可以免驗證。
快捷支付的簽約，需要提供三要素（姓名，身份證號，銀行卡號）或四要素（銀行預留手機號），信用卡可能額外需要有效期和背後後三位數cvv。註意支付公司或電商平臺是不允許保存用戶的cvv碼的。在快捷支付簽約前，用戶需先完成實名認證或更高級別的認證，以保證簽約卡為本人銀行卡。國家法規對於第三方支付用戶的信息驗證有3個等級，三級為最高安全等級，對應的付款限額和支付範圍限制也更大。
對於第三方支付公司，為了安全性、手續費等原因，會與同壹家銀行，不同的總行分行，或者銀聯等其他通道，分別簽約快捷支付；用戶在綁卡簽約時，或者後續簽約支付時，可能在簽約壹個需短信驗證的通道的同時，還簽約了其他無需短信驗證的通道。後續用戶使用快捷支付時，支付渠道路由會自動選擇當前最合適的支付通道發起扣款。對於同壹張卡的快捷支付額度，使用不同的支付通道的額度是獨立的，但總額不超過發卡行的限制。
對於產品側來說，如果要實現快捷支付功能，前端需要實現簽約卡管理、新增簽約（錄入卡信息 - 識別卡信息 - 簽約結果返回）、解綁功能。
不管是第三方支付還是快捷支付，和支付公司簽約時，都可以綁定多個收款賬戶，有時為了財務上的區分，不同業務可使用不同收款賬戶收款。
銀行轉賬基礎原理
跨行轉賬有超級網銀和小額轉賬兩種，限額都是5w以內，開放時間都是7*24小時，不同的是超級網銀實時結算，小額轉賬銀行跑批處理，是準實時的。大額轉賬是在5w以上，開放時間是工作日的 8:30 ~ 17:00，實時結算。銀行提供的轉賬產品，基本都是基於上述三種方式包裝的。
電商業務的退款、商戶結算、傭金結算、供應商貨款結算等業務都涉及到出款。
退款：壹般來說，在支付後壹段時間內（壹般3到6個月），可以使用原支付渠道的退款功能，將資金原路返回。如果超過時間限制或部分退款次數限制，則無法原路返回。退款最多可能5~7個工作日才能確認返回狀態；對於銀行來說，壹筆已經清算的收單交易，手續費已經扣取；就算產生退款，之前的收單手續費也不會退回。如果在結算之前退款，銀行側可能支持按比例退回手續費。第三方支付公司與電商平臺之間退款手續費的收取，由雙方協議決定。
銀企直連：若電商公司已接入銀行的銀企直連產品，且支付對象已綁定銀行卡，則可使用此方式。
第三方支付的代付功能：對於高頻小額的付款需求，且用戶已綁定第三方支付賬號情況下，可使用此方式。
企業網銀：壹般用於2B的大額資金轉賬。資金結算或者用戶提現。
對於第三方支付公司，用戶提現時，同壹個出款賬戶，會歸集壹定量（金額或條數）之後批量提交銀行處理，所以提現不壹定能夠實時到賬。
出款的前提是用戶已實名認證，並綁定了實名對應的銀行卡。綁卡需要驗證四要素，會需要用到第三方支付提供的信息驗證接口，或直接與銀行對接。已經簽約過快捷支付的借記卡，也可以用於該賬戶資金提現，無需再次驗證。
各個支付渠道的接口指令各不相同，為了方便業務調用以及日後拓展維護，需要建立壹個統壹的支付網關，開放給業務使用；業務調用時同時指定支付渠道，支付網關請求渠道路由，按照事先配置的路由規則，返回最合適的支付通道，發起支付請求。
網關需實現不同類型的功能接口，壹般來說就是支付通道側接口能力的並集，如充值、提現、轉賬、退款、簽約查詢、實名認證校驗等等。
引導路由：是指用戶在付款時，給用戶展示支付方式的規則，包含可見狀態，可用狀態，展示順序等。引導路由的意義是，根據用戶支付的場景，引導用戶選擇平臺側希望用戶選擇的支付方式。平臺側的需求壹般是支付成功率高（通道穩定，額度充足）、費率低等，也有因不同支付渠道商務合作關系，限定額度分流的原因。
匹配接入的支付渠道比較少時，引導路由作用不大，壹般可能只有壹個簡單的權重配置後臺，即所謂的靜態路由，或者直接記住用戶上次選擇的方式即可。
渠道路由：對於電商平臺來說，如果只接入了第三方支付，則不存在渠道路由。對於支付公司來說，如果接入了不同銀行、銀聯網聯的快捷支付接口，且用戶選擇的銀行卡簽約了多個通道時，渠道路由則按照路由規則去匹配權重最高的渠道，發起扣款請求。
在斷直連之後，支付公司的代收服務，只能通過銀聯或網聯接口，因此渠道路由意義也削弱了。對於代付服務，支付公司會在各大銀行都開設收付賬戶，將跨行轉賬都轉化為同行轉賬，以提高轉賬速度免除手續費，同時支付公司需要做好備付金管理系統，自動或人工管理監控調撥各行備付金。
當業務向支付網關發起支付請求時，支付網關需要對業務方進行鑒權判斷，確定請求是否合法。壹次支付請求壹般包含以下元素：業務標示，支付時間，支付金額，支付賬號，支付客戶端信息，支付訂單信息等。支付網關需要確認各個元素都合法，比如支付時間是否在有效期內，此支付單是否過期；支付賬號狀態是否正常，支付訂單是否是可支付的，商品是否有庫存等等。同時還需要將這些信息過壹遍風控，風控那邊會根據各種規則判斷此次支付是否有風險。風控是壹個比較復雜的系統，屬於另壹個專業領域，在此不細說。
電商平臺向支付渠道請求支付後，支付渠道會同步或異步返回支付結果信息。如果支付渠道不主動返回結果，電商平臺側則需要定時去輪詢結果。同時電商側需要將支付請求信息、結果信息、結果憑證等保存下來，也就是支付流水記錄。支付流水記錄是之後電商與支付渠道對賬的憑證。
拿到支付結果記錄後，支付系統需要向支付請求方返回支付結果，同時通知賬務系統，觸發對應的記賬操作。
各個支付渠道都會按日和按月生成交易記錄文件和資金流水賬單，分為支付、退款、提現等類型。交易記錄文件相當於信息流憑證，資金流水賬單相當於資金流憑證。
銀行渠道壹般也會推送資金流水文件，但不是所有銀行的交易都有業務對賬文件，通常收單交易業務對賬文件會普遍壹些。
電商的支付系統或者對賬系統，需要做的事情：
支付系統同樣需要和上遊各個業務系統進行對賬，包裝支付狀態金額的壹致性。壹般采用明細軋帳的方式。
收單對賬常見問題：
長款：用戶支付了但是交易系統未確認支付成功，這種情況需要及時補單或者退款處理，壹般如果業務側訂單狀態是待支付則可轉為支付成功，狀態是已取消則自動退款；也有可能是測試數據混入了生產環境；也有可能能與之前的短款差錯互相抵消；
短款：壹般是日切問題導致，掛賬後下個會計日繼續對賬；或者看是否能與之前的長款差錯互相抵消；
重復支付：壹般支付渠道都不允許重復支付同壹個訂單，發現重復支付也可以自動退款處理；
金額不壹致：可能用戶支付後，支付結果返回之前，交易系統訂單金額變化了
退款常見問題：
網絡問題或接口問題導致退款失敗，這種情況可自動再次提交退款；
對方賬戶狀態異常導致退款失敗，這種無法走原路返回退款方式，只能轉賬/代付；
退款時需要處理好支付手續費的退款，以及退款手續費誰來承擔的問題，壹般是按比例退；
對於短款差錯，可掛賬7天處理。
提現常見問題：對方賬戶狀態異常導致退款失敗，需要及時通知用戶處理。對於短款差錯，可掛賬3天處理。
產品側需要設計對賬管理後臺，可查看支付流水，對賬批次記錄，差錯處理後臺等。對於固定處理方式的差錯類型，可做成自動化處理。
合單支付是指用戶壹次支付多筆訂單，在電商中很常見。電商業務側需要自己做好訂單拆分，支付系統中，如果使用支付渠道的合單支付接口，則會自動拆分記錄支付流水，是最佳的方式；如果支付渠道沒有合單支付接口，則可拆可不拆，按原始記錄保存簡單不易出錯，拆分記錄則可方便其他業務處理。
混合支付是通過多種支付方式，支付壹筆訂單，比如余額+快捷支付。混合支付會按照不同支付方式，生成多筆支付流水。
因為不同支付方式，支付成功率不同，可能會發生有的支付方式扣款失敗的情況。因此混合支付需要按照支付成功率，優先扣款成功率較低的支付方式；如果有某些支付方式扣款失敗，需要判斷是取消支付，全部退款，還是提醒用戶換其他方式繼續支付；全部支付方式都扣款成功後，這比訂單才支付完成。後續訂單發生退款，如果是部分退款，需要判斷，優先退款手續費最低的支付方式。
電商平臺或支付公司有時候會做營銷活動，出錢補貼支付，也可以用混合支付方式處理。
據說余額+卡的混合支付有洗錢風險，目前已逐漸少見。
對於大額訂單，可以采用分次、分階段支付的方式，實質也是壹種混合支付。
訂單完成時，電商平臺需要扣取平臺傭金，結算貨款給商家；若涉及推廣服務，則需要計算推廣用戶的傭金和稅額，再結算給推廣用戶。
按照法規，沒有清結算牌照的電商，不允許自行截存貨款，之後再結算給商家。電商平臺可以選擇第三方支付公司或者使用銀行的電商清結算產品，由他們代為保存貨款，之後再結算給商家。此類產品需要先提交商戶資料給支付渠道或銀行審核，審核通過後，用戶支付此商戶訂單，提交支付同時上送清分規則（分給哪些人，按照什麽比例或金額）。在訂單交易完成時，電商側提交結算請求，支付平臺按照此前支付時上送的清分規則進行分賬結算。部分支付平臺，需要在結算時由電商平臺指定分賬對象和金額，但這樣略有二清嫌疑。
選擇這類清結算產品時，還需要註意以下幾點：
接入此類產品後，除了後端的支付、結算接口對接以外，電商平臺商戶側客戶端，也需要對接好商戶入駐進件，提現賬戶綁定，結算賬單等功能。
電商平臺常見的分銷、主播代銷、拼團、淘寶客等銷售模式，其中“分銷商”或“團長”角色，本身不是銷售主體，在訂單完成後可獲得推廣傭金。壹般來說，這部分推廣費用，在訂單生成後，商戶側可在訂單費用明細中看到此支出項；在訂單結算時，可將推廣傭金與平臺傭金壹起扣除，再由平臺將推廣傭金結算給推廣人員。
這類支出屬於勞動報酬，平臺有為推廣人員代繳稅的義務，需要按月計算稅率和金額。因此部分平臺采用月結的方式，每個月指定日期，計算每個待結推廣人的稅費，扣除後再將稅後金額結算給推廣人。也有部分平臺（比如O2O，網約車平臺等），會自己承擔此部分稅費（羊毛出在羊身上），在訂單結算時，即時將推廣傭金結算給推廣人，次月再統計推廣人稅費，平臺自己為推廣人交稅。
平臺也可以采用各種稅務籌劃方式，比如“靈活用工”的方式，與推廣人建立非全日制勞務關系，這樣推廣人可以享受更低稅率。
平臺自行結算給推廣人，可使用銀企直連、支付平臺代付等功能進行出款。而平臺代繳稅需要推廣人的實名信息，所以在推廣人在提現傭金之前，需要先實名制認證。
不管采用哪種結算方式，電商平臺都需要計算訂單結算時的各類費用明細（清分），負責清分的模塊，也叫做計費系統。
電商平臺有花樣百出的扣點規則，比如按商品、按商戶、按品類、按營銷活動等規則扣點，以及各類推廣傭金等。扣點規則路由對應著各類扣點規則，比如針對商品、商家、類目的扣點規則管理後臺，基本元素是扣點對象、扣點比例、扣點上線、規則生效時間範圍、規則狀態等。產品經理需要和運營人員確認好扣點規則判斷邏輯，即根據怎樣的條件判斷順序，確認訂單適用的扣點規則。之後加入新的扣點規則時，也需要維護這個扣點規則路由。
扣點規則路由各電商平臺都不壹樣，可能包含營銷活動、下單/支付客戶端、買家身份、扣點規則權重等等。
壹般在訂單創建時，扣點規則路由就需要根據訂單相關的信息，判斷出訂單適用的扣點規則並記錄下來。同時也需要將用於判斷的信息元素保存下來，以作為之後核對憑證。
如果訂單有推廣員的參與，則也需要在訂單創建時，計算出需要扣除的推廣費用，並保存記錄相關推廣員信息。
在計算各方分賬明細時，需要註意幾點：
與訂單交易相關的清算，壹般來說，是在訂單狀態變為終態（交易完成，退款完成），且訂單尚有待結算金額時，由交易系統向清結算系統提交清結算請求。也有壹些多次結算的場景，比如訂單裏有部分商品先確認收貨時，也可以先結算部分金額，後續再結算剩余金額。
對於有支付牌照的大型電商平臺，為了提高商戶的回款速度，也可以在訂單尚未變為終態時給商家結算貨款，比如用戶確認收貨時或者商家發貨時。如果結算後訂單發生退款，則再在商戶錢包中扣除相應金額。此類結算方式需要平臺側有比較成熟的風控能力，通過風險控制和風險轉移的方式，防止平臺資金損失。比如和商戶簽約協議，設置商戶保證金，商戶&買家風控，購買對應的賠付保險等等。
交易系統向清結算系統發起結算請求時，需提交結算訂單、結算金額、結算類型（完全/部分結算）等字段。清結算收到結算請求後，可能實時結算，也可能異步周期結算，比如每X小時壹次等，視業務量大小決定。
開始結算時，計費中心從賬務系統獲取訂單待結金額，根據結算類型核對結算金額，核對無誤後，凍結待結算金額，並提交到計費中心；計費中心找到訂單快照中的扣點規則，計算分賬明細。
計費中心計算出各方分賬明細後，需要和賬務中心進行實時或準實時的對賬，保證需結算的金額等於各方分賬明細之和。核對無誤後生成預結算單。
大部分訂單，此時結算中心可將結算單提交到支付系統，進行最終的資金轉賬。小部分訂單，結算單可能需要人工審核，則需要審核通過後再提交到支付系統，或者駁回撤銷此次結算。
各分賬方壹般會提前在支付系統內部開設好賬戶，支付系統會將資金結算到各方的資金賬戶中，對於支付系統來說，僅涉及內部賬戶間的資金轉移，因此很少會出現結算支付失敗的情形。
支付系統返回結算成功結果後，結算單狀態變為結算完成；結算系統需要實時通知交易系統和賬務系統，賬務系統記錄各賬戶資金變化，更新賬戶余額；交易系統則觸發對應的消息通知等關聯服務。如果有會計系統的話，也需要異步通知會計系統，進行會計分錄記賬。
對於成熟的支付公司，會有賬務系統和會計系統兩套系統。這兩套都是以會計分戶模型來設計，不同的是賬務系統是直接面向業務使用，隨著業務信息流實時記賬並更新余額，賬務流水更多記錄交易相關內容；會計系統是面向財務會計使用，壹般是異步入賬，使用嚴格的復式記賬法。
賬務系統中的賬戶，必須是在是賬務系統分戶中的葉子科目下。兩套系統之間的分戶模型，會有多對多的關系。賬務系統這套體系可稱為分戶賬戶（外），會計系統這套稱為分戶賬戶（內）。
按照復式記賬法，壹般分為資產、負債、損益、***同類等。
交易的實質就是各金額賬戶間資金的轉移，因此首先需要建立好對應的賬戶。
賬戶設計遵守三戶模型：客戶、賬號、賬戶。
客戶：指自然人或企業，必須要實名認證才可以開通支付賬戶，客戶以身份證號為唯壹標識。
賬號：登錄賬號，壹個客戶可以有有限多個賬號，即壹個身份證可以用於有限多個賬戶用來實名認證。但對於同壹個支付公司，壹個身份證下多個賬號，支付額度上限是***享的。根據身份認證信息豐富程度，支付平臺余額賬號等級分為壹二三類，3類擁有的支付額度和權限最高是20萬/年。余額提現、余額寶支付、信用支付無年度額度限制。銀行卡快捷支付簽約、提現銀行卡綁定等操作，也是以賬號為主體操作。
賬戶：每個賬號在支付平臺或電商網站，都會有多個不同功能的賬戶。商戶側有貨款結算賬戶，保證金賬戶；買家側有支付賬戶，信用支付賬戶，積分賬戶；或者電商平臺側的內部賬戶，比如活動補貼賬戶，訂單擔保賬戶等。
賬務核心主要有四張表：分錄流水、分戶賬、明細賬、總賬。
首先需要有壹個交易碼 - 分錄規則的分錄規則表，用來維護每種用交易碼區分的交易場景，發生時應該如何拆成會計分錄的規則。比如定義交易碼1001為訂單銀行卡快捷支付，那壹筆訂單付款流水，經過支付平臺，同步到賬務中心時，根據同步過來的交易碼1001，找到對應的分錄規則，按照規則中的定義，生成會計分錄：
當壹筆業務發生時，首先生成分錄流水，然後驅動賬戶余額變化，賬戶余額變化後，生成明細賬。日終根據分錄流水生成總賬。根據業務需要，也可以先修改賬戶余額，然後異步生成分錄流水，但是無論先生成會計分錄，還是緩沖異步生成會計分錄，都要保證分錄流水與分戶賬余額的壹致性，這壹點通過日終系統的檢查來保證。
每天首先需要做支付渠道的對賬，然後再進行賬務系統和會計系統內對賬。
需要做到：
錯處理需達到2個效果，壹個是完成對賬，另外壹個是將賬務對平，常見的賬務處理方式有掛賬、登賬、調賬。
補單：通過人為幹預方式，將原有業務進行下去，如通過接口人工幹預訂單狀態
掛賬：對於不平賬單，先掛起，等查明後再進行相應處理
登賬：會計記賬，伴隨虛擬資金從壹個賬戶向另壹個賬戶轉移的過程（原始憑證）
1、多賬
多賬主要存在2種情況，壹種是異步通知未收到，優先采用補單處理，另外壹種是同訂單2次支付，壹般通過登賬處理
2、短賬
基本不會出現，壹般通過簽名防抵賴機制與第三方協調處理。協調壹致後通過人工增加對賬單進行平賬。
3、金額不壹致
出現概率極低，壹般為電商平臺內部計算有誤。
首先得先解決此bug，然後根據異常訂單相應處理，比如說撤銷對賬，修改系統或對賬單金額後再進行對賬。