← 所有文章
指南

LINE MINI App 7 月 1 日開始收費：把付款流程和入站客服拆開

如果你的團隊用 LINE 做客戶營運，LINE 7 月 1 日的更新很容易被誤讀。這次官方更新談的是 LINE MINI App 應用內購買：自 2026 年 7 月的使用量起開始收取服務費，並修訂應用內購買條款，以釐清費用計算、結算與付款方式。

這對在 LINE 裡銷售數位內容或服務的團隊很重要。但它不代表所有 LINE 客服流程都要變成 MINI App 專案，也不代表客戶訊息應該進入付款堆疊。若你的需求只是接收 LINE 訊息、路由到客服，再從正確帳號回覆，這條路徑應該和應用內購買分開。

小團隊真正要判斷的是：哪個 LINE 表面負責哪件事。付款、數位商品、分析與入站客服，各自有不同的審核流程、成本結構與故障模式。把它們做成同一個整合，只會讓系統更重。

7 月 1 日改了什麼

LINE 宣布，LINE MINI App 應用內購買功能自 2026 年 7 月起按使用量收取服務費。官方也說明，適用費率以申請時指定的費率為準。

這項能力本身很具體。LINE 的應用內購買文件說明，使用者可以在已驗證的 MINI App 內購買數位內容。它使用 App Store 和 Google Play 的付款機制，透過 LINE Platform 提供付款驗證與通知功能，客戶端以 LIFF SDK 實作，伺服器端則透過 webhook 整合。

啟用流程也不只是設定一個 webhook。團隊需要在 LINE Developers Console 提出申請，通過後登錄 webhook URL 和測試付款人員，在 Developing channel 整合購買功能並完成測試付款，接著提交驗證審核，最後發布啟用應用內購買的已驗證 MINI App。

條件也很窄。MINI App 的服務區域與公司或所有者國家/地區都必須設為日本；正式使用需要是已驗證的 LINE MINI App；必須在 LIFF 瀏覽器內開啟；LIFF SDK 需為 2.26.0 或以上；使用者也要在 LINE 帳號中登錄日本手機號碼，並使用 LINE 15.6.0 或以上版本。

這是適合在日本 LINE MINI App 內銷售經核准數位內容的產品表面，但不是建立客服收件匣的最短路徑。

付款 Webhook 不是客服 Webhook

「webhook」這個詞同時出現在兩個世界，因此團隊容易混淆。

在 LINE MINI App 應用內購買流程裡，webhook 屬於付款系統。MINI App 伺服器會預留購買、接收購買相關 webhook、確認購買完成，並發放數位商品。這條鏈路服務於收入確認、權益發放、退款處理和合規。

客服訊息是另一種形狀。你關心的事件不是「購買完成」，而是「客戶發來訊息」。你需要的是接收訊息的帳號、傳送者、對話、訊息類型、文字或媒體內容，以及時間戳。這個事件應該立即進入客服佇列，即使付款作業、分析作業或 MINI App 審核延遲，也不該被阻塞。

對只需要 LINE 入站客服的團隊來說，付款 webhook 是錯誤抽象。它會讓客服路徑依賴商務渠道、日本 MINI App 審核、應用商店付款規則，以及服務費結算邏輯，而這些可能不是客服團隊要解的問題。

使用 UnifyPort 的入站路徑

UnifyPort 會把客戶訊息路徑獨立出來。LINE 訊息會以標準 message.received webhook 事件，透過 HTTP POST 投遞到你登錄的端點。支援的平台共用同一組事件信封：id、type、provider、account_id、occurred_at 和 data。

一則 LINE 入站文字事件可以長這樣：

{
  "id": "evt_7c41a2f90b",
  "type": "message.received",
  "provider": "line",
  "account_id": "acc_8c21d0",
  "occurred_at": "2026-07-07T02:30:00Z",
  "data": {
    "conversation": { "id": "U9d3f51a2", "type": "user" },
    "sender": { "id": "U9d3f51a2", "type": "user", "name": "Mika Tanaka" },
    "message": {
      "id": "msg_20260707_001",
      "type": "text",
      "text": "I paid in the app but still need help changing my delivery time.",
      "direction": "inbound",
      "sent_at": "2026-07-07T02:29:59Z"
    },
    "event": { "kind": "message_received" }
  }
}

webhook 端點可以訂閱 message.received，也可以用 ["*"] 訂閱完整標準事件目錄。如果啟用簽名，每次投遞會包含 X-Device-Timestamp 和 X-Device-Signature。簽名是使用端點的 signing_secret，對時間戳、一個句點和原始請求 body 計算 HMAC-SHA256 後得到的十六進位值。

回覆路徑仍然明確。客服後端可以透過 POST /v1/messages，帶上目標 account_id、收件人與訊息內容來回覆。入站客服循環不需要知道客戶來自 MINI App、rich menu、QR code，還是一般 LINE 聊天。

小團隊更乾淨的拆分方式

如果你正在做一個面向日本、銷售數位內容的 LINE MINI App，就使用官方應用內購買流程。它負責付款審核、應用商店交易、購買驗證與結算報表。這條堆疊應該謹慎、可稽核，並與財務流程綁定。

如果你正在做客戶營運，就使用事件驅動的入站層。它負責訊息接收、路由、去重、流轉到 Slack 或 CRM，以及回覆處理。這條堆疊應該快速、穩定，並能重用到其他渠道。

可以這樣拆：

工作最適合的負責方時機
數位內容購買LINE MINI App 應用內購買結帳過程
購買驗證MINI App 伺服器與 LINE 付款 webhook付款生命週期
即時客戶訊息UnifyPort message.received webhook即時事件
客服回覆POST /v1/messages人工或工作流程動作
跨渠道路由UnifyPort 標準事件信封各平台共用同一 handler

這個模型也更適合跨境團隊。LINE MINI App 應用內購買目前綁定日本條件，但客服佇列通常不會只服務單一市場。團隊可能在日本與泰國接 LINE，在越南接 Zalo，在香港或新加坡接 WhatsApp，還要為開發者客戶接 Telegram。同一套入站 schema 能避免每個市場都變成一套新整合。

現在該怎麼建

先判斷你的專案是商務表面，還是訊息營運表面。

如果是商務表面，就閱讀 LINE MINI App 應用內購買文件，確認日本相關條件，透過 LINE Developers Console 申請，預留服務費預算，並把付款 webhook 當作財務關鍵路徑來建。不要和客服路由程式碼混在一起。

如果是客服表面，就登錄一個帶 signing_secret 的 UnifyPort webhook 端點，訂閱 message.received，驗證 X-Device-Signature，保存事件，並依 provider、account_id、data.conversation.id、data.sender.id 和 data.message.type 路由。付款 ID 或訂單 ID 可以留在你自己的系統中作為 metadata，不應成為訊息傳輸層。

當客戶寫來「我已付款，但需要改配送時間」時，客服系統不應先確認付款流程是否成功才記錄訊息。它應該先接收、路由，再讓客服或自動化流程查訂單。

LINE 7 月 1 日的收費更新提醒我們：平台付款表面有自己的成本與控制規則。銷售 LINE 內數位內容時使用它；處理入站客戶會話時，保持事件驅動、簽名驗證，並與付款堆疊獨立。