Agentic commerce

Wat is agentic commerce?

Agentic commerce is kopen en verkopen waarbij een agent de aankoop doet in naam van een klant. Iemand zegt tegen zijn assistent: "bestel dezelfde vloerreiniger als vorige maand bij, maar enkel als hij nog onder de veertig euro zit". De assistent zoekt het product, controleert de prijs en plaatst de bestelling. Er komt een bestelling binnen en je spreekt de persoon die betaalt nooit.

Twee naburige artikels dekken wat errond zit. Het artikel over het agentic web gaat over je site en de machinebezoekers die erop aankomen. Generative engine optimisation gaat over vernoemd worden in een AI-antwoord. Dit artikel begint een stap later, waar er geld moet bewegen, en blijft bij de handel en de betaling.

Het meeste is nog pril. De specificaties bestaan echt, ze zijn gepubliceerd en meestal open source, de kaartnetwerken hebben programma's draaien, en de checkoutflows die vandaag live staan voor consumenten zijn bijna allemaal Amerikaans. Een Belgische handelaar kan vandaag elke specificatie lezen en toch vaststellen dat het betaalstuk een preview is.

Drie dingen moeten kloppen voor een agent kan kopen

De agent moet het product, de prijs en de beschikbaarheid zien zonder browsersessie van een mens. Die feiten moeten dus ophaalbaar zijn als tekst, via een feed of via een API. Een prijs die pas na een klik verschijnt, of beschikbaarheid getekend als een gekleurd icoontje, bestaat niet voor het ding dat het geld van je klant vasthoudt.

Jij moet kunnen vaststellen dat deze agent handelt voor een echte, identificeerbare klant die deze aankoop toestond. Daar zitten twee vragen in. Welke agent is dit, en is hij wie hij zegt te zijn. En in wiens naam handelt hij, waarvoor, tot welk bedrag. Een handtekening beantwoordt de eerste vraag, een mandaat de tweede. Gedelegeerde toegang voor agents behandelt die mandaten in het algemeen; hier bepalen ze of je de goederen verstuurt.

De betaling moet door regels die geschreven zijn voor een mens aan een kassa. In Europa is dat sterke klantauthenticatie onder PSD2: twee onafhankelijke factoren, in de praktijk een melding die de klant goedkeurt in zijn bankapp. Een agent kan die melding niet krijgen, en je wil ook geen systeem waarin hij dat wel kan.

Elk protocol hieronder is een poging tot een, twee of alle drie. Lees ze zo, en de verschillen worden duidelijker dan een vergelijkingstabel ze maakt.

De protocollen, en wat elk ervan vastlegt

Het Agentic Commerce Protocol (ACP), van OpenAI en Stripe op 29 september 2025 onder de Apache 2.0-licentie, dekt de checkout en de overdracht van de betaling. Een handelaar bouwt vijf REST-endpoints om een sessie aan te maken, bij te werken, af te ronden, te annuleren en op te vragen, rekent zelf btw en verzending, en publiceert webhooks over de bestelling. Je blijft merchant of record met je eigen betaalprovider. De gedelegeerde betaling is eenmalig en draagt een maximumbedrag, een munt, een vervaltijd en de handelaar waarvoor ze bedoeld is. Ze gaat naar je betaalprovider en niet naar jou.

Het Agent Payments Protocol (AP2), van Google op 16 september 2025, beantwoordt de toestemmingsvraag in plaats van de checkoutvraag. Het draagt ondertekende verifiable credentials, mandaten genoemd, die vastleggen wat de klant goedkeurde. De naamgeving schoof mee met de specificatie, van een intent mandate plus een cart mandate in de eerste versie naar checkout mandates en payment mandates vandaag, en het idee eronder bleef hetzelfde: een ondertekend spoor dat je naast de vraag van de agent kan leggen. Het standaardisatiewerk verhuisde naar de werkgroepen van de FIDO Alliance rond agentic authenticatie en betalingen.

Het Universal Commerce Protocol (UCP) is het breedste en het jongste. Google kondigde het aan op 11 januari 2026, samen ontwikkeld met Shopify, Etsy, Wayfair, Target en Walmart, en onderschreven door meer dan twintig andere bedrijven waaronder Adyen, Mastercard, Stripe, Visa en Zalando. Het legt winkelmandje, checkout, bestelling en identity linking over OAuth 2.0 vast, verplaatst betaalgegevens als ondoorzichtige tokens, en behandelt AP2 als optionele uitbreiding voor wie een bewijs wil van wat de klant goedkeurde.

De kaartnetwerken beantwoorden de identiteitsvraag aan je voordeur. Het Trusted Agent Protocol van Visa en Agent Pay van Mastercard laten een agent zijn verzoeken ondertekenen, zodat jouw server zijn publieke sleutel ophaalt uit een directory van het netwerk en de handtekening nakijkt. De versie van Visa draagt een vlag mee die zegt of een verzoek wil rondkijken of wil betalen. Eronder ligt Web Bot Auth, het ondertekeningsschema uit het artikel over het agentic web, hier gericht op een betaling.

Wat meestal uit de presentatie valt, is de adoptie. ACP ging van start met Etsy-verkopers in de Verenigde Staten. UCP-checkout ging live voor Amerikaanse winkels binnen de AI Mode van Google, met een wereldwijde uitbreiding die beloofd is maar geen datum heeft. De shared payment tokens van Stripe, het mechanisme dat een afgebakend kaartgegeven echt meedraagt, halen wel Europese landen waaronder België, maar onder previewvoorwaarden en met een previewversie van de API.

Wat de Europese betaalregels zeggen als een agent op de knop duwt

Geen enkele Europese toezichthouder heeft richtlijnen gepubliceerd die speciaal over agentic payments gaan. Wat er is, is het gewone regelboek plus advocaten die het lezen. Advocatenkantoor Osborne Clarke schreef in maart 2026 dat betaalmodellen met agents onder PSD2 en de authenticatienormen blijven vallen, zonder apart regime, en dat er drie vragen open blijven: wie de betaaldienst eigenlijk levert, wie de gelden van de klant controleert, en wat geldige toestemming is wanneer het werk aan een agent wordt doorgegeven.

Het mechanisme dat vandaag al bestaat, en waar aankopen door agents op steunen, is de merchant-initiated transaction. De documentatie van Stripe voor de EER zegt het onomwonden: betalingen op een bewaarde kaart waarbij de klant niet aanwezig is in de checkout kunnen tellen als merchant-initiated transaction, en die vallen technisch buiten de reikwijdte van sterke klantauthenticatie. Je authenticeert de kaart een keer, op het moment dat ze bewaard wordt, en je hebt de instemming van de klant nodig, een mandaat, om ze later te debiteren. En dan komt de zin die commercieel telt. Er komt geen challenge voor de klant en er is geen verschuiving van aansprakelijkheid. Of de aankoop van een agent wel als merchant-initiated telt, is een van de vragen waar niemand uitspraak over heeft gedaan.

De herziening die eraan komt, verandert die vorm niet. PSD3 en de Payment Services Regulation kregen op 27 november 2025 een voorlopig politiek akkoord, maar in september 2026 wachtten de teksten nog op publicatie in het Publicatieblad, en daarna duurt het meer dan een jaar voor de regels gelden. Zoals de afgesproken tekst er nu uitziet, blijft authenticatie twee onafhankelijke factoren, houden merchant-initiated transactions hun authenticatie bij het opzetten van het mandaat in plaats van bij elke betaling, en geldt authenticatie die een andere partij uitvoert als uitbesteding waarbij de betaaldienstverlener aansprakelijk blijft. Nergens staat het woord AI-agent.

Een agent die koopt op een bewaarde toestemming tegenover een mens die de betaling bevestigt

Vergelijk die twee op een dimensie: wie bewijst dat de aankoop gewenst was. Betaalt een mens, dan komt het bewijs samen met de betaling. De challenge valt binnen in zijn bankapp, hij keurt ze goed, en blijkt de betaling frauduleus, dan verschuift de aansprakelijkheid meestal naar de kaartuitgever.

Betaalt een agent op een bewaarde toestemming, dan is het bewijs eerder geleverd, een keer, toen de kaart bewaard werd en het mandaat afgesproken. Op het moment van de aankoop is er geen challenge en geen verschuiving van aansprakelijkheid, dus een betwiste afschrijving komt bij jou terecht. Het bewijsstuk van de klant is een mandaat van weken geleden, dat van jou is wat je noteerde over wat de agent vroeg en wat jij teruggaf. Daarom bestaan de mandaatformaten van AP2.

Een agent koopt bij een Belgische webshop, stap voor stap

Een webshop bij Antwerpen verkoopt schoonmaakproducten aan kleine bedrijven, met prijzen en voorraad als tekst, een productfeed en een betaalprovider die betalingen door agents ondersteunt. De assistent van een klant krijgt de opdracht om tien liter vloerreiniger bij te bestellen als die nog onder de veertig euro zit. Dit is wat er bij elke stap misgaat.

1. De catalogus lezen. De feed zegt 38 euro en de pagina zegt 42, want de feed wordt 's nachts opgebouwd en de prijs bewoog vanochtend. De agent rekent op het oude getal.

2. Zich bekendmaken. Hij ondertekent zijn verzoek, en jij kan die handtekening niet nakijken omdat niemand de sleuteldirectory van het netwerk aangesloten heeft. Zonder handtekening is hij gewoon weer een scraper voor je botbescherming.

3. Een checkoutsessie openen. Jij geeft de correcte lijnprijs terug, maar het mandaat van de klant was afgetopt op veertig euro en verzending plus btw duwen het totaal daarboven. Allebei correct, en toch geen verkoop.

4. Het betaalgegeven aanbieden. Het token hangt aan een handelaar, een bedrag en een vervaltijd, en het mandje is twintig minuten geleden samengesteld. Een vervallen token en een ingetrokken token worden allebei geweigerd, en jouw foutafhandeling moet zeggen welk van de twee het was.

5. De betaling versturen. De kaartuitgever vraagt toch authenticatie. De ACP-checkoutspecificatie heeft daar een foutcode voor, requires_3ds, en zegt er niet bij wat er dan moet gebeuren. Het werkbare antwoord is een link terug naar de mens, dus bouw dat pad eerst.

6. Bevestigen, en later klagen. De bevestiging vertrekt naar een adres dat de agent daarvoor aanmaakte, en zes weken later zegt de klant dat de agent de verkeerde concentratie bestelde. Jij hebt een mandaat, een bestelling en geen gesprek om naar te verwijzen.

Enkel stap vijf is een regel die je moet volgen. De rest zijn keuzes over je datakwaliteit, je foutafhandeling en wat je bijhoudt.

Waar moet je op letten bij agentic commerce

Een betwisting komt binnen zonder gesprek erachter. Geen surfgedrag dat je ziet, geen telefoon met je verkoopdienst, geen moment waarop de klant zelf op bevestigen klikte. Het gewone bewijs waar een retourdiscussie op steunt, is er niet, en een mandaat van weken geleden moet dat vervangen.

Vergelijken gebeurt op machinesnelheid. Een mens kijkt bij twee concurrenten, een agent kijkt er elke keer veertig na en merkt een prijswijziging binnen het uur. Hangt een stuk van je marge ervan af dat een klant niet gaat zoeken, dan haalt agentverkeer die marge weg.

Bestellingen van agents en promoties zijn een beslissing, geen standaardinstelling. Een welkomstkorting koopt een relatie, en een eerste bestelling die een assistent plaatst, maakt er misschien geen. Onthoudt die assistent de leverancier en bestelt hij zelf bij, dan zit die relatie in zijn geheugen en niet in je mailinglijst, en dan wegen kloppende voorraad en leverdata die je haalt commercieel zwaarder dan je nieuwsbrief.

Wat je nu doet, in volgorde

1. Maak je productdata machineleesbaar en vooral correct. Prijs met de btw-behandeling erbij, voorraad, levertermijn, minimale bestelhoeveelheid en retourtermijn, als tekst op de pagina en identiek in elke feed die je publiceert. Die laatste drie raken zelden in gestructureerde data, en het zijn net die waar een agent anders naar moet gissen.

2. Beslis bewust of agents bij jou mogen kopen. Rondkijken en kopen zijn aparte rechten, en het protocol van Visa draagt daar net een vlag voor mee. Beslis per productgroep en per orderbedrag, en zet het antwoord in je voorwaarden, want een klant van wie de agent aan de checkout geweigerd werd, komt vragen waarom.

3. Stel je platform en je betaalprovider twee vragen op papier. Welke agentprotocollen ondersteunen jullie vandaag in België, en wat gebeurt er met mijn aansprakelijkheid bij een betaling die een agent start. Op die tweede vraag komt een vaag antwoord, en dat is op zich ook informatie.

4. Beslis nu wat je bijhoudt als een agent bestelt. De referentie van het mandaat of het token, de prijs die je teruggaf, het exacte mandje, en het moment waarop de agent aanvaardde. Wie er op je site binnenkomt is een aparte vraag, die in het artikel over het agentic web staat. Dit is het commerciële spoor dat bepaalt wie een teruggestuurde pallet betaalt.

Dezelfde vraag langs je aankoopzijde

Een agent die je eigen voorraad bijbestelt, is ditzelfde verhaal van de andere kant bekeken, en daar botsen de meeste kleine bedrijven er eerst op, want jij hebt zowel de beslissing als het budget in handen. Dezelfde drie vragen draaien netjes om. Kan hij de prijzen van je leverancier lezen, of gokt hij op een oude offerte? Handelt hij onder een eigen identiteit met een bestedingslimiet en een einddatum, of gebruikt hij de login van iemand? En als er een factuur binnenkomt voor iets dat niemand wou, kan je dan tonen welke opdracht hij kreeg? Begin met een saaie categorie, zet er een plafond op, en lees een maand lang elke bestelling na.