การสร้างแอป Tap to Pay ของคุณเองยากแค่ไหน? (เราลองแล้ว)

ยากกว่าที่โบรชัวร์ SDK โฆษณาไว้ และความยากส่วนใหญ่ไม่ใช่เรื่องของโค้ด เราได้เปิดตัว Tap to Pay ในแอป Final POS ดังนั้นคำตอบนี้จึงมาจากประสบการณ์การทำงานจริง ไม่ใช่จากการอ่านเอกสารคู่มือ หากคุณต้องการสร้างแอป Tap to Pay ของคุณเอง โปรดเตรียมพร้อมสำหรับโครงการซอฟต์แวร์ระยะสั้นที่ถูกห่อหุ้มไว้ในโครงการขออนุญาตที่ยาวนานกว่ามาก: การเป็นพันธมิตรกับผู้ให้บริการชำระเงิน สิทธิ์การใช้งานที่ต้องขอด้วยตนเองจาก Apple หรือการประเมินในห้องปฏิบัติการบน Android และการตรวจสอบแอป ทั้งหมดนี้ต้องทำก่อนการแตะเพื่อจ่ายจริงครั้งแรกของคุณ

ข้อควรระวังเล็กน้อย: กฎเกณฑ์ของแพลตฟอร์มและอุตสาหกรรมบัตรมีการเปลี่ยนแปลงบ่อยครั้ง ข้อมูลทั้งหมดด้านล่างนี้ถูกต้อง ณ เวลาที่เผยแพร่ ดังนั้นโปรดถือว่ารายละเอียดเหล่านี้เป็นข้อมูล ณ ช่วงเวลานั้น

แอป Tap to Pay ทำหน้าที่อะไรกันแน่?

Tap to Pay จะเปลี่ยนโทรศัพท์ให้กลายเป็นเครื่องรูดบัตร โดยไม่ต้องใช้เครื่องรูดบัตรหรืออุปกรณ์ต่อพ่วงใดๆ ลูกค้าเพียงแค่แตะบัตรแบบคอนแทคเลสหรือกระเป๋าเงินบนโทรศัพท์ เช่น Apple Pay หรือ Google Pay ลงบนอุปกรณ์ของผู้ค้าโดยตรง และการชำระเงินจะทำงานผ่านชิป NFC ของโทรศัพท์ (วิทยุระยะสั้นที่ใช้สำหรับการชำระเงินแบบไร้สัมผัส) หากคำศัพท์ต่างๆ ดูสับสน เราได้แยกแยะ ความแตกต่างระหว่างการชำระเงินแบบแตะผ่านมือถือและการแตะเพื่อจ่ายบนมือถือ (Tap to Pay on mobile) ไว้ให้แล้ว

นี่คือกับดัก การอ่านแท็ก NFC นั้นเป็นโครงการสำหรับวันหยุดสุดสัปดาห์อย่างแท้จริงที่เหล่านักประดิษฐ์ทำกันอยู่ตลอดเวลา แต่การอ่านบัตรชำระเงินเป็นคนละเรื่องกัน บัตรต่างๆ จะสื่อสารด้วยโปรโตคอล EMV (โปรโตคอลชิปของอุตสาหกรรมบัตร) ข้อมูลบัตรต้องได้รับการเข้ารหัสแบบต้นทางถึงปลายทาง (End-to-end) และซอฟต์แวร์ที่ได้รับการรับรองเท่านั้นที่ได้รับอนุญาตให้สัมผัสข้อมูลนี้ได้

ทำไมคุณถึงไม่สามารถอ่านข้อมูลบัตรด้วยตัวเองได้?

เพราะทุกเลเยอร์ของระบบต้องการการอนุญาตก่อนที่โค้ดของคุณจะได้รับอนุญาตให้ทำงานในที่สาธารณะ

• Apple ไม่อนุญาตให้แอปเข้าถึง NFC สำหรับการชำระเงินโดยตรง คุณต้องใช้เฟรมเวิร์ก ProximityReader ของ Apple ซึ่งอยู่ภายใต้ สิทธิ์การใช้งาน Tap to Pay บน iPhone (สิทธิ์พิเศษที่ Apple มอบให้เป็นรายกรณี) นอกจากนี้ Apple ยังกำหนดให้คุณต้องรวมระบบเข้ากับผู้ให้บริการชำระเงิน หรือ PSP (บริษัทที่ทำหน้าที่โอนเงินจริง) ที่ได้รับการรองรับ โดย PSP จะเป็นผู้จัดหาการกำหนดค่าเครื่องอ่านที่ได้รับการรับรองซึ่งโหลดลงบนอุปกรณ์ของผู้ค้าและเป็นผู้แบกรับภาระในการรับรองมาตรฐาน

• Android ให้สิทธิ์นักพัฒนาในการเข้าถึง NFC ที่เปิดกว้างกว่า แต่แอปรับชำระเงินยังคงต้องได้รับการประเมินโดยห้องปฏิบัติการอิสระที่ได้รับการยอมรับจาก PCI ตามมาตรฐาน PCI MPoC (กฎความปลอดภัยของอุตสาหกรรมบัตรสำหรับโทรศัพท์ที่ทำหน้าที่เป็นเครื่องรับชำระเงิน)

• ภายใต้ทั้งสองแพลตฟอร์ม คุณต้องมีความสัมพันธ์กับผู้รับบัตร (Acquiring relationship): ผู้ให้บริการชำระเงินที่ยินดีจะชำระเงินให้กับผู้ค้าของคุณ พร้อมทั้งปฏิบัติตามกฎของเครือข่ายบัตร

ไม่มีสิ่งใดในนี้ที่สามารถแก้ไขได้ด้วยการเขียนโค้ดที่ดีขึ้น มันเป็นเรื่องของเอกสาร สัญญา และคิวการตรวจสอบ

ขั้นตอนการอนุมัติบน iPhone มีลักษณะอย่างไร?

ตามข้อกำหนดที่เผยแพร่ของ Apple ขั้นตอนจะเป็นดังนี้: ต้องมีบัญชี Apple Developer ในระดับองค์กร (ผู้ถือบัญชีต้องเป็นผู้ยื่นคำขอด้วยตนเอง) เป็นพันธมิตรกับ PSP ที่ได้รับการรองรับในภูมิภาคของคุณ ขอสิทธิ์การใช้งาน รวมระบบเข้ากับ ProximityReader API หรือ SDK ของ PSP ปฏิบัติตามแนวทางการออกแบบของ Apple สำหรับหน้าจอชำระเงิน และส่งแอปเพื่อรับการตรวจสอบ เอกสารของ Apple ยังระบุด้วยว่าฟีเจอร์นี้ใช้งานได้เฉพาะใน ประเทศและภูมิภาคที่รองรับ เท่านั้น ดังนั้นความพร้อมใช้งานจึงถูกกำหนดไว้สำหรับคุณในแต่ละตลาด

ลองอ่านรายการนั้นอีกครั้งในฐานะผู้ก่อตั้งหรือผู้ค้า ไม่ใช่ในฐานะนักพัฒนา ไม่มีขั้นตอนใดเลยที่เป็นการ "เขียนฟีเจอร์" ตัวฟีเจอร์นั้นเป็นส่วนที่ง่ายที่สุด แต่สิทธิ์การใช้งานต่างหากที่เป็นปราการด่านสำคัญ

งานจะไปอยู่ที่ตรงไหนหลังจากที่การแตะใช้งานได้แล้ว?

การแตะที่ได้รับการอนุมัติจะช่วยให้คุณรับชำระเงินได้ แต่ไม่ใช่ระบบขายหน้าร้าน ทันทีที่เงินเคลื่อนไหว ทุกสิ่งรอบๆ การแตะนั้นต้องถูกต้องแม่นยำ: ตะกร้าสินค้าที่ใช้ชำระเงิน ภาษีบนใบเสร็จ ขั้นตอนการคืนเงิน และรายงานที่กระทบยอดได้ (ทุกบาททุกสตางค์ต้องตรงกับการขายในแต่ละวัน) เราพบช่องว่างเดียวกันนี้เมื่อเราพิจารณาว่า คุณสามารถสร้าง POS ด้วย Lovable หรือ Replit ได้หรือไม่ การสร้างอินเทอร์เฟซนั้นรวดเร็ว แต่เลเยอร์การค้าที่อยู่เบื้องล่างต่างหากคือสิ่งที่ต้องใช้เวลาอย่างมาก

นอกจากนี้ Tap to Pay ยังมีข้อจำกัดในการทำงานเฉพาะตัว ในการใช้งานของเรา การขายต้องทำบนอุปกรณ์เครื่องเดียวกับที่ใช้แตะเพื่อจ่าย และทำงานได้เฉพาะในแอปเนทีฟเท่านั้น ไม่สามารถทำงานในเบราว์เซอร์ได้ ข้อจำกัดเช่นนี้ไม่เคยปรากฏในโบรชัวร์ใดๆ คุณต้องค้นพบมัน ออกแบบระบบเพื่อหลีกเลี่ยงข้อจำกัดนั้น แล้วจึงเขียนบทความช่วยเหลือ และเมื่อโทรศัพท์บนเคาน์เตอร์เริ่มไม่เพียงพอ คุณก็ต้องเข้าสู่ การตัดสินใจเลือกฮาร์ดแวร์จริง อยู่ดี

สรุปแล้ว การสร้างแอป Tap to Pay ของคุณเองยากแค่ไหน?

ยากในรูปแบบเฉพาะตัว: การเขียนโค้ดเป็นเพียงส่วนที่เล็กที่สุด ในขณะที่การเป็นพันธมิตรกับผู้ให้บริการชำระเงิน สิทธิ์การใช้งานจาก Apple การรับรองมาตรฐานในห้องปฏิบัติการบน Android และการตรวจสอบแอปคือส่วนสำคัญ และไม่มีสิ่งใดในนี้ที่ตอบสนองต่อความพยายามในการเขียนโค้ด สำหรับเราแล้วมันคุ้มค่า เพราะแพลตฟอร์ม POS จะกระจายต้นทุนนั้นไปยังผู้ค้าทุกคนที่ใช้งาน ตอนนี้ Tap to Pay เป็นเพียงปุ่มชำระเงินที่ผู้ค้าของเราเปิดใช้งาน และ การรับชำระเงินด้วย Tap to Pay ก็เป็นขั้นตอนการทำงาน 5 ขั้นตอนที่เคาน์เตอร์ หากระบบชำระเงินคือผลิตภัณฑ์ของคุณ การฝ่าฟันอุปสรรคเหล่านี้คือต้นทุนในการเข้าสู่ตลาด แต่หากระบบชำระเงินเป็นเพียงวิธีที่คุณจะได้รับเงิน การสร้างแอป Tap to Pay ของคุณเองก็ไม่มีความสมเหตุสมผลทางการเงินเลย เนื่องจากเวอร์ชันที่เสร็จสมบูรณ์มีอยู่แล้วในแอป POS และ ค่าธรรมเนียมคือจุดที่ต้องเปรียบเทียบกันอย่างแท้จริง

กฎเหล็ก: หากฟีเจอร์ใดต้องการการอนุญาตจากผู้อื่นจึงจะสามารถใช้งานได้ ไม่มีโค้ดที่ชาญฉลาดใดๆ ที่จะช่วยลัดขั้นตอนนั้นได้