ข้ามไปยังเนื้อหา
XSIS

องค์กรและการเชื่อมต่อระบบ

การชำระเงินด้วยบัตร

การชำระเงินด้วยบัตร: จากเครื่องรับบัตรถึงผู้รับชำระเงิน และกลับเข้าบัญชีแยกประเภท

เครื่องรับบัตร EMV และเกตเวย์การชำระเงินที่เชื่อมต่อกับผู้รับชำระเงินผ่าน ISO 8583 หรือ API พร้อมไฟล์การชำระบัญชีที่กระทบยอดใน ERP

พิมพ์เขียว

การชำระเงินด้วยบัตร: อนุมัติที่เคาน์เตอร์ ชำระบัญชีภายหลัง กระทบยอดใน ERPเครื่องหรือหน้าชำระเงินถามเกตเวย์ เกตเวย์ถามธนาคารผู้รับชำระ และธนาคารผู้รับชำระส่งต่อไปยังเครือข่ายบัตรและผู้ออกบัตร ไฟล์ชำระบัญชีมาถึงภายหลังและจับคู่กับยอดขายและค่าธรรมเนียมใน ERP การหมดเวลาทำให้เกิดการกลับรายการ เพื่อไม่ให้ลูกค้าถูกเรียกเก็บซ้ำPOSเครื่อง EMVหรือหน้าชำระเงินออนไลน์ชิป การแตะจ่ายและอีคอมเมิร์ซเกตเวย์เกตเวย์การชำระเงินการแปลงเป็นโทเคนและการกำหนดเส้นทางธนาคารธนาคารผู้รับชำระการอนุมัติและการชำระบัญชีระบบภายนอกเครือข่ายบัตรและผู้ออกบัตรอนุมัติหรือปฏิเสธERPERPยอดขาย ค่าธรรมเนียมและการจ่ายเงินXSISชั้นการเชื่อมต่อการอ่านและจับคู่ไฟล์ชำระบัญชีผู้คนทีมปฏิบัติการชำระเงินรายการไม่ตรงข้อพิพาทและการเรียกคืนเงิน1EMV · REST/JSON2ISO 85833ISO 85834ISO 85835SFTP6REST/JSON7ISO 8583 04008

การชำระเงินด้วยบัตร: อนุมัติที่เคาน์เตอร์ ชำระบัญชีภายหลัง กระทบยอดใน ERP

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

  • เส้นทางหลัก
  • แบบอะซิงโครนัส
  • เส้นทางข้อยกเว้น
ขั้นตอนการทำงาน 8 ขั้นตอน

ขั้นตอนการทำงานทีละขั้น

  1. จาก เครื่อง EMV หรือหน้าชำระเงินออนไลน์ ไปยัง เกตเวย์การชำระเงิน: คำขออนุมัติ ผ่าน EMV · REST/JSON (เส้นทางหลัก)
  2. จาก เกตเวย์การชำระเงิน ไปยัง ธนาคารผู้รับชำระ: การอนุมัติ ผ่าน ISO 8583 (เส้นทางหลัก)
  3. จาก ธนาคารผู้รับชำระ ไปยัง เครือข่ายบัตรและผู้ออกบัตร: ส่งต่อไปยังผู้ออกบัตร ผ่าน ISO 8583 (เส้นทางหลัก)
  4. จาก ธนาคารผู้รับชำระ ไปยัง เกตเวย์การชำระเงิน: อนุมัติหรือปฏิเสธ ผ่าน ISO 8583 (แบบอะซิงโครนัส)
  5. จาก ธนาคารผู้รับชำระ ไปยัง ชั้นการเชื่อมต่อ: ไฟล์ชำระบัญชีและค่าธรรมเนียม ผ่าน SFTP (แบบอะซิงโครนัส)
  6. จาก ชั้นการเชื่อมต่อ ไปยัง ERP: ยอดขาย ค่าธรรมเนียม และการจ่ายเงินที่ชำระบัญชีแล้ว ผ่าน REST/JSON (เส้นทางหลัก)
  7. จาก เกตเวย์การชำระเงิน ไปยัง เครื่อง EMV หรือหน้าชำระเงินออนไลน์: ไม่มีการตอบกลับทันเวลา: กลับรายการอัตโนมัติ ผ่าน ISO 8583 0400 (เส้นทางข้อยกเว้น)
  8. จาก ชั้นการเชื่อมต่อ ไปยัง ทีมปฏิบัติการชำระเงิน: รายการชำระบัญชีไม่ตรงหรือการเรียกคืนเงิน (เส้นทางข้อยกเว้น)

ภาพรวม

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

การออกแบบอ้างอิงส่งการอนุมัติผ่านเกตเวย์การชำระเงินที่แปลงบัตรเป็นโทเคนและส่งคำขอไปยังผู้รับชำระเงินผ่าน ISO 8583 หรือ API ของผู้รับชำระเงิน ไฟล์การชำระบัญชีและค่าธรรมเนียมถูกเก็บโดยชั้นการเชื่อมต่อ จับคู่กับยอดขายเดิม และบันทึกเข้า ERP เป็นยอดขาย ค่าธรรมเนียม และเงินที่จ่ายออก

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

กระบวนการ

  1. เริ่มที่เครื่องรับบัตรหรือหน้าชำระเงิน

    เครื่องรับบัตร EMV อ่านชิปหรือบัตรแบบไม่สัมผัส หรือหน้าชำระเงินออนไลน์เก็บข้อมูลบัตรผ่านหน้าที่โฮสต์ไว้ แล้วส่งคำขออนุมัติไปยังเกตเวย์

  2. อนุมัติผ่านเกตเวย์

    เกตเวย์แทนที่หมายเลขบัตรด้วยโทเคนและส่งคำขออนุมัติไปยังผู้รับชำระเงิน ผ่าน ISO 8583 หรือ API ของผู้รับชำระเงิน

  3. ส่งต่อไปยังผู้ออกบัตร

    ผู้รับชำระเงินส่งคำขอผ่านเครือข่ายบัตรไปยังผู้ออกบัตร ซึ่งอนุมัติหรือปฏิเสธ

  4. ส่งคำตอบกลับ

    การอนุมัติหรือการปฏิเสธย้อนกลับตามเส้นทางเดิมไปยังเครื่องรับบัตรหรือหน้าชำระเงิน พร้อมรหัสตอบกลับ

  5. รับการชำระบัญชี

    ผู้รับชำระเงินส่งไฟล์การชำระบัญชีและค่าธรรมเนียมในภายหลัง ซึ่งชั้นการเชื่อมต่อเก็บและตรวจสอบ

  6. จับคู่และบันทึก

    ชั้นนี้จับคู่ธุรกรรมที่ชำระบัญชีแล้วกับยอดขายเดิม และบันทึกยอดขาย ค่าธรรมเนียม และเงินที่จ่ายออกเข้า 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 ผ่านเกตเวย์ เพื่อให้ผู้ออกบัตรยืนยันตัวผู้ถือบัตรได้เมื่อกฎระเบียบหรือความเสี่ยงกำหนด เราจัดการทั้งขั้นตอนท้าทายและแบบไร้อุปสรรคในหน้าชำระเงิน และทดสอบทั้งสองแบบด้วยบัตรทดสอบของผู้ให้บริการ

เราใช้ผู้ให้บริการชำระเงินมากกว่าหนึ่งรายได้หรือไม่

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

เริ่มต้นด้วยการพูดคุย ไม่ใช่สัญญา

บอกเราว่าคุณต้องการสร้าง เชื่อมต่อ หรือรักษาความปลอดภัยอะไร สถาปนิกจะพิจารณาร่วมกับคุณ แล้วแนะนำว่าควรเริ่มที่ใด

ขั้นตอนถัดไป

  1. การนัดหมายเวลา

    ทีมของเราส่งอีเมลถึงคุณเพื่อนัดหมายเวลาสำหรับการปรึกษา

  2. การปรึกษาก่อนเริ่มงาน

    การปรึกษาก่อนเริ่มงานออนไลน์ฟรี 30 นาที: เราพูดคุยถึงเป้าหมาย ระบบ และข้อจำกัดของคุณ

  3. การทบทวนความพร้อม

    ในการทบทวนความพร้อมฟรี 48 ชั่วโมง สถาปนิกหลักจะตรวจสอบโครงการของคุณเทียบกับนิยามของความพร้อม 6 ข้อ และแนะนำแนวทางที่เหมาะที่สุด

  4. การเลือกแนวทาง

    โครงการที่ขอบเขตพร้อมจะได้รับข้อเสนอที่มีผลผูกพัน ภายใน 3 ถึง 5 วันทำการ โครงการในระยะแนวคิดจะเริ่มใน Blueprint Studio ระบบที่ใช้งานอยู่แต่มีปัญหา ไม่มีเอกสาร หรือต้องเชื่อมต่อ จะเริ่มด้วยการวินิจฉัยระยะเวลา 1 ถึง 2 สัปดาห์ Blueprint Studio และการวินิจฉัยต่างมีค่าธรรมเนียมคงที่ ซึ่งระบุไว้ในข้อเสนอ