การชำระเงินด้วยบัตร
การชำระเงินด้วยบัตร: จากเครื่องรับบัตรถึงผู้รับชำระเงิน และกลับเข้าบัญชีแยกประเภท
เครื่องรับบัตร EMV และเกตเวย์การชำระเงินที่เชื่อมต่อกับผู้รับชำระเงินผ่าน ISO 8583 หรือ API พร้อมไฟล์การชำระบัญชีที่กระทบยอดใน ERP
พิมพ์เขียว
เลื่อนแนวนอนเพื่อดูภาพทั้งภาพ
การชำระเงินด้วยบัตร: อนุมัติที่เคาน์เตอร์ ชำระบัญชีภายหลัง กระทบยอดใน ERP
เครื่องหรือหน้าชำระเงินถามเกตเวย์ เกตเวย์ถามธนาคารผู้รับชำระ และธนาคารผู้รับชำระส่งต่อไปยังเครือข่ายบัตรและผู้ออกบัตร ไฟล์ชำระบัญชีมาถึงภายหลังและจับคู่กับยอดขายและค่าธรรมเนียมใน ERP การหมดเวลาทำให้เกิดการกลับรายการ เพื่อไม่ให้ลูกค้าถูกเรียกเก็บซ้ำ
- เส้นทางหลัก
- แบบอะซิงโครนัส
- เส้นทางข้อยกเว้น
ขั้นตอนการทำงาน 8 ขั้นตอน
ขั้นตอนการทำงานทีละขั้น
- จาก เครื่อง EMV หรือหน้าชำระเงินออนไลน์ ไปยัง เกตเวย์การชำระเงิน: คำขออนุมัติ ผ่าน EMV · REST/JSON (เส้นทางหลัก)
- จาก เกตเวย์การชำระเงิน ไปยัง ธนาคารผู้รับชำระ: การอนุมัติ ผ่าน ISO 8583 (เส้นทางหลัก)
- จาก ธนาคารผู้รับชำระ ไปยัง เครือข่ายบัตรและผู้ออกบัตร: ส่งต่อไปยังผู้ออกบัตร ผ่าน ISO 8583 (เส้นทางหลัก)
- จาก ธนาคารผู้รับชำระ ไปยัง เกตเวย์การชำระเงิน: อนุมัติหรือปฏิเสธ ผ่าน ISO 8583 (แบบอะซิงโครนัส)
- จาก ธนาคารผู้รับชำระ ไปยัง ชั้นการเชื่อมต่อ: ไฟล์ชำระบัญชีและค่าธรรมเนียม ผ่าน SFTP (แบบอะซิงโครนัส)
- จาก ชั้นการเชื่อมต่อ ไปยัง ERP: ยอดขาย ค่าธรรมเนียม และการจ่ายเงินที่ชำระบัญชีแล้ว ผ่าน REST/JSON (เส้นทางหลัก)
- จาก เกตเวย์การชำระเงิน ไปยัง เครื่อง EMV หรือหน้าชำระเงินออนไลน์: ไม่มีการตอบกลับทันเวลา: กลับรายการอัตโนมัติ ผ่าน ISO 8583 0400 (เส้นทางข้อยกเว้น)
- จาก ชั้นการเชื่อมต่อ ไปยัง ทีมปฏิบัติการชำระเงิน: รายการชำระบัญชีไม่ตรงหรือการเรียกคืนเงิน (เส้นทางข้อยกเว้น)
ภาพรวม
นี่คือเส้นทางของการชำระเงินด้วยบัตร ตั้งแต่เครื่องรับบัตรหรือหน้าชำระเงินออนไลน์ไปยังผู้รับชำระเงิน เครือข่ายบัตร และผู้ออกบัตร แล้วย้อนกลับ ลูกค้ารอคำตอบที่เคาน์เตอร์ เงินหักค่าธรรมเนียมแล้วจะมาถึงภายหลังในไฟล์การชำระบัญชีที่ต้องจับคู่กับยอดขายใน ERP ของคุณ
การออกแบบอ้างอิงส่งการอนุมัติผ่านเกตเวย์การชำระเงินที่แปลงบัตรเป็นโทเคนและส่งคำขอไปยังผู้รับชำระเงินผ่าน ISO 8583 หรือ API ของผู้รับชำระเงิน ไฟล์การชำระบัญชีและค่าธรรมเนียมถูกเก็บโดยชั้นการเชื่อมต่อ จับคู่กับยอดขายเดิม และบันทึกเข้า ERP เป็นยอดขาย ค่าธรรมเนียม และเงินที่จ่ายออก
การออกแบบยังครอบคลุมสิ่งที่ไม่เป็นไปตามแผน คำขอที่ไม่ได้รับคำตอบทันเวลาจะถูกย้อนรายการ ลูกค้าจึงไม่ถูกเรียกเก็บซ้ำ การชำระบัญชีที่ไม่ตรงกัน หรือการเรียกคืนเงิน จะส่งต่อให้ทีมปฏิบัติการชำระเงินของคุณพร้อมยอดขายเดิมแนบไปด้วย
กระบวนการ
เริ่มที่เครื่องรับบัตรหรือหน้าชำระเงิน
เครื่องรับบัตร EMV อ่านชิปหรือบัตรแบบไม่สัมผัส หรือหน้าชำระเงินออนไลน์เก็บข้อมูลบัตรผ่านหน้าที่โฮสต์ไว้ แล้วส่งคำขออนุมัติไปยังเกตเวย์
อนุมัติผ่านเกตเวย์
เกตเวย์แทนที่หมายเลขบัตรด้วยโทเคนและส่งคำขออนุมัติไปยังผู้รับชำระเงิน ผ่าน ISO 8583 หรือ API ของผู้รับชำระเงิน
ส่งต่อไปยังผู้ออกบัตร
ผู้รับชำระเงินส่งคำขอผ่านเครือข่ายบัตรไปยังผู้ออกบัตร ซึ่งอนุมัติหรือปฏิเสธ
ส่งคำตอบกลับ
การอนุมัติหรือการปฏิเสธย้อนกลับตามเส้นทางเดิมไปยังเครื่องรับบัตรหรือหน้าชำระเงิน พร้อมรหัสตอบกลับ
รับการชำระบัญชี
ผู้รับชำระเงินส่งไฟล์การชำระบัญชีและค่าธรรมเนียมในภายหลัง ซึ่งชั้นการเชื่อมต่อเก็บและตรวจสอบ
จับคู่และบันทึก
ชั้นนี้จับคู่ธุรกรรมที่ชำระบัญชีแล้วกับยอดขายเดิม และบันทึกยอดขาย ค่าธรรมเนียม และเงินที่จ่ายออกเข้า ERP
เมื่อระบบเกิดข้อขัดข้อง
ไม่ได้รับคำตอบทันเวลา
หากเกตเวย์ไม่ได้รับคำตอบภายในเวลาที่ผู้รับชำระเงินกำหนด จะส่งการย้อนรายการ ซึ่งเป็นข้อความ ISO 8583 0400 หรือสิ่งที่เทียบเท่าใน API ลูกค้าจึงไม่ถูกเรียกเก็บสำหรับยอดขายที่ไม่ได้สำเร็จ
การชำระเงินถูกปฏิเสธ
รหัสตอบกลับไปถึงเคาน์เตอร์หรือหน้าชำระเงินพร้อมข้อความที่ชัดเจน มีการเฝ้าระวังอัตราการปฏิเสธ การเพิ่มขึ้นที่ชี้ไปยังข้อขัดข้องทางเทคนิคจึงแจ้งเตือน
การชำระบัญชีไม่ตรงกัน
ยอดที่ชำระบัญชีซึ่งต่างจากยอดขาย หรือยอดขายที่ไม่มีการชำระบัญชี จะเข้าสู่รายการรอตรวจทานสำหรับทีมปฏิบัติการชำระเงินของคุณ พร้อมบันทึกทั้งสองข้างเคียงกัน
ผู้ถือบัตรโต้แย้งการชำระเงิน
รายงานข้อโต้แย้งของผู้รับชำระเงินถูกนำเข้าและเชื่อมโยงกับยอดขายและการชำระบัญชีเดิม ทีมของคุณจึงตอบกลับพร้อมหลักฐานได้ในที่เดียว
มาตรฐานและระบบ
- มาตรฐานและช่องทางธนาคาร
- SFTP (H2H)
- การชำระเงิน
- ISO 8583
- EMV
- EMV 3-D Secure
- PCI DSS
- การเชื่อมต่อ
- REST
- Webhooks
คำถามและคำตอบ
เกตเวย์กับผู้รับชำระเงินต่างกันอย่างไร
ผู้รับชำระเงินคือธนาคารหรือสถาบันที่ได้รับอนุญาตซึ่งประมวลผลการชำระเงินด้วยบัตรให้คุณและจ่ายเงินออก ส่วนเกตเวย์คือบริการทางเทคนิคที่อยู่ข้างหน้า รับคำขอจากเครื่องรับบัตรและหน้าชำระเงิน แปลงบัตรเป็นโทเคน และส่งต่อไป ผู้ให้บริการบางรายเป็นทั้งสองอย่าง การออกแบบนี้ใช้ได้ทั้งสองกรณีและแยกบทบาททั้งสองอย่างชัดเจน
การออกแบบนี้ทำให้ข้อมูลบัตรไม่อยู่ในระบบของเราหรือไม่
นั่นคือเป้าหมายของการออกแบบ หมายเลขบัตรถูกเก็บโดยเครื่องรับบัตรที่ได้รับการรับรองหรือหน้าชำระเงินที่โฮสต์ไว้ และแทนที่ด้วยโทเคนที่เกตเวย์ ระบบ POS, ERP และที่จัดเก็บข้อมูลของคุณจึงเห็นเพียงโทเคน ซึ่งลดส่วนของระบบที่ PCI DSS ครอบคลุม ผู้ตรวจประเมินของคุณเป็นผู้ยืนยันขอบเขตสุดท้าย
ISO 8583 เหมือนกันสำหรับทุกผู้รับชำระเงินหรือไม่
ไม่เหมือน ISO 8583 กำหนดโครงสร้าง และผู้รับชำระเงินหรือเครือข่ายแต่ละรายเผยแพร่ข้อกำหนดฟิลด์ ประเภทข้อความ และรหัสของตนเอง เราจึงสร้างจากข้อกำหนดของผู้รับชำระเงินและรันการทดสอบการรับรองของรายนั้น API ของเกตเวย์ที่อยู่หน้าผู้รับชำระเงินช่วยซ่อนความแตกต่างเหล่านี้ ซึ่งมักง่ายกว่าสำหรับผู้ค้าปลีก
ทำไมการชำระบัญชีจึงมาถึงช้ากว่ายอดขาย
การอนุมัติเพียงจองเงินไว้ ผู้รับชำระเงินชำระบัญชีเป็นรอบ หลังหักค่าธรรมเนียมและค่าใช้จ่ายของเครือข่ายบัตร และจ่ายออกตามกำหนดเวลาของตนเอง การออกแบบจึงถือการอนุมัติและการชำระบัญชีเป็นเหตุการณ์แยกกันและจับคู่กัน ฝ่ายการเงินจึงเห็นว่าขายอะไร ชำระบัญชีแล้วเท่าใด และยังรอรับเท่าใด
คุณรองรับ EMV 3-D Secure สำหรับการชำระเงินออนไลน์หรือไม่
รองรับ สำหรับการชำระเงินด้วยบัตรออนไลน์ เราผสาน EMV 3-D Secure ผ่านเกตเวย์ เพื่อให้ผู้ออกบัตรยืนยันตัวผู้ถือบัตรได้เมื่อกฎระเบียบหรือความเสี่ยงกำหนด เราจัดการทั้งขั้นตอนท้าทายและแบบไร้อุปสรรคในหน้าชำระเงิน และทดสอบทั้งสองแบบด้วยบัตรทดสอบของผู้ให้บริการ
เราใช้ผู้ให้บริการชำระเงินมากกว่าหนึ่งรายได้หรือไม่
ได้ ชั้นการเชื่อมต่อเก็บโมเดลการชำระเงินภายในชุดเดียวและแปลงไปยังผู้ให้บริการแต่ละราย คุณจึงกำหนดเส้นทางตามช่องทาง ประเทศ หรือประเภทบัตร หรือย้ายปริมาณระหว่างผู้ให้บริการได้ ผู้ให้บริการแต่ละรายยังต้องมีการเชื่อมต่อและการรับรองของตนเอง ซึ่งเราวางแผนทีละราย
เริ่มต้นด้วยการพูดคุย ไม่ใช่สัญญา
บอกเราว่าคุณต้องการสร้าง เชื่อมต่อ หรือรักษาความปลอดภัยอะไร สถาปนิกจะพิจารณาร่วมกับคุณ แล้วแนะนำว่าควรเริ่มที่ใด
ขั้นตอนถัดไป
การนัดหมายเวลา
ทีมของเราส่งอีเมลถึงคุณเพื่อนัดหมายเวลาสำหรับการปรึกษา
การปรึกษาก่อนเริ่มงาน
การปรึกษาก่อนเริ่มงานออนไลน์ฟรี 30 นาที: เราพูดคุยถึงเป้าหมาย ระบบ และข้อจำกัดของคุณ
การทบทวนความพร้อม
ในการทบทวนความพร้อมฟรี 48 ชั่วโมง สถาปนิกหลักจะตรวจสอบโครงการของคุณเทียบกับนิยามของความพร้อม 6 ข้อ และแนะนำแนวทางที่เหมาะที่สุด
การเลือกแนวทาง
โครงการที่ขอบเขตพร้อมจะได้รับข้อเสนอที่มีผลผูกพัน ภายใน 3 ถึง 5 วันทำการ โครงการในระยะแนวคิดจะเริ่มใน Blueprint Studio ระบบที่ใช้งานอยู่แต่มีปัญหา ไม่มีเอกสาร หรือต้องเชื่อมต่อ จะเริ่มด้วยการวินิจฉัยระยะเวลา 1 ถึง 2 สัปดาห์ Blueprint Studio และการวินิจฉัยต่างมีค่าธรรมเนียมคงที่ ซึ่งระบุไว้ในข้อเสนอ