街口支付 × 信用卡交易,挑戰支付成功率 99.99%
Author
- Jay Fu
主要負責信用卡及銀行等業務領域,「你的支付體驗,由我測試把關」,高標準的測試品質,能為街口測試團隊帶回使用者的嘉勉。
在現在精打細算的時代,大家都非常在乎信用卡的優惠,甚至在電子支付開始普及到日常生活中時,更懂得搭配各種方案來放大自己的回饋。在使用街口支付搭配信用卡支付時,您清楚這段信用卡支付過程的全貌嗎?
其實在街口支付的支付管道中,選擇信用卡支付是佔比最高的!面對如此龐大的交易筆數,我們如何維持全年無休的信用卡支付業務?如何在流量高峰時亦維持高穩定性呢?甚至秘辛爆料,在使用街口支付時,搭配哪張卡片的優惠最高亦最受大家喜愛呢?以下就讓我們來揭開這層神秘的面紗。
信用卡交易流程是什麼樣子?
使用者從打開街口 App 時,並選擇信用卡支付管道進行支付,店家與消費者不到三秒間就完成一筆交易,看似簡單的行為中,其實有段不簡單的處理。
街口支付作為串接方,將使用者與店家的交易資訊交給收單行,請求此筆交易授權,而收單行會將此交易授權,再詢問發卡行,請求卡片相關授權,認定此卡片是否有效、額度是否充足等,才會允許交易授權。
店家先透過街口進行收款,街口則會與店家、收單行對帳並與收單行進行請款。收單行與發卡行進行清算後,發卡行會將請款款項給收單行,而收單行會將請款款項撥入街口委託的信託機構,再透過街口委託的信託機構,進行撥款給店家。而使用者則會透過發卡行收到信用卡帳單,其中清楚記載交易資訊。
街口與收單行合作的好處?
- 完善支付基礎環境
對使用者來說,不僅可以使用各家銀行的卡片綁定、支付,也可以搭配信用卡回饋及滿足消費習慣;對街口來說,可以直接與整合發卡機構服務的收單行合作,奠定穩定且合法的信用卡支付管道,對於街口支付的成長,更是推波助瀾。
- 穩定信用卡支付服務
不同的收單行服務能互相支援,而串接多間收單行的效果更能讓我們輕鬆度過流務高峰。因此當面對業務量級高峰時,能達到分流降載,並降低與單一收單行的依賴性。當其中一間收單行發生異常時,仍可透過其他間收單行維持支付服務的可用性,完全不影響使用者體驗。
街口怎麼和收單行合作?
雙方 PM 洽談業務價值,與法遵簽署相關合作條約,並確認合作方案後,PM 講述預期時程、預期功能。當團隊要投入開發資源前,大家會 Review 技術風險、技術優化的點,確保測試範圍都有涵蓋到所有的業務情境。接續,RD 依照技術設計,實作功能;SDET 根據規格需求書,測試功能,並將測試自動化,一同完成業務需求與修復變更。
當服務正式上線前,會先進行封閉測試,確認無誤後會進行灰度發佈,持續觀察線上狀況,並再三確保金流、監控、告警無誤後才會將入口完全開放。
街口與收單行合作的時候,也會關注幾點事項:
- 收單行正式環境的連線方式(長連線、短連線)、連線品質(會不會常常造成超時、無法連線)、及收單行提供可承受 RPS 相關數據,上述幾點也會是我們評估收單行是否足以支撐街口尖峰時段的交易流量的關鍵指標。
- 將信用卡業務的平日流量、特殊活動額外流量,再將此數據與收單行告知,讓收單行與街口一起配置合適環境,觀測線上狀況,並且信任收單行服務的線上品質。
因為信用卡支付是街口支付最大量級的支付管道,除了功能完整性外,街口必須確認收單行環境的穩定性與系統承載能力,保證使用者當下的支付結果與速度。
如何部署系統又不影響線上服務?
每個改動絕對會在測試環境中測試完畢,當準備部署改動於線上環境時,還是會有心理準備「環境不一致、人為難免失誤因素⋯⋯」等突發狀況,導致線上服務不可用的情形,所以街口會以下方這三個檢核點,做為上線後的品質把關,讓線上影響降低至近乎零:
- 快速恢復既往穩定版本,不在線上環境除錯。
- 了解業務的高低峰流量時段,並清楚服務機器負載是能支持故障轉移 (Failover),以保持線上服務的穩定性/可用性
- 新舊功能的兼容,確認機器服務部署能夠循序漸進,無任何停機時間 (Zero-downtime)。
依照風險評估下,街口有能力做到這兩種部署方式:
第一種,單台部署:以機器維度切分,影響單台範圍。適用於新舊功能兼容的服務變更。可參考圖例 JKO Deploy Pattern ( A )
第二種,灰度發佈,自動切流:以流量維度細分,可接受影響少部份的交易。適用需要嚴謹的觀測線上狀況穩定與否,並按照計畫階段性的對外開放服務變更。可參考圖例 JKO Deploy Pattern ( B )
當我們每串接一間收單行,我們會採取灰度發佈以觀察該收單行系統的承載能力與後續的串接狀況。
街口如何應對收單行不預期的服務停擺?
首先,街口是完全信任收單行服務,但是不完全依賴收單行服務的原因是收單行還是會需要定期維護,尤其面臨不預期服務停擺的狀況下,是需要即時感知到收單行服務的異常狀況。對於街口來說,完全信任收單行服務,與完全依賴收單行服務,是兩個不同程度的風險概念。
完全信任收單行服務 ≠ 完全依賴收單行服務
對於線上問題的發生,基於資安安全性,我們不希望讓工程師進入機器本身查看 Log,加上服務都是集群的部屬方式,這樣人工逐台進入查看 Log 偵錯方式,效率低且精準度低。因此,街口選擇了主流的監控方案:EFK (Elasticsearch, Fluentd, Kibana),幫助我們 實現 被動告警、主動維護、自動切流 的階段優化。
- 第一階段 — 被動告警:
具有即時監控能力,使用 Kibana 對收單行服務的使用量圖像化,得知高低峰時間、流量、異常筆數,如果發現異常狀況,人工介入處理,將 App 端的信用卡服務上維護。
- 第二階段 — 主動維護:
除了即時監控外,使用 ElastAlert 的配置,根據監控條件,自動處理前端信用卡維護服務,進行單點式熔斷止血。同時使用 Slack Channel 達到告警通知。減少人工成本,加速止血速度。
關於街口對於收單行監控告警條件如下,僅供參考:
- 整體交易失敗率
- 特定系統失敗代碼筆數限制
- 未在維護期間時,無任何該收單行流量
- 第三階段 — 自動切流:
街口在「第一階段 — 被動告警、第二階段 — 主動維護」時,對於收單行服務停擺,即使我們第一時間做了單點式熔斷止血後,也是只能靜靜等待收單行恢復環境,無法馬上恢復線上信用卡支付服務,這是我們滿大的痛點。
當使用者要使用街口支付來付款的時候,感受想必是「街口的信用卡支付出包了,正在處理線上問題,所以信用卡支付暫時不能用」,往往造成使用者的困擾、評價帶來不小的重擊。
街口思考出,收單行服務具有可替代性,並衍生出自動切流的線上處理計畫。街口積極與不同收單行業者談洽合約、串接測試,並實作相關分流邏輯。因為有前述階段的經驗,我們透過 ElastAlert 對於收單行服務狀況進行監控,一達到監控閥值,並觸發相關 API,進行分流設定,也透過 kibana dashboard 監控「問題發生當下,或異常修復完畢」時,切流正常與否,這套也是我們目前認為最完整、最好的線上處理方法「自動切流」。
如今發生收單行異常時,無需使用到前端信用卡維護服務,自動切換交易流量至可用收單行,當使用者要使用街口支付來付款的時候,使用者所感知的還是「服務正常、使用順暢」。
大家最愛用哪張信用卡?
秘辛爆料!據最新的業務報告得知,在街口進行信用卡支付時,最多人選擇是使用台新街口聯名卡。聰明的用戶們,清楚選擇街口支付,以及選擇優惠最多的信用卡,是最大回饋的支付組合。
街口支付 feat. 台新街口聯名卡,提供的好處有:
(截至2022/5/12發文前)
- 可信的金融服務
- 穩定的支付管道
- 良好的一站式生活體驗
- 聯名信用卡額外 1% 的回饋,讓使用者有感拿到 2% 的回饋
- 部分店家、合作品牌有 5% 回饋
- 繳費 6% 的回饋
- 街口聯名卡的限量限時專屬回饋活動
使用者越愛街口,街口回饋越多。
結論
街口支付串接收單行時,能透過「單台佈署」與「灰度發佈」等方式確認線上服務的穩定性,而每一次的服務變更,也都能挑選最適合的部屬方案將線上的影響降低至近乎零。透過不同收單行的優勢,思考出完整的自動切流計畫,讓街口支付的信用卡業務,達到「如何暫時不人工處理線上異常時,線上服務仍可維持正常運作」,並成功解耦與收單行之間的依賴性,也讓街口信用卡支付方式交易成功率逼近 99.99%,提供給使用者更為流暢的使用體驗!
JKOPay SDET Team
2022.05.12