LINE MINI App Fees Started July 1: Keep Payments Separate From Inbound Support

LINE’s July 1 update is easy to misread if your team uses LINE for customer operations. The headline is about LINE MINI App in-app purchases: service fees now apply to usage from July 2026 onward, and LINE revised the in-app purchase terms to clarify fee calculation, settlement, and payment methods.

That matters for teams building commerce inside LINE. It does not mean every LINE support workflow needs to become a MINI App project, and it definitely does not mean customer messages should be routed through a purchase stack. If all you need is to receive LINE messages, route them to support, and reply from the right account, keep that path separate from in-app purchases.

The practical question for a small team is no longer “Should we build everything inside LINE?” It is “Which LINE surface owns each job?” Payments, digital goods, analytics, and inbound support have different approval paths, operating costs, and failure modes. Treating them as one integration creates unnecessary work.

What Changed On July 1

LINE announced that service fees are now charged for the LINE MINI App in-app purchase feature for usage from July 2026 onward. LINE also says the applicable fee rate is the rate specified at the time of application.

The feature itself is specific. LINE’s in-app purchase documentation describes it as a way for users to purchase digital content inside verified MINI Apps. It uses App Store and Google Play payment mechanisms, provides payment verification and notification functions through the LINE Platform, implements the client through the LIFF SDK, and performs server-side integration using webhooks.

The start flow is also more involved than a simple webhook integration. A team applies through the LINE Developers Console, gets approval, registers a webhook URL and test payment testers, integrates the purchase feature in a Developing channel, performs test payments, applies for verification review, and then releases the verified MINI App with in-app purchase enabled.

The eligibility rules are narrow. The MINI App must have both its service region and company or owner country/region set to Japan. The app must be a verified LINE MINI App for production usage, run through the LIFF browser, use LIFF SDK 2.26.0 or later, and the user must have a Japanese phone number with LINE version 15.6.0 or later.

That is a reasonable product surface for selling approved digital content inside a Japanese LINE MINI App. It is not the shortest path to a support inbox.

Payment Webhooks Are Not Support Webhooks

The word “webhook” appears in both worlds, which is where teams get tangled.

In the LINE MINI App in-app purchase flow, the webhook is part of a payment system. Your MINI App server reserves purchases, receives purchase-related webhook events, confirms purchase completion, and grants the digital item. That webhook belongs to revenue recognition, entitlement, refund handling, and compliance.

Customer support has a different shape. The event you care about is not “a purchase was completed.” It is “a customer sent a message.” The data you need is the account that received it, the sender, the conversation, the message type, the text or media, and the timestamp. That event should land in a support queue immediately, even if a payment job, analytics job, or MINI App review is delayed.

For teams that only need inbound LINE support, a purchase webhook is the wrong abstraction. It makes the support path depend on a commerce channel, a Japanese MINI App approval surface, app store payment rules, and fee settlement logic that the support team may not need at all.

The Inbound Path With UnifyPort

UnifyPort keeps the customer-message path separate. A LINE message arrives as a standard message.received webhook event, delivered by HTTP POST to the endpoint you register. The same envelope is used across supported channels: id, type, provider, account_id, occurred_at, and data.

An inbound LINE text event can look like this:

{
  "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" }
  }
}

The webhook endpoint can subscribe to message.received or use ["*"] for the full standard event catalogue. If signing is enabled, each delivery includes X-Device-Timestamp and X-Device-Signature. The signature is the hex HMAC-SHA256 of the timestamp, a dot, and the raw request body, signed with the endpoint’s signing_secret.

Replies remain explicit. Your support backend can send a response through POST /v1/messages with the target account_id, recipient, and message body. The inbound support loop does not need to know whether the customer came from a MINI App, a rich menu, a QR code, or a normal LINE chat.

A Cleaner Split For Small Teams

If you are building a LINE MINI App that sells digital content in Japan, keep the official in-app purchase flow. It owns payment review, app store transaction handling, purchase verification, and settlement reporting. That stack should be careful, auditable, and tied to finance.

If you are building customer operations, use an event-driven inbound layer. It owns message receipt, routing, deduplication, handoff to Slack or CRM, and reply handling. That stack should be fast, available, and easy to reuse across channels.

The split can be simple:

Job	Best owner	Timing
Digital content purchase	LINE MINI App in-app purchase	During checkout
Purchase verification	MINI App server and LINE payment webhook	Payment lifecycle
Live customer message	UnifyPort message.received webhook	Immediate event
Support reply	POST /v1/messages	Agent or workflow action
Cross-channel routing	UnifyPort standard event envelope	Same handler for each provider

This model also helps when the team expands beyond Japan. LINE MINI App in-app purchase is tied to Japan-specific conditions today. A support queue usually is not. The same customer operations team may need LINE in Japan and Thailand, Zalo in Vietnam, WhatsApp in Hong Kong or Singapore, and Telegram for developer-heavy customers. One inbound schema keeps that queue from turning into one integration per market.

What To Build Now

Start by deciding whether your project is a commerce surface or a messaging operations surface.

If it is commerce, read the LINE MINI App in-app purchase documentation, confirm the Japan requirements, apply through the LINE Developers Console, budget for service fees, and build the payment webhook as a finance-critical path. Do not mix that code with support routing.

If it is support, register a UnifyPort webhook endpoint with a signing_secret, subscribe to message.received, verify X-Device-Signature, store the event, and route by provider, account_id, data.conversation.id, data.sender.id, and data.message.type. Keep any payment IDs or order IDs as metadata inside your own system, not as the transport layer.

When a customer writes “I paid but need help,” the support system should not be forced to ask whether the payment flow succeeded before it can record the message. It should receive the message, route it, and let the agent or automation look up the order as a separate step.

LINE’s July 1 fee update is a useful reminder: platform payment surfaces have their own costs and controls. Use them when you are selling digital content inside LINE. For inbound customer conversations, keep the path event-driven, signed, and independent from the payment stack.