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