ເອກະສານແນະ ນຳ ກ່ຽວກັບຄວາມປອດໄພໃນການປະສົມປະສານ 3D ຂອງຊອບແວ

ຄູ່ມືການປະສົມປະສານ 3D ປອດໄພ

ນັບແຕ່ວັນທີ 01.01.2021 ກ່ຽວກັບການກວດສອບສອງປັດໃຈຈະຖືກຈັດຕັ້ງປະຕິບັດເປັນຂໍ້ ກຳ ນົດທີ່ ຈຳ ເປັນ ສຳ ລັບທຸກໆການໂອນເງິນຜ່ານບັດອີຄອມເມີຊ. ເພື່ອປະຕິບັດຕາມພັນທະດັ່ງກ່າວ,
ຜູ້ປະກອບການຂອງເຄືອຂ່າຍບັດເຄດິດຈະໃຊ້ຂັ້ນຕອນທີ່ເອີ້ນວ່າ 3D ຄວາມປອດໄພ. ສຳ ລັບທ່ານທີ່ເປັນພໍ່ຄ້າມັນ ຈຳ ເປັນທີ່ຈະຕ້ອງສາມາດ ດຳ ເນີນຂັ້ນຕອນນີ້ ສຳ ລັບລູກຄ້າຂອງທ່ານ
01.01.2021. ໃນຕໍ່ໄປນີ້ທ່ານຈະເຫັນ ຄຳ ອະທິບາຍກ່ຽວກັບວິທີການຕ່າງໆຂອງການເຊື່ອມໂຍງແລະວິທີການ 3D ຂັ້ນຕອນທີ່ປອດໄພຕ້ອງຖືກປະຕິບັດ ສຳ ລັບພວກມັນ.

ກະລຸນາເລືອກວິທີການເຊື່ອມໂຍງທີ່ທ່ານໃຊ້

• ທ່ານ ກຳ ລັງໃຊ້ແບບຟອມເຊັກເອົາ hCO ບໍ?
• ທ່ານ ກຳ ລັງໃຊ້ແບບຟອມການ ຊຳ ລະເງິນ hPF ບໍ?
• ທ່ານ ດຳ ເນີນການຈ່າຍເງິນໂດຍບໍ່ຕ້ອງໃຊ້ແບບຟອມທີ່ລະບົບ Unzer ກຳ ນົດ?

ກະລຸນາສັງເກດ: ມັນຍັງມີຄວາມ ສຳ ຄັນໃນວິທີການ ໜີ້ ສິນຫລືການອະນຸມັດ (ການສັ່ງຈອງ). ເຖິງແມ່ນວ່າທ່ານຈະໃຊ້ແບບຟອມ ຊຳ ລະເງິນຈາກ Unzer GmbH ສຳ ລັບການລົງທະບຽນຂໍ້ມູນບັດ, ຂະບວນການ 3D ປອດໄພຈະຖືກປະຕິບັດໂດຍບໍ່ຕ້ອງມີແບບຟອມເຊັກເງິນເມື່ອຂໍ້ມູນບັດຖືກ debited ຫຼືອະນຸຍາດເປັນຄັ້ງ ທຳ ອິດ. ໃນກໍລະນີນີ້ວິທີທີສາມຂອງການເຊື່ອມໂຍງໂດຍບໍ່ມີແບບຟອມທີ່ສະຫນອງໂດຍ Unzer ໃຊ້.

ກະລຸນາສັງເກດ:
ຖ້າທ່ານໃຊ້ການຈ່າຍເງີນທີ່ເກີດຂື້ນ (ການ ຊຳ ລະການສະ ໝັກ), ໃຫ້ແນ່ໃຈວ່າທ່ານອ່ານພາກທີ່“ 3D Security and Recurring Payment”.

ຂັ້ນຕອນ 3D ປອດໄພໃນເວລາທີ່ໃຊ້ແບບຟອມເຊັກ hCO

ແບບຟອມເຊັກເອົາ hCO ຖືກອອກແບບມາແລ້ວ ສຳ ລັບຂັ້ນຕອນ 3D ປອດໄພ. ບໍ່ມີການກະ ທຳ ຫຍັງເພີ່ມເຕີມຈາກຝ່າຍທ່ານທີ່ ຈຳ ເປັນ ສຳ ລັບການຈັດຕັ້ງປະຕິບັດ. ເຖິງຢ່າງໃດກໍ່ຕາມ, ທ່ານ
ຕ້ອງຮັບປະກັນວ່າລະບົບຂອງທ່ານສາມາດຈັດການກັບ ຄຳ ຕອບທີ່ກົງກັນຂອງລະບົບການຈ່າຍເງິນຂອງພວກເຮົາໃນກໍລະນີທີ່ຂະບວນການ 3D ປອດໄພຈະເລີ່ມຕົ້ນ. ໃນການຕອບສະ ໜອງ ຂອງ asynchronous ຈາກ
ລະບົບການຈ່າຍເງິນໃຫ້ກັບເຊີບເວີຂອງທ່ານ, ຜົນຂອງການໂອນເງິນແມ່ນຖືກສົ່ງຕໍ່ແລະຕ້ອງໄດ້ຖືກປະເມີນຢູ່ທີ່ນັ້ນກ່ອນທີ່ຈະກັບມາ URL ຖືກສົ່ງຜ່ານລະບົບການຈ່າຍເງິນ.

ສຳ ລັບຈຸດປະສົງນີ້, ຕົວ ກຳ ນົດການຕໍ່ໄປນີ້ຕ້ອງໄດ້ຖືກປະເມີນຜົນ.

• ຂະບວນການ .RETURN.CODE = 000.200.000
• PROCESSING.RETURN = ການເຮັດທຸລະ ກຳ + ທີ່ຍັງຄ້າງ
• PROCESSING.RESULT = ເອັກ

ຄໍາອະທິບາຍ: ສະຖານະຂອງການເຮັດທຸລະກໍາແມ່ນ“ ລໍຖ້າ”, ພາລາມິເຕີ PROCESSING.RESULT
ສະແດງພຽງແຕ່ຜົນໄດ້ຮັບເບື້ອງຕົ້ນເທົ່ານັ້ນ. ຕາບໃດທີ່ຂະບວນການ 3D ປອດໄພຖືກປະຕິບັດ, ສະຖານະພາບ
ຍັງຄ້າງຢູ່.

ຜົນໄດ້ຮັບສຸດທ້າຍຂອງການເຮັດທຸລະກໍາແມ່ນຫຼັງຈາກນັ້ນທັງ

•  ຂະບວນການ .RETURN.CODE = 000.000.000
• PROCESSING.RESULT = ເອັກ
  or
• ຂະບວນການ .RETURN.CODE = irgendein Wert ungleich 000.000.000 oder 000.200.000
• ໂປຣແກຣມ PROCESSING.RESULT = NOK

ໃນກໍລະນີ ທຳ ອິດການເຮັດທຸລະ ກຳ ໄດ້ ສຳ ເລັດແລ້ວ, ໃນກໍລະນີທີສອງມັນລົ້ມເຫລວໂດຍລວມ. ສຸດທ້າຍສາມາດມີເຫດຜົນຕ່າງໆ, ລວມທັງການປະຕິເສດການກວດສອບຄວາມຖືກຕ້ອງ. ເຈົ້າ​ຈະ
ໄດ້ຮັບຂໍ້ມູນລາຍລະອຽດເພີ່ມເຕີມໃນພາລາມິເຕີ“ PROCESSING.RETURN” ແລະ“ PROCESSING.RETURN.CODE”.
ພວກເຮົາແນະ ນຳ ໃຫ້ທ່ານ ດຳ ເນີນການທົດສອບ ສຳ ລັບທັງສອງຂໍ້ຄວາມ. ສຳ ລັບຂໍ້ມູນເພີ່ມເຕີມກ່ຽວກັບວິທີການທົດສອບແລະລາຍລະອຽດຂອງບັດເຄດິດໃດທີ່ທ່ານສາມາດໃຊ້ເພື່ອທົດສອບ, ກະລຸນາເບິ່ງຂ້າງລຸ່ມນີ້.

ຂັ້ນຕອນຄວາມປອດໄພ 3D ເມື່ອ ນຳ ໃຊ້ແບບຟອມການ ຊຳ ລະເງິນ hPF

ແບບຟອມການກວດກາ hPF ກໍ່ໄດ້ຖືກອອກແບບເພື່ອ ນຳ ໃຊ້ຂັ້ນຕອນ 3DS ຢູ່ແລ້ວ. ບໍ່ມີການກະ ທຳ ຫຍັງເພີ່ມເຕີມຈາກຝ່າຍທ່ານທີ່ ຈຳ ເປັນ ສຳ ລັບການຈັດຕັ້ງປະຕິບັດ. ດັ່ງທີ່ໄດ້ອະທິບາຍໄວ້
ສຳ ລັບການຈັດຕັ້ງປະຕິບັດ hCO ການຕອບສະ ໜອງ ຈາກລະບົບການຈ່າຍເງິນເກີດຂື້ນເປັນສອງບາດກ້າວ, ນັ້ນແມ່ນເຫດຜົນທີ່ລະບົບຂອງທ່ານຕ້ອງກວດສອບມູນຄ່າຂອງ PROCESSING.RETURN.CODE
ພາລາມິເຕີໃນເວລາທີ່ປະມວນຜົນການຕອບຮັບ.

ສຳ ລັບຈຸດປະສົງນີ້, ຕົວ ກຳ ນົດການຕໍ່ໄປນີ້ຕ້ອງໄດ້ຖືກປະເມີນຜົນ.

• ຂະບວນການ .RETURN.CODE = 000.200.000
• PROCESSING.RETURN = ການເຮັດທຸລະ ກຳ + ທີ່ຍັງຄ້າງ
• PROCESSING.RESULT = ເອັກ

ຄຳ ອະທິບາຍ: ສະຖານະຂອງການເຮັດທຸລະ ກຳ ແມ່ນ“ ຍັງຄ້າງຢູ່”, ພາລາມິເຕີ PROCESSING.RESULT ເປັນຕົວແທນຂອງຜົນໄດ້ຮັບເບື້ອງຕົ້ນເທົ່ານັ້ນ. ຕາບໃດທີ່ຂະບວນການ 3D ປອດໄພຖືກປະຕິບັດ, ສະຖານະພາບ
ຍັງຄ້າງຢູ່.

ຜົນໄດ້ຮັບສຸດທ້າຍຂອງການເຮັດທຸລະກໍາແມ່ນຫຼັງຈາກນັ້ນທັງ

• ຂະບວນການ .RETURN.CODE = 000.000.000
• PROCESSING.RESULT = ເອັກ
  or
• ຂະບວນການ .RETURN.CODE = irgendein Wert ungleich 000.000.000 oder 000.200.000
• ໂປຣແກຣມ PROCESSING.RESULT = NOK

ໃນກໍລະນີ ທຳ ອິດການເຮັດທຸລະ ກຳ ໄດ້ ສຳ ເລັດແລ້ວ, ໃນກໍລະນີທີສອງມັນລົ້ມເຫລວໂດຍລວມ. ສຸດທ້າຍສາມາດມີເຫດຜົນຕ່າງໆ, ລວມທັງການປະຕິເສດການກວດສອບຄວາມຖືກຕ້ອງ. ເຈົ້າ​ຈະ
ໄດ້ຮັບຂໍ້ມູນລາຍລະອຽດເພີ່ມເຕີມໃນພາລາມິເຕີ“ PROCESSING.RETURN” ແລະ“ PROCESSING.RETURN.CODE”.
ພວກເຮົາແນະ ນຳ ໃຫ້ທ່ານ ດຳ ເນີນການທົດສອບ ສຳ ລັບທັງສອງຂໍ້ຄວາມ. ສຳ ລັບຂໍ້ມູນເພີ່ມເຕີມກ່ຽວກັບວິທີການທົດສອບແລະລາຍລະອຽດຂອງບັດເຄດິດໃດທີ່ທ່ານສາມາດໃຊ້ເພື່ອທົດສອບ, ກະລຸນາເບິ່ງຂ້າງລຸ່ມນີ້.

ຂັ້ນຕອນການຮັບປະກັນ 3D ດ້ວຍການເຊື່ອມຕໍ່ໂດຍກົງ

ຖ້າທ່ານບໍ່ໃຊ້ແບບຟອມການຈ່າຍເງິນທີ່ສະ ໜອງ ໂດຍ Unzer (ໃນເມື່ອກ່ອນ heidelpay) ເພື່ອປະມວນຜົນການ ຊຳ ລະບັດເຄຼດິດ, ຫຼືຖ້າທ່ານພຽງແຕ່ລົງທະບຽນບັດໂດຍໃຊ້ ໜຶ່ງ ໃນຮູບແບບແລະປະມວນຜົນ preauthorisation (ການສັ່ງຈອງ) ຫຼື debit ເປັນຂໍ້ອ້າງອີງໃນການລົງທະບຽນເປັນ ການສື່ສານໂດຍກົງກັບລະບົບການຈ່າຍເງິນ, ທ່ານຕ້ອງປະຕິບັດຂັ້ນຕອນ 3D ປອດໄພ.

ກະແສການເຮັດທຸລະ ກຳ ແບບບໍ່ສະ ໝ ່ ຳ ສະ ເໝີ:

ນີ້ແມ່ນຂະບວນການທີ່ບໍ່ສະຖຽນລະພາບເຊິ່ງເຄື່ອງແມ່ຂ່າຍຂອງທ່ານໄດ້ຮັບການສົ່ງຕໍ່ URL (ປ່ຽນເສັ້ນທາງ URL) ຈາກລະບົບການຈ່າຍເງິນຂອງພວກເຮົາ. ເຄື່ອງແມ່ຂ່າຍຂອງທ່ານຕ້ອງສົ່ງຕໍ່ລູກຄ້າຕໍ່ສິ່ງນີ້ URL ເພື່ອໃຫ້ລາວສາມາດ ດຳ ເນີນການກວດສອບຄວາມຖືກຕ້ອງຜ່ານຂັ້ນຕອນການຮັບປະກັນ 3D. ຜົນຂອງການກວດສອບຄວາມປອດໄພ 3D ນີ້ແມ່ນລາຍງານໂດຍກົງໃຫ້ Unzer ໂດຍທະນາຄານອອກບັດ.

ຫຼັງຈາກການກວດສອບຄວາມ ສຳ ເລັດຜົນແລ້ວ, ການເຮັດທຸລະ ກຳ ຈະຖືກ ດຳ ເນີນການຕໍ່ໄປໃນລະບົບ Unzer ໃນວິທີທີ່ທ່ານຮູ້ແລ້ວໂດຍການສົ່ງລະບົບຂອງທ່ານຜົນໄດ້ຮັບໂດຍລວມໃນຕອນທ້າຍ, ເຊິ່ງທ່ານຕອບ
ກັບການປ່ຽນເສັ້ນທາງ URL. ລະບົບການຈ່າຍເງິນຈະໂອນລູກຄ້າກັບຄືນສູ່ລະບົບຂອງທ່ານໂດຍໃຊ້ການປ່ຽນເສັ້ນທາງນີ້ URL ຈາກລະບົບຂອງທ່ານ

ກະລຸນາສັງເກດ: ໃນຂະບວນການເຮັດວຽກນີ້ລະບົບຂອງທ່ານໄດ້ຮັບສອງ ຄຳ ຕອບຈາກລະບົບການຈ່າຍເງິນ:

- ໜຶ່ງ ທີ່ມີສະຖານະພາບ“ ລໍຖ້າ” (PROCESSING.RETURN.CODE = 000.200.000 ແລະ PROCESSING.RETURN = ການໂອນເງິນ + ທີ່ຍັງຄ້າງ) ແລະຕົວ ກຳ ນົດການໂອນຍ້າຍໄປທີ່ທະນາຄານອອກບັດຂອງລູກຄ້າ
- ໜຶ່ງ ທີ່ມີຜົນສຸດທ້າຍຂອງການເດບິດຫຼືການຈອງ. ມັນຍັງມີສອງຕົວຊີ້ທິດທາງ URLs ໄດ້ກ່າວເຖິງໃນຂະບວນການນີ້, ໜຶ່ງ ຈາກລະບົບການຈ່າຍເງິນທີ່ລູກຄ້າຕ້ອງໄດ້ຮັບການໂອນໄປຫາຄວາມຖືກຕ້ອງທີ່ບັດທະນາຄານທີ່ອອກທະນາຄານ und one ຈາກລະບົບຂອງທ່ານ, ເມື່ອໄດ້ຮັບຜົນສຸດທ້າຍ, ເພື່ອປ່ຽນລູກຄ້າກັບເຂົ້າສູ່ລະບົບຂອງທ່ານ.

ການປ່ຽນແປງຕໍ່ໄປນີ້ຈະຖືກເຮັດຕາມຂັ້ນຕອນປົກກະຕິ. ກະລຸນາຮັບຊາບວ່າເນື່ອງຈາກການຈັດຕັ້ງປະຕິບັດວິທີການຈ່າຍເງິນແບບອື່ນໆທີ່ບໍ່ຄືກັນ, ເຊັ່ນ Paypal, ບາງວິທີການເຫຼົ່ານີ້
ຂັ້ນຕອນອາດຈະມີຢູ່ແລ້ວໃນການຈັດຕັ້ງປະຕິບັດຂອງທ່ານ.

1. ຕອບສະໜອງ URL
   ໃນການໂທລະສັບ ທຳ ອິດ (ໝາຍ ເລກ 2 ໃນແຜນວາດ) ກັບລະບົບການຈ່າຍເງິນ,“ ການຕອບຮັບ URL” ຕ້ອງໄດ້ຜ່ານເຂົ້າໄປໃນກຸ່ມຮ້ານຄ້າຕໍ່ ໜ້າ.
   
   ກະລຸນາສັງເກດ: ຕົວກໍານົດການ IDENTIFICATION.REFERENCEID ແມ່ນມີຄວາມກ່ຽວຂ້ອງເທົ່ານັ້ນຖ້າທ່ານ ໝາຍ ເຖິງການລົງທະບຽນຫຼືການ ດຳ ເນີນການອື່ນທີ່ມີຢູ່ແລ້ວ
2. ການປະມວນຜົນການໂອນຍ້າຍ URL ຖ້າຕ້ອງການການກວດສອບ, ການປ່ຽນເສັ້ນທາງ URL ແລະຕົວ ກຳ ນົດການອື່ນໆໃນກຸ່ມການໂອນຍ້າຍແມ່ນຖືກຍົກຍ້າຍໃນການຕອບຮັບຈາກລະບົບການຈ່າຍເງິນ (ເບີ 5 ໃນແຜນວາດ).
   
   
3. ການສົ່ງຕໍ່ຂອງລູກຄ້າໄປທີ່ການປ່ຽນເສັ້ນທາງ URL
   ຖ້າກຸ່ມການໂອນ ໜ້າ ກຳ ລັງຕອບສະ ໜອງ ກັບການປ່ຽນເສັ້ນທາງ URL, ໂປແກຼມທ່ອງເວັບຂອງລູກຄ້າຕ້ອງຖືກໂອນໄປຫາສິ່ງນີ້ URL (No.າຍເລກ 6 ໃນແຜນວາດ) ເພື່ອດໍາເນີນການກວດສອບຄວາມຖືກຕ້ອງ. ຕົວກໍານົດການເພີ່ມເຕີມຈາກກຸ່ມປ່ຽນເສັ້ນທາງຈະຕ້ອງຖືກໂອນໄປຫາພາຍນອກ webເວັບໄຊເປັນຕົວກໍານົດການ POST.
   ກະລຸນາສັງເກດ: ຕົວ ກຳ ນົດການເພີ່ມເຕີມແມ່ນຖືກສົ່ງຄືນໃນ“ PROCESSING.REDIRECT.xxx” ເທົ່ານັ້ນກັບ 3D Secure version 1 (ເຖິງແມ່ນວ່າ ຈຳ ນວນແລະການຕັ້ງຊື່ອາດຈະແຕກຕ່າງກັນ), ໃນຂະນະທີ່ມີ 3D Version 2 ເທົ່ານັ້ນທີ່ເປັນ PROCESSING.REDIRECT.URL ດັ່ງທີ່ສະແດງຢູ່ດ້ານລຸ່ມແມ່ນສົ່ງຄືນ: https://heidelpay.hpcgw.net/AuthService/v1/auth/public/2258_2863FFA4C5241C12E39F37
   CCF / run ນີ້ ໝາຍ ຄວາມວ່າບໍ່ວ່າປະເພດແລະ ຈຳ ນວນຂອງພາລາມິເຕີ, browser ຂອງລູກຄ້າຕ້ອງຫັນໄປຫາ PROCESSING.REDIRECT.URL.
   ຢູ່ລຸ່ມນີ້ເຈົ້າຈະພົບເຫັນຕົວລະຫັດງ່າຍ simple exampວິທີການປະຕິບັດການປ່ຽນເສັ້ນທາງດັ່ງກ່າວ. ໄດ້ ສ່ວນຫນຶ່ງແມ່ນມີຈຸດປະສົງເພື່ອແຈ້ງໃຫ້ລູກຄ້າປາຍທາງທີ່ລະບົບບໍ່ສະ ໜັບ ສະ ໜູນ Javascript ຫຼືປິດການ ນຳ ໃຊ້ມັນ. ພວກເຮົາແນະນໍາຢ່າງແຂງແຮງວ່າການປ່ຽນເສັ້ນທາງແມ່ນສໍາເລັດພາຍໃນປ່ອງຢ້ຽມບຣາວເຊີທີ່ເປີດໃຊ້ຢູ່ຂອງລູກຄ້າແລະບໍ່ໃຫ້ໃຊ້ປ່ອງຢ້ຽມປັອບອັບຫຼືປ່ອງຢ້ຽມບຣາວເຊີໃ,່, ອັນນີ້ສາມາດເຮັດໄດ້
   ລະຄາຍເຄືອງລູກຄ້າແລະ ນຳ ພາພວກເຂົາປິດ ໜ້າ ທີ່ພວກເຂົາຖືກໂອນໄປຫາ.
   
4. ການກວດສອບຜົນໄດ້ຮັບທີ່ບໍ່ຖືກຕ້ອງ
   ຜົນໄດ້ຮັບຂອງການກວດສອບໄດ້ຖືກສົ່ງໄປຫາເຄື່ອງແມ່ຂ່າຍຂອງທ່ານຢ່າງໄວວາ. ລະບົບການຈ່າຍເງິນຄາດວ່າຈະຖືກຕ້ອງ URL ເປັນການຕອບໂຕ້. (ໝາຍ ເລກ 12 ແລະ 13 ໃນແຜນວາດ). ສຳ ລັບປະສົບຜົນ ສຳ ເລັດຫລືປະຕິເສດ
   ການຈ່າຍເງິນ, ທີ່ແຕກຕ່າງກັນ URL ສາມາດຕອບສະ ໜອງ ໄດ້ທີ່ນີ້ໂດຍລະບົບຂອງທ່ານ.
5. ເສັ້ນທາງກັບມາຂອງລູກຄ້າ
   ລະບົບການຈ່າຍເງິນໂອນລູກຄ້າໄປທີ່ URL ສະຫນອງໃຫ້ໂດຍລະບົບຂອງພໍ່ຄ້າໄດ້ຫຼັງຈາກຂະບວນການກວດສອບແລະການໂອນເງິນໄດ້ຖືກສໍາເລັດ.
   ກະລຸນາສັງເກດ: ຂັ້ນຕອນທີ 4. ) ແລະ 5. ) ດຳ ເນີນການໃນແບບດຽວກັນກັບທີ່ທ່ານຄຸ້ນເຄີຍກັບການເຮັດທຸລະ ກຳ 3D ທີ່ມີຢູ່ແລ້ວ.

3D ປອດໄພແລະການ ຊຳ ລະເງີນຄືນ

ນັບແຕ່ວັນທີ 1 ເດືອນມັງກອນປີ 2021 ເປັນຕົ້ນໄປ, ການຮັບປະກັນ 3D ປອດໄພຈະເປັນສິ່ງ ຈຳ ເປັນ ສຳ ລັບທຸກໆການເຮັດທຸລະ ກຳ ການຄ້າດ້ວຍບັດ e-commerce. ເຖິງຢ່າງໃດກໍ່ຕາມ, ເນື່ອງຈາກວ່າມັນບໍ່ສາມາດໃຊ້ໄດ້ ສຳ ລັບການຈ່າຍຄືນ, ທະນາຄານ
ລະບົບມີລະບົບການເຮັດວຽກແຍກຕ່າງຫາກ ສຳ ລັບສິ່ງນີ້.

ສໍາລັບຈຸດປະສົງນີ້, ທະນາຄານຈໍາແນກລະຫວ່າງ

• CIT = ການຊື້ຂາຍຂອງລູກຄ້າໃນເບື້ອງຕົ້ນ
• MIT = ພໍ່ຄ້າເລີ່ມຕົ້ນເຮັດທຸລະ ກຳ

ການເຮັດບັດຄັ້ງ ທຳ ອິດໃນບັນຊີຜູ້ຄ້າຂອງທ່ານຕ້ອງຖືກກວດສອບດ້ວຍ 3D ປອດໄພຕັ້ງແຕ່ວັນທີ 01.01.2021 ເປັນຕົ້ນໄປ. ການຢັ້ງຢືນທີ່ປະສົບຜົນ ສຳ ເລັດດັ່ງກ່າວແມ່ນຄວາມຕ້ອງການທີ່ ຈຳ ເປັນໃນ
ເພື່ອໃຫ້ສາມາດຕໍ່ມາຈອງປື້ມຕໍ່ໄປໃນບັດດຽວກັນໂດຍບໍ່ຕ້ອງຮັບປະກັນ 3D. ລູກຄ້າຕ້ອງໄດ້ຮັບການສົ່ງຕໍ່ໄປທະນາຄານທີ່ອອກບັດ ສຳ ລັບການ ຊຳ ລະຄັ້ງ ທຳ ອິດ
ປະຕິບັດຕາມຂັ້ນຕອນທີ່ໄດ້ອະທິບາຍຂ້າງເທິງແລະພິສູດຕົວຕົນເອງວ່າເປັນຜູ້ຖືບັດ. ຖ້າການຫັກເງິນບໍ່ໄດ້ຖືກວາງແຜນໄວ້ໃນເວລາຂອງຄໍາສັ່ງ, ສໍາລັບຕົວຢ່າງample ເນື່ອງຈາກໄລຍະເວລາການທົດລອງ, ການຈອງ (ການອະນຸຍາດລ່ວງ ໜ້າ) ຢ່າງ ໜ້ອຍ ໜຶ່ງ ເອີໂຣຕ້ອງເຮັດດ້ວຍ 3D Secure ຢູ່ຕໍ່ ໜ້າ ລູກຄ້າແທນ. ການຈັບຈອງນີ້ບໍ່ ຈຳ ເປັນ.

ສຳ ລັບລູກຄ້າທີ່ມີຢູ່ແລ້ວ, ບໍ່ ຈຳ ເປັນຕ້ອງມີການກວດສອບຄວາມປອດໄພແບບ 3D Secure. ຖ້າການປ່ອຍອອກມາຄັ້ງ ທຳ ອິດທີ່ປະສົບຜົນ ສຳ ເລັດກ່ອນວັນທີ 01.01.2021, ບັນທຶກລູກຄ້າກໍ່ສາມາດຖືວ່າເປັນເຊັ່ນກັນ
ໄດ້ຮັບການຢັ້ງຢືນຢ່າງ ສຳ ເລັດຜົນ. ສຳ ລັບລູກຄ້າ ໃໝ່ ໃນວັນທີ 01.01.2021, ໃນທາງກົງກັນຂ້າມ, ການກວດສອບຄວາມປອດໄພ 3D ແມ່ນເປັນສິ່ງ ຈຳ ເປັນ ສຳ ລັບການອອກບັດຫຼືການຈອງ ທຳ ອິດ (ການອະນຸຍາດກ່ອນ).

ກະລຸນາບັນທຶກໄວ້: ໃນດ້ານນີ້, ລະບົບທະນາຄານເບິ່ງຂໍ້ມູນບັດ, ບໍ່ແມ່ນຂໍ້ມູນຂອງລູກຄ້າ. ສະນັ້ນຖ້າລູກຄ້າທີ່ມີຢູ່ແລ້ວໃຊ້ບັດໃafter່ຫຼັງຈາກວັນທີ 01.01.2021, ສໍາລັບຕົວຢ່າງample ເພາະວ່າຜ່ານມາ
ຄົນ ໜຶ່ງ iredົດອາຍຸຫຼືຍ້ອນວ່າລາວໄດ້ປ່ຽນທະນາຄານຜູ້ອອກບັດຂອງລາວ, ນີ້ແມ່ນຮອບວຽນເກີດຂຶ້ນໃfrom່ຈາກຈຸດຂອງທະນາຄານ view ແລະຕ້ອງໄດ້ຮັບການພິສູດຢືນຢັນດ້ວຍ 3D Secure ສໍາລັບການຈອງຄັ້ງທໍາອິດ.

ເມື່ອການກວດສອບຄວາມຖືກຕ້ອງໃນເບື້ອງຕົ້ນນີ້ໄດ້ປະຕິບັດຢ່າງ ສຳ ເລັດຜົນແລ້ວ, ທຸກໆທຸລະ ກຳ ຕໍ່ໄປແມ່ນຖືກຍົກເວັ້ນຈາກພັນທະໃນການ ນຳ ໃຊ້ 3D ຄວາມປອດໄພເບື້ອງຕົ້ນ ສຳ ລັບການຈ່າຍເງີນຄືນໂດຍບໍ່ຕ້ອງຮັບປະກັນ 3D ປອດໄພດັ່ງນັ້ນ:

• ຢ່າງ ໜ້ອຍ ມີການປ່ອຍສິນເຊື່ອຫຼືການຈອງລ່ວງ ໜ້າ ຢ່າງ ສຳ ເລັດຜົນ (ການອະນຸຍາດກ່ອນລ່ວງ ໜ້າ) ເຊິ່ງໄດ້ຖືກ ດຳ ເນີນດ້ວຍ 3D ຄວາມປອດໄພຫຼືເກີດຂື້ນກ່ອນວັນທີ 01.01.2021.
• ມັນຖືກອ້າງອີງເຖິງການລົງທະບຽນທີ່ມີຢູ່ແລ້ວແລະການໂອນເງິນພາຍໃຕ້ການຍື່ນສະ ເໜີ

ເພື່ອແຈ້ງໃຫ້ລະບົບການຈ່າຍເງິນຮູ້, ວ່ານີ້ແມ່ນການຈ່າຍເງິນຊ້ ຳ, ພາລາມິເຕີ RECURRENCE.MODE = ຕ້ອງໄດ້ສົ່ງຄືນເຊັ່ນກັນ. ນີ້ເປັນສັນຍານຕໍ່ລະບົບທີ່ກ
ການຈ່າຍເງີນຄືນແມ່ນຈະຖືກລາຍງານໃຫ້ລະບົບທະນາຄານ.

ກະລຸນາສັງເກດ: ຖ້າພາລາມິເຕີ RECURRENCE.MODE = REPEATED ຖືກປ້ອນເຂົ້າໃນເວລາທີ່ມີການໂຫລດບັດ ໃໝ່ ເປັນເທື່ອ ທຳ ອິດ, ການສົ່ງຕໍ່ແບບ 3D ປອດໄພຈະຖືກປະຕິບັດເຖິງວ່າຈະມີພາລາມິເຕີນີ້.

ທົດສອບການຈັດຕັ້ງປະຕິບັດ 3D ປອດໄພ

ເຈົ້າສາມາດທົດສອບການເຊື່ອມຕໍ່ 3D Secure ໄດ້ທຸກເວລາຜ່ານລະບົບການຊໍາລະຂອງພວກເຮົາ. ເພື່ອເຮັດແນວນັ້ນ, ໃຊ້ໂCONດ“ CONNECTOR_TEST” ສໍາລັບທຸລະກໍາ, ຕາມທີ່ສະແດງຢູ່ໃນອະດີດamples ຂ້າງເທິງ.
ຂໍ້ມູນເຊື່ອມຕໍ່ ສຳ ລັບການທົດສອບນີ້:

ຄວາມປອດໄພ	31HA07BC8142C5A171745D00AD63D182
ເຂົ້າສູ່ລະບົບ USER.LOGIN	31ha07bc8142c5a171744e5aef11ffd3
USER.PWD	93167DE7
ທຸລະກຳ.CHANNEL	31HA07BC8142C5A171749A60D979B6E4
ສະກຸນເງິນທີ່ ກຳ ນົດໄວ້ ສຳ ລັບ 3D Version 2	EUR, USD, SEK
ສະກຸນເງິນທີ່ ກຳ ນົດໄວ້ ສຳ ລັບ 3D Version 1	GBP, CZK, CHF

ຈຸດຈົບຂອງປະຕູລະບົບແມ່ນທັງ
ປະຕູ SGW:
- https://test-heidelpay.hpcgw.net/sgw/gtw - Latin-15 ເຂົ້າລະຫັດ
- https://test-heidelpay.hpcgw.net/sgw/gtwu - ລະຫັດ UTF-8
ປະຕູ NGW:
- https://test-heidelpay.hpcgw.net/ngw/post

ຂໍ້ມູນບັດເຄດິດ ສຳ ລັບການທົດສອບນີ້:

ຍີ່ຫໍ້	ເລກບັດ	CVV	ວັນໝົດອາຍຸ	ບັນທຶກ
MasterCard	5453010000059543	123	ວັນທີໃນອະນາຄົດ	3D - ລະຫັດຜ່ານ: secret3
ວີຊາ	4711100000000000	123	ວັນທີໃນອະນາຄົດ	3DS - ລະຫັດລັບ: ຄວາມລັບ! 33

ກະລຸນາສັງເກດ: ສຳ ລັບຄວາມປອດໄພ 3D ລຸ້ນທີ 2, ທ່ານບໍ່ ຈຳ ເປັນຕ້ອງໃສ່ລະຫັດຜ່ານ, ແຕ່ກົດທີ່ນີ້” ກົດບ່ອນນີ້ເພື່ອ ສຳ ເລັດການກວດສອບ.
ວິທີດຽວທີ່ຈະ ຈຳ ລອງຄວາມຜິດພາດກັບ 3D Secure Version 2 ແມ່ນການປ່ອຍໃຫ້ ໜ້າ ເວລາທີ່ມີເວລາເຊື່ອມຕໍ່ ໝົດ (ປະມານ 18 ນາທີ).

 

ອ່ານເພີ່ມເຕີມກ່ຽວກັບຄູ່ມືນີ້ ແລະດາວໂຫຼດ PDF:

ເອກະສານ / ຊັບພະຍາກອນ

Softwares 3D Secure Integration Guide [pdf] ເອກະສານ Unzer, ຄູ່ມືການເຊື່ອມໂຍງ, 3Dັ້ນຄົງ XNUMXD

ເອກະສານອ້າງອີງ

• ຄູ່ມືຜູ້ໃຊ້