Tại sao các ứng dụng thanh toán được lập trình theo cảm hứng (Vibe-Coded) bị từ chối khỏi App Store

Các ứng dụng thanh toán được lập trình theo cảm hứng (vibe-coded) bị từ chối khỏi App Store với tỷ lệ cao hơn hầu hết mọi thứ khác trong hàng đợi kiểm duyệt, và lý do thường không liên quan gì đến chất lượng mã nguồn. Một ứng dụng vibe-coded — ứng dụng bạn xây dựng bằng cách mô tả những gì bạn muốn cho một trợ lý AI và phát hành những gì nó viết — có thể trông không khác gì tác phẩm của dân chuyên nghiệp. Quy trình kiểm duyệt của Apple không chấm điểm mã nguồn. Nó kiểm tra xem ai đã nộp ứng dụng, cơ chế thanh toán nào xử lý loại hàng hóa nào, các quyền phần cứng có được phê duyệt riêng biệt hay không và liệu người kiểm duyệt có thể hoàn tất một giao dịch thực tế hay không. Đó chính xác là những thứ mà một trợ lý AI không thể tạo ra.

Đây là bức tường mà mọi người đều vấp phải sau khi xây dựng một POS tùy chỉnh với một mô hình AI: mã nguồn có thể hoàn thành trong một buổi chiều, nhưng việc đưa nó lên iPhone dưới dạng một ứng dụng thanh toán thực tế là một quy trình tuân thủ, không phải là một nhiệm vụ lập trình.

AI của bạn có định tuyến thanh toán qua sai hệ thống không?

Lỗi từ chối phổ biến nhất là sử dụng sai cơ chế thanh toán cho hàng hóa được bán, và các trợ lý AI cực kỳ giỏi trong việc làm sai điều này. Hướng dẫn Đánh giá Ứng dụng của Apple vạch ra một ranh giới cứng rắn. Nội dung kỹ thuật số và các dịch vụ được tiêu dùng bên trong ứng dụng phải sử dụng tính năng mua hàng trong ứng dụng (in-app purchase) của Apple theo Hướng dẫn 3.1.1. Hàng hóa vật lý và dịch vụ thực tế — một ly cà phê, một kiểu tóc, một đơn hàng được giao — phải làm ngược lại theo Hướng dẫn 3.1.5(a): họ không được phép sử dụng tính năng mua hàng trong ứng dụng và yêu cầu một phương thức thanh toán bên ngoài.

Một mô hình lập trình sẽ tái tạo lại bất kỳ mô hình thanh toán nào chiếm ưu thế trong dữ liệu đào tạo của nó — mã mẫu mua hàng trong ứng dụng từ các hướng dẫn đăng ký thuê bao, hoặc một SDK thanh toán web từ các ví dụ thương mại điện tử — mà không bao giờ hỏi bạn đang bán gì. Hãy ra lệnh cho nó tạo "một ứng dụng nhận thanh toán" và bạn sẽ nhận được một trong hai phương thức đó, được lựa chọn bởi số liệu thống kê thay vì các quy tắc của Apple. Các quy tắc này cũng thay đổi theo từng quốc gia: sau phán quyết Epic năm 2025, các ứng dụng trên cửa hàng Hoa Kỳ có thể liên kết ra các tùy chọn mua hàng bên ngoài cho hàng hóa kỹ thuật số, nhưng ngoại lệ đó chỉ áp dụng tại Hoa Kỳ. Một ứng dụng được phân phối trên toàn thế giới vẫn phải đáp ứng quy tắc nghiêm ngặt hơn ở mọi nơi khác.

Bạn có được phép nộp một ứng dụng thanh toán không?

Apple yêu cầu các ứng dụng xử lý quản lý tiền tệ hoặc dịch vụ tài chính phải được nộp bởi chính tổ chức thực sự thực hiện các dịch vụ đó, với giấy phép bắt buộc ở mọi khu vực mà ứng dụng khả dụng — đó là Hướng dẫn 3.2.1. Một nhà phát triển độc lập phát hành một ứng dụng thanh toán do AI tạo ra không phải là một tổ chức tài chính được cấp phép, và một đại lý nộp ứng dụng cho khách hàng cũng vậy. Cung cấp ứng dụng ở một quốc gia không có giấy phép chuyển tiền sẽ nhận cùng một lý do từ chối với một địa chỉ gửi thư khác.

Các nhà kiểm duyệt của Apple không đánh giá xem chương trình tuân thủ của bạn có tốt hay không; họ kiểm tra xem thực thể phù hợp có nộp ứng dụng hay không và từ chối khi không phải như vậy. Không có câu lệnh nào sửa được điều đó.

Tại sao tap-to-pay lại là một quy trình phê duyệt riêng biệt?

Việc chấp nhận thẻ không tiếp xúc trên iPhone yêu cầu quyền Tap to Pay trên iPhone — một đơn đăng ký riêng gửi tới Apple, độc lập với quy trình kiểm duyệt ứng dụng, được cấp cho một pháp nhân chứ không phải cho một kho mã nguồn. Quyền phát triển thường được thông qua trong một hoặc hai ngày. Quyền phát hành phải đi qua đội ngũ vận hành của Apple, thường mất từ một đến hai tuần và yêu cầu làm việc với một nhà cung cấp dịch vụ thanh toán được hỗ trợ. Một trợ lý AI sẽ vui vẻ viết mã tap-to-pay mà không đề cập đến bất kỳ điều nào trong số này; nộp ứng dụng trước khi quyền được cấp và ứng dụng sẽ bị trả về.

Việc chấp nhận thẻ trực tiếp cũng kéo theo các yêu cầu mà Apple không sở hữu: phần cứng đầu đọc được chứng nhận, các quy tắc EMV và phạm vi PCI cho bất kỳ thứ gì chạm vào dữ liệu thẻ. Không có điều nào trong số đó tự động sinh ra từ một mô hình viết mã Swift.

Người kiểm duyệt có thực sự hoàn tất được một giao dịch không?

Hướng dẫn 2.1, Tính hoàn thiện của ứng dụng, âm thầm loại bỏ nhiều ứng dụng thanh toán hơn cả các quy tắc thanh toán. Người kiểm duyệt phải có thể thực hiện toàn bộ ứng dụng, bao gồm cả quy trình thanh toán. Một ứng dụng thanh toán thường yêu cầu một tài khoản người bán, xác minh danh tính, đôi khi là một tài khoản ngân hàng — những thứ mà người kiểm duyệt không thể đăng ký trong quá trình kiểm duyệt. Các bản nộp vibe-coded liên tục thất bại ở đây, vì người xây dựng thường chưa bao giờ tự mình thiết lập một tài khoản người bán thực tế; ứng dụng chỉ được thử nghiệm với dữ liệu giả lập mà AI tạo ra cùng với nó. Không có tài khoản demo hoạt động và cách chạy giao dịch thử nghiệm, ứng dụng sẽ bị từ chối vì chưa hoàn thiện, và mỗi lần nộp lại sẽ tốn thêm một chu kỳ kiểm duyệt.

Vậy điều gì thực sự được phát hành?

Phần khó khăn chưa bao giờ là mã nguồn. Một trợ lý AI có thể tạo ra một giao diện thanh toán hoạt động trong một buổi chiều, nhưng việc phân phối trên App Store là một chuỗi các quyền hạn, giấy phép và chính sách kiểm duyệt nằm hoàn toàn ngoài tầm với của bất kỳ câu lệnh nào. Bản demo hoạt động; nhưng cơ sở hạ tầng thì chưa tồn tại.

Đối với một người bán hàng hóa vật lý, kết luận thực tế đơn giản hơn: đừng tham gia vào hàng đợi đó. Doanh nghiệp của bạn cần một quy trình thanh toán hoạt động, chứ không phải một danh sách ứng dụng của riêng mình trên App Store — chi phí cấp phép, chứng nhận phần cứng và kiểm duyệt chỉ có ý nghĩa đối với các công ty có sản phẩm chính là phần mềm thanh toán. Hãy vận hành quầy thanh toán của bạn trên một nền tảng POS đã gánh chịu các chi phí đó (Final được xây dựng chính xác theo cách này — thanh toán qua Final Pay với phần cứng thiết bị đầu cuối được chứng nhận, không cần tự xuất bản ứng dụng) và dành số tiền của chu kỳ kiểm duyệt đó vào những thứ thúc đẩy doanh thu, như một quy trình thanh toán nhanh hơn và phí thẻ hiệu dụng thấp hơn.

Quy trình kiểm duyệt của Apple tồn tại vì những lý do chính đáng — các ứng dụng tiền tệ bị lỗi sẽ gây hại cho những con người thực tế. Chỉ là đó không phải là quy trình mà hầu hết các nhà bán lẻ cần phải vượt qua, bất kể ai hay cái gì đã viết ra ứng dụng đó.