ACP (Agentic Commerce Protocol)

Wat de specificatie daadwerkelijk benoemt

ACP is het meest handelsspecifieke van de protocollen in deze ruimte, en de eenvoudigste manier om het te onthouden is als een lijst van objecten in plaats van als een filosofie. De revisie van april 2026 behandelt een productfeed, een afrekensessie, betalingsdelegatie, winkelwagen en authenticatie, plus een integratie-hook die een ACP-bewuste agent in staat stelt zijn afrekenmogelijkheid te adverteren via MCP tool discovery.

Elk object bestaat omdat een stap die een persoon in een browser uitvoert geen machine-equivalent heeft. Een persoon bladert door een catalogus; een agent heeft een feed nodig. Een persoon ziet een totaalbedrag verschijnen terwijl ze een adres typen; een agent heeft een sessie nodig die een bindend nummer retourneert. Een persoon typt een kaart in een formulier op uw domein; een agent heeft een gedefinieerde manier nodig om de betaling aan uw processor over te dragen zonder zelf de gegevens te bewaren.

De uitgevers zijn OpenAI en Stripe, en die combinatie is zichtbaar in de opzet van het document. Het is geschreven door een partij die een assistent-interface bezit en een partij die betalingsverwerking bezit, en het meeste wat het specificeert, is de grens tussen de twee.

Waar ACP zich bevindt ten opzichte van UCP, AP2 en MCP

De vier namen worden meestal gepresenteerd als een standaardenoorlog, wat verkopers tot de verkeerde conclusie leidt — dat de verstandige zet is om op een winnaar te wachten. Ze beantwoorden verschillende vragen en vullen elkaar grotendeels aan.

MCP, gepubliceerd door Anthropic, is het algemene mechanisme waarmee een agent leert dat een functionaliteit bestaat en hoe deze aan te roepen; het zegt niets over winkelwagens of geld. UCP, van Google en Shopify, behandelt cataloguslezingen en winkelwagenconstructie. ACP behandelt de uitvoering van het afrekenproces en betalingsdelegatie. AP2, geïnitieerd door Google en gedoneerd aan de FIDO Alliance in april 2026, behandelt het bewijzen dat een specifiek mens een specifieke betaling heeft geautoriseerd.

Sponsoring verklaart de dekking in elk geval. Google en Shopify hebben agents nodig die de catalogi van de wereld kunnen lezen, dus hun standaard specificeert ontdekking. OpenAI en Stripe hebben een aankoop nodig die ergens voltooid kan worden, dus die van hen specificeert afrekenen en betaling. Niemand heeft een specificatie geschreven voor een laag die ze niet al bezaten.

De enige overlap die het waard is om te weten, is de winkelwagengrens, waar UCP en ACP beide iets over te zeggen hebben. De vereiste aan de kant van de verkoper is hoe dan ook identiek — een catalogus met echte prijzen en echte beschikbaarheid — daarom is dat stuk werk het enige deel van de stack dat geen gok is op welke standaard de overhand krijgt.

Betalingsdelegatie is het werkelijk nieuwe onderdeel

Productfeeds zijn niet nieuw en afreken-endpoints zijn niet nieuw. Het element van ACP zonder eerder equivalent is de delegatie van betaling: de omgeving van de agent draagt de verwerking over aan de processor van de verkoper, in plaats van zelf kaartgegevens te bewaren of de merchant of record te worden.

Die regeling maakt het protocol überhaupt acceptabel voor verkopers. U behoudt de processorrelatie, de afwikkeling en het klantrecord. U behoudt ook de aansprakelijkheid, en dat is het deel dat het waard is om twee keer te lezen — een door een agent geïnitieerde aankoop en een door een mens geïnitieerde aankoop bereiken uw processor via dezelfde kanalen, terwijl de formaten voor bewijs van geschillen die vandaag bestaan, allemaal ervan uitgaan dat een persoon aanwezig was bij de transactie.

Die kloof is precies wat AP2 is geschreven om te dichten, en het wordt niet aangepakt op de ACP-laag. Een verkoper die nu door een agent geïnitieerde betalingen accepteert, accepteert deze zonder een standaardartefact dat vaststelt wat de kaarthouder heeft geautoriseerd of binnen welke limieten.

Wat ACP niet specificeert

Een specificatie lezen voor wat het weglaat, is meestal informatiever dan het lezen voor wat het bevat, en de weglatingen hier zijn groot genoeg om te veranderen wat de uitdrukking "ACP-ondersteuning" eerlijk kan betekenen.

Ze trekken ook de grens tussen het leveren van de vereisten en het implementeren van het protocol. Een machineleesbare catalogus, een scoped agent gateway en een set MCP-tools zijn zaken waarvan ACP aanneemt dat een verkoper die al heeft. Het hebben ervan is voorbereidend werk in plaats van conformiteit, en een platform dat de twee als dezelfde claim presenteert, overdrijft wat het doet.

Wat de specificatie volledig aan u overlaat:

• Vertrouwen. Niets erin beslist welke agents u moet bedienen, of onder welke voorwaarden. Dat is een beleid dat u zelf opstelt en handhaaft.
• Autorisatie en audit. Het definieert geen toestemmingsbereiken, geen idempotentievereiste en geen auditrecord. Een agent die een dubbelzinnig verzoek opnieuw probeert, is een gewone gebeurtenis, en niets in het protocol voorkomt dat dit twee bestellingen worden.
• De helft na de aankoop. Retouren, terugbetalingen, annuleringen, abonnementswijzigingen en ondersteuning vallen buiten de reikwijdte ervan, en dat is waar het grootste deel van de operationele kosten van een bestelling daadwerkelijk liggen.
• Adoptie. Een conforme implementatie verplicht geen enkele assistent om het te gebruiken. Welke interfaces wat lezen, in welke categorieën, is een commerciële kwestie die geen specificatie oplost.