ບັນທຶກບັນຊີເງິນສົດ


ໂປໂຕຄອນການລົງທະບຽນເງິນສົດ – ພື້ນຖານສໍາລັບລະບົບການຈ່າຍເງິນທີ່ທັນສະໄຫມ

ບົດແນະນຳ: ໂປໂຕຄອນການລົງທະບຽນເງິນສົດແມ່ນຫຍັງ ແລະໃຊ້ເພື່ອຫຍັງ?

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

ແຕ່ລະອະນຸສັນຍາການລົງທະບຽນເງິນສົດມີຈຸດແຂງຂອງຕົນເອງ, ຈຸດອ່ອນແລະຂໍ້ກໍານົດດ້ານວິຊາການ. ບາງຄົນເຮັດວຽກພຽງແຕ່ຢູ່ໃນເຄືອຂ່າຍທ້ອງຖິ່ນ, ໃນຂະນະທີ່ຄົນອື່ນແມ່ນພ້ອມທີ່ຈະຟັງ. ເຊັ່ນດຽວກັນ, ບາງໂປໂຕຄອນຕ້ອງການ ID terminal ຕົວເລກເພື່ອກໍານົດຈຸດທີ່ເປັນເອກະລັກ.

ຂໍ້ໄດ້ປຽບຂອງໂປໂຕຄອນການລົງທະບຽນເງິນສົດທີ່ເລືອກໄດ້ດີ:
ທຸລະກໍາໄວແລະເຊື່ອຖືໄດ້
ການເຊື່ອມໂຍງງ່າຍເຂົ້າໃນລະບົບການລົງທະບຽນເງິນສົດທີ່ມີຢູ່
ຄວາມປອດໄພສູງກວ່າໂດຍຜ່ານການໂຕ້ຕອບມາດຕະຖານ
ການເຊື່ອມຕໍ່ຄລາວເປັນໄປໄດ້ສໍາລັບການບໍລິຫານສູນກາງ

ໃນທີ່ນີ້ພວກເຮົາແນະນໍາທ່ານກ່ຽວກັບໂປໂຕຄອນການລົງທະບຽນເງິນສົດທີ່ສໍາຄັນທີ່ສຸດທີ່ມີຄຸນສົມບັດ, ຂໍ້ດີແລະຂໍ້ເສຍຂອງມັນ.

ເມື່ອຕັ້ງຄ່າຢ່າງຖືກຕ້ອງ, ໂປໂຕຄອນທີ່ດີຈະຮັບປະກັນການເຮັດທຸລະກໍາທີ່ຫມັ້ນຄົງ - ມື້ຫຼັງຈາກມື້.

ພາບລວມຂອງໂປໂຕຄອນການລົງທະບຽນເງິນສົດທີ່ສໍາຄັນທີ່ສຸດ



ZVT (ມາດຕະຖານສະຖານີການຈ່າຍເງິນ)

ZVT ແມ່ນມາດຕະຖານທີ່ໃຊ້ກັນຢ່າງກວ້າງຂວາງທີ່ສຸດໃນປະເທດທີ່ເວົ້າພາສາເຢຍລະມັນສໍາລັບການສື່ສານລະຫວ່າງລະບົບ POS ແລະເຄື່ອງຈ່າຍເງິນ. ມັນແມ່ນອີງໃສ່ການເຊື່ອມຕໍ່ເຄືອຂ່າຍທ້ອງຖິ່ນແລະຕ້ອງການ ID terminal ຕົວເລກ.

Cloud ເປີດບໍ? ບໍ່, ພຽງແຕ່ເຄືອຂ່າຍທ້ອງຖິ່ນ
ຕ້ອງການ ID terminal ຕົວເລກ? ! ແມ່ນແລ້ວ

ຂໍ້ດີ:
ມາດຕະຖານທີ່ພິສູດແລະໃຊ້ຢ່າງກວ້າງຂວາງໃນເຢຍລະມັນ
ຄວາມເຂົ້າກັນໄດ້ສູງກັບລະບົບການລົງທະບຽນເງິນສົດຫຼາຍ
ການປະຕິບັດທີ່ຫມັ້ນຄົງແລະເຊື່ອຖືໄດ້

ຂໍ້ເສຍ:
ບໍ່ມີການເຊື່ອມໂຍງຄລາວທີ່ເປັນໄປໄດ້
ຄວາມຢືດຢຸ່ນຈໍາກັດສໍາລັບລະບົບ API ທີ່ທັນສະໄໝ
ບໍ່ເໝາະສົມສຳລັບຕະຫຼາດສາກົນ



REST API

REST APIs ເຮັດໃຫ້ການສື່ສານທີ່ທັນສະໄຫມລະຫວ່າງການລົງທະບຽນເງິນສົດແລະເຄື່ອງຈ່າຍເງິນຜ່ານທາງເຊື່ອມຕໍ່ເວັບ. ພວກມັນມີຄວາມຍືດຫຍຸ່ນໂດຍສະເພາະ ແລະມັກຈະເປີດໃຊ້ຄລາວ.

Cloud ເປີດບໍ? ແມ່ນແລ້ວ
ຕ້ອງການ ID terminal ຕົວເລກ? ! ບໍ່

ຂໍ້ດີ:
ເວທີທີ່ເປັນເອກະລາດແລະມີຄວາມຍືດຫຍຸ່ນ
ສາມາດຂະຫຍາຍໄດ້ສໍາລັບລະບົບຄລາວ ແລະອອນໄລນ໌
ເຫມາະສໍາລັບລະບົບການລົງທະບຽນເງິນສົດທີ່ທັນສະໄຫມ

ຂໍ້ເສຍ:
ຕ້ອງການການເຊື່ອມຕໍ່ອິນເຕີເນັດ
ການປະຕິບັດທີ່ສັບສົນຫຼາຍ
ຂຶ້ນກັບຄວາມພ້ອມຂອງ API ຂອງຜູ້ໃຫ້ບໍລິການ



Cloud REST API

variant ຂອງ REST API ນີ້ ແມ່ນ cloud-based ຢ່າງ ເຕັມ ສ່ວນ ແລະ ເຮັດ ໃຫ້ ການ ຄຸ້ມ ຄອງ ສູນ ກາງ ຂອງ terminals ການ ຊໍາ ລະ ຜ່ານ ອິນ ເຕີ ເນັດ.

Cloud ເປີດບໍ? ແມ່ນແລ້ວ
ຕ້ອງການ ID terminal ຕົວເລກ? ! ບໍ່

ຂໍ້ດີ:
ບໍ່ຈໍາເປັນຕ້ອງມີໂຄງສ້າງພື້ນຖານ
ຄວບຄຸມສູນກາງໄດ້ສໍາລັບຮ້ານຄ້າຕ່ອງໂສ້
ສາມາດປັບຂະ ໜາດ ແລະປ່ຽນແປງໄດ້

ຂໍ້ເສຍ:
ຂຶ້ນກັບການເຊື່ອມຕໍ່ອິນເຕີເນັດທີ່ໝັ້ນຄົງ
ສັງເກດເບິ່ງຂໍ້ກໍານົດການປົກປ້ອງຂໍ້ມູນ
ຄວາມລ່າຊ້າທີ່ເປັນໄປໄດ້ເນື່ອງຈາກການສື່ສານໃນຄລາວ



OPI (Open Payment Interface)

Open Payment Interface (O.P.I) ແມ່ນສ່ວນຕິດຕໍ່ສື່ສານລະຫວ່າງລະບົບ POS ແລະ terminals ຊໍາລະເງິນ, ເຊິ່ງໂດຍສະເພາະແມ່ນການນໍາໃຊ້ໃນຕະຫຼາດສາກົນ.

Cloud ເປີດບໍ? ບໍ່, ພຽງແຕ່ເຮັດວຽກຢູ່ໃນເຄືອຂ່າຍທ້ອງຖິ່ນ
ຕ້ອງການ ID terminal ຕົວເລກ? ! ບໍ່

ຂໍ້ດີ:
ຄວາມປອດໄພສູງແລະສະຖຽນລະພາບ
ສະຫນັບສະຫນູນວິທີການຊໍາລະຕ່າງໆ
ສາມາດນໍາໃຊ້ສາກົນ

ຂໍ້ເສຍ:
ບໍ່ມີການເຊື່ອມຕໍ່ຄລາວທີ່ເປັນໄປໄດ້
ການປະສົມປະສານທີ່ສັບສົນຫຼາຍກ່ວາວິທີແກ້ໄຂ API ທີ່ທັນສະໄຫມ
ບໍ່ຖືກນໍາໃຊ້ຢ່າງກວ້າງຂວາງເປັນ ZVT ຫຼື REST API



ep2 (EFT/POS 2000)

ep2 ແມ່ນມາດຕະຖານການຈ່າຍເງິນທີ່ພັດທະນາໃນປະເທດສະວິດເຊີແລນທີ່ຮັບປະກັນການສື່ສານເປັນເອກະພາບລະຫວ່າງລະບົບການລົງທະບຽນເງິນສົດແລະເຄື່ອງຈ່າຍເງິນ. ມັນຕ້ອງການ ID terminal ຕົວເລກ.

Cloud ເປີດບໍ? ບໍ່, ພຽງແຕ່ເຄືອຂ່າຍທ້ອງຖິ່ນ
ຕ້ອງການ ID terminal ຕົວເລກ? ! ບໍ່

ຂໍ້ດີ:
ການແກ້ໄຂມາດຕະຖານໃນສະວິດເຊີແລນ
ມາດຕະຖານຄວາມປອດໄພສູງ
ການໂຕ້ຕອບເອກະພາບສໍາລັບຜູ້ໃຫ້ບໍລິການທີ່ແຕກຕ່າງກັນ

ຂໍ້ເສຍ:
ຈໍາກັດຢູ່ໃນຕະຫຼາດສະວິດ
ບໍ່ມີການເຊື່ອມໂຍງຄລາວທີ່ເປັນໄປໄດ້
ມີຄວາມຍືດຫຍຸ່ນຫນ້ອຍກວ່າການແກ້ໄຂ API ທີ່ທັນສະໄຫມ



myPOS

myPOS ເປັນການຊໍາລະເງິນຟັງທີ່ທັນສະໄຫມທີ່ບໍ່ຕ້ອງການພື້ນຖານໂຄງລ່າງຂອງທ້ອງຖິ່ນ.

Cloud ເປີດບໍ? ແມ່ນແລ້ວ
ຕ້ອງການ ID terminal ຕົວເລກ? ! ບໍ່

ຂໍ້ດີ:
ງ່າຍທີ່ຈະປະຕິບັດ
Cloud-based ເພື່ອຄວາມຍືດຫຍຸ່ນສູງສຸດ
ສະຫນັບສະຫນູນວິທີການຊໍາລະຫຼາຍ

ຂໍ້ເສຍ:
ຂຶ້ນກັບຜູ້ໃຫ້ບໍລິການ myPOS
ທາງເລືອກການປັບແຕ່ງຈໍາກັດ
ຕ້ອງການການເຊື່ອມຕໍ່ອິນເຕີເນັດ



NEXO

NEXO ແມ່ນມາດຕະຖານທີ່ໄດ້ຮັບການຍອມຮັບໃນລະດັບສາກົນສໍາລັບທຸລະກໍາການຈ່າຍເງິນທີ່ສະຫນອງການເຮັດວຽກຮ່ວມກັນແລະຄວາມປອດໄພ.

Cloud ເປີດບໍ? ແມ່ນແລ້ວ
ຕ້ອງການ ID terminal ຕົວເລກ? ! ບໍ່

ຂໍ້ດີ:
ຫຼັກຖານໃນອະນາຄົດແລະສາມາດຂະຫຍາຍໄດ້
ໄດ້ຮັບການຍອມຮັບຈາກສາກົນ
ຮອງຮັບ cloud ແລະເຄືອຂ່າຍທ້ອງຖິ່ນ

ຂໍ້ເສຍ:
ການປະຕິບັດທີ່ສັບສົນ
ຍັງບໍ່ທັນໄດ້ສ້າງຕັ້ງຂຶ້ນຢູ່ທົ່ວທຸກແຫ່ງ
ຄວາມພະຍາຍາມໃນການຝຶກອົບຮົມທີ່ສູງຂຶ້ນ



ISO 20022

ມາດຕະຖານການຈ່າຍເງິນທົ່ວໂລກທີ່ມີຄວາມສໍາຄັນໂດຍສະເພາະສໍາລັບທະນາຄານແລະຜູ້ໃຫ້ບໍລິການທາງດ້ານການເງິນ.

Cloud ເປີດບໍ? ແມ່ນແລ້ວ
ຕ້ອງການ ID terminal ຕົວເລກ? ! ບໍ່

ຂໍ້ດີ:
ມາດຕະຖານຫຼັກຖານໃນອະນາຄົດ
ຮອງຮັບຫຼາຍຮູບແບບການຈ່າຍເງິນ
ຄວາມປອດໄພສູງ

ຂໍ້ເສຍ:
ສະລັບສັບຊ້ອນແລະບໍ່ສະເຫມີໄປງ່າຍທີ່ຈະປະຕິບັດ
ຄ່າໃຊ້ຈ່າຍທີ່ສູງຂຶ້ນສໍາລັບການປັບຕົວ
ສ່ວນໃຫຍ່ສໍາລັບທະນາຄານ, ຫນ້ອຍສໍາລັບການຂາຍຍ່ອຍ



SIX (TIM)

ອະນຸສັນຍາທີ່ເປັນກຳມະສິດຂອງ SIX Payment Services, ມັກໃຊ້ໃນສະວິດເຊີແລນ.

Cloud ເປີດບໍ? ບໍ່
ຕ້ອງການ ID terminal ຕົວເລກ? ! ບໍ່

ຂໍ້ດີ:
ຄວາມປອດໄພສູງ
ເຫມາະໂດຍສະເພາະສໍາລັບຕະຫຼາດສະວິດເຊີແລນ
ການປະຕິບັດທີ່ຫມັ້ນຄົງ

ຂໍ້ເສຍ:
ບໍ່ໄດ້ແຈກຢາຍສາກົນ
ບໍ່ມີຄວາມສາມາດໃນການຟັງ
ຄວາມຍືດຫຍຸ່ນຈໍາກັດ



ຜູ້ໃຫ້ບໍລິການ Acquirer / SoftPOS ເປັນເຈົ້າຂອງ POS protocol APIs

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

Cloud ເປີດບໍ? ແມ່ນແລ້ວ, ໃນກໍລະນີຫຼາຍທີ່ສຸດ
ຕ້ອງການ ID terminal ຕົວເລກ? ! ບໍ່, ID ຜູ້ຄ້າທີ່ເປັນເອກະລັກ ຫຼືລະຫັດ API ມັກຈະຖືກນໍາໃຊ້

ຂໍ້ດີ:
ການເຊື່ອມຕໍ່ໂດຍກົງກັບໂປເຊດເຊີການຈ່າຍເງິນໂດຍບໍ່ມີຜູ້ໃຫ້ບໍລິການພາກສ່ວນທີສາມ
ການຄວບຄຸມຢ່າງເຕັມທີ່ກ່ຽວກັບຂະບວນການຊໍາລະ
ມັກຈະປະຕິບັດໄດ້ງ່າຍໂດຍຜ່ານເທກໂນໂລຍີ API ທີ່ທັນສະໄຫມ

ຂໍ້ເສຍ:
ຂຶ້ນກັບຜູ້ຮັບ ຫຼືຜູ້ໃຫ້ບໍລິການ SoftPOS ທີ່ກ່ຽວຂ້ອງ
ອາດຈະມີຄວາມຍືດຫຍຸ່ນຫນ້ອຍກວ່າອະນຸສັນຍາທົ່ວໄປ
ຄວາມຕ້ອງການການປະຕິບັດທີ່ແຕກຕ່າງກັນຂຶ້ນຢູ່ກັບຜູ້ໃຫ້ບໍລິການ
ການປ່ຽນໄປຫາຜູ້ຊື້ອື່ນອາດຈະຮຽກຮ້ອງໃຫ້ມີການປັບຕົວທີ່ສັບສົນ



Verifone FIPay / VX protocols

Verifone ສະເໜີໂປຣໂຕຄໍຊຸດຂອງຕົນເອງສຳລັບລຸ້ນທີ່ຕ່າງກັນ. ເຫຼົ່ານີ້ມີຕັ້ງແຕ່ລຸ້ນ VX ເກົ່າໄປຈົນເຖິງອຸປະກອນ Android ທີ່ທັນສະໄໝດ້ວຍ FIPay (API ທີ່ໃຊ້ຄລາວຂອງ Verifone).

Cloud ເປີດບໍ? ແມ່ນແລ້ວ (FIPay) / ບໍ່ (ໂປໂຕຄອນ VX ເກົ່າກວ່າ)
ຕ້ອງການ ID terminal ຕົວເລກ? ! ບໍ່

ຂໍ້ດີ:
ແຈກຢາຍຢ່າງກວ້າງຂວາງ, ໂດຍສະເພາະໃນເອີຣົບແລະອາເມລິກາເຫນືອ
ສະຫນັບສະຫນູນສໍາລັບວິທີການຊໍາລະຕ່າງໆ (ບັດເຄຣດິດ, NFC, ການຊໍາລະໂທລະສັບມືຖື)
FIPay ເຮັດໃຫ້ການເຊື່ອມໂຍງຄລາວທີ່ທັນສະໄຫມ

ຂໍ້ເສຍ:
ອະນຸສັນຍາທີ່ເປັນເຈົ້າຂອງ, ດັ່ງນັ້ນມີຄວາມຍືດຫຍຸ່ນຫນ້ອຍ
ໂປຣໂຕຄໍ VX ເກົ່າບໍ່ພ້ອມໃນຄລາວ
ຖືກຈຳກັດບາງສ່ວນຕໍ່ກັບບາງຈຸດຂອງ Verifone



Adyen Terminal API

Adyen ສະຫນອງການປະມວນຜົນການຈ່າຍເງິນທີ່ອີງໃສ່ API ຢ່າງເຕັມສ່ວນທີ່ສາມາດສົມທົບກັບເຄື່ອງໃຊ້ໄຟຟ້າ, ການຈ່າຍເງິນອອນໄລນ໌ແລະການແກ້ໄຂ POS ມືຖື. ຫນ້າສົນໃຈໂດຍສະເພາະສໍາລັບຜູ້ຄ້າປີກສາກົນທີ່ມີຍຸດທະສາດ omnichannel.

Cloud ເປີດບໍ? ແມ່ນແລ້ວ
ຕ້ອງການ ID terminal ຕົວເລກ? ! ບໍ່

ຂໍ້ດີ:
ການເຊື່ອມໂຍງ API ທີ່ມີຄວາມຍືດຫຍຸ່ນຫຼາຍສໍາລັບ POS, ອີຄອມເມີຊແລະມືຖື
ຮອງຮັບການຈ່າຍເງິນແບບ contactless ແລະກະເປົາເງິນດິຈິຕອນ (Apple Pay, Google Pay)
ບໍ່ຈໍາເປັນຕ້ອງມີ ID terminal ຄົງທີ່

ຂໍ້ເສຍ:
ຈຸດສຸມທີ່ເຂັ້ມແຂງກ່ຽວກັບລະບົບນິເວດ Adyen - ຫນ້ອຍທີ່ເຫມາະສົມກັບຜູ້ຊື້ພາກສ່ວນທີສາມ
ການປະຕິບັດເບື້ອງຕົ້ນອາດຈະຕ້ອງການທາງດ້ານວິຊາການຫຼາຍຂຶ້ນ
ຮູບແບບລາຄາ Adyen ແມ່ນບໍ່ເຫມາະສົມສໍາລັບຮ້ານຂາຍຍ່ອຍທັງຫມົດ



Stripe Terminal API

Stripe ແມ່ນເປັນທີ່ຮູ້ຈັກຕົ້ນຕໍເປັນຜູ້ໃຫ້ບໍລິການຈ່າຍເງິນອອນໄລນ໌, ແຕ່ຍັງສະຫນອງການແກ້ໄຂ POS ກັບ Terminal API. ໂດຍສະເພາະແມ່ນຫນ້າສົນໃຈສໍາລັບຜູ້ເລີ່ມຕົ້ນ, ບໍລິສັດອີຄອມເມີຊແລະຜູ້ຄ້າປີກສາກົນທີ່ມີ POS ທີ່ໃຊ້ຟັງໄດ້.

Cloud ເປີດບໍ? ແມ່ນແລ້ວ
ຕ້ອງການ ID terminal ຕົວເລກ? ! ບໍ່

ຂໍ້ດີ:
ການເຊື່ອມໂຍງ API ງ່າຍຫຼາຍສໍາລັບ POS ແລະການຈ່າຍເງິນອອນໄລນ໌
ການແກ້ໄຂທີ່ສາມາດຂະຫຍາຍໄດ້ສໍາລັບຮ້ານຂາຍຍ່ອຍທີ່ມີຫຼາຍສະຖານທີ່
ຮອງຮັບວິທີການຈ່າຍເງິນທີ່ທັນສະໄໝ (ເຊັ່ນ: Apple Pay, Google Pay)

ຂໍ້ເສຍ:
ຈຸດສຸມທີ່ເຂັ້ມແຂງກ່ຽວກັບລະບົບນິເວດ Stripe – ມີຄວາມຍືດຫຍຸ່ນຫນ້ອຍສໍາລັບພາກສ່ວນທີສາມ
ບໍ່ແມ່ນຜູ້ຊື້ທັງໝົດໄດ້ຮັບການສະໜັບສະໜູນ
ອາດມີຄ່າທຳນຽມການເຮັດທຸລະກຳສູງກວ່າເມື່ອທຽບກັບຜູ້ໃຫ້ບໍລິການແບບດັ້ງເດີມ



CB2 (Cartes Bancaires – ຝຣັ່ງ)

CB2 ເປັນໂປໂຕຄອນທີ່ໃຊ້ກັນຢ່າງກວ້າງຂວາງໃນປະເທດຝຣັ່ງສໍາລັບການຈ່າຍເງິນບັດເຄຣດິດ ແລະບັດເດບິດ. ມັນຖືກນໍາໃຊ້ໂດຍທະນາຄານແລະຜູ້ຄ້າຝຣັ່ງສ່ວນໃຫຍ່ແລະຖືກເຊື່ອມຕໍ່ຢ່າງໃກ້ຊິດກັບເຄືອຂ່າຍການຈ່າຍເງິນ Cartes Bancaires.

Cloud ເປີດບໍ? ບໍ່, ພຽງແຕ່ເຄືອຂ່າຍທ້ອງຖິ່ນ
ຕ້ອງການ ID terminal ຕົວເລກ? ! ແມ່ນແລ້ວ

ຂໍ້ດີ:
ແຜ່ຂະຫຍາຍຢູ່ໃນປະເທດຝຣັ່ງ
ການເຊື່ອມຕໍ່ໂດຍກົງກັບທະນາຄານຝຣັ່ງ
ເຫມາະສໍາລັບການເຮັດທຸລະກໍາລະດັບຊາດ

ຂໍ້ເສຍ:
ບໍ່ຮອງຮັບຄລາວເດີມ
ຈຳກັດການນຳໃຊ້ສາກົນ
ເປັນເຈົ້າຂອງ ແລະຜູກມັດຢ່າງແໜ້ນແຟ້ນກັບປະເທດຝຣັ່ງ



J/XFS (Java/eXtensions ສໍາລັບການບໍລິການດ້ານການເງິນ)

J/XFS ເປັນມາດຕະຖານເປີດສໍາລັບລະບົບ POS ແລະຕູ້ ATM. ມັນເຮັດໃຫ້ການເຊື່ອມຕໍ່ທີ່ປ່ຽນແປງໄດ້ຂອງສະຖານທີ່ຊໍາລະເງິນ, ຕູ້ ATM ແລະອຸປະກອນທາງການເງິນອື່ນໆໂດຍຜ່ານ API ເປັນເວທີທີ່ເປັນເອກະລາດ.

Cloud ເປີດບໍ? ບໍ່ (ການເຊື່ອມໂຍງທ້ອງຖິ່ນ)
ຕ້ອງການ ID terminal ຕົວເລກ? ! ບໍ່

ຂໍ້ດີ:
ການໂຕ້ຕອບມາດຕະຖານສໍາລັບຈຸດຈ່າຍເງິນຕ່າງໆ
modularity ທີ່ດີສໍາລັບທະນາຄານແລະຮ້ານຂາຍຍ່ອຍຂະຫນາດໃຫຍ່
ເອກະລາດຂອງຜູ້ຜະລິດຢູ່ປາຍຍອດ

ຂໍ້ເສຍ:
ຫນ້ອຍທົ່ວໄປສໍາລັບລະບົບການລົງທະບຽນເງິນສົດຄລາສສິກ
ການປະຕິບັດສາມາດສັບສົນ
ບໍ່ຮອງຮັບຄລາວເດີມ



ELM (ການຄຸ້ມຄອງການລັອກເອເລັກໂຕຣນິກ) - ສໍາລັບການປ້ໍາມັນອາຍແກັສ & e-mobility

ELM ຖືກນໍາໃຊ້ສໍາລັບສະຖານີອາຍແກັສແລະການຈ່າຍເງິນ e-mobility. ມັນເຊື່ອມຕໍ່ລະບົບການລົງທະບຽນເງິນສົດກັບປໍ້າກ໊າຊ ຫຼືສະຖານີສາກໄຟເພື່ອໃຫ້ຂະບວນການຊໍາລະແບບບໍ່ມີຮອຍຕໍ່.

Cloud ເປີດບໍ? ແມ່ນແລ້ວ
ຕ້ອງການ ID terminal ຕົວເລກ? ! ແມ່ນແລ້ວ

ຂໍ້ດີ:
ພັດທະນາໂດຍສະເພາະສໍາລັບສະຖານີອາຍແກັສແລະສະຖານີສາກໄຟອີເລັກໂທຣນິກ
Cloud ພ້ອມແລ້ວສຳລັບການແກ້ໄຂການເຄື່ອນໄຫວທີ່ທັນສະໄໝ
ສະຫນັບສະຫນູນວິທີການຊໍາລະຕ່າງໆ (ບັດ, app, RFID)

ຂໍ້ເສຍ:
ສະເພາະອຸດສາຫະກໍາຫຼາຍ - ບໍ່ເຫມາະສົມສໍາລັບຮ້ານຂາຍຍ່ອຍແບບດັ້ງເດີມ
ການຈັດຕັ້ງປະຕິບັດມັກຈະເປັນໄປໄດ້ຜ່ານຜູ້ໃຫ້ບໍລິການພິເສດເທົ່ານັ້ນ
ການເອື່ອຍອີງທີ່ເຂັ້ມແຂງກັບຜູ້ໃຫ້ບໍລິການດ້ານໂຄງລ່າງ



ໂປຣໂຕຄໍ SoftPOS ( APIs ສະເພາະຂອງຜູ້ຊື້/ຜູ້ໃຫ້ບໍລິການ)

ໂຊລູຊັ່ນ SoftPOS ເປີດໃຊ້ການຊໍາລະບັດຜ່ານໂທລະສັບສະມາດໂຟນ ຫຼືແທັບເລັດໄດ້. ຜູ້ຊື້ຫຼາຍຄົນ (ເຊັ່ນ: myPOS, SumUp, Adyen, Stripe, PayPal) ໄດ້ສ້າງໂປໂຕຄອນ API ຂອງຕົນເອງສໍາລັບ SoftPOS.

Cloud ເປີດບໍ? ແມ່ນແລ້ວ
ຕ້ອງການ ID terminal ຕົວເລກ? ! ບໍ່, ID ຜູ້ຄ້າທີ່ເປັນເອກະລັກ ຫຼືລະຫັດ API ມັກຈະຖືກນໍາໃຊ້

ຂໍ້ດີ:
ບໍ່ມີຮາດແວທີ່ຈໍາເປັນ – ໂທລະສັບສະຫຼາດຫຼືຢາເມັດແມ່ນພຽງພໍ
ມີຄວາມຍືດຫຍຸ່ນແລະງ່າຍສໍາລັບຮ້ານຂາຍຍ່ອຍຂະຫນາດນ້ອຍຫຼືຜູ້ໃຫ້ບໍລິການມືຖື
ຮອງຮັບການຈ່າຍເງິນແບບ contactless (NFC, Apple Pay, Google Pay)

ຂໍ້ເສຍ:
ມັກຈະຈຳກັດໃຫ້ຜູ້ຮັບ ຫຼືຜູ້ໃຫ້ບໍລິການສະເພາະ
ບໍ່ແມ່ນທະນາຄານ ແລະຜູ້ຊື້ທັງໝົດທີ່ຮອງຮັບ SoftPOS
ອາດຈະສູງກວ່າຄ່າທຳນຽມຕໍ່ທຸລະກຳ



SumUp Terminal API

SumUp ເປັນຜູ້ໃຫ້ບໍລິການຊໍາລະບັດມືຖືຍອດນິຍົມ ແລະ, ດ້ວຍ Terminal API, ສະຫນອງການໂຕ້ຕອບສໍາລັບການເຊື່ອມໂຍງກັບລະບົບການລົງທະບຽນເງິນສົດ, ແອັບຯມືຖື ຫຼືຮ້ານຄ້າອອນໄລນ໌. API ຊ່ວຍໃຫ້ SumUp terminals ເຊື່ອມຕໍ່ໄດ້ຢ່າງງ່າຍດາຍກັບລະບົບ POS ແລະເວທີຄລາວ.

Cloud ເປີດບໍ? ແມ່ນແລ້ວ
ຕ້ອງການ ID terminal ຕົວເລກ? ! ບໍ່

ຂໍ້ດີ:
ການເຊື່ອມໂຍງແບບງ່າຍດາຍແລະໄວຜ່ານ API
ບໍ່ຈໍາເປັນຕ້ອງມີ ID terminal ຕົວເລກ
ເຫມາະສໍາລັບພໍ່ຄ້າຂະຫນາດນ້ອຍ, ຄົນທີ່ເຮັດວຽກດ້ວຍຕົນເອງແລະຜູ້ໃຫ້ບໍລິການມືຖື
ຮອງຮັບການຈ່າຍເງິນແບບ contactless ແລະກະເປົາມືຖື (Apple Pay, Google Pay)

ຂໍ້ເສຍ:
ຂຶ້ນຢູ່ກັບລະບົບນິເວດ SumUp – ມີຄວາມຍືດຫຍຸ່ນຫນ້ອຍສໍາລັບພາກສ່ວນທີສາມ
ທາງເລືອກການປັບແຕ່ງທີ່ຈໍາກັດສໍາລັບຜູ້ຄ້າຂະຫນາດໃຫຍ່
ບໍ່ແມ່ນຜູ້ຮັບທັງຫມົດສະຫນັບສະຫນູນການເຊື່ອມຕໍ່ໂດຍກົງກັບ SumUp, ເຊັ່ນວ່າບໍ່ມີການຍອມຮັບ girocard
ອາດຈະສູງກວ່າຄ່າທຳນຽມຕໍ່ທຸລະກຳ



ສະຫຼຸບ
ການເລືອກໂປໂຕຄອນການລົງທະບຽນເງິນສົດທີ່ຖືກຕ້ອງແມ່ນຂຶ້ນກັບຄວາມຕ້ອງການສ່ວນບຸກຄົນຂອງບໍລິສັດ. ໃນຂະນະທີ່ ZVT ແລະ ep2 ຖືກພິສູດແລ້ວ, ມາດຕະຖານທ້ອງຖິ່ນ, REST API ແລະ NEXO ສະເຫນີທາງເລືອກທີ່ທັນສະໄຫມ, ຟັງໄດ້. Cloud REST API ແລະ myPOS ເຮັດໃຫ້ການເຊື່ອມໂຍງຄລາວໄດ້ງ່າຍ, ໃນຂະນະທີ່ ISO 20022 ມີຄວາມກ່ຽວຂ້ອງໂດຍສະເພາະສໍາລັບທະນາຄານ.

ຜູ້ຊື້ຫຼື SoftPOS APIs ຂອງຕົນເອງສະເຫນີການເຊື່ອມຕໍ່ໂດຍກົງກັບແພລະຕະຟອມການຈ່າຍເງິນທີ່ກ່ຽວຂ້ອງແລະໂດຍສະເພາະແມ່ນເຫມາະສົມສໍາລັບຜູ້ຄ້າທີ່ຕ້ອງການເຮັດວຽກຢ່າງໃກ້ຊິດກັບຜູ້ໃຫ້ບໍລິການຊໍາລະເງິນສະເພາະ.

ມາດຕະຖານໂປໂຕຄອນກໍານົດຄວາມພໍໃຈຂອງລູກຄ້າ, ຄວາມພະຍາຍາມໃນການຮັກສາແລະຄວາມປອດໄພການເຮັດທຸລະກໍາ.

💡 ຄໍາແນະນໍາຂອງພວກເຮົາ

ຖ້າທ່ານກໍາລັງຊອກຫາຄວາມປອດໄພແລະຄວາມຍືດຫຍຸ່ນສູງສຸດໃນອະນາຄົດ, ທ່ານຄວນອີງໃສ່ການແກ້ໄຂ API-based ຫຼື cloud-capable.

ຖ້າທ່ານຕ້ອງການການເຊື່ອມໂຍງທີ່ພິສູດ, ມີຄວາມຫມັ້ນຄົງ, ທ່ານສາມາດນໍາໃຊ້ໂປໂຕຄອນຄລາສສິກເຊັ່ນ ZVT ຫຼື ep2.

ຜູ້ທີ່ເຮັດວຽກຢ່າງໃກ້ຊິດກັບຜູ້ຊື້ຫຼືຜູ້ໃຫ້ບໍລິການ SoftPOS ສາມາດໄດ້ຮັບຜົນປະໂຫຍດຈາກ APIs ທີ່ເປັນເຈົ້າຂອງຂອງພວກເຂົາ.

ທ່ານຕ້ອງການລາຍງານການລົງທະບຽນເງິນສົດສະເພາະຫຼືບໍ່? ກະລຸນາຮູ້ສຶກວ່າບໍ່ເສຍຄ່າເພື່ອຕິດຕໍ່ພວກເຮົາ.

ໃຫ້ພວກເຮົາແນະນໍາໃຫ້ທ່ານຊອກຫາວິທີແກ້ໄຂທີ່ດີທີ່ສຸດສໍາລັບຄວາມຕ້ອງການຂອງທ່ານ!