เอกสารคู่มือการรวมโปรแกรม 3D Secure
คู่มือบูรณาการ 3D Secure
ตั้งแต่วันที่ 01.01.2021 การตรวจสอบสิทธิ์แบบสองปัจจัยจะถูกนำมาใช้เป็นข้อกำหนดบังคับสำหรับธุรกรรมการชำระเงินด้วยบัตรอีคอมเมิร์ซทั้งหมด เพื่อให้เป็นไปตามข้อผูกพันนี้
ผู้ให้บริการเครือข่ายบัตรเครดิตจะใช้ขั้นตอนที่เรียกว่า 3D Secure สำหรับคุณในฐานะผู้ค้าจำเป็นต้องดำเนินการตามขั้นตอนนี้ให้กับลูกค้าของคุณจาก
01.01.2021. ต่อไปนี้คุณจะพบคำอธิบายเกี่ยวกับวิธีการต่างๆในการผสานรวมและวิธีการใช้งานขั้นตอน 3D Secure สำหรับขั้นตอนเหล่านี้
โปรดเลือกวิธีการรวมที่คุณใช้
- คุณใช้แบบฟอร์มการชำระเงิน hCO หรือไม่
- คุณใช้แบบฟอร์มการชำระเงิน hPF หรือไม่
- คุณดำเนินการชำระเงินโดยไม่ใช้แบบฟอร์มที่ระบบ Unzer ให้มาหรือไม่?
หมายเหตุ: นอกจากนี้ยังมีความสำคัญในวิธีการหักบัญชีหรือการอนุญาตล่วงหน้า (การจอง) แม้ว่าคุณจะใช้แบบฟอร์มการชำระเงินจาก Unzer GmbH สำหรับการลงทะเบียนข้อมูลบัตรกระบวนการ 3D Secure จะดำเนินการโดยไม่มีแบบฟอร์มการชำระเงินเมื่อมีการหักข้อมูลบัตรครั้งแรกหรือได้รับอนุญาตเป็นครั้งแรก ในกรณีนี้จะใช้วิธีที่สามของการรวมโดยไม่มีแบบฟอร์มที่ Unzer จัดเตรียมไว้ให้
โปรดทราบ:
หากคุณใช้การชำระเงินที่เกิดขึ้นประจำ (การชำระเงินแบบสมัครสมาชิก) โปรดอ่านส่วน“ 3D Secure and Recurring Payment”
ขั้นตอนการรักษาความปลอดภัย 3D เมื่อใช้แบบฟอร์มการชำระเงิน hCO
แบบฟอร์มการชำระเงิน hCO ได้รับการออกแบบมาแล้วสำหรับขั้นตอน 3D Secure ไม่มีการดำเนินการเพิ่มเติมจากฝั่งของคุณที่จำเป็นสำหรับการดำเนินการตามขั้นตอน อย่างไรก็ตามคุณ
ต้องตรวจสอบให้แน่ใจว่าระบบของคุณสามารถจัดการกับคำตอบที่เกี่ยวข้องของระบบการชำระเงินของเราได้ในกรณีที่กระบวนการ 3D Secure เริ่มต้นขึ้น ในการตอบสนองแบบอะซิงโครนัสจาก
ระบบการชำระเงินไปยังเซิร์ฟเวอร์ของคุณผลลัพธ์ของธุรกรรมจะถูกส่งและต้องได้รับการประเมินก่อนที่จะส่งคืน URL จะถูกส่งไปยังระบบการชำระเงิน
เพื่อจุดประสงค์นี้ต้องประเมินพารามิเตอร์ต่อไปนี้
- กำลังดำเนินการคืนรหัส = 000.200.000
- PROCESSING.RETURN = ธุรกรรม + รอดำเนินการ
- การประมวลผลผลลัพธ์ = ACK
คำอธิบาย: สถานะของธุรกรรมคือ "รอดำเนินการ" ซึ่งเป็นพารามิเตอร์ PROCESSING.RESULT
เป็นเพียงผลลัพธ์เบื้องต้นเท่านั้น ตราบเท่าที่ดำเนินการตามกระบวนการ 3D Secure สถานะ
ยังคงรอดำเนินการ
ผลลัพธ์สุดท้ายของการทำธุรกรรมเป็นอย่างใดอย่างหนึ่ง
- กำลังดำเนินการคืนรหัส = 000.000.000
- การประมวลผลผลลัพธ์ = ACK
or - PROCESSING.RETURN.CODE = irgendein Wert ungleich 000.000.000 อื่น ๆ 000.200.000
- กำลังดำเนินการ.RESULT = NOK
ในกรณีแรกธุรกรรมเสร็จสมบูรณ์ในกรณีที่สองล้มเหลวโดยรวม ประการหลังอาจมีสาเหตุหลายประการรวมถึงการปฏิเสธการตรวจสอบสิทธิ์ คุณจะ
รับข้อมูลโดยละเอียดเพิ่มเติมในพารามิเตอร์“ PROCESSING.RETURN” และ“ PROCESSING.RETURN.CODE”
เราขอแนะนำให้คุณทำการทดสอบสำหรับทั้งสองข้อความ สำหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีการทดสอบและรายละเอียดบัตรเครดิตที่คุณสามารถใช้ในการทดสอบได้โปรดดูด้านล่าง
ขั้นตอน 3D Secure เมื่อใช้แบบฟอร์มการชำระเงิน hPF
แบบฟอร์มการชำระเงิน hPF ได้รับการออกแบบมาเพื่อใช้ขั้นตอน 3DS อยู่แล้ว ไม่มีการดำเนินการเพิ่มเติมจากฝั่งของคุณที่จำเป็นสำหรับการดำเนินการตามขั้นตอน ตามที่อธิบายไว้
สำหรับการใช้งาน hCO การตอบสนองจากระบบการชำระเงินจะเกิดขึ้นในสองขั้นตอนซึ่งเป็นสาเหตุที่ระบบของคุณต้องตรวจสอบมูลค่าของการประมวลผล RETURN.CODE
พารามิเตอร์เมื่อประมวลผลการตอบสนอง
เพื่อจุดประสงค์นี้ต้องประเมินพารามิเตอร์ต่อไปนี้
- กำลังดำเนินการคืนรหัส = 000.200.000
- PROCESSING.RETURN = ธุรกรรม + รอดำเนินการ
- การประมวลผลผลลัพธ์ = ACK
คำอธิบาย: สถานะของธุรกรรมคือ "รอดำเนินการ" พารามิเตอร์ PROCESSING.RESULT แสดงเฉพาะผลลัพธ์เบื้องต้น ตราบเท่าที่ดำเนินการตามกระบวนการ 3D Secure สถานะ
ยังคงรอดำเนินการ
ผลลัพธ์สุดท้ายของการทำธุรกรรมเป็นอย่างใดอย่างหนึ่ง
- กำลังดำเนินการคืนรหัส = 000.000.000
- การประมวลผลผลลัพธ์ = ACK
or - PROCESSING.RETURN.CODE = irgendein Wert ungleich 000.000.000 อื่น ๆ 000.200.000
- กำลังดำเนินการ.RESULT = NOK
ในกรณีแรกธุรกรรมเสร็จสมบูรณ์ในกรณีที่สองล้มเหลวโดยรวม ประการหลังอาจมีสาเหตุหลายประการรวมถึงการปฏิเสธการตรวจสอบสิทธิ์ คุณจะ
รับข้อมูลโดยละเอียดเพิ่มเติมในพารามิเตอร์“ PROCESSING.RETURN” และ“ PROCESSING.RETURN.CODE”
เราขอแนะนำให้คุณทำการทดสอบสำหรับทั้งสองข้อความ สำหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีการทดสอบและรายละเอียดบัตรเครดิตที่คุณสามารถใช้ในการทดสอบได้โปรดดูด้านล่าง
ขั้นตอนการรักษาความปลอดภัย 3D ด้วยการเชื่อมต่อโดยตรง
หากคุณไม่ได้ใช้แบบฟอร์มการชำระเงินที่ Unzer (เดิมเรียกว่าไฮเดลเพย์) เพื่อประมวลผลการชำระเงินด้วยบัตรเครดิตหรือหากคุณเพียงแค่ลงทะเบียนบัตรโดยใช้แบบฟอร์มใดรูปแบบหนึ่งและประมวลผลการอนุญาตล่วงหน้า (การจอง) หรือการตัดบัญชีเพื่ออ้างอิงการลงทะเบียน การสื่อสารโดยตรงกับระบบการชำระเงินคุณต้องใช้กระบวนการ 3D Secure
ขั้นตอนการทำธุรกรรมแบบอะซิงโครนัส:
นี่คือกระบวนการอะซิงโครนัสที่เซิร์ฟเวอร์ของคุณได้รับการส่งต่อ URL (เปลี่ยนเส้นทาง URL) จากระบบการชำระเงินของเรา เซิร์ฟเวอร์ของคุณต้องส่งต่อลูกค้าไปยังสิ่งนี้ URL เพื่อให้เขาสามารถดำเนินการรับรองความถูกต้องผ่านขั้นตอน 3D Secure ผลของการตรวจสอบความปลอดภัย 3D นี้จะรายงานโดยตรงไปยัง Unzer โดยธนาคารผู้ออกบัตร
หลังจากการรับรองความถูกต้องสำเร็จธุรกรรมจะถูกประมวลผลเพิ่มเติมในระบบ Unzer ตามวิธีที่คุณทราบอยู่แล้วโดยส่งผลลัพธ์โดยรวมให้ระบบของคุณในตอนท้ายซึ่งคุณตอบ
ด้วยการเปลี่ยนเส้นทาง URL. จากนั้นระบบการชำระเงินจะเปลี่ยนเส้นทางลูกค้ากลับไปที่ระบบของคุณโดยใช้การเปลี่ยนเส้นทางนี้ URL จากระบบของคุณ
โปรดทราบ: ในขั้นตอนการทำงานนี้ระบบของคุณจะได้รับคำตอบสองข้อจากระบบการชำระเงิน:
- หนึ่งที่มีสถานะ "รอดำเนินการ" (PROCESSING.RETURN.CODE = 000.200.000 และ PROCESSING.RETURN = ธุรกรรม + รอดำเนินการ) และพารามิเตอร์การเปลี่ยนเส้นทางไปยังธนาคารผู้ออกบัตรของลูกค้า
- หนึ่งที่มีผลสุดท้ายของการหักบัญชีหรือการจอง นอกจากนี้ยังมีสองการเปลี่ยนเส้นทาง URLที่กล่าวถึงในขั้นตอนนี้ระบบหนึ่งจากระบบการชำระเงินที่ลูกค้าจะต้องถูกเปลี่ยนเส้นทางไปตรวจสอบสิทธิ์ที่ธนาคารผู้ออกบัตรของเขาซึ่งเป็นหนึ่งเดียวจากระบบของคุณเมื่อได้รับผลลัพธ์สุดท้ายเพื่อเปลี่ยนเส้นทางลูกค้ากลับเข้าสู่ระบบของคุณ
การเปลี่ยนแปลงต่อไปนี้จะเกิดขึ้นกับขั้นตอนปกติ โปรดทราบว่าเนื่องจากการใช้วิธีการชำระเงินแบบอะซิงโครนัสอื่น ๆ เช่น Paypal บางวิธีเหล่านี้
กระบวนการอาจมีอยู่แล้วในการนำไปใช้งานของคุณ
- การตอบสนอง URL
ในการโทรครั้งแรก (หมายเลข 2 ในแผนภาพ) ไปยังระบบการชำระเงินจะมีข้อความ“ การตอบกลับ URL"จะต้องส่งผ่านในกลุ่มส่วนหน้า
หมายเหตุ: พารามิเตอร์ IDENTIFICATION.REFERENCEID จะเกี่ยวข้องก็ต่อเมื่อคุณอ้างถึงการลงทะเบียนหรือธุรกรรมอื่น ๆ ที่มีอยู่แล้ว - กำลังดำเนินการเปลี่ยนเส้นทาง URL หากจำเป็นต้องมีการตรวจสอบสิทธิ์ให้เปลี่ยนเส้นทาง URL และพารามิเตอร์อื่น ๆ ในกลุ่มการเปลี่ยนเส้นทางจะถูกโอนในการตอบกลับจากระบบการชำระเงิน (หมายเลข 5 ในแผนภาพ)
- การส่งต่อลูกค้าไปยังการเปลี่ยนเส้นทาง URL
หากกลุ่มการเปลี่ยนเส้นทางตอบสนองด้วยการเปลี่ยนเส้นทาง URLเบราว์เซอร์ของลูกค้าจะต้องเปลี่ยนเส้นทางไปที่สิ่งนี้ URL (หมายเลข 6 ในแผนภาพ) เพื่อดำเนินการตรวจสอบสิทธิ์ พารามิเตอร์เพิ่มเติมจากกลุ่มการเปลี่ยนเส้นทางจะต้องถูกถ่ายโอนไปยังภายนอก webไซต์เป็นพารามิเตอร์ POST
โปรดทราบ: พารามิเตอร์เพิ่มเติมจะส่งคืนในกลุ่ม“ PROCESSING.REDIRECT.xxx” ที่มี 3D Secure Version 1 เท่านั้น (แม้ว่าหมายเลขและการตั้งชื่ออาจแตกต่างกันไป) ในขณะที่ 3D เวอร์ชัน 2 จะมีเพียงการประมวลผลเท่านั้นURL ตามที่แสดงด้านล่างจะถูกส่งกลับ: https://heidelpay.hpcgw.net/AuthService/v1/auth/public/2258_2863FFA4C5241C12E39F37
CCF / run ซึ่งหมายความว่าโดยไม่คำนึงถึงประเภทและจำนวนพารามิเตอร์เบราว์เซอร์ไคลเอนต์จะต้องเปลี่ยนเส้นทางไปยัง PROCESSING.REDIRECTURL.
ด้านล่างคุณจะพบรหัสง่าย ๆ exampว่าสามารถดำเนินการเปลี่ยนเส้นทางดังกล่าวได้อย่างไร NS ส่วนหนึ่งมีวัตถุประสงค์เพื่อแจ้งให้ลูกค้าปลายทางที่ระบบไม่สนับสนุน Javascript หรือปิดการใช้งาน เราขอแนะนำอย่างยิ่งให้เปลี่ยนเส้นทางภายในหน้าต่างเบราว์เซอร์ที่ใช้งานอยู่ของลูกค้า และไม่ควรใช้หน้าต่างป๊อปอัปหรือหน้าต่างเบราว์เซอร์ใหม่ เนื่องจากอาจทำได้
ทำให้ลูกค้าระคายเคืองและทำให้พวกเขาปิดเพจที่พวกเขาถูกเปลี่ยนเส้นทางไป
- การตรวจสอบผลลัพธ์แบบอะซิงโครนัส
ผลลัพธ์ของการตรวจสอบความถูกต้องจะถูกส่งไปยังเซิร์ฟเวอร์ของคุณแบบอะซิงโครนัส ระบบการชำระเงินคาดว่าจะถูกต้อง URL เป็นการตอบสนอง (หมายเลข 12 และ 13 ในแผนภาพ) สำหรับความสำเร็จหรือถูกปฏิเสธ
การชำระเงินที่แตกต่างกัน URL ระบบของคุณสามารถตอบสนองได้ที่นี่ - เส้นทางกลับของลูกค้า
ระบบการชำระเงินจะเปลี่ยนเส้นทางลูกค้าไปยังไฟล์ URL ให้บริการโดยระบบของร้านค้าหลังจากขั้นตอนการตรวจสอบสิทธิ์และธุรกรรมการชำระเงินเสร็จสมบูรณ์
โปรดทราบ: ขั้นตอนที่ 4. ) และ 5. ) ดำเนินการในลักษณะเดียวกับที่คุณคุ้นเคยกับธุรกรรม NONE 3D Secure ที่มีอยู่แล้ว
3D ที่ปลอดภัยและการชำระเงินที่เกิดขึ้นประจำ
ตั้งแต่วันที่ 1 มกราคม 2021 3D Secure จะมีผลบังคับใช้สำหรับธุรกรรมบัตรอีคอมเมิร์ซทั้งหมด อย่างไรก็ตามเนื่องจากแทบจะไม่สามารถใช้กับการชำระเงินที่เกิดขึ้นประจำได้ธนาคาร
ระบบมีเวิร์กโฟลว์แยกต่างหากสำหรับสิ่งนี้
เพื่อจุดประสงค์นี้ธนาคารแยกความแตกต่างระหว่าง
- CIT = ลูกค้าเริ่มต้นธุรกรรม
- MIT = ผู้ค้าเริ่มต้นการทำธุรกรรม
การทำธุรกรรมครั้งแรกของบัตรในบัญชีร้านค้าของคุณจะต้องได้รับการรับรองความถูกต้องด้วย 3D Secure ตั้งแต่วันที่ 01.01.2021 เป็นต้นไป การรับรองความถูกต้องที่ประสบความสำเร็จดังกล่าวเป็นข้อกำหนดบังคับใน
เพื่อให้สามารถส่งการจองเพิ่มเติมในบัตรเดียวกันได้ในภายหลังโดยไม่ต้องใช้ 3D Secure ลูกค้าจะต้องถูกส่งต่อไปยังธนาคารผู้ออกบัตรเพื่อทำการหักบัญชีครั้งแรก
ตามขั้นตอนที่อธิบายไว้ข้างต้นและยืนยันตัวเองในฐานะผู้ถือบัตร หากไม่ได้วางแผนเดบิตในขณะที่สั่งซื้อ เช่นampเนื่องจากช่วงทดลองใช้งาน การจอง (การกันวงเงินล่วงหน้า) อย่างน้อยหนึ่งยูโรต้องทำด้วย 3D Secure ต่อหน้าลูกค้าแทน ไม่จำเป็นต้องจับภาพการจองนี้
อย่างไรก็ตามสำหรับลูกค้าปัจจุบันไม่จำเป็นต้องมีการรับรองความถูกต้อง 3D Secure หากการหักบัญชีสำเร็จครั้งแรกเกิดขึ้นก่อนวันที่ 01.01.2021 บันทึกของลูกค้ายังสามารถสันนิษฐานได้
ได้รับการรับรองความถูกต้องเรียบร้อยแล้ว สำหรับลูกค้าใหม่ ณ วันที่ 01.01.2021 ในทางกลับกันการรับรองความถูกต้อง 3D Secure เป็นสิ่งจำเป็นสำหรับการตัดบัญชีหรือการจองครั้งแรก (การอนุมัติล่วงหน้า)
โปรดทราบ: ในแง่นี้ ระบบธนาคารจะดูที่ข้อมูลบัตร ไม่ใช่ข้อมูลลูกค้า ดังนั้นหากลูกค้าเดิมใช้บัตรใหม่หลังวันที่ 01.01.2021 เช่นample เพราะก่อนหน้านี้
บัตรหมดอายุหรือเนื่องจากเปลี่ยนธนาคารผู้ออกบัตร ซึ่งเป็นวงจรที่เกิดซ้ำใหม่จากจุดของธนาคาร view และต้องรับรองความถูกต้องด้วย 3D Secure สำหรับการจองครั้งแรก
เมื่อดำเนินการตรวจสอบความถูกต้องครั้งแรกสำเร็จแล้วธุรกรรมเพิ่มเติมทั้งหมดจะได้รับการยกเว้นจากข้อผูกมัดในการใช้ 3D Secure ข้อกำหนดเบื้องต้นสำหรับการชำระเงินที่เกิดซ้ำโดยไม่มี 3D Secure จึงมีดังนี้:
- มีการหักบัญชีหรือการจองที่ประสบความสำเร็จอย่างน้อยหนึ่งรายการ (การอนุมัติล่วงหน้า) ซึ่งดำเนินการด้วย 3D Secure หรือเกิดขึ้นก่อน 01.01.2021
- มันถูกอ้างอิงถึงการลงทะเบียนและการตัดบัญชีที่มีอยู่เมื่อส่ง
เพื่อให้ระบบการชำระเงินทราบว่านี่เป็นการชำระเงินที่เกิดซ้ำต้องส่งพารามิเตอร์ RECURRENCE.MODE = REPEATED ด้วย สิ่งนี้ส่งสัญญาณไปยังระบบว่า a
การชำระเงินที่เกิดขึ้นประจำจะถูกรายงานไปยังระบบธนาคาร
โปรดทราบ: หากป้อนพารามิเตอร์ RECURRENCE.MODE = REPEATED เมื่อโหลดการ์ดใหม่เป็นครั้งแรกการส่งต่อ 3D Secure จะดำเนินการแม้จะมีพารามิเตอร์นี้ก็ตาม
ทดสอบการใช้งาน 3D Secure
คุณสามารถทดสอบการเชื่อมต่อ 3D Secure ได้ตลอดเวลาผ่านระบบการชำระเงินของเรา ในการดำเนินการดังกล่าว ให้ใช้โหมด “CONNECTOR_TEST” สำหรับธุรกรรมดังที่แสดงใน exampไฟล์ด้านบน
ข้อมูลการเชื่อมต่อสำหรับการทดสอบนี้:
| ความปลอดภัย SENDER | 31HA07BC8142C5A171745D00AD63D182 |
| ผู้ใช้เข้าสู่ระบบ | 31ha07bc8142c5a171744e5aef11ffd3 |
| ผู้ใช้ PWD | 93167DE7 |
| ธุรกรรม.ช่องทาง | 31HA07BC8142C5A171749A60D979B6E4 |
| กำหนดค่าสกุลเงินสำหรับ 3D เวอร์ชัน 2 | ยูโร, ดอลล่าร์, สก |
| กำหนดค่าสกุลเงินสำหรับ 3D เวอร์ชัน 1 | GBP, CZK, CHF |
ปลายทางของระบบเกตเวย์เป็นอย่างใดอย่างหนึ่ง
เกตเวย์ SGW:
- https://test-heidelpay.hpcgw.net/sgw/gtw - เข้ารหัสภาษาละติน -15
- https://test-heidelpay.hpcgw.net/sgw/gtwu - เข้ารหัส UTF-8
เกตเวย์ NGW:
- https://test-heidelpay.hpcgw.net/ngw/post
ข้อมูลบัตรเครดิตสำหรับการทดสอบนี้:
| แบรนด์ | หมายเลขบัตร | ซีวีวี | วันหมดอายุ | บันทึก |
| มาสเตอร์การ์ด | 5453010000059543 | 123 | วันที่ในอนาคต | 3D - รหัสผ่าน: ความลับ 3 |
| วีซ่า | 4711100000000000 | 123 | วันที่ในอนาคต | 3DS - รหัสผ่าน: ความลับ 33 |
โปรดทราบ: สำหรับ 3D Secure เวอร์ชัน 2 คุณไม่จำเป็นต้องป้อนรหัสผ่าน แต่เพียงแค่คลิกที่ลิงค์” คลิกที่นี่เพื่อดำเนินการตรวจสอบสิทธิ์
วิธีเดียวในการจำลองข้อผิดพลาดด้วย 3D Secure เวอร์ชัน 2 คือการปล่อยให้เพจที่มีลิงก์หมดเวลา (ประมาณ 18 นาที)
อ่านเพิ่มเติมเกี่ยวกับคู่มือนี้และดาวน์โหลด PDF:
เอกสาร / แหล่งข้อมูล
 |
คู่มือการบูรณาการซอฟต์แวร์ 3D Secure [พีดีเอฟ] เอกสารประกอบ Unzer, คู่มือการบูรณาการ, 3D Secure |
