Tự xây dựng ứng dụng Tap to Pay khó đến mức nào? (Chúng tôi đã thử)

Khó hơn những gì các tài liệu quảng cáo SDK gợi ý, và khó khăn hầu như không nằm ở phần mã nguồn. Chúng tôi đã triển khai Tap to Pay trong ứng dụng Final POS, vì vậy câu trả lời này đến từ trải nghiệm thực tế chứ không phải từ việc đọc tài liệu hướng dẫn. Nếu bạn muốn xây dựng ứng dụng tap to pay của riêng mình, hãy chuẩn bị cho một dự án phần mềm ngắn hạn được bao bọc bên trong một dự án xin cấp phép dài hạn hơn nhiều: quan hệ đối tác với đơn vị xử lý thanh toán, một quyền hạn (entitlement) được phê duyệt thủ công từ Apple hoặc một đợt đánh giá của phòng thí nghiệm trên Android, và một đợt xét duyệt ứng dụng, tất cả đều phải hoàn thành trước lượt chạm thanh toán thực tế đầu tiên của bạn.

Một lưu ý nhanh: các quy tắc của nền tảng và ngành thẻ thay đổi thường xuyên. Mọi thông tin dưới đây đều chính xác tại thời điểm xuất bản, vì vậy hãy coi các chi tiết này là một ảnh chụp nhanh tại thời điểm hiện tại.

Ứng dụng tap to pay thực sự làm gì?

Tap to pay biến chính chiếc điện thoại thành đầu đọc thẻ. Không cần thiết bị đầu cuối, không cần đầu đọc gắn ngoài (dongle): khách hàng chạm thẻ không tiếp xúc hoặc ví điện tử trên điện thoại như Apple Pay hoặc Google Pay trực tiếp lên thiết bị của chủ cửa hàng, và khoản thanh toán sẽ chạy qua chip NFC của điện thoại (sóng vô tuyến tầm ngắn dùng cho thanh toán không tiếp xúc). Nếu thuật ngữ này có vẻ dễ gây nhầm lẫn, chúng tôi đã phân tích sự khác biệt giữa thanh toán bằng cách chạm trên thiết bị di động và Tap to Pay trên thiết bị di động.

Đây chính là cái bẫy. Việc đọc một thẻ NFC thực sự chỉ là một dự án cuối tuần; những người đam mê công nghệ làm việc này liên tục. Nhưng đọc một thẻ thanh toán lại là một câu chuyện hoàn toàn khác. Thẻ sử dụng giao thức EMV (giao thức chip của ngành thẻ), dữ liệu thẻ phải được mã hóa đầu cuối và chỉ phần mềm đã được chứng nhận mới được phép chạm vào dữ liệu đó.

Tại sao bạn không thể tự mình đọc thẻ?

Bởi vì mọi lớp trong hệ thống đều yêu cầu quyền hạn trước khi mã nguồn của bạn được phép chạy công khai.

• Apple không cấp cho các ứng dụng quyền truy cập thô vào tính năng NFC thanh toán. Bạn phải sử dụng framework ProximityReader của họ, vốn nằm sau một quyền hạn Tap to Pay trên iPhone (một quyền hạn đặc biệt được Apple cấp theo từng trường hợp cụ thể). Apple cũng yêu cầu bạn tích hợp với một nhà cung cấp dịch vụ thanh toán (PSP) được hỗ trợ (công ty thực sự chuyển tiền). PSP sẽ cung cấp các cấu hình đầu đọc đã được chứng nhận được tải lên thiết bị của chủ cửa hàng và chịu trách nhiệm về mặt chứng nhận.

• Android cung cấp cho các nhà phát triển quyền truy cập NFC cởi mở hơn, nhưng một ứng dụng chấp nhận thanh toán vẫn phải được đánh giá bởi một phòng thí nghiệm độc lập được PCI công nhận theo tiêu chuẩn PCI MPoC (các quy tắc bảo mật của ngành thẻ dành cho điện thoại hoạt động như thiết bị đầu cuối thanh toán).

• Bên dưới cả hai nền tảng, bạn cần có mối quan hệ thanh toán (acquiring relationship): một đơn vị xử lý thanh toán sẵn sàng quyết toán tiền cho các chủ cửa hàng của bạn, đi kèm với các quy tắc của mạng lưới thẻ.

Không có điều nào trong số này có thể giải quyết bằng cách cố gắng viết mã nguồn tốt hơn. Đó là câu chuyện của giấy tờ, hợp đồng và các hàng đợi xét duyệt.

Lộ trình phê duyệt trên iPhone trông như thế nào?

Theo các yêu cầu đã công bố của Apple, lộ trình sẽ diễn ra như sau: sở hữu tài khoản Apple Developer cấp tổ chức (chủ tài khoản phải đích thân gửi yêu cầu), hợp tác với một PSP được hỗ trợ cho khu vực của bạn, yêu cầu cấp quyền hạn (entitlement), tích hợp API ProximityReader hoặc SDK của PSP, tuân theo các hướng dẫn thiết kế của Apple cho màn hình thanh toán và gửi ứng dụng để xét duyệt. Tài liệu của Apple cũng lưu ý rằng tính năng này chỉ hoạt động ở các quốc gia và khu vực được hỗ trợ, vì vậy bản thân tính năng khả dụng hay không đã được quyết định sẵn cho bạn theo từng thị trường.

Hãy đọc lại danh sách đó dưới góc độ của một nhà sáng lập hoặc một chủ cửa hàng thay vì một nhà phát triển. Không có bước nào trong đó là "viết tính năng". Tính năng là phần dễ dàng; quyền hạn (entitlement) mới là hào nước bảo vệ.

Công việc sẽ đi về đâu sau khi tính năng chạm hoạt động?

Một lượt chạm được phê duyệt chỉ mang lại cho bạn một khoản thanh toán, chứ không phải một hệ thống điểm bán hàng. Khoảnh khắc tiền dịch chuyển, mọi thứ xung quanh lượt chạm đó phải chính xác tuyệt đối: giỏ hàng được quyết toán, thuế trên hóa đơn, quy trình hoàn tiền và báo cáo đối soát (mỗi đô la phải khớp với một lượt bán hàng, mỗi ngày). Chúng tôi cũng tìm thấy khoảng cách tương tự khi xem xét liệu bạn có thể xây dựng một POS bằng Lovable hoặc Replit hay không: việc tạo ra một giao diện thì nhanh chóng, còn lớp thương mại bên dưới mới là thứ ngốn thời gian của bạn.

Tap to pay cũng mang lại những đặc thù vận hành riêng. Trong phiên bản triển khai của chúng tôi, giao dịch bán hàng phải được nhập trên cùng một thiết bị nhận thanh toán chạm, và nó chỉ hoạt động trong ứng dụng gốc (native app), không bao giờ hoạt động trong trình duyệt. Những hạn chế như vậy không xuất hiện trong bất kỳ tài liệu quảng cáo nào. Bạn tự phát hiện ra chúng, tìm giải pháp kỹ thuật để khắc phục, rồi viết bài viết hướng dẫn trợ giúp. Và khi một chiếc điện thoại trên quầy không còn đủ đáp ứng nhu cầu nữa, dù sao thì bạn cũng sẽ phải bước vào những quyết định thực tế về phần cứng.

Vậy, tự xây dựng ứng dụng tap to pay khó đến mức nào?

Khó theo một cách rất đặc thù: việc lập trình chỉ là phần nhỏ nhất, trong khi quan hệ đối tác với đơn vị xử lý thanh toán, quyền hạn từ Apple, chứng nhận phòng thí nghiệm trên Android và xét duyệt ứng dụng mới chiếm phần lớn, và không có điều nào trong số đó chịu tác động bởi nỗ lực kỹ thuật thuần túy. Đối với chúng tôi, điều đó là xứng đáng, bởi vì một nền tảng POS sẽ phân bổ chi phí đó cho mọi chủ cửa hàng sử dụng nó. Giờ đây, Tap to Pay là một nút thanh toán mà các chủ cửa hàng của chúng tôi chỉ cần bật lên, và thực hiện thanh toán bằng Tap to Pay là một quy trình tại quầy gồm năm bước. Nếu thanh toán là sản phẩm của bạn, thử thách này là cái giá để gia nhập. Còn nếu thanh toán chỉ là cách bạn nhận tiền, việc tự xây dựng ứng dụng tap to pay sẽ không mang lại ý nghĩa kinh tế nào; phiên bản hoàn chỉnh đã tồn tại sẵn bên trong các ứng dụng POS, và phí dịch vụ mới là nơi diễn ra sự so sánh thực sự.

Nguyên tắc vàng: nếu một tính năng cần sự cho phép của người khác để tồn tại, không có lượng mã nguồn thông minh nào có thể đi tắt đón đầu được.