後台的訂單通知外掛設定頁裡，那組 LINE Notify 權杖還好端端掛在欄位裡，狀態顯示已啟用，但這一年多，它其實什麼訊息都沒送出去。介面沒跳出任何錯誤，留言通知悄悄停了、訂單通知也悄悄停了，直到某天翻信箱才發現有一筆訂單早該出貨卻沒人知道。
這不是網站故障，也不是外掛出錯，而是 LINE Notify 這項服務本身已經被官方關閉。LINE Notify 是 LINE 從 2016 年開始提供、免審核就能用一組個人權杖把通知推送到自己 LINE 帳號的服務，過去幾年是台灣中小網店與部落格最常用的免費通知管道，不少人的 WordPress、WooCommerce 通知外掛都靠它把訂單與留言即時送到手機。服務關閉之後，原本掛在外掛設定裡的那組權杖就成了一組永遠打不通的空號，能不能找到堪用的 LINE Notify 替代方案，關係到你會不會漏接下一筆訂單。
LINE Notify 從公告到全面關閉的四個時間點
整起事件其實留了不算短的緩衝期，只是多數站長沒注意到公告，才會在服務真的關閉之後才驚覺出問題。時間軸大致是四個關鍵日期。
LINE Developers 官方新聞公告最早在 2024 年 10 月就對外預告了終止時程，這份公告發布的時間，比實際關閉日早了將近半年。接著是 2025 年 3 月 31 日，這是 LINE 官方正式訂定的 LINE Notify 服務終止日；官方公告寫得很直接，終止理由是把資源集中起來，推出功能更完整的後繼服務，也就是下面會談到的 Messaging API。緊接在終止日之後，2025 年 4 月 1 日起，LINE Notify 的 API 存取、個人頁面查詢、權杖發行這三項功能全部無法使用，既有的存取權杖也在同一天同步失效，等於一夕之間所有靠這組權杖串接的通知都會斷線。最後一個時間點落在 2025 年 5 月 12 日之後，LINE Notify 的官方帳號與相關的網頁陸續被下架，連原本用來查詢或管理權杖的頁面也一併消失，想回頭確認舊設定都無從查起。
把這四個日期擺在一起看，會發現這不是一次臨時的服務異常，而是官方按照既定時程逐步收掉一整套機制：先預告、再終止服務、再讓 API 全面失效、最後把周邊頁面清乾淨。理解這個順序，對接下來判斷「自己的網站是什麼時候開始斷線的」會有幫助。只要通知外掛裡還留著 LINE Notify 的權杖欄位，那從 2025 年 4 月 1 日起，它就已經是一個確定失效的設定，不會因為重新儲存一次或重灌外掛就恢復。
通知悄悄停了，問題出在服務本身而非網站故障
收不到 LINE 訂單或留言通知的時候，第一反應通常是懷疑網站掛了、外掛壞了，或是主機出了問題，於是花了大把時間重灌外掛、切換主機、翻遍設定頁，卻怎麼查都查不出原因。真正的原因跟這些都沒關係，問題出在 LINE Notify 這個服務本身已經被官方整批關閉。
要理解為什麼會這樣「不動聲色」地斷線，得先回頭看 LINE Notify 舊機制的運作原理。它的設計非常單純，使用者到 LINE Notify 的個人頁面申請一組權杖，外掛只要拿這組權杖呼叫 LINE 提供的 notify 相關網域，就能把訊息推送給綁定的個人帳號或群組。整個過程不需要審核、不需要建立官方帳號，門檻極低，這也是它過去在台灣中小網店與部落格採用率這麼高的原因——裝一個外掛、貼一組權杖就能用，比申請正式的官方帳號簡單太多。
正因為機制這麼單純，一旦服務端把權杖機制整批下線，影響也一樣是全面性的。2025 年 4 月 1 日之後，任何呼叫 LINE Notify 相關網域的請求都會失敗，這是服務端主動關閉造成的結果，不是暫時性的網路異常，也不會自己恢復。麻煩的是，多數依賴 LINE Notify 權杖的通知外掛，在呼叫已經失效的 API 時，介面上不見得會跳出明顯的錯誤訊息，通知就只是安靜地不再送達，很容易拖到發現訂單漏接、留言沒人回覆，才驚覺這條通知線路已經斷線超過一年。
確認自家網站是否也斷了 LINE 通知的三個線索
判斷自己的網站是不是也受影響，不需要工程背景，照著由淺到深的三個層次一步步查，就能找到答案。這三個層次分別是介面檢查、紀錄檢查、實測驗證，不同技術程度的讀者，都可以在其中找到自己會做的那一步。外掛設定畫面顯示「已啟用」或「已連結」，不代表訊息真的送得出去，很容易讓人誤判，這幾個線索要合起來看，才不會被表面的顯示狀態誤導。
外掛設定頁裡還留著的 LINE Notify 舊權杖
第一步最快、也不需要任何技術背景，直接進到 WordPress 後台，檢查有沒有安裝過依賴 LINE Notify 權杖的通知外掛，不論它處理的是留言通知、WooCommerce 訂單通知，還是表單通知。如果打開設定頁，發現那個欄位還留著一組舊的權杖字串，這就代表這條串接已經失效超過一年，該功能已經完全不會有任何動作。
這一步之所以放在最前面，是因為它幾乎不需要判斷，只要欄位裡還躺著一組 LINE Notify 的權杖，答案就已經很明確。就算外掛本身沒有跳出任何錯誤提示，這組權杖也早在 2025 年 4 月 1 日就同步失效，不會因為時間過去而自己恢復，也不會因為重新輸入一次同樣的字串而變成有效。
後台錯誤紀錄裡的連線逾時痕跡
比第一步再深一層，可以查後台通知、Email 錯誤警示，或是伺服器的 PHP 錯誤紀錄。部分外掛在呼叫已經失效的 API 時，會在這些地方留下連線逾時、無法解析網域，或是特定 HTTP 錯誤碼的訊息，這是比較明確的技術線索，能進一步證實通知失敗確實發生在外部連線這一端，而不是網站自己的程式出了問題。
不過這一步有個限制要先知道，不少低階虛擬主機預設不會顯示 PHP 錯誤訊息，或是把錯誤紀錄的等級調得很低，導致這類連線失敗的痕跡根本不會出現在你看得到的地方。也就是說，翻遍錯誤紀錄什麼都沒看到，不代表通知沒有問題，不能只靠這一項線索就下結論，還是要搭配前後兩個步驟一起判斷。
送一筆測試訂單，直接驗證 LINE 端能否收到通知
最直接、也最可靠的方式，是自己下一筆測試訂單，或是在網站上送一則測試留言，實際等看看 LINE 那端有沒有跳出通知。這一步比翻設定畫面更準，因為介面顯示的狀態本來就不保證訊息真的送出去了，唯有實際跑一次完整流程，看訊息有沒有出現在手機上，才算真正驗證過。
如果測試訂單送出後，等了合理的時間仍然沒有任何通知進來，搭配前面兩個步驟看到的舊權杖欄位與連線失敗紀錄，基本上就能確定自家網站的 LINE 通知已經因為服務終止而斷線，接下來要處理的不是找出網站哪裡壞掉，而是決定要換上哪一套替代方案。
改用官方 Messaging API，多了功能也多了用量上限
LINE 官方在兩份公告裡都明確指向同一個後繼方案，也就是 Messaging API。但這不是把舊權杖換成新權杖那麼單純，Messaging API 跟舊版 LINE Notify 在接收機制上有本質差異。舊版只要一組個人權杖，就能對單一使用者或群組直接推播；新版必須透過一個正式的 LINE 官方帳號發送訊息，接收方得先把這個官方帳號加為好友，而且每一則訊息都會計入該官方帳號每月的用量方案，不再是舊版那種近乎沒有上限的免費推播。
從一個免費、免審核的舊工具，換到一個需要申請官方帳號、還有免費則數上限的新工具，中間實際多出來的門檻與成本，遠比單純換一組權杖字串來得多，這才是兩者最大的落差所在。
從 LINE Notify 換成官方帳號的申請與綁定流程
要把通知線路接到 Messaging API，得先在 LINE Developers Console 建立一個 Provider，也就是官方定義的服務提供者角色。這個名稱會直接顯示在使用者的同意畫面上，官方文件也提醒不要用臨時想到的名稱（例如只在內部使用的品牌名或專案代號），建議直接用公司或組織的正式名稱；日後如果要更名，一般 Provider 可以在後台的「Provider 設定」隨時調整，但通過官方認證的 Provider 改名得另外向 LINE 提出申請審核，取名字時還是謹慎一點比較省事。
接下來在這個 Provider 底下建立一個 Messaging API 類型的 Channel，LINE Developers 官方文件把 Channel 定義為「供應商使用 LINE 平台功能（如 Messaging API、LINE Login）的通訊路徑」，這個建立過程會同步產生一個新的 LINE 官方帳號。實務上的建立流程是先到 Official Account Manager 註冊 Business ID，並填寫官方帳號表單完成官方帳號的建立；接著回到同一個後台啟用 Messaging API 功能，系統會自動建立對應的 Channel；最後回到 LINE Developers Console 確認 Channel 已經建立，並取得 Channel access token（頻道存取權杖），這組 token 就是取代舊版 LINE Notify 個人權杖的東西。如果只是要做單向的系統通知，不需要接收使用者傳回來的訊息，就不必額外開啟「Use webhook」這個原本是給聊天機器人接收訊息用的功能。
輕用量方案的兩百則免費額度，中小型網店常常不夠用
把免費額度換算成日常情境會更有感，每月 200 則，平均下來每天只能發出 6 至 7 則系統推播。訂單量稍微多一點，或是同時開了留言通知與訂單通知的網站，很容易在月中就把額度用完。
訊息額度是依「收件人數」計算，不是依「發送次數」計算，這條計費規則特別容易被低估。LINE Developers 官方的 Messaging API 計費文件列出，計入每月免費額度的發送方式包括 Push messages、Multicast messages、Broadcast messages、Narrowcast messages，只有 Reply messages（回覆訊息）完全免費、不計入額度；系統通知屬於主動推播，一律算 Push，會消耗額度。也就是說，同一則系統廣播，如果官方帳號底下有 10 個管理員好友，一次就會扣掉 10 則額度，這在自己估算「200 則夠不夠用」時最容易低估。同一份文件把計算公式寫得更明確：訊息則數等於發送請求數乘以收件人數，並舉例對 5 人的聊天室推送 1 則含 4 個訊息物件的請求，仍算發送了 5 則，訊息物件的數量不影響計費，證實依人頭計算是官方白紙黑字的規則，不是坊間猜測。
台灣現行的官方帳號費用方案分成三級，數字以 LINE Biz-Solutions 這份台灣官方頁面為準：輕用量方案月費 0 元、每月免費 200 則，不可加購；中用量方案月費 800 元、每月免費 3,000 則，同樣不可加購，超過需要升級到高用量方案；高用量方案月費 1,200 元、每月免費 6,000 則，超出部分可在後台設定加購上限、採階梯式計價，每則約 0.2 元起降，於當月結算、次月收取。三個方案在超額之後的行為並不一樣，這正是容易讓人以為「修好了結果又斷線」的地雷：輕用量與中用量方案一旦傳送則數超過免費額度，系統會直接回傳錯誤、訊息不會送出，不會自動幫你加購續傳，得手動升級方案才能繼續發送；只有高用量方案會在超額後依前面提到的階梯費率自動計費續傳，直到觸及自己設定的加購上限才停止。換句話說，免費或中用量方案的通知「以為修好了結果還是斷線」，十之八九是卡在額度用完卻沒升級這一關，跟「用超過就自動多算錢」是兩回事，值得在規劃通知量的時候一併考慮進去。
額度用完後，選擇升級付費方案或是多帳號分流
額度不夠用的時候，實際可以走的路大致有兩條。第一條是直接升級到中用量或高用量方案，用固定月費換取更高的免費額度與可加購空間，適合訂單量穩定成長、不想花時間管理多組帳號的網店。
第二條是社群上常見的「土法」，開設多個 LINE 官方帳號，依用途或用量分流，例如訂單通知用一個帳號、留言通知用另一個帳號，讓每個帳號各自留在 200 則免費額度內。這個做法的好處是不用額外花錢，代價是要同時維護多組帳號，管理員得記得在某個帳號額度用完的時候手動切換接收帳號，長期下來的維護成本，可能反而比直接升級付費方案還高。這兩條路各有各的代價，實際該怎麼選，要看自己的通知量與預算而定。
跳脫 LINE 生態系之外的免費通知選擇
如果不一定要靠 LINE 接收通知，還有幾種國際上常見、不受單一免費服務條款牽制的替代管道可以考慮。它們各自有不同的技術門檻與適合對象，跟 LINE 官方帳號比起來，核心差異在於大多不受每月則數上限限制，但代價是要換一套新的接收習慣。
Telegram 與 Discord 的機器人通知，設定門檻低且不限則數
Telegram 與 Discord 都提供免費的機制可以直接串接。Telegram 透過官方機器人 BotFather 建立一個 Bot 並取得 Token，就能用 API 把訊息發送出去；Discord 則更簡單，只要在頻道設定裡直接產生一組 Webhook 網址，把這組網址貼進通知外掛或自動化工具，就能開始收訊息。
這兩者都沒有 LINE 官方帳號那種每月則數上限，是目前國際上最常見、免費、專門給開發者用的通知管道。缺點是如果管理員原本沒有在用這兩款軟體，需要多安裝一個 App，也需要花一點時間熟悉頻道與通知的設定方式，多一道學習曲線。
一直都在卻常被忽略的網站原生 Email 通知
WordPress 與 WooCommerce 其實內建了新訂單、新留言的 Email 通知功能，只是預設的寄送品質常被主機或收件信箱歸類成一般信件，不夠即時醒目，這也是不少站長當初轉向 LINE 這類即時通訊軟體的原因。
搭配 SMTP 外掛改善寄送穩定度與到達率之後，Email 仍然是一個不依賴任何第三方免費額度、最不容易無預警關站的通知管道，別把關鍵通知只押在單一免費服務上，正是這裡最值得記住的原則。就算最後選擇了 Messaging API 或是 Telegram、Discord 這類替代管道，Email 都可以當成一條固定備援線路，隨時保留著。
自架推播服務，留給對技術有把握的站長
對技術門檻要求較高、想徹底擺脫「哪天服務商說關就關」這種風險的讀者，還有兩種進階做法可以了解。一種是自行架設開源的推播工具，好處是則數不受制於任何服務商，代價是需要具備伺服器維運能力；另一種是使用國際代管型的 SaaS 推播服務，不用自己架設，用低成本的一次性或訂閱月費，就能取得穩定的推播額度。
開源自架方案的代表是 Ntfy 與 Bark，兩者都是開放原始碼專案，官方網站上可以查閱它們免費、自架的特性；代管型 SaaS 的代表則是 Pushover 這類提供低成本訂閱制推播的國際服務。知道這幾條路存在就好，實際設定步驟因方案而異，要不要投入，取決於自己或團隊有沒有能力維護。
回到 WordPress 後台，把通知線路重新接上
重新接上通知線路，實際上會遇到兩種情境：一種是原本用的外掛還在維護，只是要把失效的欄位換掉；另一種是外掛已經停止維護，或者原本就沒有整合外掛，需要用更通用的方式重新串接。
確認外掛是否已更新支援新的通知方式，或需要整個換掉
先檢查原本在用的通知外掛，有沒有針對 LINE Notify 停用發出更新。部分外掛作者已經把設定欄位改成填入 Messaging API 的 Channel access token，或是加入了 Telegram、Discord 等其他管道的選項，這種情況只要照著新欄位重新設定一次即可。
如果查過之後發現這款外掛已經超過一年沒有任何更新紀錄，代表它很可能不會再支援新的串接方式，建議直接換一款仍在持續維護的外掛，或者改走下一小節的通用做法。不要繼續留著已經停止維護、又暴露對外連線的舊外掛，這同時也是一個資安上的考量，不只是功能能不能用的問題。
沒有整合外掛時，用 Webhook 或自動化工具接起來
如果現有外掛完全沒有 Messaging API 或其他管道的整合選項，可以透過 WooCommerce 內建的 Webhook 功能，把「新訂單」「訂單狀態變更」這類事件即時送到 n8n、Zapier 這類自動化平台，再由平台轉發到 Messaging API、Telegram 或 Discord。
這個做法不需要自己寫程式碼，但需要花時間在自動化平台上，把「WooCommerce 事件轉發到 LINE 或其他管道」這條流程串起來，並且測試欄位對應是否正確，例如訂單編號、金額、商品名稱這些欄位有沒有正確帶進轉發出去的訊息內容裡。對還沒有整合外掛、又不想等外掛作者更新的網站來說，這是一條可以自己動手接起來的路。
設定完成後，先送一筆測試訂單再正式上線
不管最後換成哪一種管道，重新串接完成之後，都要用測試訂單或測試留言實際跑一次，確認訊息真的送達，而且訂單相關的欄位都有正確帶入內容裡。
驗證無誤之後，記得回頭把舊的、已經失效超過一年的 LINE Notify 權杖欄位，或是已經停用的外掛整個移除或停用掉，不要讓它繼續留在後台。這樣做一方面避免日後排查問題時被這些死掉的設定混淆，另一方面也讓整個通知線路乾淨清楚，之後如果又要調整，才不用先花時間搞清楚哪些設定還有作用、哪些早就不動了。
這次的教訓其實很直接：一個免費、免審核的服務，說關就能整批關掉，而且斷線的過程可能安靜到讓人拖上一年多才發現。不管最後選擇的是 Messaging API，還是 Telegram、Discord 這類替代管道，都建議至少同時保留網站原生的 Email 通知當備援，這樣即使日後某個免費服務調整條款或停止營運，訂單與留言通知也不會像這次一樣瞬間全面消失，還可能拖很久才被發現。如果自己判斷不出問題出在哪裡，或是後台這幾項設定操作起來不熟悉，找熟悉 WordPress 維運的工程師協助排查，會比自己反覆試錯更快恢復正常。