De toezeggingsladder

Bewijsupdate · 22 september 2026

De toezeggingsladder: waar de waarheid van de ondernemer een toezegging wordt

Gestructureerde aanbetalingsvoorwaarden, technische protocolafspraken, endpointvalidatie en door de ondernemer bepaalde regels zijn verschillende bewijsniveaus. Deze update van augustus 2026 laat zien wat machineleesbaar is geworden - en wat nog altijd geen werkelijke toezegging van een lokale dienstverlener bewijst.

Update - juli-augustus 2026

Een protocol kan een toezegging beschrijven. Het systeem van de ondernemer moet haar nog steeds waarmaken.

Vier ontwikkelingen maken het midden van de ladder scherper.

1. Shopify publiceerde één begrensde aanbetalingsfunctie. In API-versie 2026-07 kan een geautoriseerde app DraftOrderInput.deposit instellen bij het maken of bijwerken van een conceptbestelling. Een Customer Account-integratie met de juiste scope kan de aanbetaling, amountDueNow en amountDueLater lezen. Shopify beperkt dit tot conceptbestellingen in Shopify Plus. Dit is bruikbaar bewijs dat een bedrijfssysteem kan structureren wat nu en later verschuldigd is; het is geen universeel aanbetalings-, reserverings- of commitmentprotocol voor lokale diensten.

1. Shopify verplaatste ook het handhavingspatroon weg van de kopersinterface. Voor bedrijfsregels verwijst Shopify ontwikkelaars van de verouderde hook useBuyerJourneyIntercept naar server-side Cart and Checkout Validation Functions die op alle checkoutoppervlakken gelden, waaronder express wallets en agentic checkout. Bestaande extensies blijven werken op huidige en eerdere versies; verwijdering volgt pas later. De architecturale les: klantzichtbare voorwaarden en server-side handhaving horen bij elkaar. Dit bewijst niet dat een specifieke ondernemer het patroon heeft geïmplementeerd.

1. UCP `v2026-08-25` breidde de woordenschat uit. De release voegt betaalvoorwaarden en -schema's toe, waaronder aanbetalingen en termijnen; momentopnamen van beleid; locatie- en fulfilmentcontext; versiebeheer van capabilities; wijzigingen in identiteit en toestemming; actions en leveranciersonafhankelijke 3DS2. De release bevat ook incompatibele schemawijzigingen. Deze velden kunnen meer van een transactie beschrijven, maar een protocolverklaring controleert niet zelfstandig actualiteit, voorraad, beschikbaarheid, juistheid van beleid, bevoegdheid van de ondernemer, fulfilment of productiegebruik. Zij creëert op zichzelf geen reserveringshold of annuleringsgarantie voor een lokale dienst.

1. Google en een externe telling laten zien waarom validatie los moet blijven van declaratie. Googles Merchant Center UCP-integratie is een beperkte Amerikaanse pilot voor deelnemende ondernemers en producten die in de VS worden verkocht. Ze biedt zelfconfiguratie, tests in sandbox- en productieomgevingen, endpointvalidatie en gereedheidsmonitoring; goedkeuring door Google en technische implementatie blijven voorwaarden. Los daarvan publiceerde UCP Checker een momentopname van openbare winkeldeclaraties. Die telling is een live teller die de uitgever elke 24 uur opnieuw crawlt, dus deze pagina herhaalt de cijfers van augustus niet langer alsof ze actueel zijn; de meting van september hieronder draagt een eigen tijdstempel en vervangt ze. Wat de telling van augustus liet zien, en de meting van september bevestigt, is de vorm en niet de omvang: declaraties aan de cataloguskant in vijf cijfers, declaraties aan de betaalkant in één cijfer. Dit zijn door de uitgever gemelde observaties van openbare manifesten, geen gecontroleerd marktaandeel, geen ondernemersadoptie en geen transactiebewijs.

De operatortest: vastleggen, tonen, handhaven, valideren en bewaren

Behandel commitment als vijf samenhangende controles:

1. Leg de voorwaarden vast in het systeem van de ondernemer. Registreer het nu en later verschuldigde bedrag, het betalingsschema, het geldende beleid, de locatie- en fulfilmentcontext en elke werkelijk bestaande hold- of annuleringsgrens. Leid geen hold af uit een aanbetalingsveld.
2. Toon de exacte voorwaarden aan de klant en de geautoriseerde integratie. Baken de toegang correct af. Een openbare capabilityverklaring en een geauthenticeerd bestelrecord zijn verschillende oppervlakken.
3. Handhaaf de bijbehorende regels server-side. Pas geschiktheid en checkoutbeleid buiten één kopersinterface toe, zodat wallets, menselijke checkout en agentic checkout geen verschillende regels krijgen.
4. Valideer declaratie en gedrag afzonderlijk. Controleer het profiel, de versies, endpoints en waargenomen antwoorden. Een geldig /.well-known/ucp-bestand is geen voltooide checkout.
5. Bewaar wat is geaccepteerd. Bewaar de voorwaarden, toestemming of bevestiging, bestelbewijzen en het annulerings- of restitutiebeleid die later nodig zijn om de transactie af te handelen. De openbare Visa-regels zijn één netwerkspecifiek voorbeeld van deze bewijsdiscipline; ze vormen geen gedeelde Shopify-UCP-implementatie.

Update - september 2026: de twee sporten die niet zijn bewogen

Wat een telling van declaraties een winkelier wel en niet kan vertellen

Een protocoldeclaratie is een ondernemer die in het openbaar, in een vorm die een machine kan lezen, verklaart dat een agent op een bepaalde manier met hem mag handelen. Het manifest is het bestand dat die verklaring bevat: voor het Universal Commerce Protocol staat het op /.well-known/ucp, op een vast adres op het eigen domein van de ondernemer, zoals robots.txt altijd op een vast adres heeft gestaan dat elke crawler weet op te vragen. Een winkelier publiceert het op dezelfde manier als een pagina met openingstijden - door een bestand neer te zetten waar iedereen het kan ophalen.

UCP Checker haalt die bestanden volgens een schema op en telt wat erin staat. Een bestand tellen is geen verkoop tellen. Volgens de gepubliceerde methodologie zijn de optionele functionele probes, die alleen draaien wanneer iemand handmatig een controle start, „bewust alleen-lezen en in frequentie beperkt — ze voeren geen checkout uit en schrijven geen status weg”, en volledige end-to-end winkelsimulaties door agents beschrijft UCP Checker als een apart product. De telling is dus een inventaris aan de aanbodkant van wat ondernemers over zichzelf hebben gedeclareerd. Het is geen adoptie, geen marktaandeel en geen bewijs dat er ooit ook maar één bestelling op is geplaatst.

De meting

[UCP Checker · 2026-09-22 20:58 UTC] 17.765 geverifieerde winkels op 21.900 gevolgde domeinen. 99,6% van de geverifieerde winkels declareert checkout, 90% winkelwagenbeheer en 60,3% orderbeheer. Twee andere declaratiecategorieën die dezelfde telling bijhoudt, springen eruit: Payment Token Exchange, met 8, en Embedded Checkout, met 1.

Lees de laatste twee cijfers tegen de rest. Duizenden winkels hebben de delen van de reis gedeclareerd die een agent tot aan de rand van een aankoop brengen. Slechts een handvol heeft de delen gedeclareerd waarmee de aankoop zelf binnen die reis zou kunnen plaatsvinden. Die kloof is geen afrondingseffect, en ze wordt niet kleiner. Sinds de telling van augustus zijn de declaraties voor winkelwagenbeheer met duizenden gegroeid, terwijl de betalingstokendeclaraties nog altijd op één cijfer staan; over de metingen van september die voor deze update zijn gedaan, hebben de tellingen voor Payment Token Exchange en Embedded Checkout helemaal niet bewogen.

Waarom juist de stilstaande sporten het afdrukken waard zijn

Elk groeiend getal op de pagina van de uitgever is de volgende ochtend verouderd, en precies daarom stempelt deze sectie het moment van meten. De twee die niet zijn bewogen, zijn precies de sporten waar de toezeggingsladder naar moet wijzen.

Een restaurantgroep kan nu al door een agent worden gevonden, die de menukaart leest en er een winkelwagen mee samenstelt. Fase één en fase twee vullen zich in het openbaar, en de telling is één openbare maat voor dat vullen. Niets daarvan beantwoordt de vraag van fase drie - kan deze aanbetaling worden geïnd, deze tafel worden vastgehouden, deze boeking binnen dit venster worden geannuleerd? - en de telling laat nu zien dat de sport van fase vier daaronder, waar binnen de reis van de agent echt geld zou bewegen, door bijna niemand wordt gedeclareerd. In dit kader is toezegbaar het woord voor de toestand waarin beide waar zijn: de ondernemer heeft een toezegging vastgelegd die hij kan nakomen, en er is een route waarlangs iemand ertegen kan betalen. Op basis van dit bewijs loopt het gedeclareerde aanbod ver voor op beide.

De eerlijke lezing is smal, en ze volstaat. Een declaratie is een ondernemer die zegt wat hij zal accepteren. Het is geen ondernemer die al iets heeft geaccepteerd. De afstand tussen die twee zinnen is de hele fase drie, en die blijft het eigen werk van de ondernemer.

Gerichte updates voor de bestaande tekst van fase drie

Begrensd toezeggingsobject

Een expliciet, geversioneerd record van wat wordt toegezegd: het bedrag dat nu en later verschuldigd is, elke echte hold met haar vervaldatum, het annuleringsvenster, het geldende beleid, de locatie- en fulfilmentcontext, de garantie en de grenzen daarvan. Een aanbetaling of betalingsschema is één veld in dat object; het bewijst geen hold, beschikbaarheid of fulfilment.

Acceptatie- en beleidsvoorwaarden

Voorwaarden moeten zichtbaar zijn voor de klant, beschikbaar zijn voor de geautoriseerde integratie en in het systeem van de ondernemer worden gehandhaafd, niet alleen in een kopersinterface. Bewaar de precieze beleidsversie en wat de klant heeft geaccepteerd, zodat terugbetalingen, annuleringen en geschillen kunnen worden afgehandeld op basis van door de ondernemer vastgelegd bewijs.

Bijgewerkt stappenplan voor ondernemers

Nu doen

• Houd gedeclareerde capability, geconfigureerd endpoint, waargenomen antwoord en voltooide productietransactie afzonderlijk in het bewijs.
• Leg aanbetalingen, betalingsschema's, annuleringsvoorwaarden, locatie- en fulfilmentcontext en elke echte reserveringshold vast als afzonderlijke velden. Gebruik het ene nooit als verkorte aanduiding voor het andere.
• Handhaaf geschiktheids- en checkoutregels server-side, toon exacte bedragen en voorwaarden en bewaar de bevestiging van de klant.

Monitoren

• Of UCP v2026-08-25 in productiesystemen van ondernemers wordt geïmplementeerd en niet alleen in templates wordt gedeclareerd.
• Of aanbetalingen en betalingsschema's overdraagbaar worden tussen platforms en veilig toegankelijk voor geautoriseerde agents.
• Of systemen voor lokale diensten echte beschikbaarheid, reserveringsholds, uitgevoerde annuleringen en fulfilmentgaranties toevoegen met bewijs van productiebetalingen.

Niet aannemen

• Neem niet aan dat aanbetalingen bij Shopify Plus-conceptbestellingen een universele boekings- of commitmentlaag voor lokale diensten zijn.
• Neem niet aan dat Googles beperkte Amerikaanse pilot algemeen beschikbaar is of dat endpointvalidatie een productietransactie bewijst.
• Neem niet aan dat een UCP-manifest, gereedheidsscore, identiteitsdeclaratie of betalingstokendeclaratie een geconfigureerde, geautoriseerde end-to-end-checkout bewijst.

Bewijsdiscipline

Waargenomen

Shopifys 2026-07-API's bieden een beschrijfbare aanbetaling voor Plus-conceptbestellingen en met de juiste scope leesbare bedragen voor nu en later. Shopify stuurt de handhaving van checkoutregels richting server-side validatie. UCP v2026-08-25 voegt voorwaarden, beleid, locaties, fulfilmentcontext, identiteit, toestemming, aanvullende authenticatieacties en versiebeheer toe, met expliciete incompatibele wijzigingen. Google documenteert een beperkte Amerikaanse Merchant Center-pilot met tools voor endpointvalidatie. UCP Checker publiceert een momentopname van declaraties, die elke 24 uur opnieuw wordt gecrawld, waarvan de tellingen aan de cataloguskant over opeenvolgende metingen zijn gestegen terwijl de tellingen voor Payment Token Exchange en Embedded Checkout op één cijfer zijn gebleven. Volgens de eigen gepubliceerde methodologie zijn de probes alleen-lezen en voeren ze geen checkout uit.

Afgeleid

Onze lezing is dat machineleesbare voorwaarden pas operationele betekenis krijgen wanneer de ondernemer ze vastlegt, de klant ze kan zien, regels server-side worden gehandhaafd, gedeclareerde endpoints zich gedragen zoals aangegeven en geaccepteerde voorwaarden worden bewaard. Dit patroon over meerdere bronnen is een architecturale gevolgtrekking. Shopify, UCP, Google, Visa en UCP Checker beweren geen gedeelde implementatie.

Te volgen

Of productiesystemen van ondernemers de UCP-specificaties van augustus implementeren; of platformspecifieke aanbetalingsvoorwaarden overdraagbaar worden; of geautoriseerde agents ze veilig kunnen gebruiken; en of systemen voor lokale diensten echte beschikbaarheids-, hold-, annulerings- en garantiesemantiek toevoegen met onafhankelijk verifieerbaar bewijs van productiebetalingen; en of de declaratietellingen voor Payment Token Exchange en Embedded Checkout ooit boven één cijfer uitkomen.

Wat deze update niet beweert

1. Zij beweert niet dat UCP v2026-08-25, de Shopify-API's of Googles pilot algemeen beschikbaar zijn voor ondernemers, landen, platforms of dienstcategorieën.
2. Zij beweert niet dat een aanbetaling een reserveringshold, beschikbaarheid van een dienst, annuleringsgarantie of fulfilment creëert.
3. Zij beweert niet dat een openbaar UCP-profiel of gevalideerd endpoint een productiebetaling heeft voltooid.
4. Zij beweert niet dat de incompatibele UCP-wijzigingen achterwaarts compatibel zijn zonder implementatiespecifieke migratie en tests.
5. Zij beweert niet dat Shopifys verouderde Buyer Journey Interception-API al is verwijderd.
6. Zij beweert niet dat de UCP Checker-telling gecontroleerd marktaandeel, ondernemersadoptie, omzet, ordervolume of end-to-end-aankoopbewijs is.
7. Zij behandelt de declaratietellingen voor Payment Token Exchange of Embedded Checkout in de gestempelde meting hierboven niet als productiebetalingscapaciteit, niet als geconfigureerde ondernemerssystemen en niet als bewijs dat er ooit een betaling is ontvangen.
8. Zij beweert niet dat Shopify, UCP, Google, Visa of UCP Checker één architectuur delen of elkaars velden implementeren.
9. Zij beweert niet dat Obenan een partnerschap, aanbeveling, certificering, pilot, bijzondere toegang of commerciële relatie met een genoemde partij heeft.
10. Zij beweert niet dat dit werk een Obenan-productimplementatie of huidige klantfunctie is.
11. Zij beweert geen ranking, aanbeveling, platformopname, voltooide transactie, omzet of ondernemersresultaat.
12. Zij presenteert de telling van UCP Checker niet als marktaandeel, adoptie, penetratie of een telling van voltooide aankopen; de telling telt declaraties in openbare manifesten, en de probes zijn alleen-lezen en voeren geen checkout uit.
13. Zij beweert niet dat enig cijfer in de gestempelde meting actueel is op het moment dat u deze pagina leest. De cijfers zijn wat de openbare telling op het gestempelde moment liet zien, en op geen ander moment.

Bronnen voor de begrensde update

1. UCP-release `v2026-08-25`
2. Shopify-changelog over aanbetalingen bij conceptbestellingen
3. Shopify Admin GraphQL `DraftOrderInput`
4. Shopify Customer Account `draftOrder`
5. Shopify-migratie naar server-side validatie
6. Google Merchant Center UCP-pilot
7. Augustustelling en methodologie van UCP Checker: https://ucpchecker.com/blog/state-of-agentic-commerce-august-2026 en https://ucpchecker.com/methodology
8. Openbare Visa-regels
9. Live declaratiestatistieken van UCP Checker, gelezen op het gestempelde moment hierboven.