承接 《工程師 & PM 可以從美國最有潛力的支付新創 Stripe 故事中學習到什麼？》中說到的:Stripe 背景介紹、Stripe API 產品的發展路徑、當支付產品變得愈來愈複雜時、產品團隊必須改變。這篇文章繼續來談 Stripe 是如何迭代他們的 API 產品。

承接 《工程師 & PM 可以從美國最有潛力的支付新創 Stripe 故事中學習到什麼？》中說到的：

• Stripe 背景介紹
• Stripe API 產品的發展路徑
• 當支付產品變得愈來愈複雜時
• 產品團隊必須改變

這篇文章繼續來談 Stripe 是如何迭代他們的 API 產品。

從一個 5 人小團隊開始

有趣的事情是，這場改革討論沒有想像中這麼盛大。他們從多年的客戶反饋下手，結合關鍵合作夥伴的串接經驗，以 5 人小組出發 (4 工程師 + 1 產品經理)，從「第一性原則」思考目前與未來的 Payment 方式，進而重構 API 設計。

「我已經不記得當時的日子是怎麼過的…但確實有一些默契讓這個小組得以不斷往前推進。」Stripe 的一位工程師說。後來他將這些看不見的默契重新歸納成 7 個原則，簡單摘要如下。

專注，Stripe 推動會議進行的 7 個訣竅

• Close laptops （關掉電腦，專心傾聽）：能幫助全體成員專心、全情投入在當下開會與共同思考。
• Pace your questions （將疑問排序討論）：將討論分成多段，每一段都先訂幾個想要討論的問題。當討論的過程中產出新問題時，先紀錄在一邊當成下一段的討論問題，把手頭上的問題討論完畢後再繼續新問題討論。
• Use colors and shapes（使用顏色與形狀來表示概念）：在討論許多抽象化的事情時，有相同的顏色或群組替概念分類，不要在當下糾結抽象化的概念應該如何命名。
• Focus on enabling real user integrations（專注在提升使用者串接的效率）：在設計 API 時團隊時常會卡在要用完美的變數名、完美的理論框架、看起來很聰明的解法，但這些對於實際串接者如果沒幫助，就要捨棄不用。
• Question every assumption underpinning existing APIs （質疑每一個已存在的 API 設計假設）：我們在規劃的時候，都會基於一個已存在的前提假設接著規劃，設計產品更是這樣。但如果要把結構打掉重做，那就要從起點開始去思考，去質疑會不會在起點就已經不是好的設計方法了。
• Invite domain experts as guests（邀請專家）：寫程式是一門專業，每一種支付方式也都是一門專業。記得邀請特定領域的專家加入會議，並且請他們給予該領域的看法與建議。
• Make decisions quickly knowing you might change your mind（意識到自己會優柔寡斷，趕快下決策）：我們在規劃時，若牽涉的主題愈複雜、愈容易優柔寡斷不敢對許多設計點下決定。比較好的做法就是讓全 Team 都有「迭代」的概念，先下一個決定做一個成果，繼續討論後發現有問題再修正下心的決定。

Photo by Jason Goodman on Unsplash

Stripe 引導客戶使用新產品的「藝術」

在經過一輪討論後，Stripe 重新設計了支付 API，新版的 API 跟原始 API 差異甚大，但在結構上可以應付未來不斷新加入的支付方式。Stripe 畫了一張圖來表示新版和舊版 API 在串接上的「功 (effort)」與「效果(Power)」，讓合作夥伴了解串接上的差異。（參考圖片，Charges 是舊版 API、PaymentIntents 是新版 API）

那 Stripe 是如何兼容說明新版與舊版的 API 呢？他們採取的策略如下：

1. 讓兩種 API 並行，通常在在美國的公司只需要信用卡的支付方式（舊版）
2. 美國公司如果想要往海外發展，潛規則地必須接受串接新版 API，但因為舊版 API 在後期開發新的支付方式時會變得極度痛苦 ( API 複雜度問題）
3. 建立一個 API 串接包 ( convenient packaging )，並在串接包中說明目前 API 有分成兩種，將新版 API 包裝成「global payments integration」。如果使用非 “global payments integration” 的串接方式，未來想要增加新的付款方式，串接難度會提高很多。

這真的是一個聰明的策略，淺意識地引導合作夥伴都要選擇新版的 API 串接。

我的啟發

這段故事根本是在告訴我們：「你要先放下執著，才能繼續成長(?)」。

為什麼呢？因為 2017 年曾經有篇 Bloomberg新聞報導宣傳：「US-based online payments startup Stripe’s system requires client companies to add just seven lines of code to their site to handle payments.」只要 7 行程式碼就可以串接完成付款服務，這在公司間的技術串接是非常不可思議的事情，也是對 Stripe 技術產品最好的讚譽。

當 Stripe API 重新翻新後，已經無法只靠「7 lines of code」完成技術串接了。想想看，要撕掉自己早期獲得的美名，這實在是一件困難的事情。

但經過這件事情後，Stripe 也學習到：

The more we grow, the more we realize that we must continue to build and rebuild deliberately and thoughtfully.

These are still early days.

(我們愈是成長，就愈是意識到必須謹慎而周到地進行建構與重建。現在仍然是早期階段)

持續迭代，持續完善。

這篇文章 推動會議進行的 7 個訣竅！支付科技新創 Stripe，是如何開發與改革舊版的 API 產品？｜專家論點【朱騏】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

這篇文章是知名線上付款服務提供商 — Stripe 的 API 故事，由於時間長達 10 年已經可以當成是一段小歷史來看了。在 Stripe 身上我們可以看到一家以 API 服務為重的公司，是如何：(1) 根據市場上的需求調整 API產品 (2) 如何應付改動產品過程中累積的「產品債」(3) 如何召集團隊重新思考自家 API 產品的本質，並進行重構 (refactor)。

Stripe 這篇《Stripe’s payments APIs: the first ten years》文章寫得真好，把技術、招募、產品的內容都寫進一個故事了，看的實在過癮。

這篇故事從不同的視角可以看出不同韻味：

1. 對工程師來說，看完這篇故事你對 Stripe API 的設計也懂個大概了
2. 對產品經理來說，這篇故事寫出了一個成長中的產品團隊如何面對市場、破除對產品的假設來迭代產品
3. 對一般人來說，我們看到的是你要先放下執著，才能繼續成長（？）

這篇文章先來介紹 Stripe 的產品背景與困境。

Stripe 背景介紹

這篇文章是知名線上付款服務提供商 — Stripe 的 API 故事，由於時間長達 10 年已經可以當成是一段小歷史來看了。

在 Stripe 身上我們可以看到一家以 API 服務為重的公司，是如何：

1. 根據市場上的需求調整 API 產品
2. 如何應付改動產品過程中累積的「產品債」
3. 如何召集團隊重新思考自家 API 產品的本質，並進行重構 (refactor)。

這篇文章精彩的地方，就在於作者可以邊以 Stripe API 當作範例、邊解釋當時為什麼會這樣設計這些 API。

Stripe API 產品的發展路徑

許多的 API 產品往往在初期都是非常直覺化的設計，例如使用者取得 Token 之後，就可以取用一連串公司提供的 API 服務。

問題是當市場出現變化的時候，公司要如何去改動這些 API，讓串接 API 的開發者可以盡快理解 API 的邏輯、同時因應市場上出現的新需求。

舉例來說，Stripe 一開始服務的對象主要是美國境內的企業，在美國「信用卡」還是付款的大宗，因此Stripe 的 API 只要先滿足這些企業需求就好。

但是當 Stripe 逐漸長大開始要走向海外市場時，要面對的是更多元的支付方式，例如 ACH Debit（ACH 自動轉帳）、Bitcoin（虛擬貨幣支付）、各種當地支付（IDEAL-荷蘭、Alipay-中國、Giropay-德國…等）。Stripe 必須開始在原先以「信用卡」付款方式的 API 加上參數，好因應市場上百花齊放的新付款方式。

早期 Stripe 的 API 是非常單純的（2011–2015年）， 只需要 Token 和 Charges 兩個參數就可以就能應付「信用卡」的支付串接。但在 2015 年加入支援「比特幣支付」後，則新增了 BitcoinReceiver 參數。

當支付產品變得愈來愈複雜時

你可能好奇說：「為什麼要新增參數呢？」原因就在於「確認支付 ( payments are finalized ) 的時間點差異」。

「信用卡」確認支付的時機點幾乎是即時的。消費者刷卡時，Stripe 就會跟發卡銀行以及國際信用卡組織做刷卡資料確認。

「ACH Debit」則是銀行帳戶間的資金移轉，通常需要數天才能完成支付確認。

「比特幣支付」指店家雖然知道消費者發起比特幣交易，但必須經過礦工的運算（等待 6 個區塊產生，每個區塊產生的時間約為 10 分鐘）才算是完成支付。

從上面的例子可以看到，由於每一種付款方式有完全不同的特性，也導致設計 API 的困難度。API 是一個高度抽象化的產品，仰賴設計者定義參數之間運作的邏輯，來模擬真實世界中事物運行的狀況。

產品團隊必須改變

時間快轉到 2017 年年底，Stripe 內部團隊發現：「糟糕！再這樣下去 Stripe API 會變得愈來愈複雜，而且都會是 Stripe 這家公司特有的程式邏輯，非常不利於合作夥伴的串接…」團隊決定大刀闊斧，對龐大的 API 做一次大型的重構 (refactor)。

我看到這邊就知道，故事精彩的地方來了！

因為這個狀況不限於技術團隊，實際上當一家公司發展到一定規模時，總會有些產品、流程、制度已經不符合現在的使用狀況，但礙於大家都覺得：「哎呀，現在不是還好好的可以用嗎，幹嘛要改變呢？」因此拒絕改變。

這就像在一棟危樓上繼續加蓋，只要大樓還可以住人、沒立即性的危險，那幹嘛要打掉重建呢？

但 Stripe 思考到：「如果公司產品還要擴展到到其他國家，再痛也得改！」於是改革開始了。

下一篇文章繼續談 Stripe 是如何改善。

這篇文章 工程師 & PM 可以從美國最有潛力的支付新創 Stripe 故事中學習到什麼？當支付產品愈趨複雜時 Stripe 團隊決定這樣做！｜專家論點【朱騏】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。