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