Waarom met vibe-coding gemaakte betalings-apps worden geweigerd in de App Store
AI kan in een middag een afreken-app schrijven, maar Apple weigert betalings-apps vanwege de indiener, de manier waarop betalingen worden gerouteerd en machtigingen die geen enkele prompt kan genereren. Dit is waar met vibe-coding gemaakte apps sneuvelen tijdens de beoordeling.

Met vibe-coding gemaakte betalings-apps worden in de App Store vaker geweigerd dan bijna al het andere in de beoordelingswachtrij, en de redenen hebben meestal niets met de kwaliteit van de code te maken. Een met vibe-coding gemaakte app — een app die je hebt gebouwd door aan een AI-assistent te beschrijven wat je wilt en vervolgens te publiceren wat deze heeft geschreven — kan er identiek uitzien als professioneel werk. De beoordeling van Apple beoordeelt de code niet. Er wordt gecontroleerd wie de app heeft ingediend, welk betalingsmechanisme welk type goederen afhandelt, of hardwaremachtigingen afzonderlijk zijn goedgekeurd en of de beoordelaar een echte transactie kan voltooien. Dat zijn precies de dingen die een AI-assistent niet kan genereren.
Dit is de muur waar iedereen tegenaan loopt na het bouwen van een aangepaste point of sale met een AI-model: de code is er in een middag, maar om deze als een echte afreken-app op een iPhone te krijgen, is een nalevingsproces nodig, geen codeertaak.
Heeft je AI betalingen via het verkeerde systeem gerouteerd?
De meest voorkomende weigering is het gebruik van het verkeerde betalingsmechanisme voor de goederen die worden verkocht, en AI-assistenten zijn er ongewoon goed in om dit verkeerd te doen. De App Review Guidelines van Apple trekken een harde grens. Digitale inhoud en diensten die binnen de app worden geconsumeerd, moeten gebruikmaken van de in-app aankopen van Apple onder Richtlijn 3.1.1. Fysieke goederen en diensten in de echte wereld — een koffie, een knipbeurt, een verzonden bestelling — moeten onder Richtlijn 3.1.5(a) precies het tegenovergestelde doen: zij mogen absoluut geen gebruikmaken van in-app aankopen en vereisen een externe betalingsmethode.

Een codeermodel reproduceert het betalingspatroon dat dominant was in zijn trainingsdata — in-app aankoop-boilerplate uit abonnementshandleidingen, of een web-checkout-SDK uit e-commercevoorbeelden — zonder ooit te vragen wat je verkoopt. Vraag het om "een app die betalingen accepteert" en je krijgt een van de twee, gekozen op basis van statistieken in plaats van de regels van Apple. De regels verschuiven ook per regio: na de Epic-uitspraak van 2025 mogen apps in de Amerikaanse App Store doorlinken naar externe aankoopopties voor digitale goederen, maar die uitzondering geldt alleen in de Verenigde Staten. Een app die wereldwijd wordt gedistribueerd, moet elders nog steeds aan de strengere regel voldoen.
Mag je überhaupt wel een betalings-app indienen?
Apple verwacht dat apps die geldbeheer of financiële diensten afhandelen, worden ingediend door de instelling die deze diensten daadwerkelijk uitvoert, met de vereiste licenties in elke regio waar de app beschikbaar is — dat is Richtlijn 3.2.1. Een individuele bouwer die een door AI gegenereerde betalings-app publiceert, is geen gelicentieerde financiële instelling, en een bureau dat er een indient voor een klant is dat evenmin. De app aanbieden in een land waar de licentie voor geldtransacties niet bestaat, leidt tot dezelfde weigering met een andere poststempel.
De beoordelaars van Apple beoordelen niet of je nalevingsprogramma goed is; ze controleren of de juiste entiteit de app heeft ingediend en weigeren deze als dat niet het geval is. Geen enkele prompt lost dat op.
Waarom is tap-to-pay een eigen goedkeuringsproces?
Het accepteren van contactloze kaarten op een iPhone vereist de 'Tap to Pay on iPhone'-machtiging — een afzonderlijke aanvraag bij Apple, onafhankelijk van de app-beoordeling, verleend aan een juridische entiteit in plaats van aan een codebase. De ontwikkelingsmachtiging wordt meestal binnen een dag of twee goedgekeurd. De publicatiemachtiging gaat via het operationele team van Apple, duurt doorgaans één tot twee weken en vereist samenwerking met een ondersteunde betalingsdienstaanbieder. Een AI-assistent schrijft met plezier de tap-to-pay-code zonder dit te vermelden; dien je de app in voordat de machtiging is verleend, dan wordt de app geweigerd.

Kaartacceptatie in de winkel brengt ook vereisten met zich mee die niet van Apple zijn: gecertificeerde lezerhardware, EMV-regels en PCI-scope voor alles wat met kaartgegevens in aanraking komt. Niets daarvan rolt uit een model dat Swift schrijft.
Kan de beoordelaar daadwerkelijk een transactie voltooien?
Richtlijn 2.1, Volledigheid van de app, blokkeert stilletjes meer betalings-apps dan de betalingsregels zelf. Beoordelaars moeten de volledige app kunnen testen, inclusief de betalingsstroom. Een betalings-app vereist doorgaans een merchant-account, identiteitsverificatie en soms een bankrekening — zaken waarvoor een beoordelaar zich tijdens de beoordeling niet kan aanmelden. Met vibe-coding gemaakte inzendingen falen hier voortdurend, omdat de bouwer vaak zelf nooit een echt merchant-account heeft aangemaakt; de app is alleen getest met testgegevens die de AI erbij heeft gegenereerd. Zonder een werkend demo-account en een manier om een testtransactie uit te voeren, wordt de app als onvolledig geweigerd, en elke herindiening kost weer een beoordelingsronde.
Dus wat gaat er daadwerkelijk live?
Het moeilijke deel was nooit de code. Een AI-assistent kan in een middag een werkende afrekeninterface produceren, maar distributie in de App Store is een hindernisbaan van machtigingen, licenties en beoordelingsbeleid die volledig buiten het bereik van een prompt liggen. De demo werkt, maar de infrastructuur ontbreekt nog.
Voor een winkelier die fysieke goederen verkoopt, is de praktische conclusie eenvoudiger: sluit achteraan aan in de rij. Je bedrijf heeft een werkende kassa nodig, niet een eigen vermelding in de App Store — de licenties, hardwarecertificering en de rompslomp van de beoordeling zijn alleen zinvol voor bedrijven wiens product de betalingssoftware zelf is. Draai de kassa op een POS-platform dat die kosten al heeft gedekt (Final is precies zo gebouwd — betalingen via Final Pay met gecertificeerde terminalhardware, geen eigen app om te publiceren), en steek het geld van de beoordelingsrondes in zaken die omzet opleveren, zoals een snellere afrekenprocedure en lagere effectieve kaartkosten.
Het beoordelingsproces van Apple bestaat om goede redenen — geld-apps die falen, duperen echte mensen. Het is alleen geen proces waar de meeste winkeliers ooit doorheen hoeven, ongeacht wie of wat de app heeft geschreven.
Veelgestelde vragen
Wat is een vibe-coded betaalapp?
Een app die is gebouwd door aan een AI-codeerassistent te beschrijven wat u wilt en te lanceren wat deze genereert, in plaats van deze regel voor regel te programmeren. Deze aanpak werkt voor de UI en logica, maar kan geen rechten, licenties of naleving van de reviewrichtlijnen opleveren.
Wat is App Store-richtlijn 3.1.1?
Dit is de regel van Apple dat digitale inhoud en diensten die binnen een app worden verkocht, via het in-app-aankopsysteem van Apple moeten lopen. Dit geldt niet voor fysieke goederen of diensten in de echte wereld, die andere betaalmethoden moeten gebruiken.
Moeten apps die fysieke goederen verkopen gebruikmaken van in-app-aankopen van Apple?
Nee. Richtlijn 3.1.5(a) vereist het tegenovergestelde: betalingen voor fysieke goederen en diensten in de echte wereld moeten een andere methode gebruiken dan in-app-aankopen, zoals de SDK van een betalingsverwerker.
Hoe lang duurt de goedkeuring voor Tap to Pay op iPhone?
Het ontwikkelingsrecht wordt meestal binnen één tot twee werkdagen verleend. Het publicatierecht wordt beoordeeld door het operationele team van Apple en duurt doorgaans één tot twee weken, mits aan de vereisten is voldaan.
Kan een winkelier kaartbetalingen accepteren zonder een eigen app te publiceren?
Ja. De meeste winkeliers publiceren nooit een app — ze voeren hun checkout uit op een POS-platform waarvan de betalingsinfrastructuur en gecertificeerde kaartlezerhardware al in productie zijn, en configureren dit voor hun bedrijf.
Waarom slagen betaalapps niet voor de volledigheidscontrole van Apple?
Beoordelaars moeten een echte transactie kunnen voltooien. Als een app een merchant-account, bankverificatie of hardware vereist die de beoordelaar niet heeft, en er geen werkend demo-account wordt verstrekt, wordt deze afgewezen onder Richtlijn 2.1.
