金流串接不再頭痛!WordPress 第三方支付 API 終極實戰 (ECPay + HitPay 全攻略)

2025/08/22 | API 串接與自動化

金流串接不再頭痛!WordPress 第三方支付 API 終極實戰 (ECPay + HitPay 全攻略)

嗨,我是浪花科技的資深工程師 Eric。在 WordPress 的世界裡打滾了這麼多年,從簡單的部落格到複雜的電商平台,我看過太多客戶為了一件事傷透腦筋——那就是「錢」。更準確地說,是如何在網站上安全、穩定地收錢。這就是我們今天要深入探討的主題:第三方支付 API 串接實作

你可能已經在用 WooCommerce,也可能裝了某個金流外掛,但你有沒有想過,如果能更深一層地理解背後的運作原理,甚至自己動手串接,你的網站將會有多大的彈性?今天,我就要帶你撩起袖子,直接面對金流串接的核心,我們將以台灣最普及的 ECPay (綠界) 和一個適合國際收款的 HitPay 為例,從觀念到實作,一次讓你搞懂 WordPress 的金流整合黑魔法。

為什麼不直接用現成外掛就好?談談手動串接 API 的好處

在我們開始之前,我得先來段工程師的小囉嗦。我知道,我知道,市面上有那麼多現成的金流外掛,裝上去、設定一下 Merchant ID 跟 Key,按幾下就搞定了,快又有效。那為什麼我們還要自討苦吃,去研究什麼 API 文件、寫程式碼呢?

身為一個對程式碼有點潔癖的工程師,有時候看到外掛為了相容各種情境,包山包海地載入一堆我根本用不到的 JavaScript 和 CSS 檔案,或是後台設定頁面複雜到像在開飛機,心裡總是有點過不去。手動串接 API 帶來的好處是:

  • 極致的客製化: 你可以完全掌控付款流程的每一個環節,打造最貼合你品牌風格與使用者體驗的結帳頁面,而不是被外掛的版面綁架。
  • 輕量與高效能: 沒有多餘的程式碼,只載入你需要的東西。對於追求網站速度的我們來說,每一毫秒都至關重要。
  • 更強的除錯能力: 當金流出問題時,因為整個流程是你親手打造的,你能夠更快速地定位問題點,而不是在外掛的程式碼海中迷航。
  • 學習與成長: 搞懂金流 API 的運作,絕對會讓你的 WordPress 開發功力提升一個檔次。

當然,這條路需要你對 PHP 和 WordPress 的運作有基本的了解。但相信我,走完這一遭,你會很有成就感。

開工前的準備:打好地基,才能蓋高樓

在我們開始撰寫任何程式碼之前,請確保你已經準備好以下幾樣東西,這就像蓋房子前的地基,缺一不可:

  • 一個正常的 WordPress 環境: 這可以是你的本機開發環境,或是測試用的主機。
  • SSL 憑證 (HTTPS): 這不是選項,是絕對的標配!任何跟金錢交易有關的傳輸,都必須在 HTTPS 的加密通道下進行,否則你就是在拿客戶的資料和你的商譽開玩笑。
  • ECPay 與 HitPay 的商家帳號: 你需要先到他們的官網註冊並取得商家資格。他們通常會提供一個「測試環境」讓你開發,這非常重要,我們所有的開發與測試都應該在測試環境完成。
  • API 金鑰: 這是你的網站與支付平台溝通的「鑰匙」,包含 MerchantID、HashKey、HashIV、API Key、Salt 等,等等我們會詳細說明。
  • 一個好的程式碼編輯器跟你最愛的咖啡: 寫 Code 是個需要專注的過程,對吧?

決戰 ECPay:台灣電商金流串接實戰

ECPay (綠界) 幾乎是台灣電商網站的標配,支援的付款方式非常多元。它的串接方式主要是透過「表單提交 (Form Post)」來達成。

ECPay 核心流程解剖

整個流程可以簡化為以下幾個步驟:

  1. 使用者在你的網站上點擊「前往付款」。
  2. 你的 WordPress 網站根據訂單資訊,動態生成一個 HTML 表單,裡面包含了所有必要的交易參數,以及一個最重要的「交易檢查碼 (CheckMacValue)」。
  3. 這個表單會自動提交 (POST) 到 ECPay 的伺服器。
  4. 使用者在 ECPay 的頁面完成付款(輸入信用卡號、ATM 轉帳等)。
  5. ECPay 處理完畢後,會做兩件事:
    a. 將使用者導回你指定的「付款完成頁 (ReturnURL)」。
    b. 在背景(Server-to-Server)發送一個通知到你指定的「回調網址 (OrderResultURL)」。
  6. 你的網站收到這個背景通知後,再次驗證檢查碼,確認通知的合法性,然後更新訂單狀態。

這裡的關鍵在於 CheckMacValue,它是一個經過特殊規則加密的字串,用來確保交易資料在傳輸過程中沒有被竄改,並且真的是由你發出的。

打造送往 ECPay 的「出師表」:付款表單與簽章生成

要向 ECPay 發起一筆交易,你需要準備一堆參數,例如:MerchantIDMerchantTradeNo(訂單編號)、TotalAmount(金額)、ItemName(商品名稱)等等。而最重要的,就是產生 CheckMacValue

ECPay 的文件寫得很清楚,它的產生規則是:將所有必要參數(不含 CheckMacValue 本身)依字母順序排序,組合成 `key=value&key2=value2` 的字串,頭尾再加上你的 HashKey 和 HashIV,然後進行 URL Encode、轉小寫,最後用 SHA256 加密。聽起來很複雜?沒關係,直接看程式碼最快:


<?php
/**
 * 生成 ECPay 的 CheckMacValue
 *
 * @param array  $params   交易參數陣列
 * @param string $hash_key ECPay 後台提供的 HashKey
 * @param string $hash_iv  ECPay 後台提供的 HashIV
 * @return string
 */
function generate_ecpay_mac($params = [], $hash_key = '', $hash_iv = '') {
    // 1. 依參數名稱的字母 A-Z 排序
    ksort($params);

    // 2. 組成 URL-encoded query string
    $query_string = http_build_query($params);

    // 3. 頭尾加上 HashKey 和 HashIV,並取代特定符號
    $string_to_hash = 'HashKey=' . $hash_key . '&' . $query_string . '&HashIV=' . $hash_iv;

    // 4. URL-encode, 轉小寫, 取代編碼後的特殊字元 (dot-net-style)
    $string_to_hash = urlencode($string_to_hash);
    $string_to_hash = strtolower($string_to_hash);
    $string_to_hash = str_replace('%2d', '-', $string_to_hash);
    $string_to_hash = str_replace('%5f', '_', $string_to_hash);
    $string_to_hash = str_replace('%2e', '.', $string_to_hash);
    $string_to_hash = str_replace('%21', '!', $string_to_hash);
    $string_to_hash = str_replace('%2a', '*', $string_to_hash);
    $string_to_hash = str_replace('%28', '(', $string_to_hash);
    $string_to_hash = str_replace('%29', ')', $string_to_hash);

    // 5. SHA256 加密後轉大寫
    $check_mac_value = strtoupper(hash('sha256', $string_to_hash));

    return $check_mac_value;
}
?>

有了這個函式,你就可以在使用者結帳時,把訂單資訊丟進去,產生 CheckMacValue,然後把所有參數渲染成一個隱藏的 HTML 表單,再用 JavaScript 自動提交它。

接收勝利的號角:處理 ECPay Server-to-Server 回調

這一步是整個流程中最容易被忽略,卻也最重要的一環。千萬不要只依賴使用者跳轉回來的 ReturnURL 來更新訂單狀態!因為使用者可能在付款成功後直接關掉瀏覽器。最可靠的做法是處理 ECPay 從伺服器端發來的 OrderResultURL 通知。

當你收到這個 POST 通知時,裡面會包含交易結果和一個回傳的 CheckMacValue。你要做的,就是用完全相同的加密規則,拿回傳的資料(不含 CheckMacValue)和你自己的 HashKey/HashIV 再算一次,比對看看兩個 CheckMacValue 是否一致。如果一致,就代表這筆通知是合法且未經竄改的,你就可以安心地去資料庫更新你的訂單狀態了。

征服 HitPay:國際金流 API 串接實戰

如果你的業務範圍不只在台灣,那麼 HitPay 就是一個不錯的選擇,它支援多國貨幣和多種支付方式(如 PayNow、GrabPay 等)。與 ECPay 不同,HitPay 主要採用 RESTful API 的方式進行串接。

HitPay API 運作邏輯

HitPay 的流程更接近現代的 API 設計:

  1. 使用者在你的網站點擊「前往付款」。
  2. 你的 WordPress 網站從後端(Server-side)向 HitPay 的 API 端點發起一個 POST 請求,請求中包含了交易資訊和你的 API Key。
  3. HitPay API 驗證你的請求後,會回傳一個 JSON,裡面包含一個專屬的付款連結 (URL)。
  4. 你的網站收到這個 URL 後,將使用者重導 (redirect) 到這個付款連結。
  5. 使用者在 HitPay 的頁面完成付款。
  6. HitPay 透過 Webhook (類似 ECPay 的回調),向你指定的網址發送一個 POST 請求,通知你交易結果。
  7. 你的網站接收到 Webhook,驗證簽章 (Signature) 的合法性,然後更新訂單狀態。

發起進攻:使用 `wp_remote_post` 建立付款請求

在 WordPress 中,要發起後端 API 請求,最好的方式就是使用內建的 `wp_remote_post` 函式。你需要將 API Key 放在 HTTP Header 中進行驗證。


<?php
function create_hitpay_payment_request($order_data, $api_key) {
    $api_url = 'https://api.hit-pay.com/v1/payment-requests'; // 注意測試與正式環境的 URL 不同

    $body = [
        'email'           => $order_data['email'],
        'amount'          => $order_data['amount'],
        'currency'        => 'TWD',
        'reference_number'=> $order_data['order_id'],
        'webhook'         => 'https://your-website.com/api/hitpay-webhook',
        'redirect_url'    => 'https://your-website.com/payment-thank-you',
    ];

    $args = [
        'body'    => json_encode($body),
        'headers' => [
            'Content-Type'      => 'application/json',
            'X-Business-Api-Key'=> $api_key,
        ],
    ];

    $response = wp_remote_post($api_url, $args);

    if (is_wp_error($response)) {
        // 處理錯誤
        return null;
    }

    $response_body = json_decode(wp_remote_retrieve_body($response), true);

    return $response_body; // 回傳的資料中會有 id 和 url
}
?>

成功的話,你會從 `$response_body` 中拿到一個 `url`,把使用者導過去就對了。

滴水不漏的防線:驗證 HitPay Webhook 簽章

當 HitPay 透過 Webhook 通知你時,會在 HTTP Header 裡帶一個 `X-Signature` 的欄位。這個簽章是使用 HMAC-SHA256 演算法,拿你的 API Salt 作為密鑰,對整個請求的 Body 進行加密得到的。

你的任務就是在收到 Webhook 時,用同樣的方式自己算一次簽章,然後跟 Header 裡收到的比對。這裡要囉嗦一下,請務必使用 `hash_equals()` 函式來比對字串,這可以有效防止「時序攻擊 (Timing Attack)」,是處理資安驗證時的標準做法。


<?php
function verify_hitpay_webhook($request_body_string, $signature_from_header, $api_salt) {
    $computed_signature = hash_hmac('sha256', $request_body_string, $api_salt);

    // 使用 hash_equals() 來防止時序攻擊
    return hash_equals($computed_signature, $signature_from_header);
}
?>

只有驗證通過,才能相信這筆通知的內容,並據此更新訂單。

金流串接的必修學分:安全,還是安全!

無論你用哪家金流,請務必把以下幾點刻在腦子裡:

  • HTTPS 是你的生命線: 再次強調,沒有 HTTPS 就沒有交易安全。
  • 永遠不要儲存信用卡號: 把處理敏感資料的責任交給專業的支付平台,這是使用第三方金流最大的好處之一。
  • 後端驗證是唯一的真理: 永遠不要相信從前端 (使用者瀏覽器) 回傳的任何結果,唯一的訂單狀態更新依據,必須是經過簽章驗證的 Server-to-Server 回調/Webhook。
  • 妥善保管你的金鑰: 你的 API Keys/Salts/HashIV 等,絕對不要寫死在佈景主題或外掛的程式碼裡,更不要上傳到公開的 Git repository。最好的做法是將它們定義在 `wp-config.php` 這個不會被公開存取的檔案中。

恭喜你,看到這裡,你已經對 WordPress 第三方支付 API 串接有了相當深入的了解。從 ECPay 的表單提交到 HitPay 的 RESTful API,你掌握了兩種主流的串接模式。這不僅僅是寫幾行程式碼,更是建立一個安全、可靠、客製化線上交易系統的基石。雖然過程比單純安裝外掛來得複雜,但這份對底層邏輯的掌控感,絕對是身為專業開發者的你,最寶貴的資產。

延伸閱讀

如果你覺得自行處理金流串接太過複雜,或是你有更獨特的商業邏輯需要客製化,浪花科技的團隊擁有豐富的 WordPress 金流整合與 API 串接經驗。我們樂於協助你打造最穩定、安全的電子商務解決方案。歡迎與我們聯繫,讓專業的團隊為您的事業加速!

常見問題 (FAQ)

Q1: 在串接第三方支付後,我需要自己處理或儲存客戶的信用卡號碼嗎?

A1: 絕對不用!這正是使用 ECPay 或 HitPay 這類第三方支付平台的最大好處。整個付款過程,包括輸入信用卡號等敏感資訊,都是在支付平台的安全頁面上完成的。你的網站完全不會接觸到這些資料,大大降低了你的資安風險與合規成本。請記住,一個重要的原則是:永遠不要在自己的伺服器上儲存完整的信用卡資訊。

Q2: 我的 ECPay CheckMacValue 檢查碼一直驗證失敗,該怎麼辦?

A2: 這是串接 ECPay 時最常見的坑。請依序檢查以下幾點:1. 參數排序: 確認你用來產生檢查碼的參數陣列 (Array) 是嚴格按照「字母順序」排序的。2. 大小寫: ECPay 的規則是在 URL Encode 後要全部轉成「小寫」。3. HashKey/HashIV: 再三確認你從 ECPay 後台複製的 HashKey 和 HashIV 是否正確,有沒有多複製到空格。4. URL Encoding 規則: ECPay 的 URL Encode 規則比較特殊 (dot-net-style),請確認你的程式碼有處理這部分,如文章中的範例程式碼所示。5. 參數遺漏: 確認所有必填的參數都包含在內了。

Q3: 為什麼一定要用 Webhook/回調 (OrderResultURL) 來更新訂單,不能只靠使用者跳轉回來的頁面 (ReturnURL) 嗎?

A3: 這是一個關於「可靠性」的關鍵問題。ReturnURL 是給「使用者」看的,它依賴使用者的瀏覽器行為。如果使用者在付款成功後、跳轉回你的網站前,網路斷線或直接關閉了瀏覽器,你的網站就永遠不會收到這次跳轉,訂單狀態就會一直是「待付款」,導致後續出貨等流程卡住。而 Webhook/回調是「伺服器對伺服器」的溝通,它不受使用者行為影響,支付平台會在後端直接、穩定地通知你的伺服器交易結果,這才是更新訂單狀態唯一可靠的依據。

 
立即諮詢,索取免費1年網站保固