接一個第三方支付，開發說要2個月？

很多產品在進行支付的時候，都有第三方支付的選項，這些年第三方支付的方式也在不斷增加。這就要求產品在設計支付渠道時，要考慮到拓展性。本文作者對此進行了分析，希望對你有幫助。

產品：我們近期需要增加一個支付渠道，評估一下工期吧？

技術：這個很麻煩，要改訂單，改流水，改前端支付接入……估計要兩個月吧。

產品：要這麼久嗎？Boss 說半個月內要上線。

技術：當初設計的時候沒有考慮接多個支付渠道，現在哪能想加就加，這可是涉及資金的環節，怎麼可能這麼快？

產品：……

一、前言

涉及到線上交易環節的系統都會接入第三方支付。當前的第三方支付渠道越來越多，從一開始的支付寶支付、到微信支付、再到雲閃付……現在還有各家銀行的支付渠道。比如我們看美團，就支援了微信、支付寶、雲閃付、美團支付和華為支付。

如此多的支付渠道，如果一開始的產品設計對支付這塊沒有考慮好，那麼出現上面的對話很正常，而且確實不能說是技術的鍋。

當然，做過多支付渠道接入的技術可能在一開始設計技術方案的時候就會考慮，但是大部分技術可能只是實現了支付的功能而已，並沒有考慮擴充套件性。然後，要擴充套件支付渠道的時候就會很被動。

二、支付閘道器

我們來看看在沒有支付閘道器的情況下，支付這個過程是怎麼樣的。

上面這幅流程圖是一個簡化版本的正向支付流程圖，發起支付的時候，使用者端需要選擇支付渠道，然後根據不同的支付渠道發起對應的支付。支付成功後，再處理訂單的支付狀態。

每一個支付渠道都有一套獨立的支付流程，也就意味著每接入一個支付渠道，這些部分都需要單獨開發，工作量和當初一開始做第一個支付的差不多，工期長就難免了。

這還是簡化的正向的支付流程，如果考慮訂單退款、資金流水管理，那麼工作量會更多。

怎麼化解這種情況？實際上還是需要產品從業務層面抽象支付過程。

我們梳理一下上面各個支付渠道的過程，發現其實發起支付、支付成功判斷和通知訂單支付成功這三個環節其實是類似的，因此可以將上面的流程圖簡化為下面的樣子。

中間框起來的那部分就是支付閘道器要做的事情。這個時候也許會有人質疑，實際上每個支付渠道還是要單獨處理一遍，並沒有簡化什麼。從面上看確實是，所以這裡就涉及到領域驅動設計的思想了。

三、領域抽象

回到我們的支付環節，我們可以拆分成三個模組，前臺模組、後臺的訂單模組和支付模組。

這三個模組如果能夠在前期透過一種形式進行分離和互動約定，那麼當三個模組的某個模組發生變動時，其他兩個模組的變動可以降低到極限，從而可以減輕變動帶來的系統開發工作量。

我們先來看看如何分離，分離的目的是儘量保證資料的單向流動，比如支付環節的資料流向圖如下。

從這幅圖我們可以看到，實際上前臺模組到支付模組的資料流是可以單向流動的，那麼我們約定好不同模組的資料互動規則就可以減少某個模組變動帶來的影響了。

下面是三個模組約定的資訊：

前臺到訂單：提交訂單時提供商品資訊，包括 SKU 的 id，數量，若考慮優惠的話把優惠資訊也一併提交；

訂單到前臺：訂單資訊，例如訂單詳情。

前臺到支付：提供支付渠道（由使用者選擇）和訂單號；支付模組會根據訂單號獲取實際要支付的金額建立支付流水，此時支付流水處於待支付狀態。這裡要注意，不能由前臺提交支付金額，因為前臺資料不是絕對可信的，實際金額要以後臺訂單模組的為準。

支付到第三方：一般接入第三方支付都需要後臺向第三方申請支付引數（通常會需要提供商戶號、金額、商家訂單號、商品資訊）。

支付到前臺：將獲取到的第三方支付引數按約定格式組裝給到前臺，讓前臺能夠按對應渠道的要求將支付引數提交到支付渠道（通常是第三方提供的 SDK）發起支付。

第三方支付到支付模組：支付後，第三方支付會推送支付成功的對賬資訊通知給到後臺，後臺核對無誤後，確認支付成功。支付模組會將之前建立的流水標記為支付成功。

支付模組到訂單模組：支付模組會告知訂單模組哪個訂單號支付成功了，然後訂單模組標記訂單為付款成功。

訂單模組到前臺：將支付成功資訊給到前臺，前臺會告知使用者已經支付成功。

由上面的資料流可以看到，實際上三個模組的邊界和資料互動是很清晰的。

因此，我們在設計的時候，把三個模組之前的互動資料約定好，那麼當支付渠道發生改變的時候，就只需要做少量改動就可以了。

在正向支付過程中訂單模組是不需要改動的，訂單模組和第三方支付並沒有直接的關聯。

增加支付渠道時，前臺一方面下單支付時提交對應的支付渠道即可。發起支付時按照第三方渠道的要求，將支付模組的渠道支付引數提交到第三方即可，實際上只是增加了第三方渠道支付的適配工作；

支付模組只需要適配新增渠道的申請支付和處理第三方支付成功的對賬通知即可。

整個工作經過梳理後會簡單很多，但這裡的前提是產品在設計之初就將支付模組和訂單模組分離了，分離後的支付模組就可以擴充套件為支付閘道器。

退款的逆向操作也是類似的，步驟如下：

前臺使用者發起退款申請，這裡也可以是後臺客服替使用者發起退款申請；

後臺稽核通過後，提交退款申請到支付閘道器（實際上是訂單模組到支付閘道器）；

支付閘道器向第三方提交退款申請。退款成功後，第三方支付會通知支付閘道器；

支付閘道器核對退款資訊無誤後，通知訂單模組退款操作成功，訂單模組會標記訂單的退款狀態。

當接入新的支付渠道時，實際上退款過程只需要支付閘道器處理即可，訂單模組不需要做任何改動。

四、總結

很多產品都會和第三方系統做對接，而第三方支付是最常見的一種形式。

如果產品同一項功能可能和多個不同渠道的第三方對接，那麼建議在不同渠道和具體業務功能之間增加一個適配功能，從而當接入新的第三方時，只需要更改適配功能，而不需要對業務功能進行大的改動，例如本篇介紹的支付閘道器。

這種設計方式，一方面需要產品經理能夠提前預判業務發展趨勢，另一方面還需要產品經理具備優秀的業務梳理和抽象能力。實際上，業務梳理和抽象能力是很多高階產品經理和初中級產品經理最為明顯的區別。

作者：產品海豚灣；公眾號：產品海豚灣（ID：pm-dophin-bay）

本文由@產品海豚灣 原創釋出於人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash，基於CC0協議。

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。