การตรวจสอบหมายเลขบัตรเครดิตเป็นงานที่ดูเรียบง่าย แต่เป็นด่านที่กำหนดว่าผู้ใช้จะทำรายการสำเร็จหรือถูกปฏิเสธด้วยเหตุผลที่เขาแก้ไขไม่ได้ บทความนี้จะอธิบายว่าการตรวจสอบแต่ละชั้นป้องกันอะไรได้จริง ลำดับการตรวจที่ประหยัดและได้ผล ข้อความแจ้งเตือนแบบใดที่ผู้ใช้เข้าใจทันที และข้อผิดพลาดที่ทีมพัฒนามักมองข้ามเพราะทดสอบด้วยข้อมูลชุดเดียวตลอดโครงการ
การตรวจสอบหมายเลขบัตรเครดิตป้องกันอะไรได้จริง?
การตรวจสอบที่ทำได้เองในระบบของคุณมีขอบเขตจำกัดชัดเจน มันป้องกันข้อมูลผิดรูปแบบ ซึ่งหมายถึงการพิมพ์ผิด การคัดลอกแล้วตกหล่น และการป้อนข้อมูลที่ไม่ใช่ตัวเลขเลย ประโยชน์หลักคือผู้ใช้ได้รับข้อความตอบกลับทันทีในจังหวะที่ยังแก้ไขได้ง่าย และระบบของคุณไม่ต้องเก็บข้อมูลที่ใช้ไม่ได้ไว้ในฐานข้อมูล
ในทางกลับกัน การตรวจสอบเหล่านี้ไม่ยืนยันว่าบัญชีมีอยู่จริง มีวงเงินเพียงพอ หรือเปิดใช้งานอยู่ การยืนยันลักษณะนั้นต้องอาศัยคำตอบจากผู้ออกบัตรผ่านเส้นทางที่ผู้ให้บริการชำระเงินจัดให้ ดังนั้นการออกแบบที่ดีคือใช้การตรวจสอบในเครื่องเป็นประตูแรก และให้ผลลัพธ์จากผู้ออกบัตรเป็นคำตัดสินสุดท้าย
ความเข้าใจผิดที่พบบ่อยคือคิดว่าการตรวจหลักสุดท้ายด้วยขั้นตอนวิธี Luhnเป็นมาตรการความปลอดภัย ทั้งที่มันเป็นเพียงตัวจับการพิมพ์ผิด และสร้างตัวเลขที่ผ่านการตรวจได้ง่ายมากจนไม่มีค่าในการป้องกันการปลอมแปลงเลย
ลำดับการตรวจสอบที่แนะนำ
หลักคิดคือตรวจสิ่งที่ถูกที่สุดก่อน แล้วจึงไล่ไปหาสิ่งที่แพงกว่า ความยาวและการตรวจชนิดอักขระถูกกว่าการคำนวณผลรวมมาก และการตรวจคำนำหน้าก็มีค่าใช้จ่ายต่ำ แต่ให้ข้อมูลที่มีประโยชน์ต่อผู้ใช้สูง
- ตัดตัวคั่นทั้งหมดออก แล้วตรวจว่าส่วนที่เหลือมีเฉพาะตัวเลข
- ปฏิเสธสตริงที่ว่างหรือสั้นเกินไปทันที เพื่อไม่ให้เสียแรงกับข้อมูลที่ผิดตั้งแต่แรก
- ตรวจความยาวว่าอยู่ในช่วงที่เครือข่ายบัตรที่รองรับใช้จริง
- ตรวจคำนำหน้าเทียบกับรายการเครือข่ายที่ธุรกิจของคุณรองรับ และแยกข้อความกรณีไม่รู้จักเครือข่ายออกจากกรณีรูปแบบผิด
- คำนวณหลักตรวจสอบเป็นด่านสุดท้ายของการตรวจรูปแบบ
- บันทึกผลลัพธ์พร้อมเหตุผลของความล้มเหลว เพื่อให้ทีมวิเคราะห์อัตราการกรอกผิดได้ในภายหลัง
การเก็บเหตุผลของความล้มเหลวไว้เป็นสถิติมีประโยชน์มาก เพราะช่วยบอกได้ว่าปัญหาอยู่ที่การออกแบบฟอร์ม การตีความของผู้ใช้ หรือกติกาที่เข้มเกินไป
ควรตรวจที่ฝั่งหน้าเว็บหรือเซิร์ฟเวอร์?
คำตอบคือทำทั้งสองที่ แต่ด้วยเป้าหมายที่ต่างกัน การตรวจฝั่งหน้าเว็บมีไว้เพื่อประสบการณ์ผู้ใช้ ให้ข้อความตอบกลับเร็วที่สุดเท่าที่ทำได้ ส่วนการตรวจฝั่งเซิร์ฟเวอร์มีไว้เพื่อความถูกต้องของข้อมูล เพราะเป็นจุดที่ผู้ใช้กดข้ามไม่ได้เลย
อันตรายที่แท้จริงไม่ได้อยู่ที่การตรวจซ้ำซ้อน แต่อยู่ที่การตรวจเฉพาะฝั่งหน้าเว็บแล้วเชื่อว่าปลอดภัยเพียงพอ ข้อมูลสามารถถูกส่งเข้าสู่ระบบโดยไม่ผ่านหน้าจอที่คุณออกแบบไว้ได้เสมอ ไม่ว่าจะเป็นจากโปรแกรมอัตโนมัติ การนำเข้าข้อมูลเป็นชุด หรือการเรียกส่วนเชื่อมต่อโดยตรง
ในทางปฏิบัติควรเขียนกติกาการตรวจไว้ที่เดียวแล้วใช้ร่วมกันทั้งสองฝั่ง เพื่อไม่ให้เกิดกรณีที่ฝั่งหน้าเว็บยอมรับแต่ฝั่งเซิร์ฟเวอร์ปฏิเสธ ซึ่งทำให้ผู้ใช้เห็นข้อความขัดแย้งกันเองในจอเดียว
ข้อความแจ้งเตือนแบบใดที่ผู้ใช้เข้าใจ
ข้อความแจ้งเตือนที่มีประโยชน์ต้องบอกว่าปัญหาคืออะไร และผู้ใช้ควรทำอะไรต่อ ตารางต่อไปนี้เปรียบเทียบกรณีที่พบบ่อย
| กรณีที่ตรวจพบ | สิ่งที่ควรบอกผู้ใช้ |
|---|---|
| มีอักขระที่ไม่ใช่ตัวเลขปนอยู่ | บอกว่าช่องนี้รับเฉพาะตัวเลข และให้ตรวจว่าคัดลอกตัวอักษรติดมาหรือไม่ |
| จำนวนหลักน้อยกว่าที่เครือข่ายต้องใช้ | บอกว่าหมายเลขไม่ครบ ให้ตรวจสอบอีกครั้งจากหน้าบัตร |
| จำนวนหลักมากเกินไป | ระบุว่ายาวเกินไป และเสนอให้ตรวจว่ามีตัวเลขซ้ำติดมาโดยไม่ตั้งใจ |
| รู้จักเครือข่ายแต่ระบบไม่รองรับ | บอกตรง ๆ ว่าไม่รองรับเครือข่ายนั้น ไม่ใช่บอกว่าหมายเลขผิด |
| คำนำหน้าไม่ตรงกับเครือข่ายใด | บอกว่าตรวจไม่พบเครือข่าย โดยไม่สรุปว่าผู้ใช้ทุจริต |
| หลักตรวจสอบไม่ผ่าน | ให้ตรวจหมายเลขอีกครั้งทีละหลัก เพราะสาเหตุที่พบบ่อยคือพิมพ์ผิดหนึ่งหลัก |
ข้อความที่ควรหลีกเลี่ยงคือข้อความกวม ๆ ว่า “ข้อมูลไม่ถูกต้อง” เพราะผู้ใช้จะไม่รู้ว่าต้องแก้ช่องใด และมักทำให้เขาลองกรอกซ้ำหลายรอบจนหมดความอดทน
ถ้าไม่ตรวจเลยจะเกิดอะไรขึ้น?
หากปล่อยให้ข้อมูลผิดรูปแบบไหลเข้าสู่ระบบ ระบบจะส่งคำขอที่ไม่มีทางสำเร็จออกไป และได้ข้อความปฏิเสธกลับมา ซึ่งมีต้นทุนทั้งเวลารอ ค่าธรรมเนียมของบางเส้นทาง และความสับสนของผู้ใช้ที่เห็นข้อความว่าบัตรถูกปฏิเสธทั้งที่ปัญหาอยู่ที่การพิมพ์ผิด
ผลพลอยได้ที่แย่กว่าคือข้อมูลเสียสะสมอยู่ในฐานข้อมูล ระบบรายงานจะเต็มไปด้วยรายการที่ล้มเหลวซึ่งกลบรายการที่ล้มเหลวด้วยเหตุผลทางธุรกิจจริง ทำให้ทีมวิเคราะห์สาเหตุได้ยากขึ้นมาก
การตรวจที่ไม่รัดกุมพอจึงไม่ใช่ปัญหาด้านเทคนิคเพียงอย่างเดียว แต่เป็นปัญหาด้านข้อมูลที่แก้ย้อนหลังได้ยากและมีค่าใช้จ่ายสูง
สำหรับนักพัฒนา: ชุดทดสอบขั้นต่ำที่ควรมี
เมื่อคุณมีฟังก์ชันตรวจสอบแล้ว สิ่งที่ต้องทำต่อคือพิสูจน์ว่ามันยอมรับสิ่งที่ควรยอมรับและปฏิเสธสิ่งที่ควรปฏิเสธ ชุดทดสอบขั้นต่ำที่แนะนำประกอบด้วย
- หมายเลขที่ควรผ่าน โดยคัดแยกตามความยาวที่ต่างกันอย่างน้อยสองแบบ
- หมายเลขที่มีตัวคั่น ทั้งช่องว่างและขีดกลาง เพื่อยืนยันว่าการถอดตัวคั่นทำงานถูกต้อง
- หมายเลขที่สลับตำแหน่งของหลักสองหลักที่อยู่ติดกัน ซึ่งต้องถูกปฏิเสธ
- สตริงที่มีตัวอักษรปนอยู่หนึ่งตัว เพื่อยืนยันว่าการตรวจชนิดอักขระทำงานก่อนการคำนวณ
- สตริงว่างและสตริงที่ยาวเกินขอบเขตบน เพื่อยืนยันว่าไม่เกิดความผิดพลาดรุนแรงในระบบ
- หมายเลขของเครือข่ายที่ไม่รองรับ เพื่อยืนยันว่าข้อความแจ้งเตือนแยกกรณีได้ถูกต้อง
ในการรันชุดทดสอบ ควรใช้ข้อมูลสมมติเสมอ เครื่องมือสร้างหมายเลขบัตรบนเว็บไซต์นี้สร้างหมายเลขที่โครงสร้างถูกต้องให้ได้ครั้งละหลายใบ ใช้ได้กับงานทดสอบเท่านั้น หมายเลขทุกใบไม่มีบัญชีรองรับและไม่เคยถูกออกให้กับใคร
สร้างหมายเลขเพื่อทดสอบการตรวจของคุณ
ในทางปฏิบัติ การมีข้อมูลนำเข้าที่หลากหลายช่วยให้คุณเจอข้อผิดพลาดในฟังก์ชันตรวจสอบได้เร็วขึ้นมาก ลองสร้างชุดข้อมูลที่ครอบคลุมหลายความยาวและหลายเครือข่าย แล้วนำไปไล่ผ่านฟังก์ชันของคุณทีละค่า สังเกตว่าค่าที่ควรผ่านมีตัวใดถูกปฏิเสธ และค่าที่ควรถูกปฏิเสธมีตัวใดหลุดผ่าน
สำหรับรายละเอียดว่าคำนำหน้าของแต่ละเครือข่ายต่างกันอย่างไร อ่านต่อได้ที่รูปแบบหมายเลขบัตรเครดิต และถ้าคุณต้องการยกระดับจากการทดสอบระดับหน่วยไปสู่การทดสอบทั้งฟอร์ม ควรอ่านเช็กลิสต์ทดสอบฟอร์มชำระเงิน
ก้าวต่อไป
ทบทวนกติกาการตรวจของคุณด้วยสองคำถาม ถ้าผู้ใช้กดข้ามหน้าจอและส่งข้อมูลเข้าสู่ส่วนเชื่อมต่อโดยตรง ระบบยังปฏิเสธข้อมูลผิดรูปแบบได้หรือไม่ และเมื่อการตรวจล้มเหลว ผู้ใช้เห็นข้อความที่บอกทางแก้จริงหรือเพียงข้อความกว้าง ๆ ที่ทำให้เขาลองซ้ำแบบเดาสุ่ม เมื่อตอบได้ครบทั้งสองข้อแล้ว จึงค่อยเพิ่มชุดทดสอบอัตโนมัติที่ครอบคลุมค่าขอบเขตตามรายการข้างต้น