← 所有文章
指南

LINE MINI App 7 月 1 日开始收费：把支付流程和入站客服拆开

如果你的团队用 LINE 做客户运营，LINE 7 月 1 日的更新很容易被误读。官方更新讲的是 LINE MINI App 应用内购买：从 2026 年 7 月的使用量开始收取服务费，同时修订应用内购买条款，明确费用计算、结算和付款方式。

这对在 LINE 里做内容或服务销售的团队很重要。但它不代表所有 LINE 客服流程都要变成 MINI App 项目，更不代表客户消息应该经过支付栈。若你的目标只是接收 LINE 消息、路由到客服、再从正确账号回复，就应该把这条路径和应用内购买拆开。

小团队真正要回答的问题不是“要不要把所有东西都做进 LINE”，而是“哪个 LINE 能力负责哪件事”。支付、数字商品、分析和入站客服有不同的审批路径、成本结构和故障模式。把它们塞进同一个集成，只会增加不必要的工程负担。

7 月 1 日具体变了什么

LINE 宣布，从 2026 年 7 月起，LINE MINI App 应用内购买功能开始按使用收取服务费。官方同时说明，适用费率以申请时指定的费率为准。

这个能力本身很明确。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 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，对时间戳、一个点号和原始请求体计算 HMAC-SHA256 后得到的十六进制值。

回复路径仍然明确。客服后端可以通过 POST /v1/messages，带上目标 account_id、接收方和消息内容发起回复。入站客服循环不需要知道客户是从 MINI App、rich menu、二维码还是普通 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 可以作为你自己系统里的元数据存在，不应该成为消息传输层。

当客户发来“我已经付款了，但还需要改配送时间”时，客服系统不应该先确认支付流程是否成功才能记录消息。它应该先接收、路由，再让客服或自动化逻辑单独查询订单。

LINE 7 月 1 日的收费更新提醒我们：平台支付表面有自己的成本和控制规则。销售 LINE 内数字内容时使用它；处理入站客户会话时，则保持事件驱动、签名校验，并与支付栈独立。