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

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

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

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

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

物業(yè)公司將商戶標識和支付標識提供給應用端。

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

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

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

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

支付中心處理數(shù)據(jù)，并回調通知應用端。

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

訂單號問題，問題起因：有些應用系統(tǒng)，使用訂單號上傳，有些使用自己系統(tǒng)中的流水號上傳并發(fā)起支付。所以這里設計如下：

• （1）應用系統(tǒng)上送的無論是訂單號還是流水號，支付中心都不直接使用，而是進行記錄，并重新生成一個唯一的流水號，上送第三方支付。

這里還涉及到退款使用哪個號進行退款的問題，這里設計為：使用支付中心流水號判定使用哪一筆訂單退款。上送了支付中心生成的流水號后，根據(jù)流水號和商戶標識以及支付標識檢索出來的結果，進行退款，退款金額不可超過該筆流水號支付的金額。應用端可以根據(jù)業(yè)務需求自行選擇退款方式，支付中心只做和流水號相關的退款。

有關收銀臺，現(xiàn)在有些第三方支付存在自己的收銀臺，有的沒有，所以支付中心必須有自己的收銀臺，但同時如果第三方支付存在已有收銀臺也沒有必要跳轉兩次。所以這里的邏輯設計為：如果第三方存在必須跳轉的收銀臺，使用第三方收銀臺，其余情況直接使用支付中心收銀臺。

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

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

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

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

數(shù)據(jù)監(jiān)控：出現(xiàn)數(shù)據(jù)異常，或者報錯，及時在釘釘群里通知。

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

穩(wěn)定性問題，第三方支付不夠穩(wěn)定：主要是用戶可能會用微信支付失敗，又用支付寶支付。這個需要應用端進行監(jiān)控，支付中心對于提供的不同訂單號會實時發(fā)起支付。同一訂單號，連續(xù)發(fā)起兩次之間間隔不超過15秒。