Hvorfor vibe-kodede betalingsapps bliver afvist i App Store

Vibe-kodede betalingsapps bliver afvist i App Store med en højere frekvens end næsten alt andet i godkendelseskøen, og årsagerne har normalt intet at gøre med kodekvaliteten. En vibe-kodet app — en app, du har bygget ved at beskrive, hvad du vil have, til en AI-assistent og udgivet det, den skrev — kan se fuldstændig professionel ud. Apples godkendelsesproces bedømmer ikke koden. Den kontrollerer, hvem der har indsendt appen, hvilken betalingsmekanisme der håndterer hvilken type varer, om hardware-rettigheder blev godkendt separat, og om testeren kan gennemføre en rigtig transaktion. Det er præcis de ting, en AI-assistent ikke kan generere.

Dette er muren, alle rammer efter at have bygget et tilpasset point of sale med en AI-model: koden er klar på en eftermiddag, men at få den ind på en iPhone som en rigtig betalingsapp er en overholdelsesproces, ikke en kodeopgave.

Har din AI routet betalinger gennem det forkerte system?

Den mest almindelige afvisning skyldes brug af den forkerte betalingsmekanisme til de varer, der sælges, og AI-assistenter er usædvanligt gode til at tage fejl her. Apples retningslinjer for app-gennemgang trækker en skarp linje. Digitalt indhold og tjenester, der forbruges i appen, skal bruge Apples køb i appen under retningslinje 3.1.1. Fysiske varer og tjenester i den virkelige verden — en kop kaffe, en klipning, en afsendt ordre — skal gøre det modsatte under retningslinje 3.1.5(a): de må overhovedet ikke bruge køb i appen og kræver en ekstern betalingsmetode.

En kodningsmodel reproducerer det betalingsmønster, der dominerede dens træningsdata — standardkode til køb i appen fra abonnementsvejledninger eller en web-checkout-SDK fra e-handelseksempler — uden nogensinde at spørge, hvad du sælger. Bed den om "en app, der tager imod betalinger", og du vil få en af de to, valgt ud fra statistik snarere end ud fra Apples regler. Reglerne ændrer sig også efter region: efter Epic-afgørelsen i 2025 må apps i den amerikanske App Store linke ud til eksterne købsmuligheder for digitale varer, men den undtagelse gælder kun i USA. En app, der distribueres globalt, skal stadig opfylde den strengere regel alle andre steder.

Har du overhovedet tilladelse til at indsende en betalingsapp?

Apple forventer, at apps, der håndterer pengestyring eller finansielle tjenesteydelser, indsendes af den institution, der rent faktisk udfører disse tjenester, med de nødvendige licenser i alle regioner, hvor appen er tilgængelig — det er retningslinje 3.2.1. En enkeltperson, der udgiver en AI-genereret betalingsapp, er ikke et licenseret pengeinstitut, og det er et bureau, der indsender en app på vegne af en kunde, heller ikke. At tilbyde appen i et land, hvor licensen til pengeoverførsel ikke er på plads, udløser den samme afvisning med et andet poststempel.

Apples testere vurderer ikke, om dit overholdelsesprogram er godt; de kontrollerer, om den rigtige enhed har indsendt appen, og afviser den, hvis det ikke er tilfældet. Det kan intet prompt rette op på.

Hvorfor er tap-to-pay sin helt egen godkendelsesproces?

At tage imod kontaktløse kort på en iPhone kræver rettigheden Tap to Pay on iPhone — en separat ansøgning til Apple, uafhængig af selve app-gennemgangen, som tildeles en juridisk enhed og ikke en kodebase. Udviklingsrettigheden godkendes normalt på en dag eller to. Udgivelsesrettigheden går gennem Apples driftsteam, tager typisk en til to uger og kræver, at man samarbejder med en understøttet betalingsudbyder. En AI-assistent skriver gladeligt tap-to-pay-koden uden at nævne noget af dette; indsender du, før rettigheden er givet, bliver appen afvist.

Fysisk kortbetaling medfører også krav, som Apple ikke selv ejer: certificeret terminalhardware, EMV-regler og PCI-omfang for alt, der berører kortdata. Intet af det kommer ud af en model, der skriver Swift.

Kan testeren rent faktisk gennemføre en transaktion?

Retningslinje 2.1, App-fuldstændighed, spænder i stilhed ben for flere betalingsapps end selve betalingsreglerne. Testere skal kunne afprøve hele appen, herunder betalingsflowet. En betalingsapp kræver typisk en indløsningsaftale, identitetsbekræftelse og nogle gange en bankkonto — ting, som en tester ikke kan oprette under en gennemgang. Vibe-kodede indsendelser fejler konstant her, fordi udvikleren ofte aldrig selv har oprettet en rigtig indløsningsaftale; appen er kun blevet testet mod fiktive data, som AI'en genererede undervejs. Uden en fungerende demokonto og en måde at køre en testtransaktion på, afvises appen som ufuldstændig, og hver genindsendelse koster en ny godkendelsesrunde.

Så hvad udgives der rent faktisk?

Den svære del var aldrig koden. En AI-assistent kan producere en fungerende betalingsgrænseflade på en eftermiddag, men distribution i App Store er et stormløb af rettigheder, licenser og godkendelsespolitikker, som ligger helt uden for, hvad et prompt kan nå. Demoen fungerer; infrastrukturen eksisterer bare ikke endnu.

For en erhvervsdrivende, der sælger fysiske varer, er den praktiske konklusion mere simpel: Lad være med at stille dig op i køen. Din virksomhed har brug for en velfungerende betalingsløsning, ikke sin egen app i App Store — licensering, hardwarecertificering og administrationen omkring godkendelse giver kun mening for virksomheder, hvis produkt er selve betalingssoftwaren. Kør kassen på en POS-platform, der allerede har afholdt disse omkostninger (Final er bygget præcis på denne måde — betalinger gennem Final Pay med certificeret terminalhardware, uden at du skal udgive din egen app), og brug pengene fra de sparede godkendelsesrunder på ting, der skaber omsætning, såsom et hurtigere betalingsflow og lavere effektive kortgebyrer.

Apples godkendelsesproces findes af gode grunde — betalingsapps, der fejler, skader rigtige mennesker. Det er bare ikke en proces, de fleste erhvervsdrivende nogensinde har brug for at gennemgå, uanset hvem eller hvad der har skrevet appen.