บทช่วยสอน August 5, 2026

ต้องตรวจสอบอะไรหลัง WhatsApp Embedded Signup เสร็จสมบูรณ์

หน้าต่าง WhatsApp Embedded Signup ที่เสร็จสมบูรณ์ยืนยันเพียงว่าขั้นตอนในเบราว์เซอร์จบแล้ว ก่อนกำหนดให้ tenant พร้อมใช้งาน backend ต้องเชื่อมผลลัพธ์กับ server session ตรวจสอบ token เลือก WhatsApp Business Account (WABA) ที่ถูกต้อง ยืนยันสิทธิ์ system user และสถานะหมายเลข สมัคร app กับ WABA และพิสูจน์ว่า webhook จริงหนึ่งรายการมาถึง tenant ที่ถูกต้อง แต่ละขั้นต้องเป็น acceptance gate แยกกัน

สรุปสำคัญ

FINISH_WHATSAPP_BUSINESS_APP_ONBOARDING หมายถึงหน้าต่าง Coexistence เสร็จ แต่ไม่ได้ยืนยันว่า backend ทุกขั้นสำเร็จ
Collection ทางการของ Meta ระบุให้ดึง shared WABA จัดการ system user ลงทะเบียนหมายเลขเมื่อเหมาะสม และสมัคร webhook ของ WABA
ห้ามเลือก WABA รายการแรกโดยอัตโนมัติ ต้องจับคู่กับ business และ tenant ปัจจุบันอย่างแม่นยำ
การผูก credit line จำเป็นเฉพาะโมเดล partner-paid ไม่ใช่เงื่อนไขร่วมของทุก integration
สัญญาณพร้อมใช้งานสุดท้ายคือ webhook จริงผ่าน tenant routing, validation, deduplication และ acknowledgement

Embedded Signup collection ทางการ ของ Meta แยกขั้นตอนเบราว์เซอร์ออกจากงาน Graph API ได้แก่ การดึง shared WABA เพิ่มหรือตรวจ system user ลงทะเบียนหมายเลข สมัคร app และแชร์ credit line เมื่อ partner เป็นผู้รับผิดชอบค่าใช้จ่าย

ขอบเขตนี้ต่างจาก checklist ย้าย Embedded Signup v4 ซึ่งเน้น configuration สำหรับเปิด flow และการรักษา Coexistence บทความนี้เริ่มหลัง finish event และกำหนดหลักฐานก่อนแสดงสถานะ “เชื่อมต่อแล้ว”

Gate	หลักฐานที่ต้องเก็บ	ขอบเขตความล้มเหลว
Session	tenant ID, one-time state, configuration ID, เวลา	ผลลัพธ์อาจผูกกับ tenant ผิดราย
Token	app, scopes, วันหมดอายุ	มี token แต่จัดการ WABA ไม่ได้
WABA	WABA ID ที่ตรง business context	รายการแรกอาจเป็นของลูกค้ารายอื่น
System user	ID และ task ที่ต้องใช้	หน้าต่างเสร็จแต่ Graph API ล้มเหลว
หมายเลข	phone-number ID และ registration/Coexistence state	มี asset แต่ messaging ยังไม่พร้อม
Subscription	WABA อยู่ใน `subscribed_apps`	Meta รับข้อความแต่ webhook ไม่มา
Delivery	event, tenant routing, validation, response	มีเพียง configuration แต่ไม่มี E2E proof

ดำเนินการตามลำดับ

1. เชื่อมผลลัพธ์กับ server session

ก่อนเปิดหน้าต่าง Meta ให้ server สร้าง session แบบใช้ครั้งเดียวและเก็บ tenant, ผู้ดำเนินการ, configuration ID และชนิด onboarding รับผลลัพธ์เพียงครั้งเดียวและปฏิเสธ state ที่หมดอายุหรือไม่ตรงกัน ห้ามส่ง token ไปยัง browser log, analytics หรือ error report

สำหรับ Coexistence ให้บันทึก event ทางการ FINISH_WHATSAPP_BUSINESS_APP_ONBOARDING ส่วน Embedded Signup แบบอื่นต้องใช้ contract ปัจจุบันของ flow นั้น ไม่ควร route ด้วยข้อความแสดงผลหรือเลข version เพียงค่าเดียว

2. ตรวจ token ก่อนใช้ asset ID

ใช้ token debugging ของ Meta เพื่อยืนยันว่า token เป็นของ app และมี permission ที่ต้องใช้ token ที่ไม่ว่างไม่ใช่หลักฐานว่าได้รับอนุญาตแล้ว เก็บเฉพาะ metadata ขั้นต่ำสำหรับ audit และ renewal ที่ server และไม่เขียน token ลง log

3. เลือก WABA อย่างแน่นอน

ดึง shared/client WABA ที่ business เข้าถึงได้ แล้วจับคู่ WABA ID กับ context ของ session ปัจจุบัน ระบบ multi-tenant ห้ามพึ่งลำดับ array หากไม่ตรงอย่างแม่นยำให้คงสถานะ verification_required แทนการเชื่อม asset อื่นโดยเงียบ ๆ

4. ตรวจ system user และเส้นทางหมายเลข

Collection ทางการใช้ GET /{waba-id}/assigned_users เพื่อตรวจ system user และควรยืนยัน task ที่ backend ต้องใช้ด้วย Standard Cloud API อาจต้องลงทะเบียนหมายเลข ส่วน Coexistence ใช้หมายเลขที่เชื่อมกับ WhatsApp Business app แล้ว จึงต้องตรวจสถานะปัจจุบันแทนการลงทะเบียนซ้ำ อ่าน คู่มือตัดสินใจ Coexistence เพื่อประเมินว่าโมเดลทางการนี้จำเป็นหรือไม่

5. สมัคร WABA และพิสูจน์ delivery

เรียก POST /{waba-id}/subscribed_apps ด้วย credential ฝั่ง server แล้วอ่านสถานะอีกครั้ง แยกสถานะ subscription ออกจาก phone readiness เพราะทั้งสองส่วนสำเร็จหรือล้มเหลวแยกกันได้

จากนั้นใช้ข้อความทดสอบที่ควบคุมได้ และกำหนดให้ webhook จริงผ่าน tenant lookup, payload validation, deduplication และ acknowledgement สำหรับ UnifyPort ให้ทำตาม webhook delivery และการตรวจลายเซ็น: ตรวจ raw body, X-Device-Timestamp, X-Device-Signature และ signing_secret ของ endpoint

UnifyPort เหมาะกับส่วนใด

UnifyPort ไม่ได้ทำ Meta Embedded Signup ไม่ได้ให้สิทธิ์ WABA ลงทะเบียนหมายเลข Cloud API ผูก credit line หรือรักษา Coexistence หาก Solution Partner หรือ Tech Provider ต้องการ asset เหล่านี้ ควรใช้ flow ทางการ

UnifyPort รองรับขอบเขตที่แคบกว่า คือเชื่อมบัญชี WhatsApp ทั่วไปและทำให้ข้อความขาเข้าที่รองรับเป็น message.received มาตรฐาน หากต้องการ inbound queue มากกว่าการ provision WABA ของลูกค้า ให้เปรียบเทียบ สามเส้นทาง WhatsApp inbound แล้วดู คู่มือ authorization ของ WhatsApp

ข้อจำกัดและข้อแลกเปลี่ยน

Checklist นี้ไม่ยืนยัน business eligibility, App Review, display name, คุณภาพหมายเลข หรือ compliance ของ Meta เพราะเป็นสถานะอื่นของ platform การผ่าน tenant ทดสอบก็ไม่ได้พิสูจน์ว่าทุก configuration ของลูกค้าจะทำงาน

อินเทอร์เฟซที่ไม่เป็นทางการไม่สามารถให้ Cloud API asset และไม่แทน Embedded Signup สำหรับ SaaS แบบ multi-tenant ในทางกลับกัน หน้าต่างที่เสร็จแล้วก็ไม่ยืนยัน tenant mapping, retry, webhook receiver หรือ billing boundary ควรแยก “browser complete” และ “operational ready” เป็นคนละสถานะ

FAQ

`FINISH_WHATSAPP_BUSINESS_APP_ONBOARDING` หมายถึงอะไร

หมายถึงหน้าต่าง WhatsApp Business app onboarding ถึง finish state ทางการแล้ว แต่ backend ยังต้องตรวจ session, asset, permission, subscription และ delivery

ไม่เพียงพอ ต้องตรวจ token, WABA ที่ถูกต้อง, system user, เส้นทางหมายเลข และ webhook subscription

ทุก integration ต้องผูก credit line หรือไม่

ไม่ เฉพาะเมื่อ partner จ่าย Meta แล้วเรียกเก็บจากลูกค้าจึงต้องมีขั้นตอนที่เกี่ยวข้อง

ต้องลงทะเบียนหมายเลข Coexistence ซ้ำหรือไม่

ไม่ ให้ตรวจสถานะและการ sync ทางการแทนการทำ standard phone registration ซ้ำ

สัญญาณยอมรับสุดท้ายคืออะไร

อย่างน้อย webhook ทดสอบหนึ่งรายการต้องถึง tenant ที่ถูกต้อง และผ่านการตรวจพร้อมตอบกลับจาก receiver ที่ใกล้เคียง production

ขั้นตอนถัดไป

ใช้ gate ตาม collection ทางการของ Meta ก่อนเปิด tenant หากต้องการเพียง inbound ของบัญชีทั่วไป ให้ประเมิน UnifyPort WhatsApp authorization

แหล่งข้อมูล

ตรวจแหล่งข้อมูลทางการเมื่อ 2026-08-05: