1. 項(xiàng)目目標(biāo)

支付中心架構(gòu)將各業(yè)務(wù)的公共交易、支付、財(cái)務(wù)等沉淀到支付中心，并主要解決了以下三個(gè)主要問題：

建立基礎(chǔ)訂單、支付、財(cái)務(wù)統(tǒng)一體系，抽象和封裝公共處理邏輯，形成統(tǒng)一的基礎(chǔ)服務(wù)，降低業(yè)務(wù)的接入成本及重復(fù)研發(fā)成本；

構(gòu)建安全、穩(wěn)定、可擴(kuò)展的系統(tǒng)，為業(yè)務(wù)的快速發(fā)展和創(chuàng)新需求提供基礎(chǔ)支撐，解決業(yè)務(wù)「快」和支付「穩(wěn)」之間的矛盾；

沉淀核心交易數(shù)據(jù)，同時(shí)為應(yīng)用端、物業(yè)公司、用戶提供數(shù)據(jù)支撐。

2. 具體調(diào)用流程

在目標(biāo)的指導(dǎo)下，我向集采、O2O、收費(fèi)易三個(gè)項(xiàng)目組的相關(guān)開發(fā)咨詢了業(yè)務(wù)邏輯，再結(jié)合我們自己的業(yè)務(wù)場(chǎng)景調(diào)整了支付中心調(diào)用流程和兩個(gè)注意點(diǎn)。

首先，我們來看一下支付中心的調(diào)用過程。

業(yè)務(wù)系統(tǒng)、支付中心和第三方通道的交互流程圖如下：

各系統(tǒng)交互流程為：

物業(yè)公司開通第三方支付渠道商戶，并獲取第三方支付參數(shù)；

物業(yè)公司將第三方支付參數(shù)提供給支付中心，開通商戶號(hào)、開通支付渠道、獲取商戶標(biāo)識(shí)和支付標(biāo)識(shí)；

物業(yè)公司將商戶標(biāo)識(shí)和支付標(biāo)識(shí)提供給應(yīng)用端；

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

應(yīng)用端使用物業(yè)公司提供的商戶標(biāo)識(shí)和支付標(biāo)識(shí)，以及必備的支付訂單號(hào)，支付金額、調(diào)起方式，上送至支付中心；

支付中心將獲取的標(biāo)識(shí)解析到對(duì)應(yīng)的參數(shù)，并整合應(yīng)用端的請(qǐng)求參數(shù)，向第三方支付發(fā)起支付，并獲取支付發(fā)起的結(jié)果；

支付中心將發(fā)起結(jié)果整合后直接返回給應(yīng)用端，注意，這里只是這個(gè)請(qǐng)求是否發(fā)起成功的通知，并不是最終支付結(jié)果的通知。

第三方支付調(diào)起用戶的支付或者跳轉(zhuǎn)收銀臺(tái)頁面、小程序調(diào)起用戶支付進(jìn)行支付，第三方支付獲取到用戶的支付結(jié)果之后。回調(diào)通知支付中心；

支付中心處理數(shù)據(jù)，并回調(diào)通知應(yīng)用端；

應(yīng)用端處理訂單信息，并開始訂單、通知用戶。

注意：

2.1 訂單號(hào)問題

問題起因：有些應(yīng)用系統(tǒng)使用訂單號(hào)上傳，有些使用自己系統(tǒng)中的流水號(hào)上傳并發(fā)起支付。

所以這里設(shè)計(jì)如下：

應(yīng)用系統(tǒng)上送的無論是訂單號(hào)還是流水號(hào)，支付中心都不直接使用，而是進(jìn)行記錄，并重新生成一個(gè)唯一的流水號(hào)上送第三方支付；

第三方支付會(huì)在校驗(yàn)參數(shù)成功確認(rèn)支付發(fā)起成功后，再返回由第三方支付生成的流水號(hào)，用于以后的賬單查詢、對(duì)賬、退款等功能；

支付中心會(huì)保存三個(gè)流水、訂單號(hào)，方便以后調(diào)用、查詢；

在收到第三方支付的調(diào)用返回時(shí)，支付中心會(huì)重組調(diào)用返回參數(shù)，將應(yīng)用上送的訂單號(hào)。支付中心生成的唯一流水號(hào)，第三方支付返回的流水號(hào)，一并返回應(yīng)用端，建議應(yīng)用端都進(jìn)行保留。

2.2 使用哪個(gè)號(hào)進(jìn)行退款的問題

這里設(shè)計(jì)為：

使用支付中心流水號(hào)判定使用哪一筆訂單退款；

上送了支付中心生成的流水號(hào)后，根據(jù)流水號(hào)和商戶標(biāo)識(shí)以及支付標(biāo)識(shí)檢索出來的結(jié)果進(jìn)行退款。退款金額不可超過該筆流水號(hào)支付的金額；

應(yīng)用端可以根據(jù)業(yè)務(wù)需求自行選擇退款方式，支付中心只做和流水號(hào)相關(guān)的退款。

2.3 有關(guān)收銀臺(tái)

現(xiàn)在有些第三方支付存在自己的收銀臺(tái)，有的沒有。所以支付中心必須有自己的收銀臺(tái)，但同時(shí)如果第三方支付存在已有收銀臺(tái)也沒有必要跳轉(zhuǎn)兩次。

所以這里的邏輯設(shè)計(jì)為：

如果第三方存在必須跳轉(zhuǎn)的收銀臺(tái)，使用第三方收銀臺(tái)。其余情況直接使用支付中心收銀臺(tái)。

3. 支付中心架構(gòu)設(shè)計(jì)

目前的系統(tǒng)功能整體架構(gòu)如下：

如圖所示，從架構(gòu)上主要分為四個(gè)大模塊：

支付中心后臺(tái)：主要是賬號(hào)管理相關(guān)，物業(yè)公司的開戶開通支付等提供支持；

支付消息：主要是用于對(duì)應(yīng)用端進(jìn)行通知；

交易核心：用來支撐整個(gè)系統(tǒng)的基礎(chǔ)交易核心，參數(shù)組裝發(fā)起、返回?cái)?shù)據(jù)的處理、異常的處理和通知等；

渠道網(wǎng)關(guān)：解析應(yīng)用端發(fā)送過來的請(qǐng)求，證書白名單的設(shè)置和使用，第三方api的調(diào)用等。

3.1 支付中心后臺(tái)

收銀臺(tái)

3.2 渠道網(wǎng)關(guān)

支付賬戶管理

物業(yè)公司選擇自己所需的支付渠道進(jìn)行開通；

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

最后請(qǐng)求中由支付中心處理，收入對(duì)應(yīng)的收款賬戶。

request 解析器

一個(gè)請(qǐng)求在進(jìn)入 request 解析器之后：

首先解析支付標(biāo)識(shí)，決定使用哪個(gè)支付插件（alipayPlugin、wechatPlugin、easyPlugin）；

其次解析調(diào)起方式（小程序、PC、APP）；

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

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

3.3 交易核心

交易核心的數(shù)據(jù)庫設(shè)計(jì)

分賬資金流向

4. 目前預(yù)見的可能的問題

數(shù)據(jù)監(jiān)控

出現(xiàn)數(shù)據(jù)異常，或者報(bào)錯(cuò)，及時(shí)在釘釘群里通知。

數(shù)據(jù)一致性問題

咱們的系統(tǒng)打算暫時(shí)只做一個(gè)模塊，應(yīng)用端可以到支付中心來同步數(shù)據(jù)。

穩(wěn)定性問題，第三方支付不夠穩(wěn)定

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

這個(gè)需要應(yīng)用端進(jìn)行監(jiān)控，支付中心對(duì)于提供的不同訂單號(hào)會(huì)實(shí)時(shí)發(fā)起支付。同一訂單號(hào)，連續(xù)發(fā)起兩次之間間隔不超過 15 秒。

轉(zhuǎn)自：fadεy

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

責(zé)任編輯：haq