告別 Google 表單與人工對帳！用 WordPress 打造「報名到付款」全自動流水線的 90 天血淚實戰

哈囉，我是浪花科技的資深 WordPress 工程師 Eric。作為一個寫了十幾年 Code 的工程師，我一直相信科技始於惰性，但有的時候，我們只是被日常的瑣碎流程給蒙蔽了雙眼。直到 2026 年初的一場驚魂記，徹底點醒了我：是時候把公司那套破舊的手動報名流程給燒了。

一、故事的起點：一場活動差點讓我社死

去年底，我們公司舉辦了一場針對企業客戶的小型教育訓練。當時的流程非常「傳統」：報名用 Google 表單、付款用 LINE Pay 連結手動傳送，最後確認入場資格，還得靠行銷同事開著 Excel 雙眼布滿血絲地人工比對。

就在活動前一天晚上十一點，我一邊灌著黑咖啡，一邊幫忙核對最後的名單。螢幕上開著三個視窗：Google Sheets、LINE 官方帳號後台，還有網銀的對帳單。突然間，我發現了一個致命錯誤：有三個人付了錢，但 Google 表單裡完全找不到他們的資料（可能是填寫到一半跳出）；另外還有兩個人根本沒匯款，卻莫名其妙被標記為「已付款」並發了確認信。

當下我的冷汗直接冒出來。幾十張表單、深夜還在互相 ping 的 LINE 訊息、不斷切換視窗導致的視覺疲勞… 那一刻我就在心裡暗暗發誓：這絕對是最後一次讓這種鳥事發生。工程師的尊嚴不允許我們在 2026 年還在當「人體 API」。

二、我原本的解法：差點被 SaaS 工具「賣掉」

出事之後，我的第一個工程師直覺當然是「不要重複造輪子」，於是立刻去調研市面上的現成工具。我試用了 Accupass、Eventbrite，甚至還看了幾個國外評價很高的活動管理 SaaS 平台。

老實說，這些工具的介面和基礎功能都很不錯，但只要一觸碰到企業真實的商業邏輯，就會遇到三道難以跨越的關卡：

• 客製化報名欄位受限：我們需要根據客戶的產業類別動態顯示不同的問題，多數 SaaS 平台的表單邏輯太過死板。
• 台灣在地金流與發票串接：國外平台通常只支援 Stripe 或 PayPal，要在台灣串接綠界 (ECPay) 或開立電子發票，簡直是難如登天。
• 資料孤島效應 (Data Silo)：這是最致命的一點。活動結束後，這些名單就困在該平台裡，要跟我們浪花科技內部的 CRM 系統同步，要嘛得升級到天價的企業版方案才能開通 Webhook，要嘛就得回到手動匯出 CSV 的石器時代。

經過三天的評估，我深刻體會到：對有一定規模或客製化需求的企業來說，買現成的 SaaS 有時候反而是一種陷阱。你的業務流程最終會被工具綁架，而不是工具來服務你的業務。

三、決定自己動手：整個系統的架構設計思路

既然決定在我們最熟悉的 WordPress 領域自己動手，那就得做一個不用再重複踩坑、未來好擴充的版本。身為工程師，我常唸後輩：「先畫架構圖，再開始寫 Code。」這套系統的底層邏輯，其實就是一條清晰的自動化流水線：

我把整個流程拆解成幾個關鍵模組：

• 資料採集層：前端利用客製化的表單收集報名資料，寫入 WordPress 的 Custom Post Type (CPT)。
• 觸發與通知層：資料一入庫，立刻觸發 WordPress Hook，透過 SMTP 發送「等待付款」通知信。
• 金流交易層：利用 API 建立綠界金流訂單，並將使用者導向付款頁面。
• 回傳與處理層 (核心)：綠界付款成功後，打 Webhook 回我們的伺服器。此時系統自動更新訂單狀態、生成專屬 QR Code 入場券，並透過 REST API 將這筆完美無瑕的資料寫入公司 CRM。
• 排程提醒層：活動前 24 小時，Cron Job 自動抓取已付款名單，推播 LINE 提醒訊息。

聽起來很複雜？但拆解開來，核心不過就是幾個精準的 Hook、一條接通外部的 Webhook，以及一個穩定的排程任務。

四、建置過程的三個翻車時刻

當然，理想很豐滿，Debug 很骨感。這 90 天的開發過程中，我結結實實地踩了幾個大坑，這邊無私分享出來，希望能幫大家少走一點彎路。

第一個坑：本地開發接不到金流 Webhook

在開發綠界金流的非同步通知 (ReturnURL) 時，我在本地 (Localhost) 開發環境點了半天，永遠收不到綠界打回來的付款成功通知。搞了快半天才猛然拍大腿：外部伺服器怎麼可能連得進我筆電的 Localhost！後來乖乖掛上 ngrok 建立 Tunnel，才終於看到那個熟悉的 HTTP 200 POST 請求進來。

第二個坑：冪等性 (Idempotency) 與重複寫入災難

金流上線測試的第二天，我發現資料庫裡居然出現了重複的付款成功紀錄。追查 Log 後發現，由於網路延遲，綠界有時候會在短時間內重發兩次 Webhook 請求。如果你的程式碼沒有做好防護，就會觸發兩次後續動作（發兩封信、建兩次 CRM 資料）。

解法很簡單也很經典：我加入了一個 order_token 的冪等性檢查機制。如下面的經典編輯器程式碼片段示範：

// 檢查訂單是否已經處理過
$is_processed = get_post_meta($order_id, '_payment_processed', true);

if ( $is_processed ) {
    // 如果已經處理過，直接回傳 1|OK 給金流端，終止執行
    die('1|OK');
}

// 標記為已處理 (鎖定)
update_post_meta($order_id, '_payment_processed', current_time('mysql'));

// 繼續執行後續發信、同步 CRM 邏輯...

第三個坑：HTML 郵件的 CSS 災難

系統自動寄出的 QR Code 確認信，在電腦版收信軟體看都很完美，結果某天老闆用他的手機 Gmail App 打開，版面整個大走鐘，按鈕跑版、QR Code 變形。為了解決這個看似前端的問題，我整整花了一個週末，把所有 CSS 改寫成 1990 年代風格的 Inline CSS 和 Table 排版，才終於征服了各大郵件 App 的相容性地獄。

五、系統上線後的真實數據和感受

三個月前，我們第一次用這套自建系統舉辦了一場 150 人的實體講座。報名、付款到活動當天結束，全程沒有任何人為介入。活動當天，同事只需要拿著手機，掃描報到者信件裡的 QR Code，系統自動完成打卡入席。

原本需要三個人輪班盯著的報名確認作業，現在行銷同事只要優雅地泡杯茶，偶爾進 WordPress 後台看一下 Dashboard 的報表就好。人工對帳的時間從每次活動的 10 小時，直接降到了 0 小時。

不過系統也不是完美的。上個月有個報名者在他的「姓名」欄位裡填了一個很特別的 Emoji 表情符號，結果寫入資料庫時因為舊版資料表編碼不是 utf8mb4 而直接噴錯，導致那筆訂單卡死。這也再次提醒我這位老鳥：永遠不要相信使用者的輸入，後端資料驗證與編碼設定永遠不嫌多。

六、給打算跟進的你：幾句不客氣的建議

寫到這邊，如果你也燃起了想要「自幹一套」的熊熊烈火，請先冷靜一下聽聽我的勸：

如果你們公司每年辦的活動不超過兩場，或者報名流程真的很簡單、不需要跟公司內部的其他系統連動，那麼用現成的 SaaS 工具（加上一點人工）絕對比自建划算。千萬不要因為看了這篇文章，就覺得自己一定要去造輪子，時間成本也是成本。

但是，如果你已經在日常流程裡感受到明顯的「斷點」與龐大的人工對帳成本，或者你有獨特的商業邏輯（例如：VIP 企業客戶自動打折、資料必須無縫即時同步至內部 CRM），那自建這套系統的投資報酬率，其實遠比你想的還要高非常多。雖然第一次建置的時候要準備好花時間踩坑，但一旦流水線跑起來，它就是你公司最不知疲倦的超級數位員工。

延伸閱讀：優化你的自動化武器庫

在開始動手前，不妨先看看我們踩過的其他自動化與 API 串接坑：

• 活動名單還在手動 Key-in？揭秘 WordPress + CRM 自動分流術，讓你的業務線索『秒速』就位！
• 訂單不再卡關！2026 WordPress 金流串接實戰：ECPay 與 HitPay API 整合開發全攻略 (附防呆程式碼)
• 資料孤島終結者！n8n Webhook + API 串接實戰：讓你的 WordPress 與外部系統「秒速」通靈

如果你不想自己經歷這 90 天的血淚踩坑期，想要一套專屬且穩定的企業自動化流程，歡迎讓浪花科技的資深工程師團隊來幫你打通系統任督二脈。
👉 準備好告別人工對帳了嗎？立即聯繫浪花科技，讓我們為你打造專屬的自動化數位引擎！