ເປັນຫຍັງຊອບແວໂປຣແກຣມສະສົມຄະແນນຈຶ່ງລົ້ມເຫລວໃນຮາດແວ POS ທີ່ຖືກລັອກໄວ້?

ໂຄງການສະສົມຄະແນນຄວາມພັກດີລົ້ມເຫຼວໃນເຄື່ອງ POS ດ້ວຍເຫດຜົນໜຶ່ງຫຼາຍກວ່າເຫດຜົນອື່ນໆ: ຮາດແວບໍ່ເຄີຍຖືກສ້າງຂຶ້ນເພື່ອໃຫ້ຊອບແວພາຍນອກເຂົ້າມາ. ຜູ້ຂາຍຍ່ອຍຊື້ແພລດຟອມສະສົມຄະແນນຄວາມພັກດີ, ເຊັນສັນຍາ, ວາງງົບປະມານການເປີດຕົວ - ຈາກນັ້ນຄົ້ນພົບລະບົບປະຕິບັດການ, SDK, ຫຼືໃບຢັ້ງຢືນການຈ່າຍເງິນຂອງເຄື່ອງນັ້ນຂັດຂວາງການເຊື່ອມໂຍງທັງໝົດ. ນີ້ບໍ່ແມ່ນບັນຫາຊອບແວ. ມັນເປັນບັນຫາສະຖາປັດຕະຍະກຳຮາດແວ, ແລະມັນປາກົດຂຶ້ນເກືອບທຸກຄັ້ງທີ່ຜູ້ຄ້າພະຍາຍາມຕິດຕັ້ງລະບົບ pos ທີ່ມີໜ້າທີ່ໂຄງການສະສົມຄະແນນຄວາມພັກດີໃສ່ເຄື່ອງທີ່ຖືກອອກແບບເປັນອຸປະກອນການຈ່າຍເງິນແບບປິດແທນທີ່ຈະເປັນອຸປະກອນຄອມພິວເຕີແບບເປີດ.
ກ່ອນທີ່ຈະປະເມີນແພລດຟອມໃດໆ, ມັນຈະຊ່ວຍໃຫ້ແກ້ໄຂບັນຫາໄດ້ ຄຳຖາມພື້ນຖານກ່ຽວກັບສິ່ງທີ່ເຄື່ອງ POS ສາມາດເຮັດຫຍັງໄດ້ ແລະ ບໍ່ສາມາດເຮັດຫຍັງໄດ້ກັບຂໍ້ມູນລາງວັນ — ເພາະວ່າຄຳຕອບແມ່ນຂຶ້ນກັບຮາດແວທີ່ຢູ່ດ້ານລຸ່ມທັງໝົດ, ບໍ່ແມ່ນລາຍຊື່ຄຸນສົມບັດຂອງຊອບແວຣຄວາມພັກດີ.
ບົດຄວາມນີ້ຈະອະທິບາຍເຫດຜົນທາງເທັກນິກສະເພາະທີ່ລະບົບ POS ທີ່ປະສົມປະສານຄວາມພັກດີລົ້ມເຫຼວໃນຮາດແວທີ່ຖືກລັອກໄວ້, ຄຳວ່າ "ລັອກໄວ້" ໝາຍຄວາມວ່າແນວໃດໃນລະດັບລະບົບປະຕິບັດການ ແລະ ລະດັບການຮັບຮອງ, ແລະ ລາຍການກວດສອບການປະເມີນຜົນສຳລັບຮ້ານຄ້າທີ່ຕ້ອງການລະບົບ POS ຄວາມພັກດີຂອງລູກຄ້າທີ່ເຮັດວຽກໄດ້ແທ້ໃນການຜະລິດ.

1. ຄຳວ່າ "ຮາດແວ POS ທີ່ຖືກລັອກໄວ້" ໝາຍຄວາມວ່າແນວໃດແທ້

ຮາດແວ POS ທີ່ຖືກລັອກໄວ້ແມ່ນເຄື່ອງຮັບເງິນທີ່ຜູ້ຜະລິດຈຳກັດວ່າແອັບພລິເຄຊັນໃດສາມາດໃຊ້ງານໄດ້, ຊັບພະຍາກອນລະບົບໃດທີ່ແອັບພລິເຄຊັນເຫຼົ່ານັ້ນສາມາດເຂົ້າເຖິງໄດ້, ຫຼືທັງສອງຢ່າງ. ນີ້ແມ່ນການເລືອກອອກແບບໂດຍເຈດຕະນາ, ບໍ່ແມ່ນຂໍ້ບົກຜ່ອງ. ເຄື່ອງຮັບເງິນແບບດັ້ງເດີມ — ໜ່ວຍທີ່ຕິດຕັ້ງຢູ່ເທິງໂຕະທີ່ສ້າງຂຶ້ນຕົ້ນຕໍສຳລັບທຸລະກຳ EMV ແລະ PIN — ໄດ້ຮັບການຮັບຮອງມາດຕະຖານ PCI PTS POI ທີ່ປະຕິບັດຕໍ່ອຸປະກອນທັງໝົດເປັນສະພາບແວດລ້ອມການຈ່າຍເງິນທີ່ເຊື່ອຖືໄດ້ອັນດຽວ. ການເພີ່ມແອັບສະສົມຄະແນນໃຫ້ກັບສະພາບແວດລ້ອມນັ້ນໃນອະດີດໝາຍເຖິງການເພີ່ມເສັ້ນທາງລະຫັດທີ່ບໍ່ໄດ້ຮັບການຢືນຢັນຢູ່ຂ້າງຂໍ້ມູນຜູ້ຖືບັດ, ເຊິ່ງຍີ່ຫໍ້ການຈ່າຍເງິນ ແລະ ຜູ້ຮັບເງິນບໍ່ອະນຸຍາດ.
ສາມລັກສະນະຮາດແວທີ່ກຳນົດເຄື່ອງໝາຍການຄ້າທີ່ຖືກລັອກໄວ້:

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

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

2. ເປັນຫຍັງຊອບແວຄວາມພັກດີຈຶ່ງມີບັນຫາໃນສະຖາປັດຕະຍະກຳ POS ທີ່ປິດ

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

2.1 ກົດລະບຽບ Sandboxing PCI PTS ຈຳກັດການເຂົ້າເຖິງຂໍ້ມູນຂອງພາກສ່ວນທີສາມ

PCI PTS POI ເວີຊັນ 7.0, ຈັດພິມໂດຍສະພາມາດຕະຖານຄວາມປອດໄພ PCI, ປະຈຸບັນອະນຸຍາດໃຫ້ແອັບພລິເຄຊັນພາກສ່ວນທີສາມເຊັ່ນ: ແອັບຮ້ານແອັບສາມາດເຮັດວຽກຢູ່ໃນອຸປະກອນ POI ທີ່ໄດ້ຮັບການຮັບຮອງ. ແຕ່ມາດຕະຖານຮຽກຮ້ອງໃຫ້ແອັບພລິເຄຊັນເຫຼົ່ານັ້ນຕ້ອງ ແຍກອອກຈາກໜ້າທີ່ການຈ່າຍເງິນທີ່ລະອຽດອ່ອນຢ່າງປອດໄພ ແລະ ໄດ້ຮັບການຢືນຢັນຕົວຕົນໂດຍໃຊ້ການຄວບຄຸມແບບລະຫັດລັບຂໍ້ກຳນົດໃໝ່ກວ່າໃນລຸ້ນດຽວກັນບລັອກແອັບພລິເຄຊັນພາກສ່ວນທີສາມຈາກການອ່ານຂໍ້ມູນ PAN ຫຼື PIN ທີ່ເປັນຂໍ້ຄວາມຈະແຈ້ງເຖິງແມ່ນວ່າແອັບພລິເຄຊັນຈະຢູ່ໃນລາຍຊື່ຂາວທີ່ໄດ້ຮັບການອະນຸມັດ. ສຳລັບເຄື່ອງຈັກສະສົມຄະແນນ, ສິ່ງນີ້ມີຄວາມສຳຄັນໂດຍກົງ: ຮູບແບບການເຊື່ອມໂຍງໃດໆທີ່ສົມມຸດວ່າແອັບສະສົມຄະແນນສາມາດອ່ານຍອດທຸລະກຳທັງໝົດ, ໂທເຄັນບັດ, ຫຼືຕົວລະບຸລູກຄ້າໂດຍກົງຈາກຂະບວນການຊຳລະເງິນແມ່ນບໍ່ສອດຄ່ອງກັບອຸປະກອນທີ່ໄດ້ຮັບການຮັບຮອງ v7.0. ແອັບສະສົມຄະແນນຕ້ອງໄດ້ຮັບຂໍ້ມູນນັ້ນຜ່ານຊ່ອງທາງທີ່ໄດ້ຮັບການອະນຸມັດ ແລະ ໂດດດ່ຽວ - ແລະໃນເຄື່ອງຮັບເງິນຫຼາຍເຄື່ອງທີ່ຖືກລັອກ, ບໍ່ມີຊ່ອງທາງດັ່ງກ່າວຢູ່.

2.2 SDK ທີ່ເປັນເຈົ້າຂອງບລັອກການຕິດຕັ້ງແອັບຄວາມພັກດີແບບພື້ນເມືອງ

ແພລດຟອມສະມາຊິກຕ້ອງລົງທະບຽນລູກຄ້າ, ຊອກຫາຍອດຄະແນນ, ນຳໃຊ້ການແລກ, ແລະພິມ ຫຼື ສະແດງລາງວັນຢູ່ຈຸດຂາຍ. ການກະທຳແຕ່ລະຢ່າງເຫຼົ່ານັ້ນຕ້ອງການ SDK hook. ເຄື່ອງຮັບເງິນທີ່ມີລະບົບປະຕິບັດການທີ່ປິດ ແລະ ເປັນເຈົ້າຂອງໂດຍຜູ້ຂາຍໂດຍທົ່ວໄປແລ້ວຈະບໍ່ເປີດເຜີຍ hook ເຫຼົ່ານີ້ໃຫ້ກັບນັກພັດທະນາພາຍນອກ - ຜູ້ຂາຍສະມາຊິກຖືກປະໄວ້ໃຫ້ລວມເຂົ້າກັນຜ່ານ webhook ປະຕູການຈ່າຍເງິນຫຼັງຈາກທຸລະກຳໄດ້ປິດແລ້ວ, ເຊິ່ງຊ້າເກີນໄປທີ່ຈະໃຊ້ສ່ວນຫຼຸດໃນເວລາຈິງ ຫຼື ກະຕຸ້ນລາງວັນໃນຊ່ວງເວລາ. ນີ້ແມ່ນຮູບແບບຄວາມລົ້ມເຫຼວທີ່ພົບເລື້ອຍທີ່ສຸດທີ່ລາຍງານໂດຍຜູ້ຄ້າທີ່ຍ້າຍຈາກເຄື່ອງຮັບເງິນແບບເກົ່າໄປສູ່ການນຳໃຊ້ໂຄງການສະມາຊິກ pos: ການເຊື່ອມໂຍງດັ່ງກ່າວ "ເຮັດວຽກ" ເປັນການຊິ້ງຄ໌ຫຼັງທຸລະກຳ, ແຕ່ບໍ່ສາມາດເຮັດຫຍັງໄດ້ໃນຈຸດໂຕ້ຕອບເອງ.

2.3 ຮອບວຽນການອັບເດດເຟີມແວຣ໌ຢຸດການເປີດຕົວຄຸນສົມບັດຄວາມພັກດີ

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

3. ຄ່າໃຊ້ຈ່າຍທີ່ແທ້ຈິງຂອງການເຊື່ອມໂຍງຄວາມຈົງຮັກພັກດີທີ່ລົ້ມເຫຼວ

ຄ່າໃຊ້ຈ່າຍໂດຍກົງຂອງການເຊື່ອມໂຍງທີ່ລົ້ມເຫຼວແມ່ນການຢຸດສະງັກ ຫຼື ການເປີດຕົວທີ່ປີ້ນກັບກັນ, ແຕ່ຄ່າໃຊ້ຈ່າຍທີ່ໃຫຍ່ກວ່າແມ່ນຍຸດທະສາດ: ຜູ້ຂາຍຍ່ອຍຍັງສືບຕໍ່ຊື້ຊອບແວຄວາມພັກດີໃນອັດຕາທີ່ເພີ່ມຂຶ້ນໃນຂະນະທີ່ຄວາມເຂົ້າກັນໄດ້ຂອງຮາດແວຍັງຄົງເປັນຄວາມຄິດທີ່ຄິດພາຍຫຼັງ. ຕະຫຼາດການຄຸ້ມຄອງຄວາມພັກດີທົ່ວໂລກບັນລຸປະມານ 17.38 ຕື້ໂດລາໃນປີ 2026, ແລະຄາດວ່າຈະເຕີບໂຕໃນອັດຕາປະສົມຕໍ່ປີສູງກວ່າ 14% ຈົນຮອດປີ 2034. ທຸກໆໂດລາທີ່ໃຊ້ຈ່າຍໃນແພລດຟອມຄວາມພັກດີທີ່ບໍ່ສາມາດໃຊ້ງານໃນຮາດແວການຈ່າຍເງິນໄດ້ແມ່ນໜຶ່ງໂດລາທີ່ໃຊ້ຈ່າຍສອງເທື່ອ - ຄັ້ງໜຶ່ງໃນຊອບແວ, ອີກຄັ້ງໜຶ່ງໃນການອັບເດດຮາດແວທີ່ຄວນຈະເກີດຂຶ້ນກ່ອນ.
ຍັງມີຄ່າໃຊ້ຈ່າຍໃນການປະຕິບັດຕາມກົດລະບຽບເຊັ່ນກັນ. ໂຄງການສະສົມຄະແນນເກັບກຳ ແລະ ປະມວນຜົນຂໍ້ມູນລູກຄ້າສ່ວນຕົວ - ຊື່, ເບີໂທລະສັບ, ປະຫວັດການຊື້, ບາງຄັ້ງຂໍ້ມູນການລົງທະບຽນທາງຊີວະມິຕິສຳລັບໂຄງການແຕະເພື່ອລະບຸຕົວຕົນ. ພາຍໃຕ້ລະບຽບຂອງ EU 2016/679 (GDPR), ການປະມວນຜົນນັ້ນຮຽກຮ້ອງໃຫ້ມີພື້ນຖານທາງກົດໝາຍທີ່ຖືກບັນທຶກໄວ້ ແລະ ກະແສການຍິນຍອມທີ່ສອດຄ່ອງກັບລະບຽບການໃນເວລາລົງທະບຽນ. ການເຊື່ອມໂຍງຄວາມພັກດີທີ່ຖືກບັງຄັບໃຫ້ຜ່ານວິທີແກ້ໄຂທີ່ບໍ່ເປັນທາງການ - ເຄື່ອງ jailbroken, APK ທີ່ບໍ່ໄດ້ຮັບການສະໜັບສະໜຸນ sideloaded, ຂົວຂູດໜ້າຈໍ - ເຮັດໃຫ້ເອກະສານການປະຕິບັດຕາມລະບຽບການນັ້ນຍາກຂຶ້ນຫຼາຍໃນລະຫວ່າງການກວດສອບ, ເພາະວ່າເສັ້ນທາງຂໍ້ມູນເອງບໍ່ເຄີຍຖືກອອກແບບມາໃຫ້ຖືກກວດສອບ.

4. ສະຖາປັດຕະຍະກຳ POS ທີ່ເປີດກວ້າງ ແລະ ພ້ອມທີ່ຈະໃຊ້ຄວາມພັກດີມີລັກສະນະແນວໃດ

ສະຖາປັດຕະຍະກຳທີ່ຮອງຮັບຄວາມພັກດີມີຄຸນລັກສະນະສາມຢ່າງຄື: SDK ແບບເປີດ, ການແຈກຢາຍຊອບແວລະດັບຮ້ານແອັບ, ແລະ ຄຸນສົມບັດການລະບຸຕົວຕົນຂອງຮາດແວທີ່ເກີນກວ່າການຮູດບັດ.

4.1 ເປີດ SDK ແລະການເຂົ້າເຖິງ API

ເຄື່ອງ POS ທີ່ອີງໃສ່ Android ທີ່ມີ SDK ທີ່ເຜີຍແຜ່ແລ້ວຊ່ວຍໃຫ້ຜູ້ຂາຍທີ່ມີສະມາຊິກສາມາດສ້າງໂດຍກົງກັບ API ທີ່ໄດ້ບັນທຶກໄວ້ສຳລັບເຄື່ອງພິມ, ເຄື່ອງສະແກນ, ຈໍສະແດງຜົນທີ່ລູກຄ້າປະເຊີນ, ແລະ kernel ການຈ່າຍເງິນ - ໂດຍບໍ່ຕ້ອງລໍຖ້າຜູ້ຜະລິດຮາດແວສຳລັບແຕ່ລະຄຸນສົມບັດໃໝ່. ນີ້ແມ່ນຮູບແບບແພລດຟອມເປີດດຽວກັນທີ່ Terminal API ຂອງ Square ໄດ້ນຳສະເໜີສຳລັບຮາດແວຂອງມັນເອງ, ແລະປະຈຸບັນມັນເປັນການປະຕິບັດມາດຕະຖານໃນທົ່ວຜູ້ຜະລິດ POS Android ສ່ວນໃຫຍ່ທີ່ຂາຍໃນສະພາບແວດລ້ອມການຂາຍຍ່ອຍຫຼາຍຜູ້ຂາຍແທນທີ່ຈະເປັນຕູ້ບໍລິການແອັບດຽວທີ່ປິດ. ຮ້ານຄ້າຈັດຊື້ຮາດແວໂດຍກົງຈາກຖານການສະໜອງ - ລວມທັງ ພູມສັນຖານ B2B ຂອງຜູ້ຜະລິດເຄື່ອງ POS ຂອງຈີນ — ຄວນປະຕິບັດຕໍ່ຄວາມເປີດກວ້າງຂອງ SDK ຄືກັບຕົວກອງການຈັດຊື້, ບໍ່ແມ່ນຄວາມຄິດທີ່ຕ້ອງໄດ້ປຶກສາຫາລືພາຍຫຼັງທີ່ໄດ້ເຊັນສັນຍາແລ້ວ.

4.2 ການຮັບຮອງ GMS ແລະ ຄວາມເຂົ້າກັນໄດ້ຂອງ App Store

ການຮັບຮອງ Google Mobile Services (GMS) ອະນຸຍາດໃຫ້ເຄື່ອງໂທລະສັບສາມາດໃຊ້ງານແພັກເກດແອັບ Android ມາດຕະຖານຜ່ານ Play Store ຫຼື ຮ້ານແອັບທີ່ມີການຈັດການທຽບເທົ່າໄດ້, ແທນທີ່ຈະຈຳກັດອຸປະກອນໃຫ້ໃຊ້ໄດ້ກັບຊອບແວທີ່ມາພ້ອມກັບເຟີມແວ. ເຄື່ອງໂທລະສັບທີ່ໄດ້ຮັບການຮັບຮອງຈາກ GMS ສາມາດຕິດຕັ້ງແອັບສະສົມຄະແນນໄດ້ຄືກັນກັບທີ່ໂທລະສັບຕິດຕັ້ງແອັບອື່ນໆ: ເປັນອິດສະຫຼະ, ຕາມຕາຕະລາງການປ່ອຍຂອງຜູ້ຂາຍເອງ, ໂດຍບໍ່ມີວົງຈອນການຮັບຮອງຄືນໃໝ່ໃນລະດັບເຟີມແວ.

4.3 ການລົງທະບຽນຄວາມພັກດີທາງຊີວະມິຕິ

ຊຸດເຄື່ອງຮັບເງິນຂະໜາດນ້ອຍກວ່າແຕ່ມີການເຕີບໂຕຢ່າງຕໍ່ເນື່ອງໄດ້ຂະຫຍາຍການລະບຸຕົວຕົນສະມາຊິກຜ່ານບັດ ແລະ ເບີໂທລະສັບໄປສູ່ການລົງທະບຽນຊີວະມິຕິ. ການຮັບຮູ້ເສັ້ນເລືອດຝ່າມືແມ່ນຕົວຢ່າງໜຶ່ງທີ່ມີຢູ່ແລ້ວໃນການນຳໃຊ້ທາງການຄ້າ - ZCS ແມ່ນໜຶ່ງໃນບັນດາຜູ້ຜະລິດ Android POS ທີ່ປະຈຸບັນສົ່ງເຄື່ອງຮັບເງິນທີ່ເປີດໃຊ້ງານດ້ວຍເສັ້ນເລືອດຝອຍດ້ວຍ SDK ເປີດ, ຊ່ວຍໃຫ້ແພລດຟອມສະມາຊິກສາມາດລົງທະບຽນຮູບແບບເສັ້ນເລືອດຝອຍຂອງລູກຄ້າເປັນຕົວລະບຸທາງເລືອກໃນເວລາຊຳລະເງິນແທນທີ່ຈະຕ້ອງການການຄົ້ນຫາບັດ, ແອັບ ຫຼື ເບີໂທລະສັບ. ຄຸນສົມບັດການລະບຸຕົວຕົນລະດັບຮາດແວປະເພດນີ້ສາມາດໃຊ້ໄດ້ໂດຍແພລດຟອມສະມາຊິກເທົ່ານັ້ນເມື່ອ SDK ຂອງເຄື່ອງຮັບເງິນເປີດເຜີຍມັນເປັນ API ທີ່ໄດ້ບັນທຶກໄວ້ - ເຊິ່ງເປັນຄວາມຕ້ອງການດ້ານສະຖາປັດຕະຍະກຳເປີດທີ່ໄດ້ອະທິບາຍຂ້າງເທິງ, ບໍ່ແມ່ນຄຸນສົມບັດທີ່ເປັນເອກະລັກສະເພາະຂອງຍີ່ຫໍ້ໃດໜຶ່ງ.

5. ລາຍການກວດສອບການປະເມີນຜົນ: ເຄື່ອງ POS ຂອງທ່ານພ້ອມແລ້ວບໍສຳລັບຄວາມພັກດີ?

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

• ●ສະມາຊິກ ເຄື່ອງນີ້ມາພ້ອມກັບ SDK ທີ່ເຜີຍແຜ່ ແລະ ບັນທຶກໄວ້ແລ້ວ — ບໍ່ພຽງແຕ່ເປັນ webhook ປະຕູການຈ່າຍເງິນເທົ່ານັ້ນ.
• ●ສະມາຊິກ ເຄື່ອງນີ້ໄດ້ຮັບການຮັບຮອງຈາກ GMS ແລະ ຮອງຮັບການຕິດຕັ້ງ ແລະ ການອັບເດດແອັບທີ່ເປັນເອກະລາດ.
• ●ສະມາຊິກ ຜູ້ຜະລິດສາມາດຢືນຢັນການປະຕິບັດຕາມ PCI PTS POI ສຳລັບການ sandboxing ແອັບພລິເຄຊັນພາກສ່ວນທີສາມໃດໆ, ເຊິ່ງກົງກັບຄວາມຕ້ອງການການແຍກໃນ PTS POI ລຸ້ນປັດຈຸບັນ.
• ●ສະມາຊິກ ຜູ້ຂາຍສະສົມຄະແນນສາມາດຕັ້ງຊື່ອ້າງອີງຮ້ານຄ້າສົດທີ່ໃຊ້ຮູບແບບເຄື່ອງໝາຍການຄ້າທີ່ແນ່ນອນ, ບໍ່ພຽງແຕ່ຍີ່ຫໍ້ເຄື່ອງໝາຍການຄ້າເທົ່ານັ້ນ.
• ●ສະມາຊິກ ຈັງຫວະການປ່ອຍເຟີມແວຂອງຜູ້ຂາຍຮາດແວໄດ້ຖືກບັນທຶກໄວ້ ແລະ ບໍ່ໄດ້ບລັອກການອັບເດດລະດັບແອັບທີ່ເປັນອິດສະຫຼະຈາກຜູ້ຂາຍຜະລິດຕະພັນສະສົມຄະແນນ.

ເງື່ອນໄຂການຄັດເລືອກເຄື່ອງຮັບສັນຍານ — ຄວາມເປີດກວ້າງຂອງລະບົບປະຕິບັດການ, ຂອບເຂດການຮັບຮອງ, ຄວາມເລິກຂອງ SDK — ແມ່ນໄດ້ກວມເອົາລາຍລະອຽດເພີ່ມເຕີມໃນ ຂອບການເຮັດວຽກທັງໝົດຂອງພວກເຮົາສຳລັບການເລືອກແພລດຟອມ Android POS, ເຊິ່ງຍ່າງຜ່ານເຫດຜົນການປະເມີນຜົນດຽວກັນນອກເໜືອໄປຈາກກໍລະນີການນຳໃຊ້ຄວາມພັກດີພຽງຢ່າງດຽວ.

6. ຄຳ ຖາມທີ່ພົບເລື້ອຍ

ຄຳຖາມທີ 1: ເຄື່ອງ POS ໃດກໍ່ສາມາດດໍາເນີນໂຄງການສະສົມຄະແນນໄດ້ບໍ?

ບໍ່. ເຄື່ອງຄອມພິວເຕີຕ້ອງການ SDK ແບບເປີດ, ການແຈກຢາຍຊອບແວລະດັບຮ້ານແອັບ, ແລະ sandboxing ທີ່ສອດຄ່ອງກັບ PCI PTS ສຳລັບແອັບພລິເຄຊັນພາກສ່ວນທີສາມ. ເຄື່ອງຄອມພິວເຕີແອັບພລິເຄຊັນດຽວທີ່ປິດຈະຈຳກັດ ຫຼື ບລັອກຊອບແວສະມາຊິກທັງໝົດ, ໂດຍບໍ່ຄຳນຶງເຖິງສິ່ງທີ່ແພລດຟອມຂອງຜູ້ຂາຍສະມາຊິກສະໜັບສະໜູນຢູ່ໃນເຈ້ຍ.
ຄຳຖາມທີ 2: ສິ່ງໃດທີ່ເຮັດໃຫ້ເຄື່ອງ POS "ຖືກລັອກໄວ້"?

ເຄື່ອງຄອມພິວເຕີທີ່ຖືກລັອກໄວ້ຈະຈຳກັດແອັບພລິເຄຊັນທີ່ສາມາດຕິດຕັ້ງໄດ້, ບໍ່ເປີດເຜີຍ SDK ສາທາລະນະ, ແລະ ແລ່ນເຟີມແວທີ່ສ້າງຂຶ້ນໂດຍອີງໃສ່ແອັບພລິເຄຊັນການຈ່າຍເງິນດຽວ. ລັກສະນະເຫຼົ່ານີ້ຫຼຸດຜ່ອນຂອບເຂດການກວດສອບ PCI ແຕ່ຍັງບລັອກແອັບຄວາມພັກດີ, ການຊິ້ງຄ໌ CRM, ແລະ ການເຊື່ອມໂຍງພາກສ່ວນທີສາມອື່ນໆໂດຍການອອກແບບ.
ຄຳຖາມທີ 3: ການປະຕິບັດຕາມ PCI ປ້ອງກັນບໍ່ໃຫ້ແອັບສະສົມຄະແນນເຮັດວຽກຢູ່ໃນຮາດແວ POS ບໍ?

ບໍ່ແມ່ນໂດຍຄ່າເລີ່ມຕົ້ນ. PCI PTS POI v7.0 ອະນຸຍາດໃຫ້ແອັບພລິເຄຊັນພາກສ່ວນທີສາມ, ລວມທັງແອັບສະມາຊິກ, ໂດຍມີເງື່ອນໄຂວ່າພວກມັນຖືກ sandboxed ອອກຈາກບັດຊຳລະເງິນ cleartext ແລະຂໍ້ມູນ PIN. ການປະຕິບັດຕາມຮຽກຮ້ອງໃຫ້ມີການແຍກ, ບໍ່ແມ່ນການຍົກເວັ້ນ, ແລະສະຖາປັດຕະຍະກຳຂອງເຄື່ອງຮັບສັນຍານຈະກຳນົດວ່າການແຍກນັ້ນເປັນໄປໄດ້ທາງດ້ານເຕັກນິກຫຼືບໍ່.
ຄຳຖາມທີ 4: ຄວາມແຕກຕ່າງລະຫວ່າງການຊິ້ງຂໍ້ມູນຄວາມພັກດີຫຼັງການເຮັດທຸລະກຳ ແລະ ການເຊື່ອມໂຍງແບບເວລາຈິງແມ່ນຫຍັງ?

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

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