LINE MINI App bắt đầu tính phí từ 1/7: tách thanh toán khỏi hỗ trợ inbound

Cập nhật ngày 1/7 của LINE rất dễ bị hiểu sai nếu đội của bạn dùng LINE cho vận hành khách hàng. Nội dung chính là LINE MINI App in-app purchase: phí dịch vụ bắt đầu áp dụng cho phần sử dụng từ tháng 7/2026, và LINE đã sửa điều khoản in-app purchase để làm rõ cách tính phí, quyết toán và phương thức thanh toán.

Điều này quan trọng với các đội bán nội dung số trong LINE. Nhưng nó không có nghĩa là mọi workflow hỗ trợ trên LINE đều phải trở thành dự án MINI App. Nó cũng không có nghĩa là tin nhắn khách hàng phải đi qua payment stack. Nếu bạn chỉ cần nhận tin nhắn LINE, đưa vào support queue và trả lời từ đúng tài khoản, hãy giữ đường đi đó tách biệt khỏi in-app purchase.

Câu hỏi thực tế cho một đội nhỏ không phải là “có nên xây mọi thứ bên trong LINE không?” Câu hỏi đúng là “mỗi bề mặt LINE chịu trách nhiệm cho việc gì?” Thanh toán, hàng hóa số, analytics và inbound support có luồng duyệt, chi phí vận hành và kiểu lỗi khác nhau. Gộp tất cả vào một integration chỉ làm hệ thống nặng hơn.

Ngày 1/7 đã thay đổi gì

LINE thông báo rằng phí dịch vụ hiện áp dụng cho tính năng in-app purchase của LINE MINI App, tính trên usage từ tháng 7/2026 trở đi. LINE cũng nói rằng mức phí áp dụng là mức đã được chỉ định tại thời điểm đăng ký.

Tính năng này khá cụ thể. Tài liệu của LINE mô tả in-app purchase là hệ thống cho phép người dùng mua nội dung số trong verified MINI Apps. Nó dùng cơ chế thanh toán của App Store và Google Play, cung cấp xác minh thanh toán và notification qua LINE Platform, client được triển khai bằng LIFF SDK, còn server-side integration dùng webhooks.

Quy trình bắt đầu cũng phức tạp hơn một webhook thông thường. Đội phải đăng ký trong LINE Developers Console, được phê duyệt, đăng ký webhook URL và tester cho test payment, tích hợp tính năng mua hàng trong Developing channel, chạy test payment, gửi verification review, rồi mới phát hành verified MINI App có bật in-app purchase.

Điều kiện sử dụng khá hẹp. MINI App phải có cả “Region to provide the service” và “Company or owner’s country or region” đặt là Japan. Khi dùng production, app phải là verified LINE MINI App, mở trong LIFF browser, dùng LIFF SDK 2.26.0 trở lên, và người dùng phải có số điện thoại Nhật trong LINE với phiên bản LINE 15.6.0 trở lên.

Đây là bề mặt hợp lý để bán nội dung số đã được duyệt trong LINE MINI App tại Nhật. Nhưng nó không phải đường ngắn nhất để có support inbox.

Payment Webhook không phải Support Webhook

Từ “webhook” xuất hiện ở cả hai thế giới, nên nhiều đội dễ trộn lẫn.

Trong flow in-app purchase của LINE MINI App, webhook là một phần của hệ thống thanh toán. MINI App server đặt trước giao dịch, nhận webhook liên quan đến purchase, xác nhận purchase completion và cấp vật phẩm số. Đường đi này phục vụ ghi nhận doanh thu, entitlement, refund và compliance.

Customer support có hình dạng khác. Event bạn cần không phải “purchase completed” mà là “customer sent a message”. Dữ liệu cần gồm account nhận tin, sender, conversation, message type, text hoặc media và timestamp. Event này phải vào support queue ngay, kể cả khi payment job, analytics job hoặc MINI App review bị chậm.

Với đội chỉ cần LINE inbound support, payment webhook là abstraction sai. Nó khiến support path phụ thuộc vào commerce channel, quy trình duyệt MINI App ở Nhật, quy tắc thanh toán của app store và logic settlement phí, trong khi đội support có thể chưa cần bất kỳ thứ nào trong đó.

Đường inbound với UnifyPort

UnifyPort tách riêng đường đi của customer message. Tin nhắn LINE đến dưới dạng event webhook chuẩn message.received, được gửi bằng HTTP POST tới endpoint bạn đăng ký. Cùng một envelope được dùng cho các kênh được hỗ trợ: id, type, provider, account_id, occurred_at và data.

Một inbound text event của LINE có thể trông như sau:

{
  "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 có thể subscribe message.received, hoặc dùng ["*"] để nhận toàn bộ standard event catalogue. Nếu bật signing, mỗi delivery có X-Device-Timestamp và X-Device-Signature. Signature là hex HMAC-SHA256 của timestamp, dấu chấm và raw request body, được ký bằng signing_secret của endpoint.

Reply path vẫn rõ ràng. Support backend có thể gọi POST /v1/messages với account_id, người nhận và message body. Inbound support loop không cần biết khách đến từ MINI App, rich menu, QR code hay LINE chat thông thường.

Cách tách sạch hơn cho đội nhỏ

Nếu bạn đang xây LINE MINI App bán nội dung số ở Nhật, hãy dùng official in-app purchase flow. Nó sở hữu payment review, app store transaction, purchase verification và settlement reporting. Stack này cần cẩn trọng, audit được và gắn với finance.

Nếu bạn đang xây customer operations, hãy dùng event-driven inbound layer. Nó sở hữu message receipt, routing, deduplication, handoff sang Slack hoặc CRM và reply handling. Stack này cần nhanh, ổn định và có thể tái sử dụng cho nhiều kênh.

Cách tách có thể đơn giản:

Công việc	Chủ sở hữu phù hợp	Thời điểm
Mua nội dung số	LINE MINI App in-app purchase	Trong checkout
Xác minh purchase	MINI App server và LINE payment webhook	Payment lifecycle
Tin nhắn khách hàng live	UnifyPort message.received webhook	Event tức thời
Support reply	POST /v1/messages	Agent hoặc workflow action
Cross-channel routing	UnifyPort standard event envelope	Cùng handler cho mọi provider

Mô hình này cũng hợp với đội cross-border. LINE MINI App in-app purchase hiện gắn với điều kiện Nhật Bản. Support queue thì thường không chỉ phục vụ một thị trường. Đội có thể cần LINE ở Nhật và Thái Lan, Zalo ở Việt Nam, WhatsApp ở Hong Kong hoặc Singapore, và Telegram cho nhóm khách hàng kỹ thuật. Một inbound schema giúp queue không biến thành một integration riêng cho từng thị trường.

Nên xây gì bây giờ

Trước hết, hãy xác định project của bạn là commerce surface hay messaging operations surface.

Nếu là commerce, đọc tài liệu LINE MINI App in-app purchase, xác nhận yêu cầu tại Nhật, đăng ký qua LINE Developers Console, dự trù phí dịch vụ và xây payment webhook như một finance-critical path. Đừng trộn nó với support routing code.

Nếu là support, đăng ký UnifyPort webhook endpoint với signing_secret, subscribe message.received, xác minh X-Device-Signature, lưu event và route theo provider, account_id, data.conversation.id, data.sender.id và data.message.type. Payment ID hoặc order ID nên là metadata trong hệ thống của bạn, không phải transport layer.

Khi khách nhắn “Tôi đã thanh toán trong app nhưng cần đổi giờ giao hàng”, hệ thống support không nên chờ payment flow xác nhận thành công mới ghi nhận tin nhắn. Nó nên nhận event, route event, rồi để agent hoặc automation tra cứu đơn hàng ở bước riêng.

Cập nhật phí ngày 1/7 của LINE là lời nhắc rõ ràng: platform payment surface có chi phí và cơ chế kiểm soát riêng. Dùng nó khi bạn bán nội dung số trong LINE. Với inbound customer conversations, hãy giữ đường đi event-driven, có chữ ký và độc lập với payment stack.