คลินิก โรงเรียน บริษัทที่ปรึกษา และผู้ให้บริการฝึกอบรม ไม่ได้ขายสินค้าเป็นชิ้น ๆ แต่ขายเวลาหนึ่งชั่วโมงของใครสักคน หรือที่นั่งในคอร์สเรียน และนั่นทำให้วิธีรับชำระเงินบนเว็บไซต์ของคุณต่างออกไป
คุณอาจต้องเก็บมัดจำเพื่อจองคิว เก็บค่าเรียนเต็มจำนวนก่อนคอร์สจะเต็ม หรือมีช่องทางให้ลูกค้าจ่ายใบแจ้งหนี้หลังงานเสร็จ ร้านค้าออนไลน์แบบมาตรฐานรองรับเรื่องเหล่านี้ได้ดีเพียงไม่กี่อย่าง บทความนี้เปรียบเทียบตัวเลือกที่รองรับได้ และอธิบายวิธีทำให้ข้อมูลบัตรไม่ต้องผ่านเว็บไซต์ของคุณเลย
คำตอบสั้น ๆ
ธุรกิจบริการส่วนใหญ่ต้องการหนึ่งหรือสองอย่างจากรายการนี้:
- ลิงก์ชำระเงิน สำหรับยอดเงินครั้งเดียว ส่งทางอีเมลหรือแชต หรือวางไว้หลังปุ่ม
- ระบบจองที่รับมัดจำ เมื่อการชำระเงินต้องผูกกับวัน เวลา และผู้ให้บริการ
- หน้าชำระเงินแบบง่าย สำหรับบริการราคาคงที่ เช่น ที่นั่งในคอร์สหรือแพ็กเกจ
- การจ่ายใบแจ้งหนี้ออนไลน์ ให้ลูกค้าจ่ายใบแจ้งหนี้แต่ละใบได้จากลิงก์
ไม่ว่าจะเลือกแบบไหน ลูกค้าควรกรอกข้อมูลบัตรเฉพาะในหน้าชำระเงินที่ผู้ให้บริการชำระเงินโฮสต์ไว้ หรือในช่องกรอกที่ฝังมาจากผู้ให้บริการเท่านั้น ไม่ใช่ในฟอร์มของคุณเอง แสดงราคาและเงื่อนไขการยกเลิกก่อนลูกค้าจ่ายเงิน และบันทึกว่าการจองชำระแล้ว ก็ต่อเมื่อผู้ให้บริการยืนยันการชำระเงินเท่านั้น
4 วิธีรับชำระเงินบนเว็บไซต์
ลิงก์ชำระเงิน
คุณสร้างลิงก์ในแดชบอร์ดของผู้ให้บริการสำหรับยอดเงินที่กำหนด แล้วส่งไป หรือวางไว้หลังปุ่ม “ชำระเงินเลย” วิธีนี้เหมาะกับธุรกิจที่ตกลงราคากันในการพูดคุยก่อน เช่น บริษัทที่ปรึกษาที่เก็บค่าจ้างล่วงหน้าแบบรีเทนเนอร์ (retainer) และตั้งค่าเสร็จได้ในไม่กี่นาที
ข้อจำกัด: ลิงก์ไม่รู้อะไรเกี่ยวกับปฏิทินของคุณเลย ต้องมีคนคอยจับคู่การชำระเงินแต่ละรายการกับลูกค้าเอง และลิงก์ที่ถูกส่งต่อหรือใช้ซ้ำอาจถูกจ่ายสองครั้ง
ระบบจองที่รับมัดจำ
ซอฟต์แวร์จัดตารางนัดหมาย ทั้งแบบบริการออนไลน์และแบบปลั๊กอิน จะแสดงช่วงเวลาที่ว่างจริง และเชื่อมต่อกับผู้ให้บริการชำระเงิน ลูกค้าเลือกเวลา จ่ายมัดจำหรือจ่ายเต็มจำนวน แล้วช่วงเวลานั้นก็เป็นของเขา เครื่องมือที่ดียังจัดการข้อความเตือนนัด การเลื่อนนัด และการคืนเงินตามกฎของคุณได้ด้วย
ข้อจำกัด: คุณต้องรับข้อจำกัดของเครื่องมือมาด้วย จึงควรตรวจว่ามันรองรับกฎจริงของคุณ (มัดจำแยกตามบริการ ชั่วโมงทำงานของพนักงาน เวลาเผื่อระหว่างนัด) ก่อนตัดสินใจ โรงแรมมีความต้องการเพิ่มเติม เช่น แผนราคา และระบบจัดการช่องทางขาย (channel manager) ซึ่งอธิบายไว้ในบทความ เว็บไซต์โรงแรมสำหรับรับจองตรง
หน้าชำระเงินสำหรับบริการราคาคงที่
เมื่อบริการมีราคาคงที่แต่ไม่ต้องใช้ปฏิทิน (ที่นั่งในคอร์ส แพ็กเกจการประเมิน บัตรกำนัล) หน้าชำระเงินสั้น ๆ ก็ใช้ได้ดี บน WordPress มักเป็นฟอร์มที่มีขั้นตอนชำระเงิน หรือปลั๊กอินร้านค้าแบบเบา ๆ ที่ตั้งค่าไว้สำหรับบริการเพียงไม่กี่รายการ
ข้อจำกัด: มันอาจค่อย ๆ ขยายจนกลายเป็นร้านค้าที่คุณต้องดูแล ถ้าคุณขายสินค้าที่จับต้องได้ด้วย เรื่องที่ต้องตัดสินใจในบทความ การออกแบบเว็บไซต์อีคอมเมิร์ซ ก็ใช้กับกรณีนี้ด้วย
การจ่ายใบแจ้งหนี้ออนไลน์
สำหรับงานที่เรียกเก็บเงินหลังส่งมอบ เครื่องมือออกใบแจ้งหนี้และโปรแกรมบัญชีหลายตัว สามารถเพิ่มลิงก์ “ชำระเงินเลย” ในใบแจ้งหนี้แต่ละใบ ซึ่งจะเปิดหน้าชำระเงินของผู้ให้บริการ พร้อมกรอกยอดเงินและเลขอ้างอิงไว้ให้แล้ว
ข้อจำกัด: หน้า “จ่ายใบแจ้งหนี้ออนไลน์” แบบทั่วไป ที่ลูกค้าต้องพิมพ์เลขใบแจ้งหนี้และยอดเงินเอง มักทำให้พิมพ์ผิด และมีเงินเข้าที่ไม่มีใครจับคู่ได้ การใช้ลิงก์แยกต่อใบแจ้งหนี้ช่วยเลี่ยงปัญหานี้ และเมื่อเชื่อมเครื่องมือเข้าด้วยกันแล้ว ระบบจะทำเครื่องหมายว่าใบแจ้งหนี้ชำระแล้วโดยอัตโนมัติ
ลิงก์ หน้าชำระเงิน หรือระบบจอง
เลือก payment gateway ให้เว็บไซต์
ในทางปฏิบัติ การเลือก “payment gateway” (ช่องทางรับชำระเงินออนไลน์) หมายถึงการเลือกผู้ให้บริการที่ดูแลหน้าชำระเงิน และโอนเงินเข้าบัญชีธนาคารของคุณ บริการที่มีให้ใช้ต่างกันไปในแต่ละประเทศ แต่ผู้ให้บริการแบ่งได้กว้าง ๆ เป็นสามประเภท:
- แพลตฟอร์มรับชำระเงินออนไลน์ สมัครได้เร็ว มีหน้าชำระเงินสำเร็จรูป ลิงก์ชำระเงิน และปลั๊กอินสำหรับเครื่องมือยอดนิยม
- บริการรับชำระเงินสำหรับร้านค้าจากธนาคารของคุณ (merchant services) ซึ่งอาจเหมาะกับยอดขายสูง แต่มักมีเอกสารมากกว่า และมีตัวเชื่อมต่อกับเว็บไซต์แบบสำเร็จรูปน้อยกว่า
- ระบบชำระเงินที่มีอยู่ในซอฟต์แวร์ที่คุณใช้อยู่แล้ว เครื่องมือจองและออกใบแจ้งหนี้หลายตัว รองรับผู้ให้บริการเพียงไม่กี่ราย
บ่อยครั้งวิธีที่ได้ผลที่สุดคือ เลือกเครื่องมือจองหรือออกใบแจ้งหนี้ก่อน แล้วค่อยเปรียบเทียบผู้ให้บริการที่เครื่องมือนั้นรองรับ
ค่าธรรมเนียมและเงื่อนไขที่ต้องตรวจ
เปรียบเทียบผู้ให้บริการโดยใช้มูลค่าการจองจริงของคุณ ไม่ใช่อัตราที่โฆษณาไว้
ข้อมูลบัตรอยู่ที่ไหน และทำไมไม่ควรเป็นเว็บไซต์คุณ
การตัดสินใจทางเทคนิคที่สำคัญที่สุดคือ ลูกค้าจะพิมพ์เลขบัตรที่ไหน คำตอบที่ปลอดภัยมีสองแบบ
หน้าชำระเงินที่ผู้ให้บริการโฮสต์ ลูกค้าจ่ายเงินบนโดเมนของผู้ให้บริการ แล้วกลับมาที่เว็บไซต์ของคุณ ซึ่งไม่เคยแตะข้อมูลบัตรเลย
ช่องกรอกข้อมูลบัตรแบบฝัง ช่องกรอกบัตรอยู่ในหน้าเว็บของคุณ แต่ผู้ให้บริการเป็นผู้แสดงผลในกรอบที่ปลอดภัย เลขบัตรจึงส่งตรงไปถึงผู้ให้บริการ
หลีกเลี่ยงการตั้งค่าใด ๆ ที่เลขบัตรต้องผ่านเซิร์ฟเวอร์หรือฟอร์มของคุณเอง เพราะนั่นทำให้เว็บไซต์ของคุณเข้าไปอยู่ในห่วงโซ่การจัดการข้อมูลบัตร และต้องทำตามข้อกำหนดที่หนักกว่ามาก
ใช้ผู้ให้บริการภายนอก ยังไม่จบแค่นั้น
PCI DSS ซึ่งเป็นมาตรฐานความปลอดภัยข้อมูลของอุตสาหกรรมบัตร ใช้กับทุกธุรกิจที่รับชำระด้วยบัตร แม้ผู้ให้บริการจะเป็นผู้จัดการข้อมูลบัตรก็ตาม การใช้หน้าชำระเงินของผู้ให้บริการ หรือช่องกรอกแบบฝัง ช่วยให้ส่วนที่คุณต้องรับผิดชอบเล็กที่สุดเท่าที่จะทำได้
แต่เว็บไซต์ของคุณก็ยังสำคัญ ผู้โจมตีที่เจาะเข้าเว็บไซต์ได้ สามารถแทรกฟอร์มบัตรปลอม หรือเปลี่ยนปุ่ม “ชำระเงินเลย” ให้ชี้ไปยังหน้าเลียนแบบ อัปเดต CMS และปลั๊กอินอยู่เสมอ และใช้สคริปต์จากบุคคลที่สามบนหน้าที่นำไปสู่การชำระเงินให้น้อยที่สุด ส่วนที่เหลืออยู่ใน คู่มือความปลอดภัย WordPress
ตรวจสอบด้วยตัวเอง ลองทำตามขั้นตอนชำระเงินของคุณเอง ถ้าเป็นหน้าของผู้ให้บริการ แถบที่อยู่จะแสดงโดเมนของผู้ให้บริการตอนถึงช่องกรอกบัตร ถ้าช่องกรอกอยู่บนหน้าเว็บของคุณเอง ให้ถามคนที่ทำเว็บไซต์ว่า “นี่คือช่องกรอกแบบฝังของผู้ให้บริการใช่ไหม” และ “เลขบัตรเคยมาถึงเซิร์ฟเวอร์ของเราบ้างไหม แม้เพียงชั่วครู่” คำตอบที่คุณต้องการคือ ใช่ และ ไม่
ออกแบบขั้นตอนชำระเงินให้คนจ่ายอย่างมั่นใจ
แสดงราคาและเงื่อนไขก่อนฟอร์ม
ระบุราคาเต็ม ยอดมัดจำ วันครบกำหนดชำระส่วนที่เหลือ และเงื่อนไขการยกเลิก เป็นประโยคธรรมดาที่อ่านง่ายบนหน้าจอง พร้อมสกุลเงิน และบอกว่ารวมภาษีแล้วหรือไม่ ลิงก์ “ข้อกำหนดและเงื่อนไข” ข้างปุ่มยังไม่พอ เพราะมีคนเปิดอ่านน้อยมาก
ฟอร์มสั้น และไม่ถามซ้ำ
ถามเฉพาะสิ่งที่การนัดหมายต้องใช้ และส่งต่อชื่อกับอีเมลจากขั้นตอนจองไปยังขั้นตอนชำระเงิน แทนที่จะถามอีกครั้ง WCAG 2.2 ซึ่งเป็นมาตรฐานการเข้าถึงสำหรับทุกคนของ W3C พูดถึงเรื่องนี้โดยตรงในเกณฑ์ความสำเร็จ Redundant Entry (ข้อ 3.3.7) บทความ การออกแบบฟอร์มบนเว็บ อธิบายเรื่องช่องกรอก ป้ายกำกับ และข้อความแจ้งข้อผิดพลาด
ให้หน้าชำระเงินของผู้ให้บริการทำหน้าที่
หน้าชำระเงินของผู้ให้บริการมักรองรับบัตรที่บันทึกไว้ วอลเล็ตในมือถือ และข้อผิดพลาดต่าง ๆ อยู่แล้ว และผู้คนก็คุ้นหน้าตาของมัน ใส่โลโก้และสีของคุณได้ แต่อย่าปรับแต่งจนจำไม่ได้ ตัวอย่างเช่น ในสหราชอาณาจักรและเขตเศรษฐกิจยุโรป กฎการยืนยันตัวตนลูกค้าแบบเข้มงวด ทำให้การจ่ายด้วยบัตรออนไลน์จำนวนมาก ต้องผ่านการตรวจสอบเพิ่มกับธนาคารของลูกค้า (ปกติคือ 3-D Secure) ซึ่งผู้ให้บริการที่ดีจัดการให้ภายในหน้าชำระเงิน เนื้อหาส่วนใหญ่ใน การปรับปรุงหน้าชำระเงิน ใช้กับการจองที่มีรายการเดียวได้ด้วย
ยืนยันให้ชัด และรับมือเมื่อบัตรถูกปฏิเสธ
หน้ายืนยันและอีเมลควรบอกว่าจองอะไร กับใคร เมื่อไร ที่ไหน จ่ายไปเท่าไรและเหลือเท่าไร และจะเลื่อนนัดได้อย่างไร พร้อมคำเชิญในปฏิทิน บนเว็บไซต์หลายภาษา ขั้นตอนชำระเงินและอีเมลควรเป็นภาษาที่ลูกค้าเลือก เมื่อบัตรถูกปฏิเสธ ให้บอกตรง ๆ กันช่วงเวลานั้นไว้ชั่วครู่ และเสนอช่องทางชำระอื่น
ตั้งกฎมัดจำ การยกเลิก และการคืนเงินก่อน
ปัญหาการชำระเงินส่วนใหญ่คือปัญหาด้านนโยบาย ตัดสินใจเรื่องเหล่านี้ก่อน เขียนแต่ละข้อให้จบในประโยคเดียว และใช้ถ้อยคำเดียวกันทั้งบนหน้าจอง หน้าชำระเงิน และอีเมลยืนยัน
- มัดจำหรือจ่ายเต็ม มัดจำเหมาะกับการนัดหมายที่ความเสี่ยงหลักคือลูกค้าไม่มาตามนัด ส่วนการจ่ายเต็มเหมาะกับคอร์สที่มีที่นั่งจำกัด
- คืนเงินหรือเปลี่ยนเป็นเครดิต มัดจำที่เปลี่ยนเป็นเครดิตสำหรับการจองครั้งต่อไป มักรู้สึกยุติธรรมกว่าการยึดไปเฉย ๆ และทำให้ลูกค้ามีเหตุผลน้อยลงที่จะโต้แย้งรายการเรียกเก็บเงิน
- ช่วงเวลายกเลิก ลูกค้ายกเลิกหรือเลื่อนนัดได้ช้าที่สุดเมื่อไร โดยยังได้เงินคืน?
- ลูกค้าไม่มาตามนัด ยึดมัดจำ หรือเรียกเก็บจากบัตรที่บันทึกไว้? ผู้ให้บริการเป็นผู้เก็บข้อมูลบัตร และลูกค้าต้องยินยอมต่อการเรียกเก็บนั้นอย่างชัดเจนตอนจอง
- กรณีคุณยกเลิกเอง คืนเงินเต็มจำนวนโดยเร็ว
ผู้ให้บริการบางรายให้คุณกันวงเงินไว้บนบัตรแทนการเก็บมัดจำ แต่การกันวงเงินมีวันหมดอายุ สำหรับการชำระออนไลน์มักราวหนึ่งสัปดาห์ จึงเหมาะกับการจองล่วงหน้าไม่กี่วัน ไม่ใช่หลายสัปดาห์ กฎหมายคุ้มครองผู้บริโภคเรื่องการยกเลิกบริการที่ซื้อออนไลน์แตกต่างกันในแต่ละประเทศ จึงควรตรวจสอบว่ากฎหมายใดใช้กับพื้นที่ที่ลูกค้าของคุณอยู่
เชื่อมการชำระเงินกับการจองและบัญชี
ยืนยันการจองจากการแจ้งเตือนของผู้ให้บริการ
เมื่อการชำระเงินสำเร็จ ล้มเหลว หรือถูกคืนเงิน ผู้ให้บริการสามารถส่งข้อความตรงไปยังเซิร์ฟเวอร์ของเว็บไซต์คุณ เรียกว่า webhook ให้ทำเครื่องหมายว่าการจองชำระแล้ว ก็ต่อเมื่อข้อความนั้นมาถึงและลายเซ็นตรวจสอบผ่านเท่านั้น เพราะบางคนปิดแท็บก่อนหน้าขอบคุณจะโหลดเสร็จ กันช่วงเวลาไว้ระหว่างที่ลูกค้ากำลังจ่าย และปล่อยคืนโดยอัตโนมัติหากเขาจ่ายไม่สำเร็จ เพื่อไม่ให้เกิดการจองซ้อน
ใช้เลขอ้างอิงเดียวกันในทุกระบบ
ใส่เลขการจองหรือเลขใบแจ้งหนี้ไว้ในช่องอ้างอิงของการชำระเงิน เพื่อให้แดชบอร์ดของผู้ให้บริการ ระบบจอง และบัญชี ชี้ไปยังรายการเดียวกัน อย่าใส่รายละเอียดที่อ่อนไหว ใช้ “นัดหมาย 1042” ไม่ใช่ชื่อการรักษา ตั้งชื่อที่แสดงบนใบแจ้งยอดบัตรให้ลูกค้าจำได้ เพราะรายการเรียกเก็บที่ไม่คุ้นตา เป็นรายการที่ถูกโต้แย้งได้ง่าย
กระทบยอดเงินโอนและวัดผลการจอง
เงินที่โอนเข้าบัญชีมักมาเป็นก้อน โดยหักค่าธรรมเนียมไว้แล้ว จึงควรเชื่อมผู้ให้บริการเข้ากับโปรแกรมบัญชี เพื่อแยกแต่ละก้อนเป็นรายการชำระเงิน ค่าธรรมเนียม และการคืนเงิน ตรวจสอบด้วยว่าคุณต้องออกใบเสร็จหรือใบกำกับภาษีแบบใด เพราะใบเสร็จของผู้ให้บริการอาจไม่เพียงพอเสมอไป
จากนั้นบันทึกการจองที่ยืนยันและชำระแล้วเป็น key event ใน Google Analytics โดยให้บันทึกเมื่อการจองได้รับการยืนยัน ไม่ใช่เมื่อมีคนกดปุ่ม และไม่มีชื่อหรืออีเมลอยู่ในข้อมูล บทความ การติดตาม conversion ใน GA4 อธิบายวิธีทำ ส่วนบทความ อธิบายการเชื่อมต่อระบบของเว็บไซต์ แสดงให้เห็นว่าการจอง การชำระเงิน CRM และบัญชี ทำงานร่วมกันอย่างไร
เช็กลิสต์ความปลอดภัยและความเป็นส่วนตัว
คำถามที่พบบ่อย
ถ้าผู้ให้บริการชำระเงินดูแลข้อมูลบัตรให้ ยังต้องรับผิดชอบเรื่อง PCI DSS อยู่ไหม?
ใช่ แต่ภาระเบากว่ามาก เมื่อข้อมูลบัตรถูกกรอกเฉพาะในหน้าชำระเงินของผู้ให้บริการ หรือช่องกรอกแบบฝังเท่านั้น โดยทั่วไปคุณจะเข้าเกณฑ์การตรวจสอบระดับที่ง่ายที่สุด และผู้ให้บริการบางรายจัดการเอกสารให้คุณด้วย ผู้ให้บริการหรือธนาคารผู้รับบัตร (acquiring bank) ของคุณจะยืนยันว่าข้อกำหนดใดใช้กับคุณ
ลูกค้าจ่ายเงินเป็นสกุลเงินของตัวเองได้ไหม?
ผู้ให้บริการหลายรายเรียกเก็บได้หลายสกุลเงิน และโอนให้คุณเป็นสกุลเงินของคุณ ก่อนเปิดใช้ ให้ตรวจว่าใครเป็นผู้รับภาระค่าแปลงสกุลเงิน และการคืนเงินในสกุลเงินต่างประเทศทำงานอย่างไร
จะทดสอบการชำระเงินก่อนใช้งานจริงได้อย่างไร?
ใช้โหมดทดสอบของผู้ให้บริการ ซึ่งรับเลขบัตรทดสอบที่เผยแพร่ไว้ และไม่มีการเคลื่อนย้ายเงินจริง ลองทั้งการจ่ายที่สำเร็จ บัตรถูกปฏิเสธ การคืนเงิน และการยกเลิก แล้วตรวจว่าแต่ละกรณีอัปเดตการจอง อีเมล และข้อมูลในระบบของคุณ
ขั้นตอนต่อไป
การชำระเงินได้ผลดีที่สุด เมื่อวางแผนกฎ เครื่องมือ และหน้าเว็บไปพร้อมกัน:
- หาจุดที่การรับเงินเป็นปัญหา เช่น ต้องตามทวงใบแจ้งหนี้ ลูกค้าไม่มาตามนัด หรือต้องจับคู่ยอดโอนกับการจอง
- เขียนกฎมัดจำ การยกเลิก และการคืนเงิน
- เลือกตัวเลือกที่เบาที่สุดที่แก้ปัญหาได้ แล้วเลือกผู้ให้บริการที่ตัวเลือกนั้นรองรับ
- สร้างหน้าเว็บโดยใช้หน้าชำระเงินของผู้ให้บริการเป็นแกนหลัก
- ทดสอบทุกเส้นทาง เปิดใช้งานจริง และติดตามการจองที่ชำระแล้ว
ถ้าคุณกำลังวางแผนเว็บไซต์ใหม่ ให้พูดเรื่องการจองและการชำระเงินตั้งแต่การคุยครั้งแรก เพราะการออกแบบไว้ตั้งแต่ต้อง ง่ายกว่าการมาต่อเติมทีหลังมาก บทความ การเชื่อมต่อระบบของเว็บไซต์ ของเราอธิบายว่าเว็บไซต์เชื่อมกับเครื่องมือจองและชำระเงินที่อยู่เบื้องหลังอย่างไร และ ตรวจสอบเว็บไซต์ฟรี จะแสดงให้เห็นว่าวันนี้ผู้เข้าชมติดต่อและจองกับคุณได้ง่ายแค่ไหน