Комиссии LINE MINI App вступили в силу 1 июля: отделите платежи от входящей поддержки

Обновление LINE от 1 июля легко понять неправильно, если ваша команда использует LINE для поддержки клиентов. Речь идет о встроенных покупках в LINE MINI App: с использования за июль 2026 года начинают применяться сервисные комиссии, а условия in-app purchase были обновлены, чтобы уточнить расчет комиссий, расчеты и способы выплаты.

Это важно для команд, которые продают цифровой контент внутри LINE. Но это не значит, что каждый сценарий поддержки в LINE должен становиться проектом MINI App. И это точно не значит, что сообщения клиентов нужно пропускать через платежный контур. Если вам нужно получать сообщения LINE, направлять их в поддержку и отвечать с нужного аккаунта, держите этот путь отдельно от встроенных покупок.

Практический вопрос для небольшой команды звучит не так: «строить ли все внутри LINE?» Правильный вопрос: «какая поверхность LINE отвечает за какую работу?» Платежи, цифровые товары, аналитика и входящая поддержка имеют разные проверки, затраты и режимы отказа. Один общий интеграционный слой делает систему тяжелее, чем нужно.

Что изменилось 1 июля

LINE объявила, что сервисные комиссии теперь применяются к встроенным покупкам LINE MINI App начиная с использования за июль 2026 года. Применяемая ставка комиссии определяется ставкой, указанной при подаче заявки.

Сама функция довольно конкретна. Документация LINE описывает in-app purchase как систему, позволяющую пользователям покупать цифровой контент внутри проверенных MINI Apps. Она использует платежные механизмы App Store и Google Play, дает функции проверки платежей и уведомлений через LINE Platform, реализует клиент через LIFF SDK, а серверную интеграцию выполняет через webhooks.

Путь запуска тоже сложнее, чем простая настройка webhook. Команда подает заявку в LINE Developers Console, получает одобрение, регистрирует webhook URL и тестировщиков платежей, интегрирует покупку в Developing channel, проводит тестовые платежи, отправляет приложение на проверку и только затем выпускает проверенный MINI App с включенными встроенными покупками.

Условия узкие. У MINI App регион предоставления сервиса и страна или регион компании либо владельца должны быть установлены как Japan. Для production это должен быть проверенный LINE MINI App, открываемый в LIFF browser, с LIFF SDK 2.26.0 или выше. Пользователь должен иметь японский номер телефона в LINE и версию LINE 15.6.0 или выше.

Это подходящая поверхность для продажи одобренного цифрового контента внутри японского LINE MINI App. Но это не самый короткий путь к inbox для поддержки.

Платежный Webhook не равен Support Webhook

Слово webhook встречается в обоих мирах, из-за чего команды часто смешивают контуры.

В сценарии LINE MINI App in-app purchase webhook является частью платежной системы. Сервер MINI App резервирует покупку, получает события о покупке, подтверждает завершение и выдает цифровой предмет. Этот путь нужен для признания выручки, выдачи прав, возвратов и compliance.

Поддержка клиентов устроена иначе. Вам важно не событие «покупка завершена», а событие «клиент отправил сообщение». Нужны аккаунт-получатель, отправитель, разговор, тип сообщения, текст или медиа и время. Такое событие должно попасть в очередь поддержки сразу, даже если платежный job, аналитика или проверка MINI App задержались.

Если команде нужна только входящая поддержка LINE, платежный webhook является неверной абстракцией. Он привязывает поддержку к commerce channel, японской проверке MINI App, правилам App Store и Google Play и логике расчетов комиссий, которые могут вообще не относиться к текущей задаче поддержки.

Входящий путь через UnifyPort

UnifyPort отделяет путь клиентских сообщений. Сообщение LINE приходит как стандартное webhook-событие message.received, доставленное HTTP POST на зарегистрированный endpoint. Для поддерживаемых каналов используется одна envelope-структура: 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 endpoint может подписаться на message.received или использовать ["*"] для полного каталога стандартных событий. Если включена подпись, каждая доставка содержит X-Device-Timestamp и X-Device-Signature. Подпись — это hex HMAC-SHA256 от timestamp, точки и raw request body, подписанный signing_secret этого endpoint.

Ответы остаются явными. Backend поддержки вызывает POST /v1/messages, указывая целевой account_id, получателя и тело сообщения. Входящий цикл поддержки не должен знать, пришел ли клиент из MINI App, rich menu, QR code или обычного LINE chat.

Более чистое разделение для небольших команд

Если вы строите LINE MINI App для продажи цифрового контента в Японии, используйте официальный in-app purchase flow. Он отвечает за платежную проверку, транзакции app store, подтверждение покупки и отчетность по расчетам. Этот стек должен быть осторожным, аудируемым и связанным с финансами.

Если вы строите customer operations, используйте событийный входящий слой. Он отвечает за прием сообщений, routing, дедупликацию, передачу в Slack или CRM и обработку ответов. Этот стек должен быть быстрым, доступным и переиспользуемым между каналами.

Разделение может быть простым:

Задача	Лучший владелец	Время
Покупка цифрового контента	LINE MINI App in-app purchase	Во время checkout
Проверка покупки	Сервер MINI App и платежный webhook LINE	Жизненный цикл платежа
Живое сообщение клиента	UnifyPort message.received webhook	Мгновенное событие
Ответ поддержки	POST /v1/messages	Действие агента или workflow
Cross-channel routing	Стандартная envelope UnifyPort	Один handler для каждого provider

Такая модель помогает и при расширении за пределы Японии. LINE MINI App in-app purchase сегодня привязан к японским условиям. Очередь поддержки обычно не привязана к одному рынку. Команде могут понадобиться LINE в Японии и Таиланде, Zalo во Вьетнаме, WhatsApp в Гонконге или Сингапуре и Telegram для технической аудитории. Единая входящая schema не дает очереди превратиться в отдельную интеграцию для каждого рынка.

Что строить сейчас

Сначала решите, ваш проект является commerce surface или messaging operations surface.

Если это commerce, изучите документацию LINE MINI App in-app purchase, подтвердите японские требования, подайте заявку через LINE Developers Console, заложите бюджет на сервисные комиссии и стройте платежный webhook как финансово критичный путь. Не смешивайте его с routing кодом поддержки.

Если это поддержка, зарегистрируйте UnifyPort webhook endpoint с signing_secret, подпишитесь на message.received, проверяйте X-Device-Signature, сохраняйте событие и маршрутизируйте по provider, account_id, data.conversation.id, data.sender.id и data.message.type. Payment ID и order ID лучше хранить как metadata в вашей системе, а не превращать в транспортный слой.

Когда клиент пишет: «Я оплатил в приложении, но хочу изменить время доставки», система поддержки не должна ждать успешной проверки платежного flow, чтобы записать сообщение. Она должна принять событие, отправить его в нужную очередь, а заказ можно посмотреть отдельным шагом.

Обновление LINE от 1 июля напоминает: платежные поверхности платформ имеют собственные комиссии и контрольные правила. Используйте их, когда продаете цифровой контент внутри LINE. Для входящих клиентских разговоров держите путь событийным, подписанным и независимым от платежного стека.