เชื่อมต่อ Payment Gateway: คู่มือระบบรับชำระเงินออนไลน์

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

เลือก Payment Gateway ในไทยอย่างไร

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

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

ขั้นตอนการรับชำระเงินที่ถูกต้อง

1. สร้างออเดอร์ฝั่งเซิร์ฟเวอร์ก่อนเสมอ

ก่อนเรียก gateway ให้สร้างออเดอร์สถานะ pending และคำนวณยอดเงินฝั่งเซิร์ฟเวอร์จากข้อมูลสินค้าและส่วนลดในระบบเราเอง ห้ามเชื่อยอดเงินที่ส่งมาจากเบราว์เซอร์หรือแอปเด็ดขาด

2. หน้าชำระเงินและ Tokenization

รูปแบบที่ใช้กันบ่อยมีสามแบบ คือ พาลูกค้าไปหน้าชำระเงินของ gateway (hosted payment page), ฝังช่องกรอกบัตรจาก JavaScript หรือ SDK ของ gateway ที่แปลงข้อมูลบัตรเป็น token ให้ทันที หรือแสดง QR พร้อมเพย์ที่สร้างเฉพาะออเดอร์นั้น สองแบบแรกทำให้เลขบัตรวิ่งจากเครื่องลูกค้าตรงไปที่ gateway เซิร์ฟเวอร์ของเราเห็นแค่ token เท่านั้น

3. 3-D Secure และหน้า Return URL

การจ่ายด้วยบัตรมักต้องยืนยันตัวตนแบบ 3-D Secure กับธนาคารผู้ออกบัตร แล้วจึงพาลูกค้ากลับมาที่เว็บเรา หน้า return URL มีไว้แสดงสถานะให้ลูกค้าดูเท่านั้น เพราะลูกค้าอาจปิดแท็บหรือเน็ตหลุดกลางทาง จึงห้ามเปลี่ยนสถานะออเดอร์เป็น "ชำระแล้ว" เพียงเพราะเบราว์เซอร์กลับมาที่หน้านี้

4. ยึด Webhook เป็นหลักฐานการชำระเงิน

gateway จะส่ง event มาที่เซิร์ฟเวอร์เมื่อรายการสำเร็จ ล้มเหลว หมดอายุ หรือถูกคืนเงิน ตัวรับ webhook ควรตรวจสอบ event ก่อน (เช็ก signature หรือดึงข้อมูล charge จาก API ของ gateway ซ้ำ) อัปเดตออเดอร์เพียงครั้งเดียว ตอบกลับด้วยสถานะ 2xx ให้เร็ว แล้วส่งงานที่ใช้เวลานาน เช่น ส่งอีเมลหรือตัดสต็อก ไปทำใน background queue

POST /webhooks/payments
1. ตรวจ signature หรือดึง charge ตาม ID จาก API ของ gateway
2. เริ่ม database transaction
3. บันทึก event.id ลง processed_events (unique) -> ถ้ามีอยู่แล้ว ตอบ 200 ทันที
4. โหลดออเดอร์จาก metadata ของ charge และล็อกแถวไว้
5. ถ้า charge สำเร็จ และ charge.amount == order.amount_satang: เปลี่ยนเป็นชำระแล้ว
6. commit แล้วตอบ 200
7. ส่งงานต่อเข้า queue: อีเมลใบเสร็จ แจ้งคลังสินค้า

ตัวอย่าง event แบบย่อ (แต่ละ gateway ใช้ชื่อฟิลด์ต่างกัน นี่เป็นเพียงตัวอย่างประกอบ)

{
  "id": "evt_123",
  "type": "charge.succeeded",
  "data": {
    "charge_id": "chrg_456",
    "amount": 159000,
    "currency": "THB",
    "metadata": { "order_id": "ORD-2026-0042" }
  }
}

สังเกตยอดเงิน gateway หลายเจ้าระบุเงินบาทเป็นหน่วยสตางค์ 159000 จึงหมายถึง 1,590.00 บาท ควรเก็บจำนวนเงินเป็นจำนวนเต็มเสมอ ไม่ใช้เลขทศนิยมแบบ floating point

5. Idempotency Key กันตัดเงินซ้ำ

การ timeout และการยิงซ้ำ (retry) เป็นเรื่องปกติของระบบเครือข่าย ถ้าไม่ป้องกันไว้ อาจเกิดการตัดเงินหรือสร้างออเดอร์ซ้ำ ควรแนบ idempotency key (เช่น สร้างจากเลขออเดอร์) ไปกับคำขอสร้าง charge ในกรณีที่ gateway รองรับ และฝั่งเราควรตั้ง unique constraint ให้ charge ID และ event ID เพื่อประมวลผลแต่ละรายการแค่ครั้งเดียว เพราะ gateway เองก็ส่ง webhook ซ้ำเป็นเรื่องปกติ

6. กระทบยอด (Reconciliation)

วันละครั้ง ให้เทียบข้อมูลสามชุด คือ ออเดอร์ที่ระบบเราบันทึกว่าชำระแล้ว รายการที่ gateway บันทึกไว้ และเงินที่เข้าบัญชีธนาคารจริง ยอดที่ gateway โอนมามักหักค่าธรรมเนียม ยอดคืนเงิน และ chargeback ไว้แล้ว ฝ่ายบัญชีจึงต้องการทั้งยอดรวมและยอดสุทธิ รายการไหนไม่ตรงให้แจ้งคนตรวจทันที ไม่ต้องรอปิดงบสิ้นเดือน

7. การคืนเงินและข้อพิพาท

คืนเงินผ่าน API ของ gateway รองรับการคืนบางส่วน และบันทึกการคืนเงินแต่ละครั้งเป็นรายการใหม่ที่ผูกกับ charge เดิม แทนการแก้ไขรายการเก่า ระยะเวลาที่เงินกลับเข้าบัตรลูกค้าขึ้นกับธนาคารผู้ออกบัตร ส่วนกรณีลูกค้าปฏิเสธรายการ (chargeback) ควรเก็บหลักฐาน เช่น หลักฐานการจัดส่งและบทสนทนากับลูกค้าไว้ให้ครบ

ความปลอดภัยและขอบเขต PCI DSS

PCI DSS คือมาตรฐานความปลอดภัยของอุตสาหกรรมบัตร ใช้กับทุกธุรกิจที่รับบัตร ส่วนงานที่ต้องทำมากหรือน้อยขึ้นกับเส้นทางของข้อมูลบัตร

• ใช้หน้าชำระเงินหรือช่องกรอกบัตรของ gateway ข้อมูลบัตรจะไม่เข้าระบบเรา และมักทำให้อยู่ในขอบเขตการประเมินตนเองที่เล็กที่สุด ควรสอบถาม gateway หรือธนาคารผู้รับบัตรว่าต้องใช้แบบประเมินชุดไหน
• ห้ามเก็บเลขบัตรและ CVV และตรวจให้แน่ใจว่า log ระบบ ตัวเก็บ error และเครื่องมือ analytics ไม่ได้บันทึกข้อมูลเหล่านี้ไปโดยไม่ตั้งใจ
• ใช้ tokenization สำหรับการซื้อซ้ำหรือตัดบัตรรายเดือน เก็บ token ลูกค้าหรือ token บัตรจาก gateway แทนข้อมูลบัตรจริง
• เก็บ secret key ไว้ฝั่งเซิร์ฟเวอร์ ใน environment variable หรือ secret manager และเปลี่ยนทันทีถ้าหลุด ฝั่ง frontend ใช้ได้เฉพาะ public key
• ป้องกันหน้าชำระเงิน ด้วย HTTPS, Content Security Policy ที่เข้มงวด และควบคุมสคริปต์จากภายนอก เพราะการฝังสคริปต์แปลกปลอมเป็นวิธีขโมยข้อมูลบัตรที่พบบ่อย
• ดูแลตาม PDPA สำหรับชื่อ ที่อยู่ และเบอร์โทรลูกค้าที่เก็บไว้กับออเดอร์

ข้อผิดพลาดที่พบบ่อย

• เปลี่ยนสถานะเป็นชำระแล้วตอนเบราว์เซอร์ redirect กลับ แทนที่จะรอ webhook
• รับราคาหรือยอดเงินจากฝั่ง client
• ไม่มี idempotency ทำให้ตัดเงินซ้ำหรือออเดอร์ซ้ำ
• endpoint รับ webhook ไม่ตรวจสอบความถูกต้องของ event
• ทำงานหนักใน webhook handler จน timeout แล้วโดน retry ถล่ม
• เก็บเงินเป็นทศนิยมแทนจำนวนเต็มหน่วยสตางค์
• ไม่จัดการสถานะ pending และ expired โดยเฉพาะ QR พร้อมเพย์ที่มีเวลาหมดอายุ
• ใช้ key ของ test และ live ปนกันระหว่าง environment
• ทดสอบแค่กรณีจ่ายผ่าน ไม่ทดสอบบัตรถูกปฏิเสธ 3-D Secure ล้มเหลว หรือ webhook มาช้า
• ไม่กระทบยอดเลยจนฝ่ายบัญชีเจอยอดไม่ตรงตอนปิดเดือน

ระยะเวลาและงบประมาณ

การเชื่อม gateway เจ้าเดียวกับหน้าชำระเงินพื้นฐานเป็นงานไม่ใหญ่ แต่ถ้ารวมการคืนเงิน ระบบสมาชิกรายเดือน หลายช่องทางชำระ รายงานกระทบยอด และหลังบ้านสำหรับแอดมิน ก็จะใช้เวลามากขึ้น ในเรทราคาของ Vectorkub แอปที่มีระบบชำระเงิน ระบบสมาชิก และหน้าแอดมิน มักอยู่ในระดับ Web & Mobile Application ประมาณ 80,000–120,000 บาท ใช้เวลาราว 2–3 เดือน ขึ้นกับขอบเขตงาน ถ้าอยากเห็นภาพงบประมาณในมุมกว้าง อ่านต่อได้ที่ ค่าทำเว็บไซต์ในไทย

คำถามที่พบบ่อย (FAQ)

ต้องมีใบรับรอง PCI DSS ถึงจะรับบัตรได้ไหม?

ร้านค้าทุกรายที่รับบัตรต้องปฏิบัติตาม PCI DSS แต่วิธีรับรองขึ้นกับปริมาณธุรกรรมและรูปแบบการเชื่อมต่อ ถ้าใช้หน้าชำระเงินหรือช่องกรอกบัตรของ gateway ภาระจะน้อยมาก gateway หรือธนาคารผู้รับบัตรจะแจ้งว่าต้องทำอะไรบ้าง

รับพร้อมเพย์โดยไม่ใช้ payment gateway ได้ไหม?

ได้ ธนาคารออก QR พร้อมเพย์แบบ static ให้ได้ แต่ต้องมีคนคอยตรวจยอดโอนเอง ถ้าต้องการยืนยันการชำระแบบอัตโนมัติ ควรใช้ gateway หรือ API ของธนาคารที่สร้าง dynamic QR แยกตามออเดอร์และแจ้งกลับเมื่อชำระแล้ว

Payment gateway เจ้าไหนถูกที่สุด?

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

เชื่อมต่อ payment gateway ใช้เวลานานแค่ไหน?

หน้าชำระเงินพื้นฐานกับ gateway เจ้าเดียวใช้เวลาพัฒนาตั้งแต่ไม่กี่วันถึงราวสองสัปดาห์ ส่วนระบบเต็มรูปแบบที่มีการคืนเงิน ตัดบัตรรายเดือน กระทบยอด และเครื่องมือหลังบ้าน ใช้เวลานานกว่านั้น และควรทดสอบใน sandbox ให้ครบก่อนขึ้นระบบจริง

ทำให้ถูกตั้งแต่ครั้งแรก

ระบบรับชำระเงินออนไลน์คือจุดที่ทางลัดเล็กๆ กลายเป็นเงินที่หายไปจริง ทีมพัฒนาซอฟต์แวร์ตามสั่ง ของเราพัฒนาหน้าชำระเงิน ระบบรับ webhook และระบบกระทบยอดให้ธุรกิจไทยด้วย Go, NestJS และ PostgreSQL ปรึกษาเรื่องระบบชำระเงินกับเรา แล้วเราจะช่วยเลือก gateway และวางขอบเขตงานเชื่อมต่อให้เหมาะกับธุรกิจของคุณ