Gemini 3.6 Flash kan in seconden een afrekenscherm ontwerpen. Wat moet er kloppen voordat er een echte betaling wordt verwerkt?

Snelheid was nooit het ontbrekende stukje. Voordat een door AI gegenereerde checkout een echte betaling kan verwerken, moeten vijf dingen kloppen: voorraad die standhoudt wanneer twee kassa's tegelijk verkopen, rapportages die aansluiten (overeenkomen met het geld dat daadwerkelijk is verschoven), belasting die past bij het rechtsgebied, PCI-compliant verwerking van betalingen en gecertificeerde hardware voor fysieke kaartbetalingen. Gemini 3.6 Flash maakt het eerste ontwerp van een afrekenscherm sneller en goedkoper dan ooit. Het verandert niets aan die andere vijf. Een Gemini 3.6 Flash POS-prototype is een echte voorsprong; een inzetbaar kassasysteem is een heel ander eindpunt.

Modelnamen, prijzen en benchmarks veranderen snel. De onderstaande details zijn nauwkeurig op het moment van publicatie; zie ze als een momentopname.

Wat heeft Gemini 3.6 Flash daadwerkelijk veranderd?

Het maakte snelle, goedkope codegeneratie nog goedkoper en nauwkeuriger. Google bracht Gemini 3.6 Flash uit op 21 juli 2026, samen met Gemini 3.5 Flash-Lite¹. Het kost $ 1,50 per miljoen inputtokens en $ 7,50 per miljoen outputtokens, gebruikt ongeveer 17 procent minder outputtokens dan zijn voorganger en laat een flinke sprong zien in codenauwkeurigheid met een score van 49 procent op de DeepSWE-benchmark vergeleken met 37 procent voor 3.5 Flash².

Voor een ondernemer die experimenteert met AI-builders vertaalt zich dat in iets normaals en eenduidigs: het ontwerpen van een afrekenscherm duurt nu seconden en kost een paar cent. Erop itereren kost eveneens centen. De knelkoppeling bij het bouwen van een maatwerk-POS is verschoven. Het gaat er niet langer om of het model de schermen kan genereren. Het gaat om alles waar die schermen op rusten.

Waarom is een afrekenscherm geen POS?

Omdat een afrekenscherm de uitvoer is en een POS de centrale bron van de werkelijkheid is (de enige plek waar je verkoopcijfers als de waarheid gelden). Het scherm is de zichtbare tien procent. Daaronder bevindt zich de status die correct moet blijven op elk kassa-station, bij elke terugbetaling en bij elke netwerkstoring, plus geldstromen die aan regels gebonden zijn, ongeacht of de code handgeschreven of gegenereerd is. We bespraken ditzelfde onderscheid toen GPT-5.6 werd gelanceerd, en dat geldt sindsdien voor elk snel model.

Tegenwerpingen zijn voor de hand liggend: deze modellen schrijven nu code van productiekwaliteit, dus waarom laten we Gemini 3.6 Flash niet ook de voorraad- en belastinglogica schrijven? Dat kan het. Het probleem is niet het schrijven van de code. Het probleem is bewijzen dat die code correct werkt onder omstandigheden die je nooit in een demo ziet, en opmerken wanneer dat in stilte niet het geval is. Een afrekenscherm dat verkeerd wordt weergegeven, valt binnen seconden op. Een grootboek dat uit balans raakt, wordt pas aan het einde van de maand opgemerkt door je boekhouder, en tot die tijd ziet elk rapport er prima uit.

Wat moet er kloppen voor de eerste echte betaling?

Vijf dingen, en geen van alle verschijnen ze in een voorbeeldvenster.

Voorraadbeheer dat bestand is tegen gelijktijdige transacties

Gelijktijdigheid (twee kassa's die op hetzelfde moment dezelfde voorraad aanspreken) is waar gegenereerde voorraadcode als eerste faalt. Twee kassa's verkopen het laatste exemplaar van een artikel in dezelfde seconde. Naïeve code controleert het aantal, ziet er één beschikbaar en laat beide verkopen doorgaan. Nu heb je iets verkocht wat je niet hebt, en de fout stapelt zich ongemerkt op tijdens elk druk uur. Een correct systeem serialiseert die schrijfopdrachten, zodat één verkoop wint en de andere een leeg schap ziet. Dat is infrastructuurgedrag, geen schermgedrag, en geen enkel voorbeeldvenster zal dat ooit laten zien.

Rapportages die aansluiten

Reconciliatie (het afstemmen van je rapporten met het geld dat daadwerkelijk is overgemaakt) gaat mis bij randgevallen: een terugbetaling na het sluiten van de sessie, een annulering na het tellen van de kassa, een gedeeltelijke terugbetaling op een kortingsregel, een betaling die opnieuw wordt geprobeerd na een netwerkonderbreking. Elk randgeval dat een gegenereerd rapport mist, is een klein gat tussen wat het rapport zegt en wat de bank heeft gestort. Ondernemers ontdekken deze gaten niet tijdens het testen. Ze ontdekken ze bij de belastingaangifte.

Belasting die past bij het rechtsgebied

Omzetbelasting stapelt zich op: een nationaal tarief bovenop een regionaal tarief, vrijstellingen per product en tarieven die veranderen op een datum die door een wetgever is vastgesteld in plaats van door jouw releaseschema. Het fout doen is geen bugticket, het is een aansprakelijkheid. Een echt systeem configureert belastingen één keer en past ze overal consistent toe, zoals belastinggroepen werken in de Merchant Hub.

Betalingsverwerking die voldoet aan PCI

PCI DSS (de beveiligingsstandaard van de betaalkaartindustrie) bestaat om te zorgen dat kaartgegevens alleen worden verwerkt door geauditeerde systemen. Gegenereerde code mag nooit een kaartnummer te zien krijgen. In de praktijk betekent dit dat betalingen via de gecertificeerde stack van een betaalprovider lopen, waarbij kaartgegevens worden getokeniseerd (vervangen door een plaatsvervangend token) voordat jouw software ook maar iets aanraakt. Dit is het minst onderhandelbare punt op de lijst en valt volledig buiten wat een model genereert.

Gecertificeerde hardware voor fysieke betalingen

Contactloze en chipbetalingen werken alleen op terminals die zijn gecertificeerd door de kaartnetwerken, en certificering wordt per apparaat behaald via laboratoriumtests. Dit kan niet worden gegenereerd, via een prompt worden gemaakt of achteraf worden gecorrigeerd. Als je klanten fysiek betalen, moet er een gecertificeerde terminal zitten tussen hun kaart en jouw code.

Waar helpt een snel model daadwerkelijk bij?

Precies waar deze release de nadruk op legde: beschrijven, ontwerpen en itereren. Een goedkoop, snel model is het juiste hulpmiddel om schermen en stroomlogica vorm te geven, voor de lunch vijf lay-outs uit te proberen en een checkout te verfijnen totdat deze aansluit op de dagelijkse praktijk aan je kassa. De aanpak die werkt, is het model dat te laten doen bovenop een handelsinfrastructuur die het voorraadbeheer, de reconciliatie, de belastingen en de betalingen al regelt.

Dat is hoe Build van Final met modellen omgaat: je kunt Gemini of een willekeurige MCP-client verbinden en je afrekenproces laten bouwen met een live voorbeeld, terwijl Final Pay betalingen op de achtergrond afwikkelt via een betaalprovider en gecertificeerde terminalhardware. Zie voor een stappenplan hoe je bouwt met Gemini 3.6 Flash of hoe de drie grote modellen zich verhouden bij POS-ontwikkeling.

Dus, wat moet er kloppen voordat Gemini 3.6 Flash een echte betaling verwerkt?

Voorraadbeheer bij gelijktijdige transacties, rapportages die aansluiten, belasting die past bij het rechtsgebied, PCI-compliant verwerking van betalingen en gecertificeerde hardware. Gemini 3.6 Flash heeft het afrekenscherm zojuist het goedkoopste onderdeel van het project gemaakt, maar heeft niets van die lijst aangeraakt. Vuistregel: als een fout op je bankrekening te zien zou zijn in plaats van op je scherm, laat gegenereerde code hier dan niet alleen verantwoordelijk voor zijn. Ontwerp met het snelste model dat je kunt krijgen en uitrol vervolgens op infrastructuur die is gebouwd om geauditeerd te worden. Als je die opsplitsing vandaag wilt proberen, aan de slag met Build.