1. 項目目標

支付中心架構將各業務的公共交易、支付、財務等沉淀到支付中心，并主要解決了以下三個主要問題：

建立基礎訂單、支付、財務統一體系，抽象和封裝公共處理邏輯，形成統一的基礎服務，降低業務的接入成本及重復研發成本；

構建安全、穩定、可擴展的系統，為業務的快速發展和創新需求提供基礎支撐，解決業務「快」和支付「穩」之間的矛盾；

沉淀核心交易數據，同時為應用端、物業公司、用戶提供數據支撐。

2. 具體調用流程

在目標的指導下，我向集采、O2O、收費易三個項目組的相關開發咨詢了業務邏輯，再結合我們自己的業務場景調整了支付中心調用流程和兩個注意點。

首先，我們來看一下支付中心的調用過程。

業務系統、支付中心和第三方通道的交互流程圖如下：

各系統交互流程為：

物業公司開通第三方支付渠道商戶，并獲取第三方支付參數；

物業公司將第三方支付參數提供給支付中心，開通商戶號、開通支付渠道、獲取商戶標識和支付標識；

物業公司將商戶標識和支付標識提供給應用端；

至此，物業公司注冊流程完畢，接下來是支付流程；

應用端使用物業公司提供的商戶標識和支付標識，以及必備的支付訂單號，支付金額、調起方式，上送至支付中心；

支付中心將獲取的標識解析到對應的參數，并整合應用端的請求參數，向第三方支付發起支付，并獲取支付發起的結果；

支付中心將發起結果整合后直接返回給應用端，注意，這里只是這個請求是否發起成功的通知，并不是最終支付結果的通知。

第三方支付調起用戶的支付或者跳轉收銀臺頁面、小程序調起用戶支付進行支付，第三方支付獲取到用戶的支付結果之后。回調通知支付中心；

支付中心處理數據，并回調通知應用端；

應用端處理訂單信息，并開始訂單、通知用戶。

注意：

2.1 訂單號問題

問題起因：有些應用系統使用訂單號上傳，有些使用自己系統中的流水號上傳并發起支付。

所以這里設計如下：

應用系統上送的無論是訂單號還是流水號，支付中心都不直接使用，而是進行記錄，并重新生成一個唯一的流水號上送第三方支付；

第三方支付會在校驗參數成功確認支付發起成功后，再返回由第三方支付生成的流水號，用于以后的賬單查詢、對賬、退款等功能；

支付中心會保存三個流水、訂單號，方便以后調用、查詢；

在收到第三方支付的調用返回時，支付中心會重組調用返回參數，將應用上送的訂單號。支付中心生成的唯一流水號，第三方支付返回的流水號，一并返回應用端，建議應用端都進行保留。

2.2 使用哪個號進行退款的問題

這里設計為：

使用支付中心流水號判定使用哪一筆訂單退款；

上送了支付中心生成的流水號后，根據流水號和商戶標識以及支付標識檢索出來的結果進行退款。退款金額不可超過該筆流水號支付的金額；

應用端可以根據業務需求自行選擇退款方式，支付中心只做和流水號相關的退款。

2.3 有關收銀臺

現在有些第三方支付存在自己的收銀臺，有的沒有。所以支付中心必須有自己的收銀臺，但同時如果第三方支付存在已有收銀臺也沒有必要跳轉兩次。

所以這里的邏輯設計為：

如果第三方存在必須跳轉的收銀臺，使用第三方收銀臺。其余情況直接使用支付中心收銀臺。

3. 支付中心架構設計

目前的系統功能整體架構如下：

如圖所示，從架構上主要分為四個大模塊：

支付中心后臺：主要是賬號管理相關，物業公司的開戶開通支付等提供支持；

支付消息：主要是用于對應用端進行通知；

交易核心：用來支撐整個系統的基礎交易核心，參數組裝發起、返回數據的處理、異常的處理和通知等；

渠道網關：解析應用端發送過來的請求，證書白名單的設置和使用，第三方api的調用等。

3.1 支付中心后臺

收銀臺

3.2 渠道網關

支付賬戶管理

物業公司選擇自己所需的支付渠道進行開通；

用戶選擇自己傾向的支付方式；

最后請求中由支付中心處理，收入對應的收款賬戶。

request 解析器

一個請求在進入 request 解析器之后：

首先解析支付標識，決定使用哪個支付插件（alipayPlugin、wechatPlugin、easyPlugin）；

其次解析調起方式（小程序、PC、APP）；

獲取可用的支付插件（alipaypaymentappexecutor、xxxexecutor）；

最后選擇方法（onpay waponpay refund）。

3.3 交易核心

交易核心的數據庫設計

分賬資金流向

4. 目前預見的可能的問題

數據監控

出現數據異常，或者報錯，及時在釘釘群里通知。

數據一致性問題

咱們的系統打算暫時只做一個模塊，應用端可以到支付中心來同步數據。

穩定性問題，第三方支付不夠穩定

主要是用戶可能會用微信支付失敗，又用支付寶支付。

這個需要應用端進行監控，支付中心對于提供的不同訂單號會實時發起支付。同一訂單號，連續發起兩次之間間隔不超過 15 秒。

轉自：fadεy

鏈接：blog.csdn.net/liuzhirou1/article/details/117649569

責任編輯：haq