使用第三方支付集成有何風險，例如 Beecloud 或者 Ping++？

12-29

使用第三方支付集成有何風險，例如 Beecloud 或者 Ping++

謝邀。
對熟悉支付的開發人員而言，此類服務其實接入並不難，一個成熟的支付渠道接入一般一周之內就能完成接入。但對諸多對支付及交易系統沒概念的初創型公司，可能成為一個業務發展的大瓶頸。因此對這些公司而言，此類服務確實能夠降低支付方面的集成難度及接入時間。這也是為何有諸多提供支付集成接入服務商的存在（甚至一些有支付牌照的公司也提供多種第三方支付渠道的集成接入服務）。

採用此類服務的風險（首先聲明和強調一下，不是針對某個平台，只是從技術層面探討可能存在的風險）：
1、信息泄露風險
大致分成幾種：
a、支付渠道參數泄露
由於需要將支付渠道參數提供給第三方支付集成服務商，這樣增加了信息泄露的概率。而出現信息泄露問題後，由於商家和第三方支付集成公司都持有支付參數信息，責任邊界及損失承擔方無法確認。
Beecloud及Ping++的兩位創始人在以上回答中提到了他們的措施，但極為不認同「黑客拿到這些參數能幹嘛呢？我想來想去他們能做的就是給你們的公司打錢，貌似也不是啥壞事。」的觀點。
例如：
假如商家接入了銀聯全渠道的代扣介面，支付渠道參數被泄露了，黑客調用此介面，對通過其他渠道獲取的信用卡進行惡意代扣，出現了投訴及糾紛，導致商戶必須賠付這些資金。
例如商家本身提供合法正當的服務，支付渠道參數被泄露了，黑客使用此介面，用於博彩、洗錢等非法服務，被第三方支付的風控系統監測，導致商家被加入黑名單。

b、交易數據泄露
因支付集成服務提供商內控不嚴等原因，交易信息通過這些渠道泄露給競爭對手，競爭對手通過分析交易信息可以有助於分析其業務模式及發展戰略。這也是為何京東後面停止與支付寶合作的原因之一。

c、客戶數據泄露
要開通移動支付等服務，一般要對客戶身份進行實名認證，如果通過第三方支付集成服務商的
SDK調用第三方支付的實名認證介面，由於數據需要通過第三方傳遞，可能存在客戶數據泄露的風險。

2、支付集成服務商提供服務跟不上商戶業務發展需要的風險
由於集成服務商提供的介面服務依賴於各家支付公司，坦率地說：國內主流支付公司的介面都極爛，有一堆坑，其諸多介面也在不斷完善中，因此支付集成服務商的價值之一就是對支付介面相對熟悉，可能知道這些坑。

直接與各家支付公司對接可以及時得到一手的介面更新信息（例如出現安全漏洞後），但如果依賴於支付集成服務商，必須等其開發資源排期、SDK發版本進度等諸多不可控因素。

如果商家業務模式需要在支付模式有創新（非標準化支付服務，例如要T+0結算），依靠支付集成服務提供商，周期可能很長，而且可能最重滿足不了需要。

3、支付集成服務商系統穩定性、安全性的風險
Beecloud及Ping++的兩位創始人在上面回答中對自身系統穩定性措施談了許多，這裡就不細說。

需要指出一點：在選擇平台時候，一定要注意外部攻擊的風險（例如DDOS攻擊）。

標準接入模式下，是商家-&>多家第三方支付；在集成服務商介入後，變成商家-&>集成服務商-&>多家第三方支付。
在集成服務商模式下，如果其系統遭受DDOS等外部攻擊，相當於接的多家支付都無法使用。而在標準模式下，除非多家第三方支付同時遭受攻擊，否則是部分可用的。
在防攻擊、防釣魚、容災能力、信息安全等方面的防護能力上第三方支付肯定是強於集成服務提供商。

另外在APP SDK上，支付集成服務商在第三方支付SDK基礎上包裝了標準介面，方便了接入，但在SDK的安全上也引入了潛在風險（例如SDK在官方SDK出現漏洞後更改不及時）。

4、資金安全風險
由於做二次清分及結算存在支付牌照合規監管要求，因此一般集成服務商一般不提供結算服務，都是由支付公司直接將資金結算給商家，但並不意味著資金就安全了。
上面的支付渠道參數泄露其實就是涉及資金安全風險，其他例子包括洗錢等風險。

最後談談我對第三方支付集成服務的觀點：
1、第三方支付集成服務商有其存在的價值。
2、任何服務都由其優缺點，每家公司需要根據自身情況來做決定
3、整體而言，第三方支付集成服務適合於那些創業初期、需要快速驗證模式業務的公司。

最後再聲明一下：此處只是從技術角度探討風險，不針對任何一家支付集成服務商。

大家都注意到了支付參數的問題。

由於有了這些支付參數，其實可以對資金進行逆向操作，比如退貨

不過更大的風險在於，類似支付寶，其實是提供了批量轉賬的功能，意味著，拿到這些參數的人，有辦法將你賬戶裡面的錢嗖嗖嗖轉到他指定的賬戶，參見 https://b.alipay.com/order/productDetail.htm?productId=2011052500326597tabId=1#ps-tabinfo-hash

不過我相信，作為一家有節操的企業，不會自己幹這種事，所以，對企業來講，需要保證三點
1.內控，防止內部員工監守自盜
2.外部防禦，防止外部人員通過某些方式竊取
3.系統設計方法，我認為這是最重要的。不要說什麼加密的資料庫安全，只要是軟加密的，一定有破解的辦法。所以，引入硬體加密機吧，並建立健全的信息管理機制。將所有的渠道參數，從拿到的那一刻起，送到加密機裡面做個加密再儲存起來，用的時候也送到加密機去轉加密給到渠道，從系統設計的角度，讓自己的內部人員也無法拿到渠道參數…

謝題主的問題，我們是 Ping++，作為國內最早的一家做第三方支付集成的公司，這類問題其實我們在其它地方有過闡述，現在我們還是希望能在此和大家分享一下。

使用第三方支付集成有何風險？

這其實也幾乎是每個商戶在使用前必問的一個題目。支付本身的風險不必再提，我們想說的是：使用第三方支付集成公司的產品後，與你直接去使用支付渠道相比，增加了哪些風險？

首先介紹一下 APP 直接接入支付需要經過的流程。

申請渠道參數，接入各渠道 SDK，根據渠道參數構建支付憑據（請求渠道介面和加密渠道參數），客戶端調起支付控制項，處理渠道的支付非同步通知。

再介紹下 APP 使用第三方支付集成公司接入支付需要經過的流程（以 Ping++ 為例）

申請渠道參數，在 Ping++ 管理平台填寫商戶信息，接入 Ping++ SDK，發起支付請求，客戶端通過 Ping++ SDK 調起支付控制項，處理 Ping++ SDK 的支付成功的非同步通知。

從流程對比來看，Ping++ 在構建支付憑據、調起支付控制項以及非同步通知等處做了封裝處理，商戶不需要關心各渠道支付的參數，請求地址，加密方式，流程的區別，簡化了商戶的接入成本。但這也是使用第三方支付集成公司可能增加風險的幾個地方，主要體現在以下 2 個方面：

a. 安全性

支付最應該保障的是安全性，安全性的風險主要涉及資金、支付要素信息和商戶身份信息三方面。商戶通過第三方支付集成公司接入支付渠道，均為真實身份，交易資金直接由支付渠道清算到商戶賬戶，所有支付要素信息也均是相應的渠道的支付控制項採集，所以第三方支付集成公司不會也不可能接觸到支付要素信息。最大的風險是在商戶身份信息（即支付渠道參數）泄露這個層面。

支付渠道參數泄露後，並不是不會對商家造成影響，因為這些參數會被其它人利用，用來發起交易並進行退款操作。比如某商戶的微信支付參數被泄露給了 A，A 可以在商戶的 App 里發起交易，並在收到貨時發起退款操作，此時，商戶就承擔了一些風險。

所以在最初設計 Ping++ 時，安全性也是我們一直非常重視的問題。包括不會要求商戶提供任何可能導致商戶資金風險的安全信息，用於標示商戶身份的信息及數字證書均加密存儲在資料庫中，交易報文均通過 https 進行傳輸，這些都可以用來最大程度保證商戶身份安全。

在數據安全層面，Ping++ 已於 2016 年 10 月 10 日通過 PCI DSS 國際安全認證（Ping++獲 PCI DSS認證領跑聚合支付數據安全--貴州頻道--人民網）。PCI DSS 認證是全球公認的支付領域系統數據安全和產品安全標準，Ping++ 也是截至目前國內聚合支付行業為數不多的獲得認證的企業。PCI 認證是國際範圍內支付卡數據安全領域最嚴苛的安全認證標準，企業接入 Ping++ 支付系統不僅能節省高昂的認證費用、繁瑣的技術升級流程，也保證了系統的穩定性和並發承受能力。

b. 穩定性

穩定性更多考量的是一家公司對異常情況的處理能力。比如支付渠道故障，訂單異常，高並發時伺服器負載的壓力。商戶若自行接入支付，原本只需要依賴商戶和支付渠道本身的伺服器，現在中間增加了一層第三方支付集成公司，從表面上是增加了出現異常的可能，但實際上使用 Ping++ 在穩定性上，是降低了風險的。

渠道故障：前段時間支付寶蕭山區某工地光纖被挖斷，不少用戶在數小時內無法使用支付寶，這類支付渠道自身造成的故障無法避免。但在這一點上，作為第三方支付集成的公司也是有必要告訴商戶問題出在哪裡。Ping++ 針對這類故障專門設計了支付服務狀態監控，實時監控所有支付渠道的穩定性，商戶可以在第一時間知道是支付渠道的問題，還是 Ping ++ 的問題。

訂單異常：每個支付渠道的都有不同的錯誤類型，相關的文檔也不是很詳細，沒有支付經驗的開發人員往往會在出現這些錯誤時踩坑，而 Ping++ 做好了良好的介面封裝，將可能的錯誤情況以清晰友好的格式返回給商戶。

並發問題：在業務量突然暴增時，若是自行接入，可能在伺服器在處理這些問題沒有很好的經驗，導致訂單的流失。Ping++ 對於並發處理做了很好的優化，例如使用緩存來減輕資料庫負載等，非同步處理一些事務等。

技術支持：Ping++ 目前已經服務了 14000 多家商戶（數字於 2016.10 更新），對於各類異常問題都能在最快時間定位，並做技術解答，而這也是在自行接入支付渠道時無法獲得的支持。

為什麼需要第三方支付集成公司的存在？

作為第三方支付集成公司，除了單純的做支付接入外，更多的是要給商戶比支付渠道更好的服務，不然商戶就完全沒有使用我們的意義。

2014 年整年，Ping++ 在幫商戶做支付接入上，2016 年，我們更多的是在幫商戶提升用戶的支付體驗，以此幫商戶提高支付轉化率。而在很多商戶看不見也感知不到，但在 Ping++ 看來會給商戶支付帶來問題的地方，我們也做了很多優化處理，包括系統安全性的不斷鞏固升級，PCI DSS 國際安全認證的通過等等。

更重要的是，作為聚合支付解決方案提供商，區別於其它
To B 類型的互聯網公司的一個很重要的一點，就是你在支付行業的經驗，設計產品是從支付產品考慮，而不僅僅是個互聯網產品。在支付系統基礎之上，2016 年 9 月，我們新上線了用戶賬戶系統和多級商戶系統，賬戶系統全面支持充值、優惠券、提現、餘額賬戶的功能，多級商戶系統是針對平台類商戶，提供了子商戶管理、分成結算、財務對賬等功能，這些功能都更加貼近商戶的業務本身，也讓商戶的支付系統更加完整及安全。

BeeCloud 的黃總也在回復中提到了社會需要分工，沒必要大家都重複造輪子。這種「共享經濟」的理念我們很贊同，Ping++ 也在幾個月前提到過，在此也可把網易科技報道的 Ping++ CEO 金亦冶的文章分享給大家看看金亦冶：為什麼說這個世界終究是屬於那些2B公司?_網易科技

最後，歡迎大家來 Ping++ 官網體驗產品： https://pingxx.com/

我是BeeCloud的創始人，這個問題我很關注，因為我是技術出身，寫代碼也10多年了，所以我試著站在一個程序員的角度，給出一個比較詳盡而客觀的回答：

使用第三方支付集成，風險有沒有？確實有，主要在幾方面：

1、服務的穩定性

使用了第三方的支付服務，勢必會涉及與第三方的伺服器通訊。比如BeeCloud的做法是把後端完全打包，客戶端通過一個統一的REST API與BeeCloud通訊，BeeCloud負責與微信，銀聯，支付寶的伺服器通信，這樣開發者完全不用寫後端的代碼了。但是如果第三方支付集成的伺服器掛掉，那支付就會受到影響。

2、支付參數的安全性

如果使用第三方支付集成，難免涉及到與我們共享一些支付的參數，比如微信的AppID和AppSecret等。不用多說，任何一個提供我們類似服務的企業都會盡全力防止這類參數泄漏，就像所有的網站都會保護好自己用戶的密碼信息一樣。這些參數即使被偷，能夠多大壞處，也要分情況討論，下面會詳述。

3、客戶端的bug

如果是iOS和Android，需要引入第三方支付集成的客戶端SDK，這個SDK中如果有一些bug，比如iOS里調用了一個nil對象的方法，Android里的NPE都會導致app崩潰，第三方SDK導致app crash是引入第三方SDK的最常見的問題之一。

需要澄清的一點，因為在 @西弗倫斯的回答中有提到，資金安全方面，BeeCloud完全在資金的閉環之外，完全不參與資金的清算，錢直接從用戶的賬戶到商戶在微信支付寶銀聯的賬戶里，我們沒有做代理清算。做了代理清算是不是不安全有待商榷，但是我們這樣完全不做代理清算的話，資金安全由支付寶微信銀聯直接保證的。

回到主問題，既然使用第三方支付集成存在這些風險，那麼是否表示一定不能用這類第三方服務呢？

我覺得不然，即使是站在一個客觀的角度。

節省開發周期，節約開發的時間和人工成本，快速接入，這些都是顯而易見的好處，我暫且放下不說。針對我剛才提到的3點風險，我做一個分析：

1、服務端穩定性

支付的服務是需要backend的支持的，比如算簽名，比如從支付渠道那裡接收支付結果的回調，比如記錄支付結果，這一類的服務都需要雲端的伺服器的支持，因為這些事情是客戶端不可能做到的。有了雲端的伺服器，就會有穩定性的風險，那這個選擇就在於你是希望自己來take care一切，還是把其中的一部分（比如支付）的穩定性的保障交給一些人（比如BeeCloud）來take care？我回國之前就在美國矽谷上班，那裡各種第三方技術服務的使用習慣很好，一個網站或者一個app基本都是各種第三方服務拼裝起來的，我們的榜樣Stripe就是這個例子。國內目前對這個第三方服務的接受度也是在逐步提高的。我永遠都不會說BeeCloud是完美的，但是我們一直在努力解決我們遇到的各種問題，比如如果一台伺服器故障，如何保障服務不會宕掉，比如突發的高並發如何處理。無論是穩定性，還是性能都是影響終端用戶付款體驗的重要部分，無論是否使用第三方的集成服務，如果你們產品交易量不小的話，我建議都需要找一個專業的團隊設計實現支付的後端架構，因為支付畢竟是產品的各種組件中至關重要的一個部分，如果出問題會帶來直接的經濟損失。

2、支付參數的安全性
首先討論下黑客拿到某個商戶A的支付參數可以用來做什麼？拿支付寶的即時到帳產品舉例吧。第一，收款：黑客可以用這些參數開發一個自己的網站，以商戶A的名義通過支付寶即時到帳產品收款。從資金層面，黑客並沒有辦法收到錢，因為錢直接被付到商戶A的對公支付寶賬號里。但是這也存在一些隱患，比如黑客的目的不是金錢，而是損害商戶A，使用商戶A的支付參數在非法的網站上進行收款服務，就有可能導致商戶A的支付寶賬戶被封禁。第二，退款：黑客可以利用退款參數，對已經支付過的某一筆訂單發起退款，當然需要首先知道一筆已經支付成功的訂單的訂單號，其次商戶A必須同意這一筆退款，例如支付寶的話，還需要登陸支付寶商戶後台輸入支付密碼才能完成退款。其他評論中有提到一些第三方支付的代扣介面，這些參數如果丟失，可能導致更嚴重的後果，不過如果如果僅僅依賴於支付參數而沒有其他的風控措施的話，這些介面本身的安全性也是值得詬病的。

3、客戶端的bug

我覺得這個問題和1是一樣的，還是那個選擇的問題，你是願意自己take care這些bug的處理（因為你就算自己實現，也有可能引入各種bug），還是把支付的客戶端業務交給第三方的SDK提供方來take care。其實換一個角度，因為一個SDK被各種不同的客戶用過，有各種bug肯定會被各種客戶發現然後修正，經過了一段時間的積累，SDK的那部分代碼出錯的可能會遠小於自己去從頭實現一套自己的客戶端。

總結一下就是，我覺得社會需要分工，一些工作（比如接入支付寶，微信，銀聯這些技術開發集成），如果有人做過，就沒必要大家都重複去造輪子，節約下來的時間人力物力還有程序員的腦力可以為祖國的四個現代化建設做很多事情，BeeCloud就是我基於這樣的一個理念創立的。

注1：本評論在2015/7/15修正過，主要是修正了對支付參數安全性的一些不太確切的描述。

這個問題看了樓上的回答，包括同行的兩家業界翹楚，除了前面給出的答案，我也來說說我的理解。

首先是業務方面。

支付的專業性較強，小企業資源有限，使用第三方支付集成商可以降低企業成本，將有限的資源及精力放到自身的核心業務上。

1.互聯網企業使用支付主要進行收款。除商戶密鑰外，所有信息的採集均在第三方支付公司，第三方支付公司的賬號密碼都在商戶自己手中，第三方支付集成商不能發起提現，即便是跑路，錢也乖乖的趴在第三方支付公司賬戶上。

2.怎樣才算真正支付了？真正發起了一筆交易？這其中的信息流為：商戶端（例如app）－
第三方支付集成商
－第三方支付公司－銀行，走第三方支付集成商的企業的信息流和企業直接接第三方支付公司比起來，只多了一步集成商而已。資金流為：客戶銀行卡
－第三方支付公司備付金賬戶－商戶銀行卡，這個資金流與企業是否接入第三方支付集成商毫無關係。至於說到第三方支付集成商，真正的風險是系統宕機，這塊在技術方面再詳細說。

3.運營諮詢。支付的坑（這一部分樓上都沒有提到）不僅僅在於支付接入上，在後續的業務運營當中，不斷的有新的問題發生。這些問題對於小企業都很難快速定位，在最短的時間內給用戶一個滿意的答案。例如用戶拒付了怎麼辦、支付公司對某筆交易調單了怎麼辦、用戶重複支付了怎麼辦、對賬發生差異了怎麼辦等一系列的問題，如果使用專業的的第三方支付集成商，這些問題都可以得到很好的解決。

其次是技術方面。技術層面的很多風險都可以通過處理進行解決。

1. 操作風險：支付系統和錢打交道，風險的控制和一般互聯網系統是完全不一樣的，所以操作風險是其中非常嚴重的一個風險之一。常見的有上線風險、配置風險、測試風險和運營風險。上線風險是指在上線過程中因為操作問題到導致，最好的解決方案是實現完全的灰度發布，徹底隔離用戶數據；配置風險指證書、響應碼等等的配置錯誤導致的風險，這塊最好的解決方案是通過嚴格的自動化流程式控制制，去除人工化操作；
測試風險是指測試過程疏忽導致的資金風險，這塊也需要嚴格的自動化流程式控制制；運營風險指的是比如路由切換等造成的風險，這裡只能通過審核來控制，沒有特別好的方法，因為有的地方是必須人參與、不可自動化的部分。

2. 程序風險：常見的有並發風險，狀態設置錯誤風險，核對風險，查詢風險等。並發險就是指分散式環境下，由於並發導致的資金多付少付，多扣少扣風險，這塊最好的方案是有限狀態機加影響條數來解決；狀態設置錯誤風險，是指所有的第三方支付集成都是對接三方的響應碼，響應碼管理是非常複雜的事情，如果狀態翻譯錯誤，那麼就會導致資金風險，所以方案是統一響應碼+狀態保守原則，即非明確失敗的狀態一定是處理中，後續通過查詢查回結果；核對風險，是指第一次查詢結果和第二次查詢結果可能不一致，這個常常是由於三方和銀行某些特殊錯誤導致的，所以一定需要核對查詢；查詢風險，常見的就是查詢速度過快導致訂單不存在，所以針對不同的三方，都需要設置不同的查詢時間。

總結一下，除了becloud的黃總和pingxx說的沒必要大家都重複造輪子，選擇專業的第三方支付集成集成商，可以幫助小企業規避支付風險。

最後，我們也來分享下付錢拉的故事，付錢拉：基於聚合支付展開的金融服務，如此多樣

官網：付錢拉_首頁 | 創業者的支付之道。歡迎大家來體驗。

愛貝雲計費是從2009年開始就在做在線計費和在線支付集成方案的公司，初創團隊是最早在移動夢網時代就作計費平台的產品研發人員。很多人都從技術方面和安全方面去分析使用第三方支付集成方案的必要性，其實這也是國內外互聯網行業的一個很重要的差異。
1、從技術上來說：專業的事情專業的人來做，第三方的支付集成商專註在這個領域中，像前面的兄弟所說的，該踩的坑，能踩的坑都基本上趟得差不多了。例如：前段時間某個支付通道方切換DNS服務，造成北方服務的不穩定，像愛貝，會進行南北異地機房的服務切換，而一般的開發者是不會專門只是為了支付去作多機房服務熱備的。降低了開發者的開發成本，這個大家應該都是能體會到的。除了接入時的開發成本以外，當支付平台方有作變動的時候，也都由集成商對這些變動作了兼容，而減少了開發者需要強更客戶端等的風險。同時，在作多平台的兼容的時候，使用集成商的服務也更有優勢，大部分平台都會覆蓋ios、android、h5、pc，像愛貝還覆蓋了wins，同時考慮到pad和6"屏以上的大屏手機的用戶交互問題，還單獨出HD版本來進行適配，以提高用戶付費的轉化率（互聯網上的消費，大部分時候是衝動消費，如何快速的進行轉化為實際消費很重要）

2、安全性：這個有兩個方面了，
第一：技術上的安全性，像愛貝的所有介面都是要作對稱加密的，包括服務端之間的回調等，信息泄漏上面本身不存在問題。
第二：服務端泄漏商戶的敏感信息，包括帳號信息和交易數據等。正因為支付集成公司是做跟計費支付相關的，跟錢很近的業務，所以這方面的管控比一般的公司都要嚴格很多，愛貝雲計費的在線支付集成服務上線6年了，服務幾千家商戶，都從未發生過這種信息泄漏問題，所以目前百度、中國移動、酷派雲商店等這樣大型互聯網公司、互聯網渠道方和電信運營商都在使用愛貝的服務。

3、其他的增值服務：第三方的支付集成商，一般都會提供其他的增值服務，這塊對於大部分的開發團隊來說都是隱性的成本。像愛貝會提供7x24小時的客服座席服務，來處理用戶支付過程中的問題，包括用戶的投訴，支付掉單的補單等，多維度的數據統計分析來幫助日常的運營決策等。

我也從事了十幾年的互聯網產品研發，在重複造輪子的問題上，國內的公司，都很容易陷入到大而全，小而全的循環中去，在互聯網公司中會尤為突出，技術上確實沒有不可實現的，但是管理者需要考慮開發成本和時間成本。市場化的公司應該專註在擅長和主營的業務中去，特定的領域採用專業公司的服務，自身輕裝上陣，在互聯網這種快魚吃慢魚的環境中業務會更有競爭力。

最後，在那些體量已經很大的公司中，確實是會做閉環，但是大家都會發現支付部門都是獨立於業務部門存在的團隊，從一定程度上來說，業務部門其實也是在使用第三方提供的支付服務。

我也在做公司內部支付中心，以下純屬個人觀點；

詳細看了兩家的API，拋開安全不講，發現部分問題：
1. 對於回調介面都未做參數簽名
存在的風險：用戶下了單但沒付款，知道回掉介面，直接mock一個支付成功請求，商戶以為已支付成功，結果錢沒收到貨發出去了。
2. 回調均未考慮第三方處理失敗的情況，給出關鍵的提示，要知道支付寶和微信針對不同的支付場景可是定義了數十個錯誤碼和異常碼。
3. beecloud參數不統一，駝峰命名和蛇形命名交叉使用，很是迷惑，還把第三方的所有參數封裝在messageDetail中，其實商戶估計只關心這筆訂單的主體內容和交易（付款和退款）是否成功吧。
4. ping++ 回調參數給了一大堆示例，但對欄位的解釋隻字不提，難道要開發者去猜？

個人對介面的理解：
第一層：能用，不能容錯，不能給出準確的提示。
第二層：實用，能容錯，能給出準確的提示。
第三層：好用，在第二層的基礎上增加統一的規範，完善並標準的文檔，每一種場景標準的測試用例，最後做到開箱即用。

介面並發問題暫不在此羅列。

作為半個業內人員，也來瞎扯幾句。
看了上面所有回答，其實都忽視了一項科學分析的基本原則：不設對照組的實驗都是扯淡。

所謂風險和安全性，都是相對的，需要先假設企業不使用支付集成，會有什麼替代方案，再講這個方案與支付集成相比，才可以說風險更大或是更小。而絕對的安全是不存在。

舉個例子，熱議的渠道參數泄露問題。
方案1：不使用支付集成
能接觸到渠道參數的人可能但不限於產品經理、研發經理、開發人員、IT運維等。
數據存儲是自建機房或雲主機。
方案2：使用支付集成
能接觸到渠道參數的人可能但不限於產品經理、支付集成公司等。
數據存儲是支付渠道公司機房或雲主機。

從企業的美好願望出發，總是樂觀的認為自己的員工是忠誠可靠的，自己的伺服器安全萬無一失，但從實際案例和人性來看，只能說自求多福了。
所以從某種意義上說，把渠道參數交給【成熟的】支付集成公司風險反而會更小。（垂直行業123除外）

其他方面使用相同的分析方法，相信大家也能得出自己的結論，就此惜墨。

當初幫公司的線上支付選擇技術方案時，曾深得此帖幫助。如今作為已使用BeeCloud一年多的用戶，想通過剛剛發生的一件小事來吐槽下使用第三方支付集成平台的感受，希望能投桃報李，對其他朋友有參考價值：

BeeCloud SDK的示例中將 Key 和 Secret 都存儲到了App的客戶端，例如Android平台的代碼示例是「BeeCloud.setAppIdAndSecret("appId", "appSecret");」，可根據計算機安全最基本的「客戶端的一切都可被破解或篡改」的原則，這種做法存在嚴重安全隱患，因為一旦有人惡意得到 Key 和 Secret，就可利用以下漏洞實現不真正付款即騙取到商品：
1. 正常創建訂單，並不對訂單信息做任何篡改；
2. 跳過支付環節（即不真正支付）；
3. 用Key和Secret，及實時生成的 timestamp 生成簽名，並冒充Beecloud的伺服器對商家的webhook進行回調；
4. 商家的webhook發現簽名有效，無法識別出冒充的回調並非來自Beecloud，而是以為支付已成功完成，從而發貨。

我想，任何稍了解計算機安全的技術人員，都能看出上述問題是個比較明顯且嚴重的安全隱患，可在我跟BeeCloud研發中心的技術人員討教、溝通的過程中，對方竟一直說這種做法並無任何問題，跟我所說的將Secret存儲於伺服器端只將訂單簽名提供客戶端的做法在安全性上沒有差別，甚至還跟我舉例說「就像你沒有保管好銀行卡密碼，丟了錢不能怪銀行」一樣……銀行是無須對用戶泄露銀行卡密碼負責，但哪家銀行會像BeeCloud這樣，在給用戶的使用說明（文檔）中建議用戶將銀行卡密碼寫到紙上並把紙藏到公共圖書館的一本書里呢？！

在我費盡口舌終於跟BeeCloud的技術支持人員解釋清楚上述邏輯後，對方給出的處理建議是：讓我到BeeCloud的技術討論群內把問題描述清楚，他們會更新技術文檔，對所述安全隱患予以提醒。可我把問題提到他們的技術討論群後，並未得到適宜反饋，也許還不及我現在這樣寫到知乎里，對其他朋友的參考和提醒作用大。這也是促我在知乎首次發帖的原因。

最後我想說，對於一個專註於做好支付平台的技術公司，研發中心的技術人員會如此態度對待客戶提出的嚴重安全隱患，實在讓人驚詫和失望。從成為BeeCloud用戶的一年多時間裡，我們曾前後幾次電話諮詢技術問題，對方技術人員的水平和態度常讓人錯覺客戶是客服、客服卻是上帝……BeeCloud的首頁以一句「創造更好的支付體驗」為口號，可即使不理會對於支付而言正確、安全和可靠都遠比體驗重要，我作為其用戶也並未真享受到「更好的體驗」。

自己接支付寶、微信的成本也不高，為啥要讓他們再抽一次手續費？如果真要接，還是注意下清算是否直接清到賬戶里，而不是代理清算。

今天公司的支付想要改版，去大概看了一下ping++和beecloud的接入，現在心裡很苦惱幾點：
1、自己實現支付寶和微信接入成本並不高呀。第三方平台都只是對於官方接入參數的提交而已。官方的需要的參數一個不少，全部都傳過去。它只是幫你按照官方文檔加密和提交而已。
2、支付寶的KEY和微信的APPID什麼的自己給第三方平台，這個風險好大。
3、你的交易參數都給了第三方平台，估計接下來第三方就會推出大數據服務了。分析你的資金已經交易情況。
真心和苦惱第三方支付平台的用戶集中在哪些公司？沒有後台開發能力的公司？

風險很大，沒有必要。一旦泄漏了，連誰泄漏的都查不到。第三方支付打死不認，你的損失自己扛好了。

風險就是很大程度上被聚合支付所控制。

起初在使用Ping++聚合支付的時候，免費套餐也可以用的很開心。後來逐步收取請求超額部分的費用，再到現在超額費用從每千次20元漲到了50元，升級套餐的話最低的是每年9999元。現在想擺脫Ping++也沒那麼輕易擺脫了，因為線上的應用已經嵌入了Ping++的SDK。

如果APP只接入微信、支付寶的話，現在我看來使用聚合支付並沒有到特別明顯的優勢，感覺還是直接自己去接入微信，支付寶來的更合適。

「接入和維護支付寶，微信，銀聯等這些主流支付通道的技術開發集成是需要耗費大量的人力物力資源」
看到有個答主這麼回答，然後推薦自家產品，額。。。。
支付寶開發文檔和微信支付平台要介面有介面，要文檔有文檔，各種語言Sdk，為啥還要去買個第三方的服務？

最近我也在集成支付寶,微信,銀聯,移動端和PC端都要用.
我的服務端是用的nodejs,但這3家都是沒有nodejs的demo的,只能自己看著java的demo和文檔試,對於沒有證書加密經驗的人來說,還是挺難的.
目前支付寶和微信的弄好了,沒有怎麼費勁。銀聯不行,卡在了數字證書籤名的地方,因為以前實在沒有這方面的經驗.而銀聯的客服人員,只能說那感覺,真酸爽!而百度上也真心難搜相關的信息。
有人建議我配個java的服務端環境，把銀聯的demo複製上去，只做簽名一件事，其他流程回nodejs端處理，不想折騰了，準備勸說老闆放棄用銀聯了！
而其實集成系統做的就是這件事，因為各家支付邏輯並不複雜，而且基本都一樣，主要就是簽名問題。那麼多伺服器語言,很多都不是專業搞加密的技術人員,所以集成支付還是有市場的,但是客戶最大的擔心都在安全這塊，靠公司自律，客戶能放心使用嗎？

以上很多說的是技術方面和安全方面的問題，但是考慮自身大數據的問題，每個接入的企業其所有支付數量，金額等各種信息都會被第三方所掌握，這恐怕是很多企業難以接受的，商業風險很大。

法律條款 | Ping++

對於Ping++，我想說，真的要認真看看這個條款，基本上出了什麼事導致服務中斷，你也只能自己承擔。不明白為什麼可以加上第8點"其他"..差不多就是萬能護身符了。。

四、服務中斷及不可抗力
（一） Ping++ 系統因下列狀況導致服務暫停或中斷的，本公司不承擔違約或賠償責任：
1、因自然災害如洪水、颱風、火災、爆炸、雷電、地震和風暴等以及社會事件如停電、戰爭、動亂、恐怖襲擊、政府行為、國家政策的突然變動和罷工等不可抗力之因素，造成本公司 Ping++ 系統障礙不能提供服務的；
2、黑客攻擊；
3、網路、電信設備出現故障不能進行數據傳輸的；
4、雲服務系統、計算機系統遭到破壞、癱瘓或無法正常使用而導致信息或紀錄的丟失；
5、電信技術部門調整或故障、網站升級、銀行方面、支付渠道的問題等原因而造成的服務中斷或者延遲；
6、因政府管制而造成的暫時關閉；
7、病毒侵襲；
8、其他。
（二）本公司需要定期或不定期地對提供 Ping++ 服務系統及其相關的設備進行檢修或者維護，如因此類情況而造成網路服務（包括收費網路服務）在合理時間內的中斷，本公司無需為此承擔任何責任。本公司保留不經事先通知為維修保養、升級或其它目的暫停本服務任何部分的權利。

一直用支付寶不會有風險吧

第三支付服務的好處還有個費率低，以及准入門檻低，你們利益相關都不提了？至於所謂的appSecret，微信支付需要給服務商提供這個參數？別搞笑了，微信支付不可能蠢到這個地步

現在我也擔心賬戶安全的問題，因為我是集成的支付寶即時到賬，商戶id和密鑰都給技術人員了，這個泄密的，對我賬戶資金會構成什麼樣的風險？

對熟悉支付的開發人員而言，此類服務其實接入並不難，在資質齊全、流程熟練的情況下，一個成熟的支付渠道接入一般一、二周之內應該可以完成。但是對於廣大的中小企業來說這種接入反而會是自身業務發展的一大瓶頸。因此對這些公司而言，支付平台服務確實能夠降低支付方面的集成難度及接入時間，讓公司有更多的時間和精力投入自身產品的研發之中。

風險和收益往往是並存的，中小企業確實可以獨自去接支付寶、微信等等第三方支付介面，但是一個小的公司的主要精力應該在於APP的開發和運營，單獨安排一個人去對接支付介面，維護介面穩定，也是會造成人員精力的不合理應用，專註於什麼就把什麼做好，輔助性的工作完全可以外包出去，這也是社會發展的大趨勢，沒有完全獨立的個人，更不會有完全獨立的企業。接入和維護支付寶，微信，銀聯等這些主流支付通道的技術開發集成是需要耗費大量的人力物力資源的，多出來的人力更多的放在開發和自身運維不是更有效果？

明天雲平台（iTP-PAY）明天雲平台就很好的解決了這個瓶頸。

舉個生活中的簡單例子，為什麼現在越來越多的人選擇去餐館就餐，而不是自己在家買菜做飯？明明自己做菜做飯會更經濟實惠、安全舒心，但是我們還是會選擇去餐廳就餐，一方面是因為我們需要餐廳的便捷舒適來給我們的生活騰出更多的時間來做更喜歡的事情，另一方面是我們可以把更多的時間和精力用來做自己更專業的事情，從而做的更好。所以這就有了服務的需求和必然。

對於支付介面同樣是這樣的體現，我們與其花時間精力去一個個對接微信、支付寶、銀聯等等支付通道，為什麼不選擇市面上已經融合好的服務平台來節省下我們的這部分精力，從而跟多的去做一些產品的改進和客戶體驗的升級，因此，選擇一些支付平台就成了中小企業的首選，即快捷、高效實現了自己支付通道的使用需求，又免除了通道維護的成本和風險，對平台付出服務費也是理所當然的，至於付出多少確實需要自身去體驗和談判的。

使用第三方支付集成服務確實會存在一定風險，但是風險可控，做好防範，便不失為一種便捷高效的可行做法。

第三方支付集成服務具備哪些特點：

1、第三方支付集成服務商為大家提供便捷服務，確實有其存在的價值；

2、風險往往與收益共存，每家公司需要根據自身需求來自主決定是否選用。

3、第三方支付集成服務更多的適用於中小企業開發者，主要解決接入複雜耗時、維護難度大的問題，明天雲平台（iTP-PAY）就是專門針對中小企業APP開發者支付通道接入需求而提供的基礎服務平台；

4、支付集成風險性主要在於對於支付通道的把控性不足及資金的安全性問題；

5、支付通道還是自身申請的更合適，如果自身資源有限，也可以選擇那些幫助代申請支付通道的平台更為可靠。

與其擔心風險的存在，倒不如仔細考慮平台的風險防控機制是否有效，是否能將自己的利益最大化，風險最小化。繼續拿餐飲來舉例子，我們難道不清楚外賣和餐廳就餐會有食品不衛生的風險嗎？選擇外賣還不是因為方便便宜省時省力，選擇高檔餐廳還不是為了品質生活？只是因為需求層次不同，所以選擇不一樣。對於支付平台的選擇也是一樣的，明天雲平台（iTP-PAY）就為支付需求者統統考慮到了這一點，我們建立完善的風控機制，提供便捷、全面、可靠地支付通道，同時我們還開展代接入渠道服務，幫您解決後期想自己接入通道問題。

明天雲平台（iTP-PAY）明天雲平台絕對是個不錯的選擇