Payment System 實戰系列（一）：工程師要先和老闆對話＆破除迷失
那些 PO & PM & 行銷 & UI/UX 工程師要先知道的事
誒 Brian, 我們需要讓使用者在我們平台上付費喔～
誒 Brian, Apple Pay 好潮，我們來討論一下～
隨著 B2C 、 E-Commerce、OTT ……網路平台興起，在網站上、手機上完成付費作業，讓顧客可以直接取得供應商服務，幾乎是現在網路新創必碰的難題，筆者相信在讀文章的各位，也正面臨串接金流服務的痛苦 😭
於是本系列文章，會試著從業務端角度，試圖回推工程開發上，所需要具備的知識涵養與基本概念，然後帶領實作部分的串接細節，順便說說這些年踩過的大小雷，希望讓正要入手的工程師能更快、更穩掌握技術內涵。
本系列文章適合誰
- 正要踏入支付串接開發的你
- 想要整合網路付費 + Apple IAP + Google IAB …. 多個平台的你
- 想要實作訂閱服務（週期性扣款）的你
- 純粹入過，想領略支付系統惱人之處的你
本系列的預期文章列表
- 盤點各大支付系統（Stripe / Apple IAP / Google IAB）
- 後端開發前的前置作業
- 實作第一站 — Stripe 串接（尚未）
- 實作第二站 — Apple In-App Purchase 串接（尚未）
- 實作第三站 — Google In-App Billing 串接（尚未）
- 實作第四站 — 整合收據並建立報表系統（尚未）
由於筆者對於 Stripe 較熟悉，故 Stripe / TapPay 我將以 Stripe 為主要陳述對象。
筆者在此建議，如果你有串接 TapPay 服務的計畫，建議還是觀看 Stripe 的文章與 Document ，它堪稱老字牌的支付平台，資料面層級上處理的相當成熟，建議讀者奉 Stripe 為圭臬著手資料庫設計，在後期維護及擴充上，絕對可以幫你省下很多工！（我沒有收 Stripe 業配，是真心推薦）
開發之前，工程師需要和 老闆 / 行銷 談的事
- 支付平台的串接
對於要串接支付的企業而言，首先映入眼簾的必定是，如何和信用卡公司(Visa / Mastercard……) 處理金流，是不是每家公司都要一個一個談，談完是不是會收到一份份 API Document ，然後和銀行洽談完，是不是還要請他們確定我們公司主要配合的銀行能不能合作，之間手續費怎麼算…….
如上所述，如此繁瑣的過程必定有商業價值，有商業價值的地方一定會有公司出來做。 Stripe（海外）& Tappay（國內）就因此誕生了！這兩家公司主要就是負責金流的中介商，他們可以協助為你處理收單銀行的溝通，以及與信用卡公司的金流處理。
（編按：據讀者所知，串 TapPay 的有賴你們 Negotiation 能力了，看能和收單銀行談出什麼價碼。而當然還有綠界…之類的支付平台，但不論哪個，共同開發概念皆不會差太多。）
簡單而言，你只需要取得 Stripe / TapPay 這類型支付平台的服務，將收單銀行/公司資訊設定好，並允許他們酌收每筆付款手續費用（Stripe 為 3 %）。身為工程師的你就只需要對 Stripe / TapPay 負責就好！
- 開發規格的確認
開發規格的確認，雖然是工程界投入開發前的必要條件，但對於金流服務而言，這點更加重要啊～
倘若你今天完成了 Stripe 串接，老闆與你說：
誒 Brian, 為了要有良好的使用者體驗，我們覺得 Apple In-App Purchase 需要串接～
這時候你肯定會直接爆炸，因為 Apple In-App Purchase (IAP)的規格和 Stripe 完全不同，若要再額外串接，你必須拆掉原有的系統，想想兩者要如何整合，寫好規格，確認 Payment Flow ，重新測試與上線，這樣的工時與效益是完全不合比例。
筆者建議工程師的你，與你的老闆與行銷團隊儘早確認未來 半年至 1年，支付系統所需要整體的規格。儘管第一階段，貴企業不選擇串接手機上的付費金流，但若已預知未來將發生，建議觀看本系列第二篇、第三篇的簡說，務必保留資料庫設計上的彈性。
開發時的迷失
- 為什麼不講講 Apple Pay / Google Pay 的串接呢？他們付費起來很方便耶？
首先，不論 Apple Pay 或 Google Pay ，他們都沒有負責金流處理！
在付費的系統，他的角色是扮演授權 (Authorize) 的角色，讓開發端得知欲付費的卡片允許付款。你可以將之比擬成，使用者在慢慢輸入信用卡卡號/到期日/CVC 的時間，可以縮短到 Apple Pay / Google Pay Beep 的一聲。
當信用卡透過 Apple Pay / Google Pay 付費後，仍需要串接如 Stripe / TapPay 的支付平台，完成後續的金流作業。(好新聞是，以上兩者都設定好接口了，照著文件走就可以完成串接)
Btw, 現今除了實體刷卡機，在網頁上也可以串接 Apple Pay / Google Pay ，甚至 Line Pay 也崛起了。加速付費流程想必是 UX 工程師的心願，讀者不妨可參考 Stripe / TapPay 與 Apple Pay 的串接文件，快速了解如何整合。
2. 要實作 一次性付費 還是 週期性付費 的系統呢？
在實作前，必須先釐清你的服務需求是一次性付款還是週期性付款。
一次性付款，如小明在蝦皮上買了一個包包，這類服務在 Stripe / Apple Pay / Google Pay 統稱 Product 。若你要實踐這方面的服務，在各官網的 API Document 搜尋 “Product” ，應該不難找到服務。此類付費模式也較簡單，筆者在此也不會花太大篇幅介紹，僅會稍微提到～
週期性付款，又稱訂閱制，如小明在 Netflix 每個月固定付費，這類服務在各支付平台統稱 Subscription 。同上，在各 API Document 搜尋此關鍵字，也可以找到相對應的串接說明。此類付費模式較困難，筆者在此會花費較大篇幅介紹。
而倘若你的服務是 一次性付款 + 週期性付款 ，進入開發前務必要在資料庫設計多費點心，因為這類較複雜的付費模式，很容易在客服追蹤時產生混亂。
既然破除了一些迷思，下一步便是開始探討各大支付系統了！
