← 所有文章
指南

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 browser 內打開；LIFF SDK 要係 2.26.0 或以上；使用者亦要喺 LINE 帳號登記日本手機號碼，並使用 LINE 15.6.0 或以上版本。

呢套能力適合喺日本 LINE MINI App 內銷售經批准嘅數碼內容，但唔係建立客服 inbox 嘅最短路徑。

付款 Webhook 唔係客服 Webhook

「webhook」呢個詞同時出現喺兩個世界，所以團隊好容易混淆。

喺 LINE MINI App 應用內購買流程入面，webhook 屬於付款系統。MINI App server 會預留購買、接收購買相關 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，對時間戳、一個句點同原始 request body 計算 HMAC-SHA256 後得出嘅十六進位值。

回覆路徑仍然清晰。客服後端可以透過 POST /v1/messages，帶上目標 account_id、收件人同訊息內容回覆。入站客服循環唔需要知道客戶係由 MINI App、rich menu、QR code，定普通 LINE chat 入嚟。

小團隊更乾淨嘅拆法

如果你正喺日本做銷售數碼內容嘅 LINE MINI App，就使用官方應用內購買流程。佢負責付款審核、應用商店交易、購買驗證同結算報表。呢條堆疊應該謹慎、可審計，並同財務流程綁定。

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

可以咁拆：

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

呢個模型亦更適合跨境團隊。LINE MINI App 應用內購買目前綁定日本條件，但客服隊列通常唔會只服務單一市場。團隊可能喺日本同泰國接 LINE，喺越南接 Zalo，喺香港或新加坡接 WhatsApp，亦要為 developer 客戶接 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 內銷售數碼內容時使用佢；處理入站客戶對話時，保持事件驅動、簽名驗證，並同付款堆疊獨立。