Loading
บทความที่เกี่ยวข้อง
บทความที่เกี่ยวข้อง
TrustFinance Research Team
ต.ค. 12, 2026
2 min read
2
Authorized โดยทั่วไปหมายถึงการอนุมัติและกันยอดไว้บนวิธีชำระเงินที่รองรับ ส่วน Captured หมายถึงรายการได้ผ่านจากขั้นอนุมัติอย่างเดียวไปสู่การเรียกเก็บแล้ว สถานะใดสถานะหนึ่งไม่ได้ยืนยันว่าเงินโอนเข้าบัญชีธนาคารของร้านค้าแล้ว
ก่อนดำเนินการให้อ่านนิยามของผู้ให้บริการ การส่งคำขอ capture การรับคำขอไว้ และผลประมวลผลจริงอาจเป็นคนละเหตุการณ์ ชื่อในคู่มือนี้ใช้อธิบายแต่ละขั้น ไม่ได้หมายความว่าทุกระบบใช้ชื่อสถานะเหมือนกัน
รายการบนบัตรอาจแสดงยอดกันไว้คล้ายยอดเรียกเก็บสำเร็จ ภาพหน้าจอที่ลูกค้าส่งมาช่วยประกอบการตรวจ แต่ควรเทียบกับประวัติรายการของผู้ให้บริการก่อนถือว่าคำสั่งซื้อได้รับชำระแล้ว
เชื่อมเลขคำสั่งซื้อ เลขอ้างอิงการอนุมัติ และเลขอ้างอิงการเรียกเก็บไว้ด้วยกัน จากนั้นกระทบยอดกับข้อมูล settlement และ payout แยกต่างหาก ยอดขายรวมบนหน้าจอเดียวตอบไม่ได้ว่าทุกรายการเข้าธนาคารแล้วหรือยัง
| ขั้นตอน | สิ่งที่ต้องตรวจ | สิ่งที่ยังยืนยันไม่ได้ |
|---|---|---|
| Authorized | การกันยอดที่รองรับและเวลาหมดอายุจริง | เงินเข้าบัญชีธนาคารร้านค้า |
| ส่งคำขอ capture | เลขอ้างอิงคำขอและผลประมวลผล | ผลสำเร็จจากคำตอบรับเพียงอย่างเดียว |
| Captured | สถานะเรียกเก็บที่ผู้ให้บริการยืนยันและประวัติภายหลัง | Settlement การโอนเข้าธนาคาร หรือการไม่มีข้อพิพาท |
| Settlement | ข้อมูลยอดคงเหลือหรือการชำระบัญชีของผู้ให้บริการ | เงินเข้าธนาคารร้านค้าแล้ว |
| Payout | เลขอ้างอิงการโอนที่กระทบยอดกับธนาคาร | การได้รับเงินเพียงเพราะส่งคำสั่งโอน |
เริ่มจากตรวจว่าวิธีชำระเงิน บัญชีร้านค้า และรายการนั้นรองรับการเรียกเก็บแยกจากการอนุมัติหรือไม่ บางวิธีเรียกเก็บอัตโนมัติหรือไม่รองรับ manual capture อย่าใช้ความสามารถของบัตรแทนเงื่อนไขการหักบัญชีหรือกระเป๋าเงินทุกชนิด
ตรวจการตั้งค่า capture ของรายการจริง แบบอัตโนมัติ แบบหน่วงเวลาอัตโนมัติ และแบบร้านค้าสั่งเองมีหน้าที่ติดตามต่างกัน ค่าเริ่มต้นของบัญชีอาจต่างจากค่าระดับรายการที่ระบบอนุญาต ใบยืนยันคำสั่งซื้อใช้แทนการตรวจนี้ไม่ได้
ดูเวลาหมดอายุของรายการและเขตเวลาที่ใช้จริง เครือข่ายบัตร ประเภทธุรกรรม ประเทศ และกฎผู้ให้บริการอาจทำให้ระยะเวลาต่างกัน อย่านำกำหนดเจ็ดวันหรือ 28 วันไปใช้กับทุกรายการ
การขยายอายุ authorization และการ capture บางส่วนหลายครั้งเป็นคุณสมบัติที่มีเงื่อนไข ต้องตรวจสิทธิและการเปิดใช้ปัจจุบันก่อนพึ่งพา ระยะเวลาส่งสินค้าที่ยาวไม่ได้ทำให้ยอดกันวงเงินเดิมมีอายุเพิ่มขึ้นเอง
ตรวจสกุลเงิน ยอดอนุมัติ ยอดที่ยังเรียกเก็บได้ และเลขอ้างอิงให้ตรงก่อนส่งคำขอ ยอดที่ยกเลิกหรือหมดอายุ จำนวนที่ระบบไม่รองรับ หรือสกุลเงินไม่ตรงอาจทำให้ดำเนินการไม่สำเร็จ
การตอบรับคำขอแบบประมวลผลภายหลังยังไม่ใช่ผลสำเร็จ เช่น Adyen แยกคำขอที่รับไว้จากผล webhook และอธิบายกรณี CAPTURE_FAILED ที่อาจเกิดตามมา ต้องตรวจผลจริงและประวัติหลังจากนั้นด้วย
สมมติคำสั่งซื้อผ่านบัตรที่รองรับเป็นเงิน 1,200 หน่วย อนุมัติวันที่ 1 เวลา 10:00 UTC และยกตัวอย่างการเรียกเก็บวันที่ 2 เวลา 10:00 UTC สมมติหมดอายุวันที่ 3 เวลา 18:00 UTC ตัวเลขและเวลาทั้งหมดสร้างขึ้นเพื่ออธิบาย
ในขั้นแรกบันทึกยอดอนุมัติ 1,200 และยอดเรียกเก็บศูนย์ นี่เป็นยอดที่กันฝั่งลูกค้า ไม่ใช่เงินสดร้านค้า 1,200 หรือเงินสำรองของผู้ประมวลผล ตัวอย่างละค่าธรรมเนียมและภาษีไว้เพื่อความชัดเจน ไม่ได้อ้างว่าบริการจริงไม่มีค่าใช้จ่าย
ในทางเลือกเรียกเก็บบางส่วน สมมติผู้ให้บริการยืนยันการประมวลผลเรียกเก็บ 900 และระบบสมมตินี้รองรับเพียงครั้งเดียว ส่วนที่ไม่ได้ใช้ 300 ถูกยกเลิกหรือปล่อยตามเงื่อนไขดังกล่าว โดย 1,200 ลบ 900 เท่ากับ 300
อีกทางเลือกหนึ่ง ร้านค้ายกเลิกการอนุมัติเต็มยอดก่อนเรียกเก็บใด ๆ ยอดกัน 1,200 เข้าสู่ขั้นตอนยกเลิกหรือปล่อยวงเงินที่รองรับ ทางเลือกนี้ไม่มีรายการเรียกเก็บให้คืนเงิน และไม่ได้กำหนดเวลาที่ธนาคารลูกค้าจะแสดงการปล่อยยอด
อีกทางเลือกคือไม่ได้เรียกเก็บก่อนกำหนดสมมติ เมื่อ authorization หมดอายุ จะนำยอดกันเดิมมาเรียกเก็บภายหลังโดยตรงไม่ได้ หากจะขออนุมัติใหม่ต้องใช้กระบวนการที่ผู้ให้บริการอนุญาตและมีความยินยอมของลูกค้าที่เหมาะสม
แต่ละทางเลือกไม่ใช่ยอดที่นำมาบวกกัน ส่วนที่ไม่ได้ใช้ 300 ในแบบจำลองไม่ใช่เงินคืนจากยอดเรียกเก็บ 900 แม้มีผลยืนยันการเรียกเก็บแล้ว ก็ยังต้องตรวจ settlement และการเข้าธนาคารแยกต่างหาก
| ทางเลือกของตัวอย่าง | ยอดเรียกเก็บ | ยอดอนุมัติที่ไม่ใช้ | การตรวจแยก |
|---|---|---|---|
| เรียกเก็บบางส่วนวันที่ 2 | 900 | 300 ยกเลิกหรือปล่อยตามสมมติฐานว่าทำได้ครั้งเดียว | ผล capture, settlement และยอดเข้าธนาคาร |
| ยกเลิกก่อนเรียกเก็บ | 0 | 1,200 เข้ากระบวนการยกเลิกหรือปล่อย | สถานะผู้ให้บริการและธนาคารลูกค้า |
| ไม่เรียกเก็บก่อนวันที่ 3 เวลา 18:00 UTC | 0 | 1,200 หมดอายุตามกำหนดสมมติ | รายการใหม่ต้องมีขั้นตอนที่ใช้ได้ |
กำหนดนโยบายส่งมอบของร้านให้ชัดเจนตามธุรกิจและวิธีชำระเงิน บางขั้นตอนที่รองรับเรียกเก็บช่วงส่งสินค้า บางขั้นตอนต่างออกไป อย่ารับปากการส่งมอบหรือความคุ้มครองทางการเงินเพียงเพราะ authorization ผ่าน
หาก capture ล้มเหลวหรือยังไม่แน่ใจผล ให้ตรวจประวัติรายการเดิมก่อนลองใหม่หรือสร้างรายการเรียกเก็บใหม่ เทียบเลขอ้างอิงและยอดเงินเพื่อไม่ให้ฝ่ายบริการลูกค้าเรียกเก็บซ้ำโดยไม่ตั้งใจ
เมื่อรายการถูกเรียกเก็บแล้ว การคืนเงินหรือกลับรายการต้องใช้ขั้นตอนที่ผู้ให้บริการรองรับตามกรณี การยกเลิกคำสั่งซื้อในระบบร้านเพียงอย่างเดียวไม่ได้ยกเลิก authorization หรือคืนเงินที่เรียกเก็บไปแล้ว
ถ้ายกเลิกแล้วลูกค้ายังเห็นยอดกันไว้ ให้แจ้งเลขอ้างอิง ยอด และเวลาที่อนุญาตให้ใช้ติดตามกับผู้ให้บริการหรือธนาคาร อย่ารับประกันว่าจะปล่อยทันทีหรือขอข้อมูลบัตรครบชุดจากลูกค้า
ไม่จำเป็นเสมอไป หน้าจอของผู้ออกบัตรอาจทำให้ยอดกันกับยอดเรียกเก็บดูคล้ายกัน ให้เทียบสถานะการชำระ การเรียกเก็บ และการยกเลิกของรายการตรงตัว อธิบายตามหลักฐานปัจจุบันโดยไม่รับปากเวลาประมวลผลของธนาคาร
ทำได้เฉพาะเมื่อขั้นตอนจริงรองรับการเรียกเก็บเพิ่มและ authorization ยังใช้ได้ ตัวอย่างนี้กำหนดชัดว่ารองรับการเรียกเก็บบางส่วนครั้งเดียวแล้วปล่อยส่วนที่เหลือ จึงห้ามถือว่า 300 นั้นนำมาเรียกเก็บได้อีกอัตโนมัติ
เมื่อรู้สถานะ capture แล้ว อ่าน Settlement เงินคืน และ Chargeback เพื่อแยก settlement กับเงินเข้าธนาคาร และ ต้นทุน Payment Gateway รวม เพื่อดูค่าธรรมเนียมกับเงินที่ร้านค้ายังใช้ไม่ได้ อ่านคู่มือเพิ่มเติมได้ที่ TrustFinance Blog
เอกสารทางการด้านล่างอธิบายกลไกเฉพาะผู้ให้บริการที่ตรวจเมื่อ 12 ตุลาคม 2026 ไม่ได้กำหนดวันหมดอายุสากล สิทธิผู้บริโภคในทุกประเทศ หรือรับประกันการได้รับเงิน ให้ตรวจสัญญาของนิติบุคคล บัญชี และวิธีชำระที่ใช้จริง
TrustFinance Research Team
Official TrustFinance research and editorial team, sharing insights, analysis, and best practices to help financial companies and traders build transparency, credibility, and growth.
