街口支付與銀行的藍色蜘蛛網
究竟街口與銀行間到底是命運的安排，或是另有隱情，真相到底是什麼？
Author
- Williams Chueh
主要負責行銷及銀行領域，「測試與品質，不僅僅在於工作，而是落實在日常生活中。」，技術團隊對於軟體品質的千錘百鍊，讓產品在支付戰場中脫穎而出。
近期，電子支付交易金額首度超越電子票證（請參照新聞內容），代表著民眾對於電子支付的消費習性與信賴逐漸增加，但對於電子支付的使用者而言，可能不大理解電子支付與銀行之間的關係，為什麼電子支付業者要與那麼多家銀行合作？那這些業者與銀行又是怎麼進行合作？
目錄街口與銀行為什麼要合作
與銀行合作的好處
與銀行如何合作
與銀行合作時可能遇到的痛點與解決方式
通用解決方案的產生
街口跟銀行為什麼要合作？
為了發展更多的金融性商品，串接銀行為街口建立基礎設施重要的一環，而在電子支付發展的前期並沒有中間平台能做整合（在 2021/7 電支電票修法後，財金平台設立「跨機構共用平台」），跟銀行一間一間談合作也成為了明確進入電支領域的門檻，建立越高的門檻在同業間則更具有競爭優勢。
電子支付業者主管機關為金管會，因此我們做的任何事都必須得合規、合法，在設計新的功能時，都必須優先考慮法遵議題、硬體模組、軟體效能、報送資料到持續監控，讓使用者享受到服務的穩定性與資訊相關的安全性。而基於目前法令，與銀行約定連結存款帳戶則成為街口產品發展的根基。
街口發展的面向分為「必須要做」、「做多一點」、「想做更多」三個階段，而目前街口所在的階段為「想做更多」，除了提升使用者體驗外也期望能解決技術人員在維運上的痛點。
相關報導：
- 靠龐大用戶基礎提升場景覆蓋率，街口支付要成為異業生態圈整合平臺
- 「一張表看電支業者佈局」三大電支業者未來戰略大比較與銀行合作的好處？
- 第一點，完備行動支付基礎環境。
對使用者而言，合作銀行越多代表街口的服務更為便利；對街口而言，則可以發展更多金融性商品，像是微銀行相關業務（e.g. 買賣基金、借貸、匯兌）。 - 第二點，技術能力的共建。
在合作的過程中，與銀行端會有許多交流，其中包含許多技術層面的問題、遇到問題時的共同討論、解決與處理問題的合作模式，這些借鏡與經驗讓街口成為各間銀行最值得信賴的合作夥伴。 - 第三點，描繪使用者的輪廓，精準行銷
整合分析後以數據來驅動精準客群，進而規劃行銷策略與活動，讓行銷更有效益。
與銀行如何合作？
在說明合作的原因與好處後，接著就來談合作過程中，街口在面對多家銀行時，每個環節該如何進行，會遇到什麼樣的問題，而這些問題的解法，能夠歸納出一些標準化流程，讓我們可以更有效率的進行統整與維護。
新增一間銀行
首先，雙方 PM 著手洽談業務價值、合作細節、規格選型等。其次，RD 會協同 IT 合作，同時進行開發與設置環境，SDET 則根據規格著手撰寫測試計畫與 Test Case 並進行 Review，確保大家對測試的範圍與交付目標一致。RD 陸續交付開發完成的 API，SDET 則利用 Postman 等工具對其進行測試，並將測試內容轉換為自動化案例，以達成持續開發、持續測試、持續整合。接著透過E2E 整合測試確認整體功能符合需求。最後，在封閉測試環境中確認所有設置與功能正常後，才將其對外開放。
銀行上線後的維護調整
雙方會依照業務場景的變更及流程做優化。首先由需求方說明改動原因、內容及風險，後續技術團隊介入，針對需求進行開發與測試，並會進入多個迭代直到任務完成。
與銀行合作時可能遇到的痛點與解決方式？
銀行端大量異常，單點式截斷流量止血
街口身為系統整合服務商，當上游廠商辦活動（例如雙十一、五倍券等）導致交易量級的提升，此時有些銀行端夥伴承受不住時，則會發生系統異常，大大地影響使用者體驗與對街口的信賴程度。
因此街口會針對銀行端進行監控，針對交易狀態、逾時訊息與錯誤代碼狀態做為監控指標。銀行異常的狀況下，用戶透過銀行帳戶進行交易行為時，經過了漫長等待而得到失敗的結果，造成使用者體驗不佳。又或者異常造成系統逾時，會連帶影響街口端帳務與銀行端不一致，後期只能以人工介入去排查帳務，這些都是可以減少的成本。因此，一旦監控到合作方異常，街口會立即採取單點式截斷 — 直接關閉 App 中銀行相關的入口點或行為點，並用 Kibana 搭配關鍵字搜尋 log 找到錯誤內容，快速排查線上問題以提升使用者體驗。
法遵議題，模組化的拼湊與拆解
近年來，金管會對於法令逐步與時俱進，例如電支電票的合併整合支付生態圈、許可電支業者進行小額匯兌與外幣買賣。面對法令的調整，我們持續將原有的架構拆分、模組化，好處除了易於維護以外，更能支援未來業務的可擴充性，避免未來變動幅度增大時解耦更耗時費力。在未來法令再度調整時，先觸發 Jenkins 執行自動化確認 API 鏈路的問題節點，減少手動測試，讓測試開發的效益極大化。
不易掌握第三方服務的品質，制定合作方案
首先，與第三方串接勢必會有合作流程的差異，而被省略的流程如冒煙測試、監控機制、機器配置，提高對應的測試成本與潛在風險揭露，導致合作過程中來回的確認與修復，而延宕了測試的進度。其次，修復的品質是無法掌握的，可能會有修 A 壞 B 的情況。另外，銀行端也會不定期的提出測試需求，但需求的敘述不明確，因此在測試計畫上較難因地制宜做規劃。為了減少此狀況，PM 會先確認 deadline、影響層面、測試目的與期望結果等等……，再將測試需求提報給測試人員。
串聯第三方環境不穩定，Mock Service 取而代之
銀行端為了遵循法規，敏感性資料必須落地，在硬體資源有限情況下，測試環境與測試資料大部分會與開發者共用，便會造成測試環境不穩定、測試結果不明確，而一再被要求重複測試。銀行上線後，維運階段仍會有許多調整，容易造成測試髒資料、憑證過期、參數不一致……。為了避免外部依賴而影響開發、測試進度，目前街口以 Mock Service 來達到業務場景的基本驗證，在必要時刻關閉 Mock Service 確認串接的正確性。
財務帳差，提出完整解決方案
街口與銀行皆會進行對帳作業，確認平帳後才會進行後續撥款，但有時雙方帳務不一致情況導致帳差出現，就需要額外的人力介入確認。
因此街口開設新專案來解決上述問題，主要目標為透過系統平帳，減少人工作業時間並降低人工平帳錯誤率，因此只要請銀行端上傳日終檔，讓程式去抓取日終檔並針對逐筆交易數量與金額進行對帳的工作。
通用解決方案的產生
目前遇到的兩個痛點，街口設計了新的雛形，將主動權回到街口，讓街口將流程切分、決定核心服務的串接，最終實現透明且可控的流程。
串接銀行的測試成本逐漸堆積
初期與銀行的串接為街口公規，當串接銀行的數量少時，測試、維運的成本還不明顯；串接銀行的數量變多時，街口公規已不敷使用。既要串接新銀行的規格又要維運既有銀行，不同規格會產生額外的維運成本，不論是在開發、維運與測試上都會遇到問題。
- 解法一：目前由財金資訊公司主導的財金平台，方案則統一由財金平台所提供。
- 解法二：核心服務進行重構，將重複內容抽出寫成物件進行模組化，業務邏輯搭配settings.json 及 config，讓風險降至最低，提高可控性。
- 解法三：新專案來重新審視並設計流程，徹底改善原有問題。
與第三方合作，街口缺乏主動性
分析系統架構後，更了解測試的痛點與架構的限制，像是對於「綁定銀行功能」，街口僅能扮演被動方，等待銀行端通知。因為銀行端內部流程對於街口而言不可控亦不透明，導致確認問題的時間成本上升。
街口目前已經累積超過 1000 萬以上的綁定次數，一旦綁定任何一間銀行有問題，街口客服、技術團隊就會投入資源去協助排查。最後，問題的來源大部分都來自於合作方或環境因素，造成街口人力成本的提升與外部信賴度下降。
分析問題的原因，除了有服務不穩定以外，許多也是來自於不直覺的綁定流程、設計，導致使用者綁定失敗，當使用者一再嘗試失敗以後，便可能放棄這間銀行或使用街口。數據顯示，銀行 A 綁定成功率約 30%，銀行 B 綁定成功率約 22%，在眾多銀行綁定成功率都如此低迷的情況下，變成了街口想發展金融性商品的一大痛點。
期望綁定成功率改善的情況下，PM 主導了一個新專案，徹底解決長久以來綁定成功率低迷的情況。「自刻銀行網頁」將銀行網銀的架構做切分來串接 API，達到化繁為簡的效果。
成果揭曉，銀行 A 綁定成功率由 30% → 90%，銀行 B 由 22% → 73%，就綁定結果而言，分別成長了 300% 與 330%，顯著提升了綁定銀行的成功率。
而兩者主要流程差異有幾點，介面升級、流程簡化、拿回主動權。將外部銀行的網銀綁定流程改為街口自刻的綁定頁面後，畫面簡潔而直觀，進而優化使用者的體驗。
結論
透過與許多第三方的合作經驗，街口歸納出一套適用於各銀行串接的方案，不僅解耦了原有系統的相依性，也減少了與外部方的請求數，降低了流量的消耗進而提升綁定銀行的成功率。在與第三方合作上，會遇到許多限制與差異，但這不代表被動方僅能袖手旁觀，應該更需要將阻力轉換為助力，體現影響力與技術能力，以共同成就台灣友善的金融科技環境。
JKOPay SDET Team
2021.12.23
