工程師 & PM 可以從美國最有潛力的支付新創 Stripe 故事中學習到什麼？當支付產品愈趨複雜時 Stripe 團隊決定這樣做！｜專家論點【朱騏】
Stripe 這篇《Stripe’s payments APIs: the first ten years》文章寫得真好，把技術、招募、產品的內容都寫進一個故事了，看的實在過癮。
這篇故事從不同的視角可以看出不同韻味：
- 對工程師來說，看完這篇故事你對 Stripe API 的設計也懂個大概了
- 對產品經理來說，這篇故事寫出了一個成長中的產品團隊如何面對市場、破除對產品的假設來迭代產品
- 對一般人來說，我們看到的是你要先放下執著，才能繼續成長（？）
這篇文章先來介紹 Stripe 的產品背景與困境。
Stripe 背景介紹
這篇文章是知名線上付款服務提供商 — Stripe 的 API 故事，由於時間長達 10 年已經可以當成是一段小歷史來看了。
在 Stripe 身上我們可以看到一家以 API 服務為重的公司，是如何：
- 根據市場上的需求調整 API 產品
- 如何應付改動產品過程中累積的「產品債」
- 如何召集團隊重新思考自家 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 是如何改善。
瀏覽 10,505 次
