Γιατί οι εφαρμογές πληρωμών με κώδικα «Vibe» απορρίπτονται από το App Store

Οι εφαρμογές πληρωμών με κώδικα vibe απορρίπτονται από το App Store με υψηλότερο ρυθμό από σχεδόν οτιδήποτε άλλο στην ουρά ελέγχου, και οι λόγοι συνήθως δεν έχουν καμία σχέση με την ποιότητα του κώδικα. Μια εφαρμογή με κώδικα vibe — αυτή που φτιάξατε περιγράφοντας τι θέλετε σε έναν βοηθό AI και δημοσιεύοντας ό,τι έγραψε — μπορεί να φαίνεται πανομοιότυπη με μια επαγγελματική δουλειά. Ο έλεγχος της Apple δεν βαθμολογεί τον κώδικα. Ελέγχει ποιος υπέβαλε την εφαρμογή, ποιος μηχανισμός πληρωμής διαχειρίζεται κάθε τύπο αγαθών, αν τα δικαιώματα υλικού εγκρίθηκαν ξεχωριστά και αν ο ελεγκτής μπορεί να ολοκληρώσει μια πραγματική συναλλαγή. Αυτά είναι ακριβώς τα πράγματα που ένας βοηθός AI δεν μπορεί να δημιουργήσει.

Αυτός είναι ο τοίχος στον οποίο προσκρούουν όλοι μετά την κατασκευή ενός προσαρμοσμένου σημείου πώλησης με ένα μοντέλο AI: ο κώδικας υπάρχει μέσα σε ένα απόγευμα, αλλά η μεταφορά του σε ένα iPhone ως πραγματική εφαρμογή checkout είναι μια διαδικασία συμμόρφωσης, όχι μια εργασία προγραμματισμού.

Μήπως η AI σας δρομολόγησε τις πληρωμές μέσω λάθος συστήματος;

Η πιο συνηθισμένη απόρριψη οφείλεται στη χρήση λάθος μηχανισμού πληρωμής για τα αγαθά που πωλούνται, και οι βοηθοί AI είναι ασυνήθιστα καλοί στο να κάνουν λάθος σε αυτό. Οι Οδηγίες Ελέγχου Εφαρμογών της Apple τραβούν μια σκληρή γραμμή. Το ψηφιακό περιεχόμενο και οι υπηρεσίες που καταναλώνονται μέσα στην εφαρμογή πρέπει να χρησιμοποιούν τις αγορές εντός εφαρμογής (in-app purchase) της Apple σύμφωνα με την Οδηγία 3.1.1. Τα φυσικά αγαθά και οι υπηρεσίες του πραγματικού κόσμου — ένας καφές, ένα κούρεμα, μια αποστολή παραγγελίας — πρέπει να κάνουν το αντίθετο σύμφωνα με την Οδηγία 3.1.5(α): δεν επιτρέπεται να χρησιμοποιούν καθόλου αγορές εντός εφαρμογής και απαιτούν εξωτερική μέθοδο πληρωμής.

Ένα μοντέλο κώδικα αναπαράγει όποιο μοτίβο πληρωμής κυριαρχούσε στα δεδομένα εκπαίδευσής του — έτοιμο κώδικα για in-app purchase από σεμινάρια συνδρομών ή ένα SDK για web checkout από παραδείγματα ηλεκτρονικού εμπορίου — χωρίς να ρωτήσει ποτέ τι πουλάτε. Ζητήστε του «μια εφαρμογή που δέχεται πληρωμές» και θα λάβετε μία από τις δύο επιλογές, επιλεγμένη βάσει στατιστικών και όχι βάσει των κανόνων της Apple. Οι κανόνες αλλάζουν επίσης ανάλογα με το κατάστημα: μετά την απόφαση για την Epic το 2025, οι εφαρμογές στο κατάστημα των ΗΠΑ μπορούν να συνδέονται με εξωτερικές επιλογές αγοράς για ψηφιακά αγαθά, αλλά αυτή η εξαίρεση ισχύει μόνο στις Ηνωμένες Πολιτείες. Μια εφαρμογή που διανέμεται παγκοσμίως πρέπει να ικανοποιεί τον αυστηρότερο κανόνα παντού αλλού.

Σας επιτρέπεται καν να υποβάλετε μια εφαρμογή πληρωμών;

Η Apple απαιτεί οι εφαρμογές που διαχειρίζονται χρήματα ή χρηματοοικονομικές υπηρεσίες να υποβάλλονται από το ίδρυμα που εκτελεί πραγματικά αυτές τις υπηρεσίες, με την απαιτούμενη αδειοδότηση σε κάθε περιοχή όπου η εφαρμογή είναι διαθέσιμη — αυτή είναι η Οδηγία 3.2.1. Ένας μεμονωμένος δημιουργός που κυκλοφορεί μια εφαρμογή πληρωμών παραγόμενη από AI δεν είναι αδειοδοτημένο χρηματοπιστωτικό ίδρυμα, ούτε και ένα γραφείο που υποβάλλει μια εφαρμογή για λογαριασμό ενός πελάτη. Η προσφορά της εφαρμογής σε μια χώρα όπου δεν υπάρχει η αδειοδότηση για τη διακίνηση χρημάτων οδηγεί στην ίδια απόρριψη με διαφορετική αιτιολογία.

Οι ελεγκτές της Apple δεν αξιολογούν αν το πρόγραμμα συμμόρφωσής σας είναι καλό· ελέγχουν αν η σωστή οντότητα υπέβαλε την εφαρμογή και την απορρίπτουν αν δεν συμβαίνει αυτό. Καμία εντολή δεν το διορθώνει αυτό.

Γιατί το tap-to-pay είναι μια ξεχωριστή διαδικασία έγκρισης;

Η αποδοχή ανέπαφων καρτών σε ένα iPhone απαιτεί το δικαίωμα Tap to Pay on iPhone — μια ξεχωριστή αίτηση στην Apple, ανεξάρτητη από τον έλεγχο της εφαρμογής, η οποία παραχωρείται σε νομική οντότητα και όχι σε μια βάση κώδικα. Το δικαίωμα ανάπτυξης συνήθως εγκρίνεται σε μία ή δύο ημέρες. Το δικαίωμα δημοσίευσης περνάει από την ομάδα λειτουργιών της Apple, συνήθως διαρκεί μία έως δύο εβδομάδες και απαιτεί συνεργασία με έναν υποστηριζόμενο πάροχο υπηρεσιών πληρωμών. Ένας βοηθός AI θα γράψει ευχαρίστως τον κώδικα για το tap-to-pay χωρίς να αναφέρει τίποτα από όλα αυτά· αν υποβάλετε την εφαρμογή πριν χορηγηθεί το δικαίωμα, η εφαρμογή θα απορριφθεί.

Η αποδοχή με φυσική παρουσία κάρτας συνεπάγεται επίσης απαιτήσεις που δεν ανήκουν στην Apple: πιστοποιημένο υλικό ανάγνωσης, κανόνες EMV και πεδίο εφαρμογής PCI για οτιδήποτε αγγίζει δεδομένα κάρτας. Τίποτα από αυτά δεν προκύπτει από ένα μοντέλο που γράφει Swift.

Μπορεί ο ελεγκτής να ολοκληρώσει πραγματικά μια συναλλαγή;

Η Οδηγία 2.1, Πληρότητα Εφαρμογής, απορρίπτει αθόρυβα περισσότερες εφαρμογές πληρωμών από ό,τι οι κανόνες πληρωμών. Οι ελεγκτές πρέπει να μπορούν να δοκιμάσουν την πλήρη εφαρμογή, συμπεριλαμβανομένης της ροής πληρωμής. Μια εφαρμογή πληρωμών συνήθως απαιτεί λογαριασμό εμπόρου, επαλήθευση ταυτότητας, μερικές φορές τραπεζικό λογαριασμό — πράγματα για τα οποία ένας ελεγκτής δεν μπορεί να εγγραφεί κατά τη διάρκεια του ελέγχου. Οι υποβολές με κώδικα vibe αποτυγχάνουν συνεχώς εδώ, επειδή ο δημιουργός συχνά δεν έχει δημιουργήσει ποτέ ο ίδιος έναν πραγματικό λογαριασμό εμπόρου· η εφαρμογή δοκιμάστηκε μόνο με εικονικά δεδομένα που παρήγαγε η AI μαζί με αυτήν. Χωρίς έναν λειτουργικό λογαριασμό επίδειξης και έναν τρόπο εκτέλεσης μιας δοκιμαστικής συναλλαγής, η εφαρμογή απορρίπτεται ως ημιτελής, και κάθε επανυποβολή κοστίζει έναν ακόμα κύκλο ελέγχου.

Τι τελικά κυκλοφορεί;

Το δύσκολο κομμάτι δεν ήταν ποτέ ο κώδικας. Ένας βοηθός AI μπορεί να παράγει μια λειτουργική διεπαφή checkout σε ένα απόγευμα, αλλά η διανομή στο App Store είναι ένας γολγοθάς δικαιωμάτων, αδειοδοτήσεων και πολιτικών ελέγχου που βρίσκεται εντελώς έξω από οτιδήποτε μπορεί να φτάσει μια εντολή. Το demo λειτουργεί· η υποδομή δεν υπάρχει ακόμα.

Για έναν έμπορο που πουλάει φυσικά αγαθά, το πρακτικό συμπέρασμα είναι απλούστερο: μην μπείτε στην ουρά. Η επιχείρησή σας χρειάζεται ένα λειτουργικό checkout, όχι τη δική της καταχώριση στο App Store — η αδειοδότηση, η πιστοποίηση υλικού και τα έξοδα ελέγχου έχουν νόημα μόνο για εταιρείες των οποίων το προϊόν είναι το ίδιο το λογισμικό πληρωμών. Λειτουργήστε το ταμείο σας σε μια πλατφόρμα POS που έχει ήδη απορροφήσει αυτά τα κόστη (το Final είναι κατασκευασμένο ακριβώς με αυτόν τον τρόπο — πληρωμές μέσω του Final Pay με πιστοποιημένο υλικό τερματικού, χωρίς δική σας εφαρμογή προς δημοσίευση) και επενδύστε τα χρήματα του κύκλου ελέγχου σε πράγματα που φέρνουν έσοδα, όπως μια ταχύτερη ροή checkout και χαμηλότερες πραγματικές προμήθειες καρτών.

Η διαδικασία ελέγχου της Apple υπάρχει για καλούς λόγους — οι εφαρμογές διαχείρισης χρημάτων που αποτυγχάνουν βλάπτουν πραγματικούς ανθρώπους. Απλώς δεν είναι μια διαδικασία που οι περισσότεροι έμποροι χρειάζεται να περάσουν ποτέ, ανεξάρτητα από το ποιος ή τι έγραψε την εφαρμογή.