← 所有文章
教學

2026 年 10 月起，點樣追蹤同計算 WhatsApp service message 收費

要喺 2026 年 10 月 1 日前追蹤同計算 WhatsApp service message 收費，做法係用 Meta Pricing Analytics API 統計已送達嘅 SERVICE 訊息，同時保存訊息狀態 webhook 入面嘅 pricing object，再按電話號碼同市場拆分數據。現階段可以先建立訊息量基準；Meta 喺 9 月 1 日前公布 10 月服務費率之後，就要更新收費預算。

重點

  • Meta 會由 2026 年 10 月 1 日起，按每條已送達嘅 service message 收費；客戶服務對話唔再係計費單位。
  • Pricing Analytics 會用 pricing_type: REGULAR 同 pricing_category: SERVICE 標示呢類記錄。
  • 訊息需要收費時，狀態 webhook 會喺 pricing object 回傳 billable: true、type: regular 同 category: service。
  • 服務訊息費率因市場而異，同該市場嘅 utility 及 authentication message 費率一致，但無 volume-tier 折扣。
  • Click-to-WhatsApp 廣告同 Facebook 行動呼籲按鈕帶入嘅 72 小時免費入口時段，訊息送達仍然免費，計數時要分開處理。

2026 年 10 月 1 日有咩改變

Meta 嘅官方定價更新列明，企業只可以喺 24 小時客戶服務時段仍然開放期間，發送非範本訊息。由 10 月 1 日起，真人或者唔係由 Meta Business Agent 驅動嘅第三方 AI 所發出嘅非範本訊息，都會當作 service message 收費。

計費數據要保留以下三個界線：

情況Meta 點樣分類要追蹤嘅數據
真人客服或第三方 AI 喺開放時段內回覆Service message按市場統計已送達訊息數目
Meta Business Agent 回覆Meta Business Agent message獨立訊息類別同 token 費用
訊息喺 72 小時免費入口時段內送出訊息送達仍然免費入口來源同時段狀態

每條訊息只會套用一種類別費用，唔好將 service message 收費同 Meta Business Agent 費用同時加落同一條非範本回覆。亦唔可以假設 10 月費率而家已經落實：Meta 表示會喺 2026 年 9 月 1 日前公布 10 月 1 日生效嘅費率，之後最多可以每季調整一次。

之前嘅 Meta Business Agent 定價比較講解架構選擇，2026 年 7 月費率表指南就整理唔同市場嘅費率背景。本文由完成架構決定之後開始，集中講團隊要喺新收費生效前量度咩數據。

點樣追蹤同計算 WhatsApp service message 收費

1. 建立已送達訊息量基準

揀一段有代表性嘅時間，通常係完整四星期，再查詢 Pricing Analytics 入面嘅服務訊息類別。Meta 文件描述嘅結果包括以下欄位：

欄位建立基準時嘅用途
start / end鎖定報表時段
phone_number分開統計每個發送號碼
country將訊息量配對正確嘅市場費率
pricing_type: REGULAR排除其他定價類型
pricing_category: SERVICE只計 service message
volume統計已送達嘅服務訊息數目
cost新收費生效後核對費用

按日期、電話號碼同國家或地區保存結果，唔好再將數據合併成「對話」。Meta 由 10 月起會按每條已送達嘅企業訊息計量，所以一次客服交流有五條企業回覆，就會有五個計費單位，而唔係一個對話單位。

2. 保存狀態 webhook 嘅 pricing object

Meta 表示，訊息類別同收費狀態亦會出現喺訊息狀態 webhook。需要收費嘅 service message 記錄會有以下結構：

{
  "pricing": {
    "billable": true,
    "pricing_model": "PMP",
    "type": "regular",
    "category": "service"
  }
}

匯總數據之前，要將 pricing object 同自己嘅訊息記錄一齊保存。判斷準則唔係客服覺得某條訊息係咪「支援回覆」，而係 Meta 有無將已送達訊息回報為 category: service，以及 billable 係咪 true。

3. 將 webhook 同 Pricing Analytics 對數

每日對照以下兩組數字：

  1. pricing.category 係 service 嘅已送達狀態 webhook 記錄數目。
  2. 相同電話號碼、國家或地區同日期範圍之內，Pricing Analytics 中 pricing_category 係 SERVICE 嘅 volume。

兩邊數字有差異時應該查明原因，唔好直接取平均數。常見界線包括狀態事件延遲到達、時區設定唔一致、報表時段漏咗最後一日，或者訊息被歸入 Meta Business Agent 而唔係 service message。

4. 未有 10 月正式費率，點樣先計預算

用一條將訊息量同費率分開嘅公式：

預計 service message 收費
  = 各市場已送達嘅 SERVICE 訊息量
  × 該市場公布嘅服務訊息費率

喺 9 月 1 日前做預算，可以根據 Meta 所講「服務訊息費率同各市場嘅 utility 及 authentication message 費率一致」，將現行費率當作規劃參考，而唔係最終價錢。官方 10 月費率公布之後要重新計算；亦唔好將 utility 或 authentication message 嘅 volume-tier 折扣套用落 service message，因為 Meta 明確表示服務訊息無 volume tiers。

如果 Business Solution Provider 另外收平台費或服務費，就要分開列帳。BSP 帳單審核指南解釋點解將 Meta 用量費同供應商費用混埋一齊，會令人睇唔清真正要處理嘅成本決定。

5. 新收費開始前測試例外情況

喺 10 月 1 日前建立一份精簡驗收表：

  • 真人客服喺 24 小時客戶服務時段內正常回覆；
  • 第三方 AI 喺同一時段內產生回覆；
  • Meta Business Agent 回覆；
  • 喺有效嘅 72 小時免費入口時段內回覆；
  • 對兩個唔同收件人市場重複同一情況。

每個情況都要記錄狀態 webhook 回傳嘅類別，再搵返對應嘅 Pricing Analytics 數據列。咁樣財務、客服同工程團隊就可以喺第一張帳單出現前，共用同一套計費定義。

UnifyPort 可以點樣配合

以上量度方式適用於經官方 WhatsApp Business Platform 發送嘅流量。團隊如果用 UnifyPort 非官方接口接收一般帳號嘅入站訊息，控制面並唔相同；Meta Pricing Analytics 類別唔係呢條路徑嘅計費依據。

UnifyPort 會將 WhatsApp 入站訊息轉成標準 message.received envelope，同 Telegram、LINE、TikTok、Zalo 及 X 共用同一結構：

{
  "id": "evt_7c41f0b2a9",
  "type": "message.received",
  "provider": "whatsapp",
  "account_id": "acc_8c21d0",
  "occurred_at": "2026-07-14T02:15:00Z",
  "data": {
    "conversation": { "id": "84901234567", "type": "user" },
    "sender": { "id": "84901234567", "type": "user", "name": "Minh Tran" },
    "message": {
      "id": "wamid.HBgM",
      "type": "text",
      "text": "Can you check my delivery window?",
      "direction": "inbound",
      "sent_at": "2026-07-14T02:14:58Z"
    }
  }
}

以上係事件結構示例。啟用簽章之後，要喺處理事件之前使用 signing_secret 同 X-Device-Timestamp，按原始 request body 驗證 X-Device-Signature。Webhook 投遞參考記錄咗 HMAC-SHA256 嘅輸入格式同投遞行為。

呢個係畀需要一般帳號入站接入，或者要將多個訊息渠道放入同一隊列嘅團隊所用嘅另一種整合方式；如果訊息仍然經 Meta 官方平台發送，就唔會因此免除官方收費。

限制同取捨

如果你需要已核准範本、官方推廣工具、Meta 原生分析、Click-to-WhatsApp 歸因，或者 Business Solution Provider 提供嘅託管支援，官方 WhatsApp Business Platform 會較合適。只要工作流程仲有任何一段使用官方平台，就應該保留官方計費量度方案。

UnifyPort 唔會取代 WhatsApp 政策合規、官方推廣功能或者 Meta 帳單記錄，其非官方接口亦唔會提供 Meta Pricing Analytics 類別。使用混合架構時，要維護獨立帳目，並清楚標示每條出站路徑。

常見問題

2026 年 10 月 1 日後，WhatsApp service message 點樣收費？

Meta 會按每條已送達嘅 service message 收費，唔係按一次對話收費。要計每條被歸類做 service 嘅企業回覆，而唔係計 24 小時客戶服務時段嘅數目。

用邊個 Pricing Analytics 類別先可以追蹤 service message 收費？

使用 pricing_type: REGULAR 同 pricing_category: SERVICE，再按電話號碼、國家或地區同報表時段，拆分回傳嘅 volume 同 cost。

2026 年 7 月可唔可以計到 10 月嘅最終收費？

而家可以先量度訊息量同建立計算模型，但最終費率仲未鎖定。Meta 表示會喺 2026 年 9 月 1 日前公布 10 月 1 日生效嘅費率。

WhatsApp service message 有無 volume-tier 折扣？

無。Meta 嘅更新指出 service message 無 volume tiers；utility 同 authentication message 就繼續沿用各自嘅級距規則。

72 小時免費入口時段仲係咪免費？

訊息送達仍然免費。Meta 表示有效嘅 72 小時免費入口時段唔收訊息送達費，但 Meta Business Agent 嘅 token 用量仍然可能另外計費。

下一步

如果你正喺官方計費模型以外評估統一入站路徑，可以跟住 UnifyPort Quickstart先測試一條有簽章嘅 message.received 事件，再調整正式環境路由。

資料來源