คู่มือ WhatsApp OTP Verification API สำหรับ B2B ไทย: ส่งเร็ว High Delivery Rate

ลองนึกภาพว่าผู้ค้าส่งในเชียงใหม่กำลังเร่งยืนยันการรับตู้คอนเทนเนอร์ด่วนที่ส่งออกจากท่าเรือแหลมฉบัง แต่ Outlook กลับจัดอีเมล OTP ไว้ในโฟลเดอร์สแปมหรือเกตเวย์ SMS ระหว่างประเทศล่าช้าจนต้องรอนานกว่าหนึ่งนาที ก่อนจะปิดระบบแล้วหันไปสั่งซื้อกับคู่แข่งผ่าน WhatsApp เพื่อป้องกันไม่ให้เหตุการณ์นี้เกิดขึ้น ก่อนที่ WhatsApp OTP verification API จะส่งรหัสแรก ทีมของคุณต้องตัดสินใจว่าใครเป็นเจ้าของระบบ โดยคุณสามารถ ลงทะเบียนบัญชี WhatsApp Business ของตนเองและดูแลระบบยืนยันตัวตนทั้งหมดด้วยตนเอง หรือ ส่งรหัส OTP ผ่านผู้ให้บริการที่มีหมายเลขผู้ส่งและมีเทมเพลตที่ได้รับอนุมัติแล้ว หากเลือกแนวทางแรก การยืนยันบัญชีและการตรวจสอบเทมเพลตของ Meta จะกลายเป็นขั้นตอนสำคัญบน Critical Path ซึ่งโดยทั่วไปใช้เวลาหลายวัน แต่หากเลือกแนวทางที่สอง ตัวตนผู้ส่งที่ปรากฏในบทสนทนาจะเป็นของผู้ให้บริการ ทีมที่ข้ามคำถามนี้มักได้คำตอบโดยไม่ตั้งใจ ก่อนจะกลับมาพบปัญหาเดิมอีกครั้งในช่วงสัปดาห์เปิดใช้งานจริง

เนื้อหาต่อไปนี้จะอธิบายทั้งสองแนวทาง ตั้งแต่สิ่งที่เทมเพลต Authentication ควบคุมจริง วิธีเชื่อมต่อ โฟลว์การส่งและยืนยันรหัส ไปจนถึง สัญญาณสถานะการจัดส่ง ที่ควรจัดการ รวมถึงการแยกโดเมนการตลาดออกจากโดเมน OTP อย่างเด็ดขาด เพื่อป้องกันไม่ให้ Outlook หรือ Gmail บล็อกอีเมลยืนยันทั้งหมด และ ตรรกะของกลยุทธ์สำรอง (Fallback Strategy) เมื่อช่องทางหลักล้มเหลว ซึ่งช่วยให้ผู้ใช้สมัครต่อได้เมื่อ WhatsApp ส่งข้อความไม่ถึง โดยระบบควรสลับไปใช้ SMS ผ่านสองช่องทางสำหรับ AIS และ True–dtac โดยอัตโนมัติ ข้อสมมติฐานเบื้องต้นคือ WhatsApp เป็นส่วนหนึ่งของช่องทางยืนยันตัวตนของคุณแล้ว แม้ LINE จะครองตลาดการสื่อสารส่วนบุคคลในไทย แต่สำหรับธุรกิจ B2B การค้าระหว่างไทย–จีน การนำเข้า–ส่งออก และซัพพลายเชนข้ามประเทศ WhatsApp คือมาตรฐานการสื่อสารทางธุรกิจสากล หากยังไม่ได้ข้อสรุปในส่วนนี้ โปรดอ่าน ภาพรวม WhatsApp OTP ซึ่งเปรียบเทียบแต่ละช่องทางและอธิบายกรณีใช้งานที่เกี่ยวข้องกับการตัดสินใจ

สองแนวทางในการสร้างระบบยืนยัน OTP ผ่าน WhatsApp

ทั้งสองแนวทางสามารถส่งรหัสไปยังบทสนทนา WhatsApp ได้ แต่แตกต่างกันที่ ทีมของคุณต้องดูแลแพลตฟอร์มด้วยตนเองมากน้อยเพียงใด

แนวทางที่ใช้กลุ่มหมายเลขของผู้ให้บริการมีขึ้นเพราะการลงทะเบียน WABA เป็นขั้นตอนที่ใช้เวลานานที่สุดในการเปิดใช้ WhatsApp OTP ตาม เอกสาร EngageLab OTP บริการ OTP มีกลุ่มหมายเลข WhatsApp ในตัว จึงส่งรหัสได้โดยไม่ต้องลงทะเบียนบัญชีธุรกิจแยกต่างหาก พร้อมรองรับ SMS อีเมล และเสียงผ่าน API เดียวกัน

เลือกแนวทางเชื่อมต่อโดยตรง เมื่อบทสนทนา WhatsApp เป็นส่วนหนึ่งของประสบการณ์ใช้งานผลิตภัณฑ์ และคุณต้องการให้ตัวตนผู้ส่งที่ได้รับการยืนยันของตนเองปรากฏอยู่ในบทสนทนา เลือกแนวทาง OTP API เมื่อระบบยืนยันตัวตนทำหน้าที่เป็นโครงสร้างพื้นฐานเบื้องหลัง กล่าวคือ ส่งรหัสออกไป รับผลการยืนยันกลับมา และแสดงข้อมูลในรายงาน โดยทีมของคุณไม่ต้องรับผิดชอบการตรวจสอบเทมเพลตเป็นงานประจำ สำหรับทีมที่ส่งข้อความการตลาดผ่าน WhatsApp อยู่แล้ว โดยทั่วไปมักมี WABA ของตนเอง จึงอาจเหมาะกับแนวทางเชื่อมต่อโดยตรงมากกว่า หากตรงกับกรณีของคุณ ขั้นตอนการลงทะเบียนผู้ส่งและการจัดการเทมเพลตอธิบายไว้ใน คู่มือส่งข้อความด้วย WhatsApp API และ บทเปรียบเทียบผู้ให้บริการโซลูชัน ซึ่งช่วยให้คุณเลือก BSP ที่เหมาะสมสำหรับบัญชีดังกล่าว

สิ่งที่เทมเพลต Authentication เป็นตัวกำหนดสำหรับแนวทาง WABA Direct

WhatsApp ไม่มี Endpoint ทั่วไปสำหรับส่งรหัส ข้อความทุกข้อความที่ธุรกิจเป็นฝ่ายเริ่มต้องใช้เทมเพลตที่ได้รับอนุมัติล่วงหน้า และรหัสผ่านแบบใช้ครั้งเดียวต้องอยู่ในหมวด Authentication ซึ่งกำหนดให้เนื้อหาเป็นข้อความด้านความปลอดภัยโดยใช้รหัสของคุณเป็นตัวแปร

ปุ่มคือส่วนที่เชื่อมเทมเพลตเข้ากับแอปของคุณ เทมเพลต Authentication รองรับการทำงานของปุ่มสามรูปแบบตามที่ระบุไว้ใน เอกสาร Meta for Developers โดยแต่ละรูปแบบกำหนดให้แอปของคุณรองรับการทำงานที่แตกต่างกัน

One-tap และ Zero-tap รองรับเฉพาะ Android เมื่อส่งเทมเพลต Authentication ไปยัง iPhone แอปจะแสดงปุ่มคัดลอกรหัสไม่ว่าคุณจะกำหนดค่าแบบใด ดังนั้นผู้ใช้ iOS ยังคงต้องกรอกรหัสด้วยตนเอง นอกจากนี้ Payload จำเป็นต้องระบุปุ่มสำรองด้วย แม้เป็นเทมเพลต Zero-tap ก็ยังต้องประกาศปุ่ม One-tap และปุ่มคัดลอกรหัสสำหรับผู้ใช้ที่ไม่สามารถใช้งาน Zero-tap ได้

ข้อกำหนดของ Meta ก่อนเรียก API ครั้งแรก

เทมเพลตอาจได้รับอนุมัติหรือถูกปฏิเสธตามนโยบาย และการขอความยินยอมคือขั้นตอนที่มักทำให้การเปิดใช้งานล่าช้า เอกสาร WhatsApp ของ EngageLab ระบุเงื่อนไขสามข้อที่ต้องดำเนินการให้ครบก่อนส่งข้อความ Authentication

ต้องได้รับความยินยอมแบบ Opt-in ก่อนเริ่มยืนยันตัวตน ข้อความ WhatsApp ทุกข้อความที่ธุรกิจเป็นฝ่ายเริ่มต้องได้รับความยินยอมล่วงหน้า และข้อความ Authentication ก็ไม่มีข้อยกเว้น ควรขอความยินยอมตั้งแต่ขั้นตอนสมัครใช้งาน หากเพิ่งขอความยินยอมบนหน้าจอยืนยันตัวตน การเรียก API ครั้งแรกของคุณจะไม่เป็นไปตามข้อกำหนดทันที

WhatsApp ต้องไม่ถูกตั้งเป็นช่องทางเริ่มต้นโดยที่ผู้ใช้ไม่รับรู้ Meta กำหนดให้คุณเสนอ WhatsApp เป็นหนึ่งในตัวเลือกสำหรับรับรหัสแทนการบังคับใช้งาน หน้าจอยืนยันตัวตนจึงต้องมีตัวเลือกช่องทาง และต้องมีช่องทางที่สองพร้อมใช้งาน เช่น SMS ที่สามารถสลับเส้นทางระหว่าง AIS และ True–dtac ได้

ผู้ใช้ต้องทราบว่ารหัสจะถูกกรอกโดยอัตโนมัติ เมื่อใช้ Zero-tap การยืนยันที่สำเร็จอาจดูเหมือนไม่มีอะไรเกิดขึ้น จึงควรแจ้งให้ผู้ใช้ทราบบนหน้าจออย่างชัดเจน ผู้ใช้ที่สับสนอาจขอรหัสใหม่ และการส่งซ้ำทุกครั้งจะถูกคิดค่าบริการเป็นข้อความ

สร้างโฟลว์การส่งและยืนยันรหัส

จำนวนครั้งที่ต้องเรียก API ขึ้นอยู่กับว่าฝ่ายใดเป็นผู้สร้างรหัส แผนการเชื่อมต่อระบบมักเลือกแนวทางนี้ผิด และเพิ่งพบปัญหาในขั้นตอนตรวจสอบโค้ด

เมื่อแพลตฟอร์มเป็นผู้สร้างรหัส คุณต้องเรียก API สองครั้ง โดยใช้ POST /v1/messages เพื่อส่งรหัส แล้วเรียก POST /v1/verifications พร้อม message_id ที่ได้รับกลับมาและรหัสที่ผู้ใช้กรอก รายละเอียดของ Request และ Response อยู่ในเอกสาร การส่งรหัส OTP และ การตรวจสอบรหัส OTP

เมื่อระบบของคุณเป็นผู้สร้างรหัสเอง ให้ส่งรหัสผ่าน POST /v1/codes แทน และตาม การส่งรหัส OTP กำหนดเอง คุณไม่ต้องเรียก API เพื่อยืนยันรหัสภายหลัง เนื่องจากการเปรียบเทียบรหัสจะดำเนินการภายในแอปพลิเคชันของคุณ ทีมที่มีระบบประเมินความเสี่ยงอยู่แล้วมักเลือกแนวทางนี้ เพื่อให้เหตุการณ์การยืนยันตัวตนถูกรวมไว้กับสัญญาณความเสี่ยงอื่นในระบบเดียวกัน

รูปแบบของ Request เป็นส่วนที่ไม่ซับซ้อน แต่นโยบายและข้อจำกัดที่ครอบอยู่รอบกระบวนการต่างหากคือสิ่งที่ผู้โจมตีจะทดสอบและผู้ใช้ที่ไม่ได้รับรหัสจะพบเจอ

เก็บ API Key ไว้ฝั่งเซิร์ฟเวอร์เท่านั้น Request สำหรับยืนยันรหัสที่เรียกได้จาก JavaScript ฝั่ง Client จะกลายเป็น Endpoint แบบเปิด และ Endpoint สำหรับ OTP เป็นเป้าหมายของ การทุจริตจากการปั๊ม SMS (SMS Pumping Fraud) ซึ่งสร้างค่าใช้จ่ายจาก Traffic ที่ไม่ได้เกิดจากผู้ใช้จริง

จัดการสัญญาณสถานะการจัดส่งที่สำคัญสำหรับ OTP

การยืนยันตัวตนเป็นหนึ่งในข้อความไม่กี่ประเภทที่สถานะการจัดส่งควรกำหนดสิ่งที่ผลิตภัณฑ์ต้องทำต่อไป รหัสที่ส่งไม่ถึงอุปกรณ์เป็นปัญหาคนละแบบกับรหัสที่ส่งถึงแล้วแต่ผู้ใช้ไม่ได้ดำเนินการ และ มีเพียง Callback เท่านั้นที่บอกได้ว่าคุณกำลังพบปัญหาแบบใด

แนวทาง Managed OTP รายงานวงจรชีวิตเดียวกันสำหรับทุกช่องทาง Handler เดียวกันจึงรองรับทั้งรหัสที่ส่งผ่าน WhatsApp และรหัสที่สลับไปส่งผ่าน SMS ตาม อินเทอร์เฟซการเรียกกลับสถานะวงจรชีวิต ระบบจะแสดงสถานะดังต่อไปนี้

กำหนด Funnel เป็น requested → sent → delivered → verified ทีมส่วนใหญ่มักติดตามเฉพาะตัวเลขสุดท้าย ทำให้ไม่สามารถแยกได้ว่าอัตราการยืนยันที่ลดลงเกิดจากปัญหาการจัดส่ง ปัญหาด้าน UX หรือการทุจริตที่เพิ่มจำนวน Request บริเวณต้น Funnel ควรแยกความล้มเหลวตามช่องทาง ประเทศปลายทาง และเครือข่ายอย่าง AIS หรือ True–dtac ข้อมูลนี้จะช่วยให้คุณตัดสินใจได้ว่า WhatsApp เหมาะที่จะเป็นช่องทางหลักในแต่ละตลาดหรือไม่

ออกแบบกลยุทธ์สำรองก่อนจำเป็นต้องใช้งาน

WhatsApp ไม่สามารถเข้าถึงผู้ใช้ทุกคนได้ ผู้ใช้อาจไม่เคยติดตั้งแอป หมายเลขอาจไม่ได้ลงทะเบียนกับ WhatsApp ยังไม่ได้ให้ความยินยอมแบบ Opt-in หรือการเชื่อมต่ออินเทอร์เน็ตอาจขัดข้องในพื้นที่คลังสินค้าและท่าเรือ ขณะที่เครือข่ายโทรศัพท์มือถือยังใช้งานได้ ทุกกรณีให้ผลลัพธ์เหมือนกันคือผู้ใช้ติดอยู่บนหน้าจอยืนยันตัวตน

สำหรับแนวทาง Managed OTP กลยุทธ์สำรองเมื่อช่องทางหลักล้มเหลวเป็นการตั้งค่า ไม่ใช่ตรรกะภายในแอปพลิเคชัน คุณจัดลำดับช่องทางไว้ในเทมเพลต และแพลตฟอร์มจะย้ายไปยังช่องทางถัดไปเมื่อช่องทางปัจจุบันล้มเหลว สำหรับประเทศไทยควรกำหนดให้ช่องทาง SMS สำรองรองรับสองเส้นทางผ่าน AIS และ True–dtac เพื่อหลีกเลี่ยงความแออัดของช่องทางใดช่องทางหนึ่ง การออกแบบระบบต้องคำนึงถึงเรื่องนี้สองจุด Callback Handler ของคุณ ต้องไม่ส่งข้อความครั้งที่สอง เมื่อได้รับสถานะล้มเหลว เนื่องจากแพลตฟอร์มได้ย้ายไปยังช่องทางถัดไปแล้ว การส่งซ้ำด้วยตนเองจะทำให้เกิดข้อความที่ต้องชำระเงินสองข้อความและมีรหัสสองชุดแข่งขันกันบนช่องกรอกเดียวกัน ส่วนค่า send_channel ที่ได้รับจากการเรียกส่งข้อความจะแสดงช่องทางที่ใช้ในขณะนั้น ไม่ใช่การรับประกันว่าข้อความจะถูกส่งสำเร็จผ่านช่องทางใดในท้ายที่สุด

สิ่งที่ทีมของคุณยังต้องกำหนดคือนโยบาย ในประเทศไทยควรแยกกลุ่มลูกค้า B2B ข้ามประเทศที่คุ้นเคยกับ WhatsApp ออกจากกลุ่มผู้ใช้ทั่วไปที่อาจเหมาะกับ SMS เป็นช่องทางเริ่มต้น รวมถึงกำหนดจำนวนครั้งทั้งหมดที่การสมัครหนึ่งรายการสามารถใช้ได้ ต้องจำกัดจำนวนรวมของทุกช่องทาง ไม่ใช่กำหนดแยกตามช่องทาง การลองส่งผ่าน WhatsApp สามครั้งแล้วตามด้วย SMS อีกสามครั้งเท่ากับข้อความที่ต้องชำระเงินหกข้อความสำหรับการสมัครเพียงครั้งเดียว และสคริปต์โจมตีจะใช้โควตาทั้งหมดที่มี หากต้องการเปรียบเทียบความน่าเชื่อถือและค่าใช้จ่ายของแต่ละช่องทาง โปรดดู บทเปรียบเทียบ OTP แบบหลายช่องทาง

กำหนดค่า WhatsApp OTP ผ่าน Console แบบทีละขั้นตอน

คำแนะนำนี้ใช้ บริการ Managed OTP และกลุ่มหมายเลข WhatsApp ที่มีอยู่ในระบบ คุณไม่จำเป็นต้องมีบัญชี WhatsApp Business ของตนเองหรือเปิดใช้ผลิตภัณฑ์ WhatsApp Business API แยกต่างหากสำหรับแนวทางนี้ แต่ละขั้นตอนจะระบุหน้าจอ สิ่งที่ต้องดำเนินการ และสัญญาณที่ใช้ตรวจสอบว่าการตั้งค่าสำเร็จ

1 เปิดใช้บริการ OTP และสร้างแอปพลิเคชัน

สร้างบัญชี เปิดใช้บริการ OTP แล้วเข้าสู่ OTP Sub-console จากนั้นสร้างแอปพลิเคชันสำหรับผลิตภัณฑ์หรือ Environment ที่จะใช้ส่งรหัส ควรแยกแอปพลิเคชัน Production และ Testing ออกจากกัน เนื่องจาก API Key เทมเพลต ข้อมูลการใช้งาน และเหตุการณ์ Callback จะถูกกำหนดขอบเขตตามแอปพลิเคชัน หากนำมารวมกันจะทำให้ตรวจสอบสาเหตุของการส่งล้มเหลวได้ยากในภายหลัง

2 สร้างเทมเพลต OTP

เปิด การจัดการเทมเพลต แล้วคลิก สร้างเทมเพลต นอกจากชื่อและลายเซ็นแล้ว หน้าจอนี้ยังใช้กำหนดพารามิเตอร์ด้านความปลอดภัย ได้แก่ ประเภทและความยาวของรหัส ระยะเวลาที่รหัสมีผล และกลยุทธ์การส่ง ควรใช้ Template ID ที่สื่อถึงการใช้งานจริง เช่น login_otp_whatsapp_primary เพื่อให้เข้าใจวัตถุประสงค์ได้ทันทีเมื่อดู API Request, Callback Payload และรายงาน โดยไม่ต้องเปิดเทมเพลต

สิ่งที่ต้องระวัง คือระยะเวลาที่รหัสมีผล เมื่อกลยุทธ์การส่งมี WhatsApp ระบบจะรองรับเฉพาะ 1, 5 หรือ 10 นาที ดังนั้นค่าระยะเวลา 3 นาทีที่กำหนดไว้ในขั้นตอนออกแบบจะไม่สามารถใช้กับแบบฟอร์มนี้ได้

3 กำหนดให้ WhatsApp เป็นช่องทางหลัก

ในส่วน ช่องทางหมายเลขโทรศัพท์ ให้กำหนด WhatsApp เป็นช่องทางหลักสำหรับส่งรหัส แนวทาง Managed OTP ใช้เทมเพลต WhatsApp OTP เริ่มต้น ตัวเลือกที่คุณควบคุมได้ในส่วนนี้จึงจำกัดอยู่ที่เนื้อหาเพิ่มเติม ได้แก่ การแสดงข้อความเตือนด้านความปลอดภัยเพื่อไม่ให้ผู้ใช้เปิดเผยรหัส และการแสดงระยะเวลาที่รหัสมีผล ส่วนรูปแบบปุ่มจะกำหนดโดยเทมเพลตของผู้ให้บริการ

4 เพิ่ม SMS หรือ Voice เป็นช่องทางสำรอง

เพิ่มช่องทางสำรองต่อจาก WhatsApp ได้สูงสุดสองช่องทาง กลยุทธ์ที่ใช้โดยทั่วไปคือ WhatsApp → SMS → Voice และแต่ละช่องทางสามารถปรากฏในลำดับได้เพียงครั้งเดียว สำหรับประเทศไทย ชั้น SMS ควรรองรับสองเส้นทางผ่าน AIS และ True–dtac เพื่อให้ระบบสลับเส้นทางได้เมื่อช่องทางใดช่องทางหนึ่งแออัด หน้าจอนี้คือจุดที่กลยุทธ์สำรองเมื่อช่องทางหลักล้มเหลวจากส่วนก่อนหน้าเริ่มทำงานจริง หาก WhatsApp ส่งข้อความไม่สำเร็จ แพลตฟอร์มจะลองใช้ช่องทางถัดไปที่กำหนดไว้โดยคุณไม่ต้องเรียก API เพิ่ม

5 ส่งเทมเพลตเพื่อตรวจสอบและรอการอนุมัติ

ส่งเทมเพลตเข้าสู่กระบวนการตรวจสอบ เทมเพลตจะอยู่ในสถานะรออนุมัติและยังไม่สามารถใช้ส่งข้อความจริงได้จนกว่าจะได้รับอนุมัติ ก่อนดำเนินการต่อ ให้ตรวจสอบว่าสถานะแสดงเป็นอนุมัติแล้ว WhatsApp เป็นช่องทางหลักตามที่ต้องการ ลำดับช่องทางสำรองตรงตามที่ออกแบบไว้ และความยาวกับระยะเวลาที่รหัสมีผลสอดคล้องกับโฟลว์การยืนยันตัวตนของคุณ

6 สร้างคีย์ API สำหรับใช้งานฝั่งเซิร์ฟเวอร์

เปิดคีย์ API แล้วสร้าง Key สำหรับแอปพลิเคชัน กำหนดวันหมดอายุ รายการ IP ที่อนุญาต และสิทธิ์ขั้นต่ำที่โฟลว์จำเป็นต้องใช้ จัดเก็บข้อมูลรับรองไว้ใน Backend เท่านั้น หาก JavaScript บน Browser หรือไฟล์ Binary ของแอปมือถือสามารถเข้าถึง OTP Key ได้ ระบบจะมี Endpoint สำหรับส่งรหัสแบบเปิด ซึ่งเป็นช่องโหว่สำหรับการทุจริตตามที่อธิบายไว้ก่อนหน้านี้

7 เชื่อมต่อการส่ง การยืนยัน และ Callback

เมื่อผู้ใช้ขอรหัส ให้เรียก POST /v1/messages พร้อมหมายเลขปลายทางและ Template ID ที่ได้รับอนุมัติแล้ว จากนั้นเก็บ message_id ที่ได้รับกลับมาไว้ เนื่องจากเป็นค่าที่เชื่อมการตรวจสอบภายหลังเข้ากับการส่งครั้งนี้ เมื่อผู้ใช้ส่งรหัส ให้เรียก POST /v1/verifications พร้อม ID ดังกล่าวและค่าที่ผู้ใช้กรอก อนุญาตให้ดำเนินการที่ได้รับการป้องกันต่อเมื่อ Response ยืนยันว่าการตรวจสอบสำเร็จเท่านั้น

ขั้นตอนที่ 1 ส่งรหัสจาก Backend แทนที่ Placeholder ด้วยหมายเลขปลายทาง Template ID และข้อมูลรับรอง dev_key:dev_secret ที่เข้ารหัสแบบ Base64 ห้ามเปิดเผยข้อมูลรับรองนี้ในโค้ดของ Browser หรือแอปมือถือ

curl --request POST 'https://otp.api.engagelab.cc/v1/messages' \
  --header 'Content-Type: application/json' \
  --header "Authorization: Basic $OTP_BASIC_AUTH" \
  --data '{
    "to": "+6591234567",
    "template": {
      "id": "login_otp_whatsapp_primary",
      "language": "default",
      "params": {}
    }
  }'

Response ที่สำเร็จจะส่ง Identifier ที่คุณต้องเก็บไว้กลับมา ค่า send_channel แสดงช่องทางที่ใช้ในขั้นตอนนี้ ไม่ใช่หลักฐานยืนยันว่าข้อความถูกส่งสำเร็จผ่านช่องทางใดหลังใช้กลยุทธ์สำรอง

{
  "message_id": "1725407449772531712",
  "send_channel": "whatsapp"
}

ขั้นตอนที่ 2 ยืนยันรหัสฝั่งเซิร์ฟเวอร์ จับคู่ค่าที่ผู้ใช้กรอกกับ message_id จาก Response ของการส่งรหัส

curl --request POST 'https://otp.api.engagelab.cc/v1/verifications' \
  --header 'Content-Type: application/json' \
  --header "Authorization: Basic $OTP_BASIC_AUTH" \
  --data '{
    "message_id": "1725407449772531712",
    "verify_code": "667090"
  }'

ดำเนินการเข้าสู่ระบบ สมัครใช้งาน หรือทำรายการที่ได้รับการป้องกันต่อเมื่อค่า verified เป็น true เท่านั้น ข้อความที่ยืนยันสำเร็จแล้วจะไม่สามารถนำมายืนยันซ้ำได้

{
  "message_id": "1725407449772531712",
  "verify_code": "667090",
  "verified": true
}

จากนั้นลงทะเบียน HTTPS Callback Endpoint เพื่อส่งสถานะตลอดวงจรชีวิตไปยังระบบที่คุณสามารถค้นหาและตรวจสอบได้ ใช้ข้อมูลนี้สำหรับ Monitoring และ Reconciliation ไม่ใช่เป็น Trigger สำหรับส่งข้อความซ้ำ เนื่องจากกลยุทธ์ช่องทางกำลังจัดการการสลับไปยังช่องทางสำรองอยู่แล้ว

8 ทดสอบเส้นทางที่ล้มเหลว ไม่ใช่เฉพาะกรณีที่ทำงานสำเร็จ

เริ่มจากส่งรหัสจริงไปยังหมายเลขของคุณเอง แล้วใช้เวลาที่เหลือทดสอบกรณีที่อาจเกิดข้อผิดพลาด ได้แก่ หมายเลขที่ไม่มีบัญชี WhatsApp หมายเลขที่ติดต่อไม่ได้ รหัสหมดอายุ รหัสที่ถูกส่งเพื่อยืนยันสองครั้ง การส่งผ่าน WhatsApp ที่ล้มเหลวและควรสลับไปยัง SMS รวมถึงการสลับเส้นทาง SMS ผ่าน AIS และ True–dtac และ Callback Endpoint ที่ส่ง Error กลับมา เส้นทางเหล่านี้ไม่เคยถูกทดสอบในการสาธิตที่มีเฉพาะกรณีสำเร็จ แต่จะถูกพบภายในไม่กี่ชั่วโมงหลังเริ่มมี Traffic จริง เติมยอดคงเหลือในบัญชีก่อนเริ่มรับ Traffic จากระบบ Production เนื่องจากยอดคงเหลือที่หมดจะทำให้ระบบหยุดส่งข้อความ ไม่ว่าเทมเพลตจะได้รับการตั้งค่าไว้อย่างถูกต้องเพียงใด

คำถามที่พบบ่อยเกี่ยวกับ WhatsApp OTP Verification API

จำเป็นต้องมีบัญชี WhatsApp Business เพื่อส่ง OTP หรือไม่

ไม่จำเป็นในทุกกรณี การส่งผ่าน WhatsApp Business API โดยตรงต้องใช้บัญชีธุรกิจของคุณเองที่ลงทะเบียนและยืนยันแล้ว แต่การส่งผ่าน OTP API ที่มีกลุ่มหมายเลข WhatsApp ไม่จำเป็นต้องมีบัญชีดังกล่าว จึงช่วยนำขั้นตอนลงทะเบียนบัญชีและตรวจสอบเทมเพลตออกจาก Critical Path อย่างไรก็ตาม ตัวตนผู้ส่งที่ปรากฏในบทสนทนาจะเป็นของผู้ให้บริการ ไม่ใช่แบรนด์ของคุณ

ควรให้ Backend ของคุณหรือแพลตฟอร์มเป็นผู้สร้างรหัส

สามารถเลือกได้ทั้งสองแบบ โดยแตกต่างกันที่สิ่งที่ทีมของคุณต้องดูแล เมื่อแพลตฟอร์มเป็นผู้สร้างรหัส โฟลว์จะประกอบด้วยการส่งและการยืนยันผ่านการเรียก API สองครั้ง ส่วนการบังคับใช้วันหมดอายุและการใช้งานได้ครั้งเดียวจะกำหนดผ่านเทมเพลต เมื่อระบบของคุณเป็นผู้สร้างรหัส ให้ส่งค่าที่สร้างไว้ล่วงหน้าผ่าน Custom Send Endpoint และเปรียบเทียบรหัสด้วยตนเองโดยไม่ต้องเรียก API ของผู้ให้บริการเพื่อยืนยัน ทีมที่มีระบบประเมินความเสี่ยงอยู่แล้วมักเก็บการสร้างรหัสไว้ภายในระบบ เพื่อส่งเหตุการณ์การยืนยันเข้าสู่ระบบดังกล่าวโดยตรง

WhatsApp OTP สามารถกรอกรหัสอัตโนมัติบน iPhone ได้หรือไม่

ไม่ได้ One-tap Autofill และ Zero-tap เป็นความสามารถของเทมเพลต WhatsApp Authentication ที่รองรับเฉพาะ Android บน iOS แอป WhatsApp จะแสดงปุ่มคัดลอกรหัสแทน และผู้ใช้ต้องวางรหัสด้วยตนเอง การทำงานนี้เป็นการตั้งค่าระดับเทมเพลตสำหรับแนวทาง WABA Direct หากคุณใช้แนวทาง Managed OTP ควรสอบถามผู้ให้บริการว่าเทมเพลตรองรับปุ่มประเภทใดก่อนประเมินงานพัฒนา

ควรดำเนินการอย่างไรเมื่อส่งข้อความ WhatsApp ไม่สำเร็จ

สำหรับแนวทาง Managed OTP กลยุทธ์ช่องทางจะจัดการให้อัตโนมัติ โดยแพลตฟอร์มจะย้ายไปยังช่องทางถัดไปที่กำหนดไว้ Callback Handler ของคุณจึงควรบันทึกความล้มเหลวแทนการส่งข้อความครั้งที่สอง สิ่งที่ทีมของคุณยังต้องควบคุมคือจำนวนครั้งรวมของทุกช่องทาง และการกำหนดช่องทางหลักในแต่ละประเทศ สำหรับธุรกิจ B2B ข้ามประเทศในไทยสามารถใช้ WhatsApp เป็นช่องทางหลัก พร้อม SMS สำรองที่สลับเส้นทางระหว่าง AIS และ True–dtac ได้ การส่งซ้ำโดยไม่จำกัดจะเพิ่มค่าใช้จ่ายให้กับ Traffic ที่มีแนวโน้มเป็นการโจมตีอัตโนมัติมากที่สุด

ควรเปรียบเทียบผู้ให้บริการ WhatsApp OTP API อย่างไร

อย่าพิจารณาเฉพาะราคาต่อข้อความ แต่ควรตรวจสอบรายละเอียดด้านการดำเนินงาน ได้แก่ กลุ่มหมายเลขช่วยลดขั้นตอนลงทะเบียน WABA ได้หรือไม่ เทมเพลตรองรับปุ่ม Authentication ประเภทใด กำหนดกลยุทธ์สำรองอย่างไรและฝ่ายใดเป็นผู้ดำเนินการ มี Callback สถานะการจัดส่งใดบ้าง และครอบคลุมประเทศที่ผู้ใช้ของคุณอยู่จริงเพียงใด สำหรับประเทศไทยควรตรวจสอบเส้นทางการส่งผ่าน AIS และ True–dtac รวมถึงความพร้อมของ WhatsApp สำหรับลูกค้า B2B ข้ามประเทศของคุณ คู่มือเลือกผู้ให้บริการ OTP API อธิบายเกณฑ์เหล่านี้ไว้อย่างละเอียด

เปิดใช้ระบบยืนยันตัวตนที่รองรับ Traffic จริงได้อย่างมั่นคง

การเรียกใช้งาน WhatsApp OTP Verification API อาจใช้เวลาเพียงช่วงบ่าย แต่การทำให้ระบบทำงานได้อย่างมีประสิทธิภาพต้องใช้เวลามากกว่านั้น เลือกแนวทางการเชื่อมต่อตามระดับการควบคุมแพลตฟอร์มที่ทีมของคุณต้องการ กำหนดตั้งแต่ต้นว่าระบบของคุณหรือแพลตฟอร์มจะเป็นผู้สร้างรหัส เนื่องจากการตัดสินใจนี้กำหนดจำนวนครั้งที่ต้องเรียก API ตั้งค่านโยบายวันหมดอายุ การใช้งานได้ครั้งเดียว การส่งซ้ำ และจำนวนครั้งที่กรอกรหัสก่อนเปิดใช้งานจริง ไม่ใช่หลังพบการโจมตีครั้งแรก และปล่อยให้กลยุทธ์ช่องทางจัดการการสลับไปยังช่องทางสำรอง แทนการเขียน Script ส่งซ้ำไว้ใน Callback Handler

ทดสอบเส้นทางที่ล้มเหลวบนทั้งสองแพลตฟอร์มก่อนที่ผู้ใช้จริงจะเป็นผู้พบปัญหา สร้างเทมเพลต กำหนด SMS เป็นช่องทางสำรองต่อจาก WhatsApp พร้อมทดสอบเส้นทางผ่าน AIS และ True–dtac จากนั้นส่งรหัสไปยังหมายเลขของคุณเองบนอุปกรณ์ Android และ iPhone