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 搜尋此關鍵字,也可以找到相對應的串接說明。此類付費模式較困難,筆者在此會花費較大篇幅介紹。
而倘若你的服務是 一次性付款 + 週期性付款 ,進入開發前務必要在資料庫設計多費點心,因為這類較複雜的付費模式,很容易在客服追蹤時產生混亂。
既然破除了一些迷思,下一步便是開始探討各大支付系統了!