ຈາກການຮັບໂອນເງິນເອງ ສູ່ Payment Gateway: ບົດຮຽນຈາກນັກສຶກສາທີ່ຢາກສ້າງລະບົບຂາຍປີ້ລົດ
ຖ້າຍ້ອນກັບໄປໃນຕອນທີ່ຂ້ອຍຍັງເປັນນັກສຶກສາ ມີຫນຶ່ງໂປເຈັກທີ່ຂ້ອຍຢາກເຮັດຫຼາຍ ນັ້ນກໍຄື **ລະບົບຂາຍປີ້ລົດໂດຍສານ.
ແນວຄິດໃນຕອນນັ້ນກໍບໍ່ໄດ້ຊັບຊ້ອນຫຍັງ. ຢາກໃຫ້ລູກຄ້າເຂົ້າລະບົບ, ເລືອກເສັ້ນທາງ, ເລືອກຮອບລົດ, ເລືອກບ່ອນນັ່ງ ແລະຈ່າຍເງິນຜ່ານລະບົບ.
ບັນຫາທີ່ໃຫຍ່ກວ່າທີ່ຄິດກັບກາຍເປັນວ່າ...
“ແລ້ວເຮົາຈະຮັບເງິນຈາກລູກຄ້າແນວໃດ?”
ໃນຕອນນັ້ນ ຂ້ອຍແກ້ບັນຫາແນວໃດ?
ຕອນນັ້ນຂ້ອຍຍັງຮຽນຢູ່ ແລະບໍ່ຮູ້ເລື່ອງ **Payment Gateway, API ຫຼືການເຊື່ອມຕໍ່ລະບົບກັບທະນາຄານ ຫຼາຍປານໃດ.
ດັ່ງນັ້ນ ວິທີທີ່ຄິດອອກໃນຕອນນັ້ນກໍຄື:
ເອົາ QR Code ຂອງບັນຊີສ່ວນຕົວຂອງຂ້ອຍມາສະແດງໃນລະບົບ.
ລູກຄ້າເຂົ້າມາຊື້ປີ້ → ເຫັນ QR Code → ໂອນເງິນ → ແຄັບຫນ້າຈໍຫຼັກຖານການໂອນ → ສົ່ງເຂົ້າ Chat → ແລ້ວຂ້ອຍຈຶ່ງເຂົ້າໄປກວດ ແລະອັບເດດສະຖານະການຈ່າຍເງິນໃຫ້.
ເວລານັ້ນມັນອາດຈະເບິ່ງຄືວ່າ “ໃຊ້ໄດ້”.
ແຕ່ພໍລອງຄິດໃນມຸມຂອງລະບົບທີ່ຈະມີຜູ້ໃຊ້ຈຳນວນຫຼາຍ ກໍຈະເຫັນບັນຫາທັນທີ.
- ຕ້ອງກວດການໂອນເງິນເອງ
- ຕ້ອງລໍຖ້າ Screenshot
- ຕ້ອງອັບເດດສະຖານະເອງ
- ຖ້າມີຄົນຊື້ຫຼາຍ ກໍອາດສັບສົນໄດ້
- ລະບົບບໍ່ສາມາດຮູ້ໄດ້ແບບ Real-time ວ່າເງິນເຂົ້າແລ້ວຫຼືຍັງ
ແລະຄຳຖາມທີ່ຄ້າງຄາຢູ່ຕອນນັ້ນກໍຄື...
“ຖ້າຢາກເຊື່ອມກັບທະນາຄານແບບຈິງໆ ເຮົາຕ້ອງເຮັດແນວໃດ?”
ຈຸດທີ່ຂ້ອຍບໍ່ຮູ້ໃນຕອນນັ້ນ
ຕອນທີ່ຍັງຮຽນ ການເຫັນຄຳວ່າ Payment API ຫຼື Payment Gateway ມັນເບິ່ງຄືເລື່ອງໃຫຍ່ຫຼາຍ.
ຂ້ອຍເຄີຍຄິດວ່າຖ້າຈະເຮັດ Payment ໃນລະບົບ ອາດຈະຕ້ອງໄປຕິດຕໍ່ທະນາຄານໂດຍກົງ, ຂໍ API, ຂຽນລະບົບເອງຫຼາຍຢ່າງ ແລະມີຂັ້ນຕອນທີ່ຍຸ່ງຍາກ.
ແຕ່ເມື່ອໄດ້ມາຮູ້ຈັກ Payment Gateway ແລະໂຊລູຊັນດ້ານ Payment ທີ່ມີຢູ່ ມຸມມອງກໍປ່ຽນໄປ.
ເພາະບາງສ່ວນທີ່ເຄີຍຄິດວ່າ “ຕ້ອງເຮັດເອງ” ມີລະບົບທີ່ຊ່ວຍຈັດການໃຫ້ແລ້ວ.
ແລ້ວ “ພາຈ່າຍ” ເຂົ້າມາຊ່ວຍແນວໃດ?
ພໍ ພາຈ່າຍ ເປີດໂຕ ສຳລັບຂ້ອຍມັນໃຫ້ຄວາມຮູ້ສຶກຄື:
“ອ້າວ! ສິ່ງທີ່ເຮົາຫາທາງເຮັດຢູ່ ມັນມີຕົວຊ່ວຍແລ້ວ.”
ເພາະແທນທີ່ເຮົາຈະຕ້ອງຄິດລະບົບ Payment ໃໝ່ທັງໝົດ ພວກເຮົາສາມາດໃຊ້ Payment Gateway ເຂົ້າມາເປັນຕົວກາງລະຫວ່າງລະບົບຂອງເຮົາກັບລະບົບການຊຳລະເງິນ.
ແນວຄິດກໍຈະປະມານນີ້:
ລູກຄ້າ → ລະບົບຂາຍປີ້ → ພາຈ່າຍ / Payment Gateway → ການຊຳລະເງິນ → ລະບົບຂາຍປີ້
ເມື່ອການຈ່າຍເງິນສຳເລັດ ລະບົບກໍສາມາດນຳສະຖານະການຈ່າຍເງິນໄປໃຊ້ຕໍ່ໃນ Workflow ຂອງລະບົບໄດ້.
ສຳລັບລະບົບຂາຍປີ້ ນັ້ນໝາຍຄວາມວ່າ:
ເລືອກປີ້ → ກົດຈ່າຍ → ຊຳລະເງິນ → ລະບົບກວດສະຖານະ → ຢືນຢັນການຈອງ
ບໍ່ຈຳເປັນຕ້ອງ:
ໂອນ → ແຄັບຫນ້າຈໍ → ສົ່ງ Chat → ລໍຖ້າ Admin ກວດ → Admin ອັບເດດ
ຄວາມຕ່າງຈຸດນີ້ແຫຼະ ທີ່ເຮັດໃຫ້ Workflow ຂອງ Application ສັ້ນ ແລະໄວຂຶ້ນຫຼາຍ.
ສິ່ງທີ່ Payment Gateway ຊ່ວຍໃນໂປເຈັກ
ສຳລັບ Developer ຫຼືນັກສຶກສາທີ່ກຳລັງສ້າງ Startup Project ສິ່ງສຳຄັນບໍ່ແມ່ນແຕ່ “ຮັບເງິນໄດ້”.
ແຕ່ມັນຄືການຫຼຸດວຽກທີ່ບໍ່ຈຳເປັນອອກຈາກໂປເຈັກ.
ຕົວຢ່າງ:
- ລົດລົງທະບຽນຈອງປີ້ງ່າຍຂຶ້ນ
- ການຈ່າຍເງິນເປັນ Workflow ດຽວກັບ Application
- ຫຼຸດການກວດ Screenshot ດ້ວຍມື
- ຫຼຸດການອັບເດດສະຖານະແບບ Manual
- ເຮັດໃຫ້ User Experience ດີຂຶ້ນ
- Developer ສາມາດໂຟກັສກັບ Core Feature ຂອງໂປເຈັກໄດ້ຫຼາຍຂຶ້ນ
ສຳລັບຂ້ອຍ ນີ້ຄືຈຸດສຳຄັນຫຼາຍ.
ເພາະເວລາເຮົາເປັນນັກສຶກສາ ຫຼືຄົນທີ່ກຳລັງເລີ່ມໂປເຈັກໃໝ່ ຊັບພະຍາກອນທັງຄົນ, ເວລາ ແລະຄວາມຮູ້ ມີຈຳກັດ.
ຖ້າມີຕົວຊ່ວຍທີ່ສາມາດຫຼຸດພາລະສ່ວນນີ້ໄດ້ ມັນກໍຊ່ວຍໃຫ້ເຮົາໄປໂຟກັສກັບສິ່ງທີ່ໂປເຈັກຂອງເຮົາຕ້ອງການແທ້ໆ.
ຈາກໂປເຈັກນັກສຶກສາ ສູ່ແນວຄິດຂອງ Startup
ປະສົບການນີ້ສອນຂ້ອຍວ່າ ໃນການສ້າງ Application ໜຶ່ງອັນ ບາງຄັ້ງສິ່ງທີ່ຍາກບໍ່ແມ່ນການຂຽນ Code.
ແຕ່ແມ່ນການຮູ້ວ່າ:
“ສ່ວນໃດຄວນເຮັດເອງ ແລະສ່ວນໃດຄວນໃຫ້ຜູ້ຊ່ຽວຊານຫຼື Platform ທີ່ມີຢູ່ແລ້ວຊ່ວຍ.”
Payment ເປັນຕົວຢ່າງທີ່ດີຫຼາຍ.
ເຮົາສາມາດສ້າງ UI ຈ່າຍເງິນເອງ, ສ້າງ Order System ເອງ, ສ້າງ Booking System ເອງ.
ແຕ່ການຈັດການ Payment ບໍ່ຄວນຄິດແຕ່ວ່າ:
“ຈະເຮັດໃຫ້ເງິນໂອນເຂົ້າໄດ້ແນວໃດ?”
ເຮົາຕ້ອງຄິດເຖິງ Security, Transaction Status, ການຢືນຢັນການຈ່າຍ, ການຈັດການຄວາມຜິດພາດ, ແລະອື່ນໆ.
ນີ້ແມ່ນເຫດຜົນທີ່ Payment Gateway ຈຶ່ງມີບົດບາດສຳຄັນ.
ຖ້າຂ້ອຍກັບໄປເລີ່ມໂປເຈັກນັ້ນອີກຄັ້ງ...
ຖ້າກັບໄປເປັນນັກສຶກສາຄົນເກົ່າອີກຄັ້ງ ແລະຈະເຮັດລະບົບຂາຍປີ້ລົດໂດຍສານອີກຮອບ ຂ້ອຍຄົງບໍ່ໃຊ້ວິທີ:
QR ບັນຊີສ່ວນຕົວ → ໂອນ → Screenshot → Chat → ລໍຖ້າ Admin ອີກແລ້ວ.
ແຕ່ຈະເລີ່ມຈາກການຫາ Payment Solution ທີ່ເໝາະກັບໂປເຈັກ ແລະສຶກສາວ່າມັນສາມາດ Integrate ກັບ Application ຂອງເຮົາໄດ້ແນວໃດ.
ແລະຖ້າມີຕົວເລືອກເຊັ່ນ ພາຈ່າຍ ທີ່ຊ່ວຍໃຫ້ການ Integrate Payment ງ່າຍຂຶ້ນ ສຳລັບຂ້ອຍມັນກໍເປັນຕົວເລືອກທີ່ນ່າສົນໃຈ.
ສຳລັບຄົນທີ່ກຳລັງເລີ່ມ Project ຂອງຕົນເອງ
ຖ້າເຈົ້າກຳລັງສ້າງ E-commerce, Booking System, Ticketing System, Delivery App, Marketplace ຫຼື Application ທີ່ຕ້ອງມີການຊຳລະເງິນ ຢ່າລໍຖ້າໃຫ້ໂປເຈັກເຮົາໃຫຍ່ກ່ອນແລ້ວຈຶ່ງຄິດເລື່ອງ Payment.
ເພາະ Payment ແມ່ນສ່ວນໜຶ່ງຂອງ User Experience ແລະ Business Workflow ຕັ້ງແຕ່ຕົ້ນ.
ສຳລັບຂ້ອຍ ພາຈ່າຍ ບໍ່ແມ່ນພຽງແຕ່ Payment Gateway ອີກຕົວໜຶ່ງ.
ແຕ່ມັນເປັນຄຳຕອບຂອງບັນຫາທີ່ຂ້ອຍເຄີຍເຈີຕອນເປັນນັກສຶກສາ:
“ຖ້າຂ້ອຍຢາກໃຫ້ Application ຂອງຂ້ອຍຮັບຊຳລະເງິນໄດ້ ແຕ່ຂ້ອຍບໍ່ຮູ້ຈະເລີ່ມຈາກໃສ?”
ມື້ນີ້ ຄຳຕອບນັ້ນບໍ່ຈຳເປັນຕ້ອງແມ່ນການເອົາ QR ບັນຊີສ່ວນຕົວມາວາງໃນໜ້າຈ່າຍອີກຕໍ່ໄປ.
ການມີ Payment Gateway ທີ່ຊ່ວຍເຊື່ອມຕໍ່ Payment ໃຫ້ງ່າຍຂຶ້ນ ອາດຊ່ວຍໃຫ້ຈາກໂປເຈັກນ້ອຍໆຂອງນັກສຶກສາ ສາມາດພັດທະນາໄປສູ່ Application ທີ່ພ້ອມໃຊ້ງານຈິງໄດ້ງ່າຍຂຶ້ນ.
"ບາງຄັ້ງການເລີ່ມ Startup ບໍ່ໄດ້ຍາກເພາະເຮົາຂຽນ Code ບໍ່ເປັນ.
ແຕ່ຍາກເພາະເຮົາບໍ່ຮູ້ວ່າ ມີຕົວຊ່ວຍຫຍັງຢູ່ແລ້ວ."
ແລະສຳລັບຂ້ອຍ ພາຈ່າຍແມ່ນໜຶ່ງໃນຕົວຊ່ວຍນັ້ນ.