1
雷鋒網(wǎng)按：本文作者朱赟，Airbnb 資深程序媛。本文主要來談?wù)?nbsp;Airbnb 支付的故事，以及正在經(jīng)歷的變革。關(guān)于Airbnb介紹，可以參看前FB軟件工程師覃超文章：《深度解析：不高頻不剛需也火了，Airbnb 靠什么征服了你們？》，以及《Airbnb的生意越來越好，它究竟是怎么抓住用戶的？》
Airbnb 作為共享經(jīng)濟的典范，很多人已經(jīng)對其有很多了解，今天這篇，就講講 Airbnb 支付的故事，以及我們的架構(gòu)正在經(jīng)歷的變革。文章的內(nèi)容主要是我和同事 Karen 在 Airbnb 技術(shù)大會 OpenAir 2016 上代表 Payments team 做的一次演講。內(nèi)容公司已經(jīng)審核，發(fā)博客這件事也是支付組的老大們首肯的。英文版近期會發(fā)在公司的博客上。
特別感謝我的老大楊江明的支持和審稿以及對部分內(nèi)容的修訂。
當(dāng)人們提起 Airbnb 的時候，人們不會覺得這是一家支付的公司。然而，支付是 Airbnb 最核心的部分之一。回想一下用戶預(yù)訂 Airbnb 的流程：我們首先根據(jù)入住的天數(shù)和清潔費用等計算需要收取的金額。 然后計算相應(yīng)地區(qū)的稅率以及其他服務(wù)費。再用用戶提供的付款方式進行收款，并在用戶入住后付款給房東。每個步驟看似很簡單，其實支持它們的底層實現(xiàn)極其復(fù)雜，尤其是 Airbnb 對全球范圍的雙向支付，這個問題和我們一些同行如 Braintree 和 Stripe 要解決的問題其實很類似。
Airbnb 作為一個共享經(jīng)濟的平臺，起源于三個支柱性的要素：信任、歸屬感、合法性。信任是我們產(chǎn)品的基石，也是我們企業(yè)的基石（見之前寫過的《我們共享的不僅僅是資源和經(jīng)濟，還有信念和信任》）。任何一個牽涉到現(xiàn)金交易的平臺都需要強大的信任體系來支撐。而這樣的信任就來自于支付的實現(xiàn)，來自于每筆交易的安全性和可靠性。而關(guān)于歸屬感，這意味著我們希望用戶可以按他/她自己熟悉的方式來支付。這樣我們才可能讓他/她們更有產(chǎn)品本土化的體驗。最后，合法性意味著我們會遵循所有地區(qū)的法律法規(guī)，比如我們需要代表不同城市收取不同的出租房產(chǎn)需要繳納的稅收等等。
| Airbnb 支付的起源
關(guān)于 Airbnb 支付的起源，有一個很好玩的故事。
最早的 Airbnb 網(wǎng)站，并沒有線上付款，只有定價。Guest 入住的時候交現(xiàn)金給房東。還在 2009 年的時候，有一次，我們的創(chuàng)始人之一 Brian Chesky 到德州 Austin 參加 SXSW 大會。他剛?cè)胱〉臅r候，房東就按慣例跟他要現(xiàn)金。因為他當(dāng)是身上沒有，所以他就跟房東說他晚上出去會到 ATM 取錢回來。然而，那天晚上他卻忘了這件事。所以第二天一早房東問他要錢他又沒有。Brain 說 “今天我出去一定取錢給你”。繁忙的一天過去了，Brian 又忘了取錢。Brain 再三保證明天去 SXSW 的時候一定取錢。然而悲劇都是這么發(fā)生的，老大又忘了......這時候情況有點囧、老大有點尷尬。房東甚至開始懷疑他到底能不能拿到錢了。
這件事讓 Brian 意識到我們的平臺必須有支付的功能，幫房東在房客預(yù)定的時候就收取費用，而不是等到入住時再進行現(xiàn)金交易。于是不久后，我們的 CTO Nate 等人就完成了我們 Airbnb 支付的第一個版本。
最早期我們的支付系統(tǒng)只支持 PayPal。后來又有了信用卡。這兩個支付方式主要都是針對美國用戶的。隨著 Airbnb 擴展到越來越多的國家，我們的支付也一直作為國際化的先行軍，前后打入了 191 個國家。和 Uber 不同，Uber 的大部分交易司機和乘客是同一個國家的，而且付錢和收錢幾乎同步進行。Airbnb 的很大一部分交易都是跨境的。而且 guest 在預(yù)定的時候付款，房東在入住第二天收款，中間還有一段時差。更別提我們還要兼顧各國的法律法規(guī)和稅務(wù)條款。
除了大家熟悉的 PayPal，信用卡等支付方式，我們還支持一些非典型的支付方式，如基于現(xiàn)金的 Boletos 和 VaCuba。讓世界上任意一個國家的人都可以使用 Airbnb 支付，對我們和我們的用戶來說都很重要。即使是一些很偏遠和不那么發(fā)達的國家，我們也想盡辦法提升他/她們的支付體驗。
關(guān)于 Airbnb 支付的國際化，說幾個好玩的故事。
古巴。古巴是一個很奇特的國家。Airbnb 能夠獲取批準(zhǔn)進入古巴市場，付出的努力也是很大的。很多現(xiàn)代的基礎(chǔ)設(shè)施，尤其是支付相關(guān)的，在古巴都不存在。例如，他們完全不能支持信用卡或任何類似的支付方式。為了讓古巴人也可以在 Airbnb 上租房，我們使用了 VaCuba 這種支付方式，其本質(zhì)就是人工開著游艇、駕著飛機、騎著自行車，將現(xiàn)金像送貨那樣送到房東的家里。這也是為什么去年 Airbnb 作為第一家美國公司將業(yè)務(wù)開展到古巴的時候，奧巴馬也給予了很高的評價。
巴西。如果說古巴是沒有一個信用卡網(wǎng)絡(luò)，那么巴西的問題就是他們支持了太多的信用卡網(wǎng)絡(luò)。每一個網(wǎng)絡(luò)的覆蓋面又很有限。此外，現(xiàn)金支付依然是巴西最常見的付款方式。為了讓巴西人民可以按照他們的方式自由付款，我們在支付系統(tǒng)里加入了一種新的支付方式 Boleto。Boleto 是一種基于異步收款單的一種支付方式。簡單來說，當(dāng)房客在我們的網(wǎng)站上預(yù)訂 Airbnb 之后，我們通過 Boleto 為其生成一個交款憑證。用戶可以到銀行按該憑證付錢。付完錢以后，銀行會給 Airbnb 發(fā)一個通知，告訴我們款項已到，我們就可以進一步處理這筆訂單。在此之后，我們也在另外幾個國家使用這種類似的異步收款方式。
中國。中國最常見的線上支付方式要數(shù)銀聯(lián)、支付寶、和微信支付了。目前為止，我們使用了一些 “非典型” 方式支持了銀聯(lián)支付和支付寶支付。什么意思呢？拿支付寶來說，我們沒有直接和阿里對接，而是通過一個叫做 Adyen 的第三方來對接的?？墒?Adyen 有很多問題，造成了一些中國用戶的支付寶支付的體驗比較差。好在我們已經(jīng)著手直接和支付寶對接了。微信支付未來也是有可能會支持的。
印度。印度是一個極其以移動應(yīng)用為核心的國家。這就意味著所有的預(yù)訂、支付、授權(quán)等等都必須在手機上支持。此外，他們有嚴(yán)格的法規(guī)要求所有境內(nèi)游的資金需要保證滯留在印度境內(nèi)的賬戶上。因此對于印度，我們需要設(shè)置特殊的賬戶和支付路由選擇。這在維系我們的賬戶收支上增加了一定的定制困難。
后面的部分我們會講到支付的軟件架構(gòu)。在此之前，有一些常識和名詞有必要先大概解釋一下。
任何一個系統(tǒng)的支付，都應(yīng)該（至少）包括下面三個部分：
結(jié)賬和付款（checkout）流程。這包括很多的用戶界面和交互部分。
平臺和銀行或者第三方的實際資金流動。
內(nèi)部 auditing 和 reporting 系統(tǒng)產(chǎn)生所有財務(wù)報表。
第一部分很好理解。第二部分根據(jù)實際對接的金融機構(gòu)的不同，實現(xiàn)起來有很大的差異。比如，這是一個基于銀行賬戶的交易？還是基于 “錢包” 的交易？是同步的交易？還是異步的交易？有沒有一個可以存下來以后再用的賬戶？還是每次都需要用戶重新輸入付款方式的信息？交易是一步完成？還是通過多個步驟完成？等等。為了簡單起見，我們在以下統(tǒng)稱一種接入的支付方式為一個 processor。
而第三部分因為用戶完全不可見，很多時候非支付行業(yè)的人對其了解比較少。而公司的財務(wù)報表其實是一個公司支付最最不可或缺的部分。尤其是對于一些已經(jīng)上市或者有投資人的公司，這些報表是他們了解公司運營情況的主要信息來源。
相對應(yīng)的，Airbnb 支付最核心的模塊也是三個部分：
在 Airbnb 網(wǎng)上用戶預(yù)訂和付款流程和入住后我們向房東付款流程；
支持世界各地各種 Processor 的集成，可能是 Airbnb 收款，也可能是 Airbnb 付款；
產(chǎn)生所有的財務(wù)報表
早期的 Airbnb 包括支付在內(nèi)的所有的代碼，都是在一個 Ruby on Rails（RoR）App 上的。每一種支付方式的對接，都是高度定制化的。這就意味著，每接入一種新的支付方式，需要的的工程師資源都很高。而且在我們接入二十多種不同支付后，代碼邏輯變得異常復(fù)雜，可維護性極差。
此外，RoR 的數(shù)據(jù)訪問都是通過 ActiveRecord 進行的。熟悉 RoR 的都知道，ActiveRecord 很難對數(shù)據(jù)訪問進行限定和跟蹤，所有的數(shù)據(jù)默認(rèn)都是可任意修改的。而對歷史事務(wù)的紀(jì)錄和所有事務(wù)事件的可跟蹤性，是支付最核心的需求之一。所以早期 Airbnb 的做法，是在所有支付相關(guān)的核心數(shù)據(jù)庫表上面加了 DB trigger，以記錄所有的數(shù)據(jù)變動，包括插入 / 更改 / 刪除，并保存到另外的 audit table 中。
當(dāng)我們生成財報的時候，我們就是基于這些這些 audit table，用層層迭代的 SQL 語句，來查詢生成我們想要的各種數(shù)據(jù)。而因為 audit table 記錄的僅僅是數(shù)據(jù)變動，不是事件，所以我們還需要根據(jù)這些數(shù)據(jù)變動去 reverse engineer 到底在整個支付流程中發(fā)生了什么。
以上種種可以看出，我們最核心的三個模塊都有著極復(fù)雜的業(yè)務(wù)邏輯。復(fù)雜到全公司只有極少數(shù)幾個工程師真正了解其中的邏輯。當(dāng)我們處理的交易越來越多，業(yè)務(wù)邏輯越來越復(fù)雜，更多的新產(chǎn)品屬性需要在支付流程上做相應(yīng)的改動的同時，我們遇到的問題和可能犯的錯誤也就越多。
抽象成技術(shù)的問題來說，我們的老系統(tǒng)存在以下問題：
初始的支付流程是按照我們的傳統(tǒng)的 Airbnb 訂房流程來設(shè)計和實現(xiàn)的。每出現(xiàn)一個新的產(chǎn)品需要支付的支持，這個流程就會一定程度上被 hack 來滿足需求。例如，我們?nèi)绻伊艘恍┑谌綆臀覀兎g一些網(wǎng)頁，我們會 hack 我們的 “給房東付款” 的付款流程來對其進行支持。房客和住宿過程中如果需要別的付費服務(wù)，那我們的平臺目前也不能很好地支持。
每個 processor 的集成都是高度定制的。考慮我們現(xiàn)在有 25 種 processor，這意味著所有的處理支付的路由部分都有很多的分支處理，簡單說代碼不可避免地出現(xiàn)無數(shù)的 if 語句和 case 語句。加上很多 processor 又有針對不同貨幣的處理邏輯。因此當(dāng)出現(xiàn) bug 的時候，理清這些千頭萬緒的交易路由成了高難度的任務(wù)。很多如 Boleto 和 VaCuba 的特殊性又增加更多的特殊處理。因此每個新的 processor 的集成的難度都變得越來越大。想做一些智能路由處理幾乎不可能。
生成報表是基于 DB trigger 生成的 audit trail tables 來做的。Reverse Engineer 的過程也隨著業(yè)務(wù)邏輯的復(fù)雜和各種 hack 支付的做法變得艱難而脆弱。同時，這種相關(guān)性也讓對這些 table schema 的改動變得異常困難。我們因此增加了很多 “臨時” 的方案，例如 EAV 模型的大量使用。然而這些方案一定程度上減弱了交易的事務(wù)性。相關(guān)數(shù)據(jù)以多種狀態(tài)并存來增加了系統(tǒng)維護性的難度。
為了解決以上闡述的種種問題，我們的支付系統(tǒng)的新的架構(gòu)會將一些主要的支付相關(guān)的功能用三個服務(wù)來實現(xiàn)。需要提出的是，所有 API 設(shè)計，一個很重要的設(shè)計理念，就是 API 將實現(xiàn)細節(jié)盡可能的通過抽象來隱藏，而只將干凈統(tǒng)一的接口顯露給調(diào)用者。
Panama，我們的新的 Billing API。用統(tǒng)一的結(jié)賬流程來支持 Airbnb 所有的產(chǎn)品。Panama 通過對產(chǎn)品具體屬性的抽象，而使用統(tǒng)一的如 price engine 和統(tǒng)一的 tax engine 來支持必須的產(chǎn)品共性。這樣可以在我們的系統(tǒng)中快速的支持任意一種新產(chǎn)品的結(jié)賬流程。此外，整個結(jié)賬流程對所有產(chǎn)品保持統(tǒng)一化：在用戶付款前統(tǒng)一確認(rèn)庫存狀態(tài)；統(tǒng)一的支付流程；統(tǒng)一的 fulfillment（庫存和出貨處理）。最終的結(jié)賬結(jié)果也是用統(tǒng)一的數(shù)據(jù)模型（Bill ＋ LineItem）來表示。這些數(shù)據(jù)模型是之后所有對訂單的修改和取消等操作的參照標(biāo)準(zhǔn)（source of truth）。操作產(chǎn)生相對應(yīng)的 Platform Event 發(fā)送到 Kafka message bus上。
Gibraltar：Payment Gateway。Airbnb 的產(chǎn)品往往只關(guān)心 Payin 和 Payout 的結(jié)果，而不關(guān)心 Payin 和 Payout 的實現(xiàn)細節(jié)。Gibraltar 把所有不同 processor 的 Payin 和 Payout 抽象成統(tǒng)一的 API 接口。極大地簡化了產(chǎn)品以及支付的實現(xiàn)復(fù)雜度。所有的實際交易 transaction（事務(wù)）都由該 API 層控制并記錄。產(chǎn)生相對應(yīng)的 Payment Event 發(fā)送到 Kafka message bus上。
Braavos：Financial Reporting Service：財務(wù)系統(tǒng)往往只關(guān)心一些統(tǒng)一的財務(wù)賬戶（如應(yīng)收賬款，應(yīng)付賬款，利潤，稅款等）以及這些賬戶之間的資金流動，而不關(guān)心產(chǎn)品的邏輯細節(jié)（例如 reservation 如何 block calendar，如何發(fā)通知 email，等等）。Braavos 收到來自于 Panama 的各種 Platform Event（產(chǎn)品事件）和來自于 Gibraltar 的 Payment Event（支付事件）之后，把上述事件中的財務(wù)賬戶信息統(tǒng)一表示成 subledger，這樣就可以構(gòu)建跨多個產(chǎn)品的統(tǒng)一的報表邏輯。
這里說一個題外話。雖說 naming 和 cache invalidation 是計算機科學(xué)里的兩大難題，很明顯 Airbnb 的工程師以為 service 取有典故又好玩的名字為樂。Braavos 是 Game of Throne 里面的 home of Iron Bank，是一個很靠北面、很富足的城市。Panama （巴拿馬運河）是大西洋和太平洋之間的一條運河，控制兩片水域之間的船只來往。Gibraltar （直布羅陀海峽）是 Spain 和 Morocco 之間的一個具有很重要地理位置的海峽。這些名字也意味著這幾個 service 在我們整個 Airbnb 系統(tǒng)中的舉足輕重的地位。
當(dāng)所有的基礎(chǔ)功能都實現(xiàn)了以后，我們就可以不用花費大量的工程師資源去維護和迭加各種定制的業(yè)務(wù)邏輯。整個系統(tǒng)變得更模塊化，邏輯的復(fù)雜度大大降低。新產(chǎn)品或者新支付方式的支持也變得更加容易。于是我們開始著力于在系統(tǒng)上增加更多的智能，使用機器學(xué)習(xí)能來對一些數(shù)據(jù)流進行優(yōu)化。舉幾個例子。
費用定制的智能化。現(xiàn)有的所有 guest fee，host fee 等都是基本固定的。我們可以根據(jù)一些機器學(xué)習(xí)模型來調(diào)整價格，看什么樣的 Airbnb 收費最合理。例如如果你是一個長期的租房，那么我們可以適當(dāng)?shù)亟档?service rate 等等。
支付路由選取的優(yōu)化。因為我們接入了多個 processor，所以所有的信用卡，都是可以通過不同的 processor 來處理。目前我們是根據(jù)發(fā)卡行和本地貨幣來決定 processor，以后我們還可以根據(jù)信用卡交易通過率、每筆收費等來動態(tài)調(diào)整 processor 的選擇。降低每筆交易的成本，增加訂單成功率，改善用戶體驗。
Credit 和 coupon 系統(tǒng)的完善。建立一個更方便的 stored value service。這有點類似 Airbnb 錢包。讓一些長期使用 Airbnb 的用戶的支付變得更方便。
最后，雖然目前我們的報表生成是基于批處理的，我們正和我們的數(shù)據(jù)組共同努力，希望將整個過程做成 streaming based 處理。這樣我們就能更實時的自動生成我們的各種報表。
PS：這篇介紹比較 high level，如果你對支付中某個方面或者文章中的某一點特別感興趣，歡迎留言。我會考慮在后期的文章中展開討論。
題圖：from Pinterest
雷鋒網(wǎng)注：轉(zhuǎn)載請聯(lián)系我們授權(quán)，并保留出處和作者完整信息，不得修改文章。
雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。
