Wat AI fout doet bij het ontwerpen van een checkout (en hoe je dit oplost)

AI doet één voorspelbaar ding fout bij het ontwerpen van een checkout: het ontwerpt voor de demo, niet voor de tienduizendste transactie. Vraag een AI-appbuilder om een checkout en je krijgt binnen enkele minuten iets overtuigends. Een overzichtelijk winkelwagentje, nette knoppen, een strak betaalscherm. De fouten zitten in alles wat een screenshot niet kan laten zien: hoe het proces omgaat met een terugbetaling, een deeltijdbetaling, een belastingregel of een rij klanten op zaterdagmiddag om twaalf uur.

De oplossing is niet betere prompting. Het is beslissen welke delen van de checkout de AI mag beheren, en welke delen het nooit mag improviseren. Dit is waar door AI gegenereerde checkouts daadwerkelijk vastlopen, en wat je daaraan kunt doen.

Waarom ziet een door AI ontworpen checkout er goed uit, maar faalt deze in de praktijk?

Twee redenen. Ten eerste leert AI checkout-ontwerp van bestaande checkouts, en bestaande checkouts zijn matig. Het Baymard Institute stelt het gemiddelde gedocumenteerde percentage afgebroken online winkelwagentjes op 70,22%¹, en stelt vast dat de gemiddelde Amerikaanse checkout 23,48 formulierelementen bevat, terwijl een ideaal proces er 12 tot 14 nodig heeft¹. Een model dat is getraind op het gemiddelde, reproduceert het gemiddelde, inclusief de fouten.

Ten tweede: de 'happy-path'-bias. Gegenereerde software wordt beoordeeld zoals een demo wordt beoordeeld: werkt het standaardscenario? Een checkout wordt beoordeeld zoals een kassa wordt beoordeeld: werkt elk scenario, elke keer weer, terwijl er een klant toekijkt? Dat zijn heel andere maatstaven, en het verschil daartussen blijft onzichtbaar totdat er echt geld doorheen stroomt.

Wat doet AI eigenlijk fout in een checkout?

Vijf fouten komen keer op keer terug. (Zie voor het dieperliggende infrastructuurtekort daarachter Kun je een POS bouwen met Lovable of Replit?. Deze lijst gaat over de checkout zelf.)

• Berekeningen. Gegenereerde code voert valuta-berekeningen routinematig uit in floating-point (decimale wiskunde die onvoorspelbaar afrondt), waardoor centen verschuiven bij kortingen, belastingen en deeltijdbetalingen. Het symptoom openbaart zich bij de dagsluiting: totalen die niet tot op de cent nauwkeurig aansluiten op je dagrapportage.

• Belastingen. AI hardcodeert één tarief. Echte btw of omzetbelasting is afhankelijk van het rechtsgebied, het type artikel, vrijstellingen en datums, en verandert zonder dat je code daarvan op de hoogte wordt gesteld. Een checkout die gokt naar belasting is geen checkout; het is een risico met een mooie interface.

• De 'unhappy paths'. Terugbetalingen, annuleringen, deeltijdbetalingen, handmatige prijsaanpassingen, een wegvallende verbinding tijdens een betaling. Demo's testen ze nooit; aan de toonbank komen ze dagelijks voor. De meeste door AI gegenereerde checkouts hebben ze simpelweg niet.

• Snelheid voor de kassier. AI kopieert e-commercepatronen die zijn gebouwd voor een consument die eenmalig afrekent. Een kassier doorloopt hetzelfde proces honderden keren per dienst, dus elke extra tik telt op tot extra wachttijd. Zelfs kleine keuzes veranderen de dynamiek aan de toonbank; waar de fooi-optie verschijnt is al een beslissing op zich.

• Betalingen. Een betaalknop is nog geen betaling. Om fysiek een kaartbetaling te accepteren, heb je een betalingsverwerker, PCI-compliance (de gegevensbeveiligingsregels van de creditcardindustrie) en gecertificeerde kaartlezers nodig. Niets daarvan kan worden gegenereerd met een prompt; het moet er al zijn. Wat betalingsinfrastructuur daadwerkelijk omvat is uitgebreider dan de meeste mensen verwachten.

Hoe los je een door AI ontworpen checkout op?

Splits de taak in tweeën. AI is oprecht goed in het ontwerpgedeelte: lay-out, volgorde van het proces, formulering en het vormgeven van het scherm rond hoe je winkel daadwerkelijk verkoopt. Laat dat aan de AI over. Het financiële gedeelte (berekeningen, belastingen, betalingsverwerking, het transactieregister) moet afkomstig zijn van een handelsinfrastructuur die deterministisch is (die elke keer hetzelfde, juiste antwoord geeft), niet van code die per prompt wordt bedacht.

"Prompt het gewoon om belastingen correct te verwerken" lost dit niet op, omdat je aan de buitenkant niet kunt zien of het heeft gewerkt. Een checkout can maandenlang een paar cent per transactie afwijken voordat iemand het merkt. De oplossing is dus structureel:

• Beperk in plaats van te prompten. Gebruik een platform waar totalen, belastingen en betaalmethoden zijn ingebouwd en de AI ze alleen kan rangschikken, niet opnieuw kan uitvinden.

• Test de 'unhappy paths' voor de lancering. Voer een terugbetaling, een annulering, een deeltijdbetaling en een annulering tijdens de betaling uit. Als een van deze ontbreekt, heb je een demo, geen checkout.

• Sluit de boeken aan op dag één. Vergelijk de totalen van je checkout met de gegevens van je betalingsverwerker na de eerste echte verkoopdag. Verschillen van enkele centen vallen direct op, of helemaal niet.

• Let op workarounds. Als het personeel in week één al omwegen om het proces heen verzint, is het ontwerp mislukt. Los het op voordat de workarounds het systeem worden.

Dus, wat doet AI fout bij het ontwerpen van een checkout?

Het krijgt het plaatje goed, maar de techniek erachter verkeerd: happy-path-processen, geïmproviseerde berekeningen, gegokte belastingen en geen oplossing voor terugbetalingen, deeltijdbetalingen of fysieke kaartbetalingen. Niets daarvan wordt opgelost door een betere prompt; het wordt opgelost door de AI bovenop een infrastructuur te plaatsen die het geld al beheert. De vuistregel: laat AI het proces ontwerpen, laat het nooit het geld improviseren.

Die splitsing is het idee achter op prompts gebaseerde builders zoals Build van Final, waarbij je de checkout beschrijft die je wilt en de onderliggende totalen, belastingen en Final Pay-transacties afkomstig zijn van een systeem dat altijd klopt. Om dit in de praktijk te zien, bouw je je eerste flow in ongeveer tien minuten, of zoom uit met AI voor bedrijven: wat het wel (en niet) kan doen.