前言

近期公司計畫介接紅陽金流,因為剛從文件地獄回來,所以本篇應該不會有什麼好話。

首先來個前置常識:所有台灣的第三方服務與金流服務商,都是垃圾

都是垃圾

提供的服務面向

付款渠道

  • 信用卡、銀聯卡
  • 超商條碼、超商代碼
  • 虛擬銀行帳號
  • Web ATM
  • TaiwayPay
  • Apple Pay、Google Pay
  • 貨到付款(超商取貨)

其它服務

  • 電子發票
    • 立吉富發票整合
    • 紅陽支付自家系統
  • 物流系統
    • 7-11
    • 全家
    • 全家大宗寄倉超商取貨

紅陽金流比較著重於實體貨物的販售流程,基本上所有的付款渠道都是建立在需要物流的前提上進行文件撰寫的,同時也沒有定期定額訂閱(Subscription)的選擇。

註:沒有實體貨物也是可以使用的,就是文件上會多出很多不必要的參數。

優勢

  • 沒有。
  • 哦好啦,大概就是他們老闆人面很廣或業務很強,可以拉到很多合約,然後讓一狗票工程師被荼毒

劣勢

不完整的沙盒機制

一般來說,所有關於「金流」的服務都具備沙盒機制。

這部份可以參考 Paypal SandboxStripe Testing

  • Paypal 是直接提供了一個虛擬環境,在該環境上的所做所為完全不會影響到現實世界
  • Stripe 是提供多種假的信用卡號,並且每組信用卡號都有不同的意義

紅陽有點類似於參考了 Paypal Sandbox 與 Stripe Testing,然後做出一個東施效顰的笑話。

  1. 紅陽具備測試區,但是測試區打出來的資料並不完整
    • 「超商代碼」與「貨到付款」這兩個付款方式,僅能取得交易結果,無法取得付款結果
      • 交易結果:當交易建立後,紅陽會送出一個 WebHook 通知商店,請商店另外通知消費者
      • 付款結果:當消費者付款後,紅陽會送出一個 WebHook 通知商店,讓商店處理消費者已經付款的行為
  2. 紅陽提供了一些測試用的卡號規則
    • 尚在有效期限內
    • CVC 任意填寫
    • 前 6 碼為真實卡號
    • 後 10 碼任意填寫
      • 最後 2 碼為 31 或 33 時,模擬 3D 驗證交易
      • 最後 2 碼為 00、41、51,模擬授權失敗

相較於 Paypal,紅陽金流的沙盒機制完全就是個不完成品,我很驚訝這種服務還敢上線。

相較於 Stripe,提供的信用卡號代表太少,無法驗證「某種」錯誤造成的付款失敗。

順帶一提,如果在紅陽的測試區(沙盒)禁用了 Cookie,則會出現 .NET View State 驗證失敗的錯誤訊息。這種在未經使用者同意的情況下擅自使用 Cookie,已經違反 GDPR。

IIS 錯誤

低劣的文件品質

技術文件以 PDF 公開讓人下載,然而卻常常發生跨頁印刷的問題,導致閱讀參數還要上下翻動。

跨頁印刷

  • 技術文件應以純 Web 文件為主軸
    • 輔以 PDF 針對 Spec 進行說明

例如 PaypalStripe,甚至是 微信支付 都有這樣的機制。

  • 技術文件應具備良好的關鍵字搜索功能

  • 技術文件不應隨意 Reference 到其它頁面上,這徒增文件閱讀成本

    • 例如「與 XXX 相同之參數不再說明」,然後就把說明完全省略

Omitted Docs

  • 技術文件必須有範例
    • 必須至少有一個成功的 Request 與其 Response
    • 應該有一個失敗的 Request 與其 Response

以下是 Paypal 文件中的 Request 與 Response 範例

Paypal Request Paypal Response

沒有 SDK

考量到語言流行與應用廣度,廠商應該至少提供,() 中代表最好有提供,但沒有的話也尚可接受

  • Java
  • .NET
  • PHP
  • Nodjs
  • (Python)
  • (Ruby on Rails)
  • (Golang)

且這些 SDK 必須能夠以現代的方式被使用(如 Java 可被 Maven 或 Gradle 載入;PHP 遵守 PSR-4)且符合語言標準(如 PHP 符合 PSR-12),並且包含足夠且值得信賴的測試。

紅陽通通沒有提供,他們僅提供寫得跟一坨屎差不多的範例程式講句難聽的,這種 PHP 範例程式找個沒有程式基礎的路人教兩個禮拜都能寫出這種垃圾。

註:我只有閱覽過 PHP 部份的範例程式,C# 因為不熟悉所以不便進行評論

我曾經針對這點向客服詢問,以下是紅陽提供的回覆

Esafe Reply

好的,中規中矩符合 SOP 的屁話。

奇葩的系統設計

紅陽的系統設計非常令人驚嘆(或驚嚇)

  1. 需要由前端建立一個 actionhttps://www.esafe.com.tw/Service/Etopm.aspx 的 Form 把參數以 POST 送出。
    • 這部份無法由後端送,因為送出之後就直接渲染出 HTML
      • 以正常的邏輯來說,應該用 3xx 重導向至真正的付款資料填寫畫面
    • 假設商店存在類似於 ClickJacking 的問題,紅陽系統端是完全無法防範的(因為送出的商店代號根本就已經被竄改了)
    • 因為資料會是由前端送出的,所以紅端系統端所設定的交易密碼(Transaction Password)是會直接暴露的
      • 這部份視系統實作,如果檢查碼是由後端運算則 Transaction Password 是不會暴露的(而且應該要這麼做)
  2. 使用 SHA1 作為校驗碼的生成機制
    • 在 SHA1 已被證實攻破的情況下,仍然使用 SHA1
    • 註:退款退貨的 API 使用 SHA256,算是系統中的異類
  3. 沒有妥善的錯誤處理機制
    • 由前端送出付款資料之後,以 alert() 的方式顯示錯誤
      • alert() 對於 UX 是極差的
      • 顯示的錯誤訊息可能是「交易校驗碼錯誤」,這種是消費者完全無從解決的
    • 無論是什麼資料,Status Code 一律是 200
      • 雖然這是很多系統常見的問題,但妥善的使用 Status Code 有助於系統設計
  4. Webhook 回傳的資料,包括大量的無效資料
    • 例如完全沒有使用物流,卻仍然回傳 CargoNo=''(物流編號)
    • 不使用 XML 或 JSON,僅透過 Plain Text 顯示錯誤訊息
    • 系統送出 Webhook,又讓使用者再次送出(技術文件是指「前景傳送」與「背景傳送」,但這完全雞肋)
      • 有時候是直接由系統送出兩個 Webhook
    • 系統提供的確認用 Webhook 無法調整發送頻率與次數(每小時一次,最多三次)
  5. 語焉不詳的參數名稱
    • 大量使用諸如 web(商家代號), MN(交易金額), Td(商家訂單編號), sna(消費者姓名), sdt(消費者電話) 這類不易被理解的縮寫
    • 混雜各類命名規則 DonationCodeCarrier_ID
  6. 詭異的參數限制
    • 如交易內容(OrderInfo)、消費者姓名(sna)及備註(note1, note2)不可有特殊字元
    • 這項限制的目的可能是為了避免商店本身被 XSS,但也有可能是紅陽本身的系統存在 SQL Injection 問題

以下是我嘗試使用 Taiwaypay 進行測試會收到的回覆

Empty Data

兩個相同時間的 POST 都是由紅陽發出,內容卻有一些不同

結語

會寫這篇文章,主要是因為大部份第三方支付評比都是從服務面向去分析,鮮少有從技術面切入的文章。

基本上看到這種文件品質、客服回覆、範例程式與測試環境,我很訝異這廠商居然能夠成為三大台灣第三方支付服務商。(紅陽、藍新與綠界)

其實也不難想像為什麼會有「第四方支付」的出現。

註:這裡也不為所謂的「第一間台灣第四方支付」背書,因為它的網站根本沒有公開 API 文件與任何 SDK。

或許以後有機會可以寫寫藍新或綠界的,因為沒接過所以無從評論。

  • 不過從藍新 SDK 這種缺乏 namespace 且沒有 composer 機制的 SDK 大概也沒有什麼參考價值。
  • 綠界 SDK 這種單個檔案塞進所有 class 的設計,大概也是可以直接洗洗睡。