Hvorfor vibe-kodede betalingsapper blir avvist av App Store

Vibe-kodede betalingsapper blir avvist fra App Store i høyere grad enn nesten alt annet i vurderingskøen, og årsakene har vanligvis ingenting med kodekvalitet å gjøre. En vibe-kodet app – en du har bygget ved å beskrive hva du vil ha til en AI-assistent og publisert det den skrev – kan se helt identisk ut med profesjonelt arbeid. Apples vurdering gir ikke karakter på koden. Den sjekker hvem som sendte inn appen, hvilken betalingsmekanisme som håndterer hvilken type varer, om maskinvarerettigheter ble godkjent separat, og om testeren kan gjennomføre en reell transaksjon. Dette er nøyaktig de tingene en AI-assistent ikke kan generere.

Dette er veggen alle møter etter å ha bygget en tilpasset POS med en AI-modell: koden er klar på en ettermiddag, men å få den inn på en iPhone som en ekte betalingsapp er en samsvarsprosess, ikke en kodeoppgave.

Ruter din AI betalinger gjennom feil system?

Den vanligste årsaken til avslag er bruk av feil betalingsmekanisme for varene som selges, og AI-assistenter er uvanlig flinke til å gjøre feil her. Apples retningslinjer for app-vurdering trekker en hard grense. Digitalt innhold og tjenester som forbrukes i appen må bruke Apples kjøp i app under retningslinje 3.1.1. Fysiske varer og tjenester i den virkelige verden – en kaffe, en hårklipp, en sendt bestilling – må gjøre det motsatte under retningslinje 3.1.5(a): de kan ikke bruke kjøp i app i det hele tatt, og krever en ekstern betalingsmetode.

En kodingsmodell gjenskaper det betalingsmønsteret som dominerte i treningsdataene dens – enten standardkode for kjøp i app fra abonnementsveiledninger, eller en SDK for nettbetaling fra e-handelseksempler – uten noen gang å spørre hva du faktisk selger. Be den om "en app som tar imot betalinger", og du vil få en av de to, valgt ut fra statistikk snarere enn Apples regler. Reglene varierer også etter marked: etter Epic-dommen i 2025 kan apper i det amerikanske markedet lenke ut til eksterne kjøpsalternativer for digitale varer, men dette unntaket gjelder bare i USA. En app som distribueres globalt må fortsatt oppfylle de strengere reglene alle andre steder.

Har du i det hele tatt lov til å sende inn en betalingsapp?

Apple forventer at apper som håndterer pengehåndtering eller finansielle tjenester sendes inn av institusjonen som faktisk utfører disse tjenestene, med de nødvendige lisensene i alle regioner der appen er tilgjengelig – det er retningslinje 3.2.1. En enkeltutvikler som publiserer en AI-generert betalingsapp er ikke en lisensiert finansinstitusjon, og det er heller ikke et byrå som sender inn en app på vegne av en kunde. Å tilby appen i et land der lisensen for pengeoverføring ikke foreligger, fører til nøyaktig samme avslag, bare med et annet poststempel.

Apples testere vurderer ikke om samsvarsprogrammet ditt er godt; de sjekker om riktig juridisk enhet har sendt inn appen, og avviser den hvis det ikke er tilfelle. Ingen ledetekst kan fikse det.

Hvorfor er tap-to-pay en helt egen godkjenningsprosess?

Å ta imot kontaktløse kort på en iPhone krever rettigheten "Tap to Pay on iPhone" – en separat søknad til Apple, uavhengig av den vanlige app-vurderingen, som innvilges til en juridisk enhet i stedet for til en kodebase. Utviklingsrettigheten blir vanligvis godkjent på en dag eller to. Publiseringstillatelsen går gjennom Apples driftsteam, tar vanligvis én til to uker, og krever at du samarbeider med en støttet betalingsleverandør. En AI-assistent skriver gjerne tap-to-pay-koden uten å nevne noe av dette; sender du inn appen før rettigheten er innvilget, blir den avvist.

Kortbetalinger med fysisk tilstedeværelse drar også med seg krav som Apple ikke eier: sertifisert terminalmaskinvare, EMV-regler og PCI-omfang for alt som berører kortdata. Ingenting av dette kommer ut av en modell som skriver Swift.

Kan testeren faktisk gjennomføre en transaksjon?

Retningslinje 2.1, Fullstendig app, stopper i det stille flere betalingsapper enn selve betalingsreglene gjør. Testere må kunne prøve hele appen, inkludert betalingsflyten. En betalingsapp krever vanligvis en innløserkonto, identitetsbekreftelse, og noen ganger en bankkonto – ting en tester ikke kan registrere seg for under vurderingen. Vibe-kodede innsendinger feiler konstant her, fordi utvikleren ofte aldri har opprettet en ekte innløserkonto selv; appen ble bare testet mot fiktive testdata som AIn genererte underveis. Uten en fungerende demokonto og en måte å kjøre en testtransaksjon på, blir appen avvist som ufullstendig, og hver nye innsending koster en ny vurderingsrunde.

Så hva er det som faktisk fungerer?

Den vanskelige delen var aldri koden. En AI-assistent kan produsere et fungerende betalingsgrensesnitt på en ettermiddag, men distribusjon i App Store er et hinderløp av rettigheter, lisensiering og retningslinjer som ligger helt utenfor det en ledetekst kan nå. Demoen fungerer, men infrastrukturen eksisterer ikke ennå.

For en butikkeier som selger fysiske varer, er den praktiske konklusjonen enklere: ikke still deg i den køen. Bedriften din trenger en fungerende kasse, ikke en egen oppføring i App Store – lisensiering, maskinvaresertifisering og administrasjonskostnadene ved app-vurdering gir bare mening for selskaper som har selve betalingsprogramvaren som sitt produkt. Kjør kassen på en POS-plattform som allerede har tatt disse kostnadene (Final er bygget nøyaktig slik – betalinger gjennom Final Pay med sertifisert terminalmaskinvare, uten at du må publisere en egen app), og bruk pengene du sparer på raskere betalingsflyt en raskere betalingsprosess og lavere reelle kortgebyrer.

Apples vurderingsprosess eksisterer av gode grunner – betalingsapper som feiler, skader ekte mennesker. Det er bare ikke en prosess de fleste butikkeiere noensinne trenger å gå gjennom, uansett hvem eller hva som har skrevet appen.