ค่าธรรมเนียม LINE MINI App เริ่ม 1 กรกฎาคม: แยก payment flow ออกจาก inbound support

อัปเดตวันที่ 1 กรกฎาคมของ LINE อาจทำให้ทีมที่ใช้ LINE เป็นช่องทางดูแลลูกค้าเข้าใจผิดได้ง่าย ประเด็นหลักคือ LINE MINI App in-app purchase: LINE เริ่มคิด service fee สำหรับ usage ตั้งแต่กรกฎาคม 2026 เป็นต้นไป และปรับ terms ของ in-app purchase เพื่ออธิบายการคำนวณ fee, settlement และ payment method ให้ชัดขึ้น

เรื่องนี้สำคัญสำหรับทีมที่ขาย digital content ภายใน LINE แต่ไม่ได้แปลว่า workflow support บน LINE ทุกอย่างต้องกลายเป็นโปรเจกต์ MINI App และไม่ได้แปลว่าข้อความจากลูกค้าควรผ่าน payment stack ถ้าคุณแค่ต้องรับ LINE messages, route เข้า support และตอบกลับจาก account ที่ถูกต้อง ให้แยก path นี้ออกจาก in-app purchase

คำถามจริงสำหรับทีมเล็กไม่ใช่ “ควรสร้างทุกอย่างใน LINE ไหม” แต่คือ “surface ไหนของ LINE ควรรับผิดชอบงานไหน” Payment, digital goods, analytics และ inbound support มี approval path, operating cost และ failure mode ต่างกัน การรวมทั้งหมดเป็น integration เดียวทำให้ระบบซับซ้อนเกินจำเป็น

วันที่ 1 กรกฎาคมเปลี่ยนอะไร

LINE ประกาศว่า service fee จะถูกคิดกับฟีเจอร์ in-app purchase ของ LINE MINI App สำหรับ usage ตั้งแต่กรกฎาคม 2026 เป็นต้นไป LINE ยังระบุว่า fee rate ที่ใช้คือ rate ที่กำหนดตอนสมัครใช้บริการ

ตัวฟีเจอร์มีขอบเขตชัดเจน เอกสารของ LINE อธิบายว่า in-app purchase คือระบบที่ให้ผู้ใช้ซื้อ digital content ภายใน verified MINI Apps ใช้กลไก payment ของ App Store และ Google Play, มี payment verification และ notification ผ่าน LINE Platform, implement client ด้วย LIFF SDK และทำ server-side integration ผ่าน webhooks

ขั้นตอนเริ่มใช้ก็ไม่ใช่แค่ตั้ง webhook หนึ่งตัว ทีมต้องสมัครผ่าน LINE Developers Console, ได้รับ approval, ลงทะเบียน webhook URL และ tester สำหรับ test payment, integrate ฟีเจอร์ purchase ใน Developing channel, ทำ test payment, ขอ verification review แล้วจึง release verified MINI App ที่เปิดใช้ in-app purchase

เงื่อนไขค่อนข้างแคบ MINI App ต้องตั้งทั้ง “Region to provide the service” และ “Company or owner’s country or region” เป็น Japan ใน production ต้องเป็น verified LINE MINI App, เปิดใน LIFF browser, ใช้ LIFF SDK 2.26.0 ขึ้นไป และผู้ใช้ต้องมีหมายเลขโทรศัพท์ญี่ปุ่นใน LINE พร้อม LINE version 15.6.0 ขึ้นไป

นี่เป็น surface ที่เหมาะสำหรับการขาย digital content ที่ได้รับอนุมัติใน LINE MINI App ของญี่ปุ่น แต่ไม่ใช่ทางลัดที่สุดสำหรับสร้าง support inbox

Payment Webhook ไม่ใช่ Support Webhook

คำว่า webhook อยู่ทั้งสองโลก ทำให้ทีมมักเอามาปนกัน

ใน flow in-app purchase ของ LINE MINI App, webhook เป็นส่วนหนึ่งของระบบ payment ฝั่ง MINI App server จะ reserve purchase, รับ webhook event ที่เกี่ยวกับ purchase, confirm purchase completion และ grant digital item เส้นทางนี้เกี่ยวกับ revenue recognition, entitlement, refund และ compliance

Customer support มีรูปแบบต่างออกไป Event ที่คุณต้องการไม่ใช่ “purchase completed” แต่คือ “customer sent a message” ข้อมูลที่ต้องใช้คือ account ที่รับข้อความ, sender, conversation, message type, text หรือ media และ timestamp Event นี้ควรเข้า support queue ทันที แม้ payment job, analytics job หรือ MINI App review จะล่าช้า

สำหรับทีมที่ต้องการแค่ LINE inbound support, payment webhook เป็น abstraction ที่ผิด มันทำให้ support path ไปผูกกับ commerce channel, review surface ของ MINI App ในญี่ปุ่น, กฎ payment ของ app store และ logic settlement fee ซึ่งอาจไม่ใช่สิ่งที่ทีม support ต้องการเลย

Inbound Path ด้วย UnifyPort

UnifyPort แยกเส้นทาง customer message ออกมา LINE message จะมาถึงเป็น webhook event มาตรฐาน message.received โดยส่ง HTTP POST ไปยัง endpoint ที่คุณลงทะเบียนไว้ Envelope เดียวกันใช้ข้าม supported channels: id, type, provider, account_id, occurred_at และ data

Inbound LINE text event อาจมีหน้าตาแบบนี้:

{
  "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 สามารถ subscribe message.received หรือใช้ ["*"] เพื่อรับ standard event catalogue ทั้งหมด หากเปิด signing ทุก delivery จะมี X-Device-Timestamp และ X-Device-Signature Signature คือ hex HMAC-SHA256 ของ timestamp, จุด และ raw request body โดยใช้ signing_secret ของ endpoint

Reply path ยังชัดเจน Support backend สามารถเรียก POST /v1/messages พร้อม target account_id, recipient และ message body ได้ Inbound support loop ไม่จำเป็นต้องรู้ว่าลูกค้ามาจาก MINI App, rich menu, QR code หรือ LINE chat ปกติ

การแยกที่สะอาดกว่าสำหรับทีมเล็ก

ถ้าคุณกำลังสร้าง LINE MINI App ที่ขาย digital content ในญี่ปุ่น ให้ใช้ official in-app purchase flow มันดูแล payment review, app store transaction, purchase verification และ settlement reporting Stack นี้ควร audit ได้ รอบคอบ และผูกกับ finance

ถ้าคุณกำลังสร้าง customer operations ให้ใช้ event-driven inbound layer มันดูแล message receipt, routing, deduplication, handoff ไป Slack หรือ CRM และ reply handling Stack นี้ควรเร็ว เสถียร และ reuse ข้าม channel ได้

แยกได้แบบนี้:

งาน	เจ้าของที่เหมาะสม	เวลา
ซื้อ digital content	LINE MINI App in-app purchase	ระหว่าง checkout
ตรวจสอบ purchase	MINI App server และ LINE payment webhook	Payment lifecycle
ข้อความลูกค้าแบบ live	UnifyPort message.received webhook	Event ทันที
Support reply	POST /v1/messages	Agent หรือ workflow action
Cross-channel routing	UnifyPort standard event envelope	Handler เดียวสำหรับทุก provider

โมเดลนี้เหมาะกับทีม cross-border ด้วย LINE MINI App in-app purchase ตอนนี้ผูกกับเงื่อนไขญี่ปุ่น แต่ support queue มักไม่ได้จำกัดอยู่ตลาดเดียว ทีมอาจต้องใช้ LINE ในญี่ปุ่นและไทย, Zalo ในเวียดนาม, WhatsApp ในฮ่องกงหรือสิงคโปร์ และ Telegram สำหรับลูกค้ากลุ่ม developer Schema inbound เดียวช่วยไม่ให้ queue กลายเป็น integration แยกตามประเทศ

ตอนนี้ควรสร้างอะไร

เริ่มจากตัดสินว่า project ของคุณเป็น commerce surface หรือ messaging operations surface

ถ้าเป็น commerce ให้อ่านเอกสาร LINE MINI App in-app purchase, ยืนยัน requirement ของญี่ปุ่น, สมัครผ่าน LINE Developers Console, เตรียม budget สำหรับ service fee และสร้าง payment webhook เป็น finance-critical path อย่าเอาไปปนกับ support routing code

ถ้าเป็น support ให้ลงทะเบียน UnifyPort webhook endpoint พร้อม signing_secret, subscribe message.received, ตรวจสอบ X-Device-Signature, เก็บ event และ route ตาม provider, account_id, data.conversation.id, data.sender.id และ data.message.type ส่วน payment ID หรือ order ID ควรเป็น metadata ในระบบของคุณ ไม่ใช่ transport layer

เมื่อลูกค้าส่งข้อความว่า “ฉันจ่ายใน app แล้ว แต่ยังต้องการเปลี่ยนเวลาส่งของ” ระบบ support ไม่ควรรอให้ payment flow ยืนยันสำเร็จก่อนจึงบันทึกข้อความ ควรรับ event, route แล้วให้ agent หรือ automation ค้น order เป็นอีกขั้นตอนหนึ่ง

อัปเดตค่าธรรมเนียมวันที่ 1 กรกฎาคมของ LINE เป็น reminder ที่ดีว่า platform payment surface มีต้นทุนและ control ของตัวเอง ใช้มันเมื่อคุณขาย digital content ใน LINE แต่สำหรับ inbound customer conversations ให้เก็บ path เป็น event-driven, signed และแยกจาก payment stack