Stripe Checkout gebruikt WebMCP: je toolset moet meeveranderen

Door Enrico Clein · Gepubliceerd 25 september 2026 · 3 min lezen

Een agent kan de juiste tool kiezen en toch met verouderde invoer werken. Stripe laat met zijn Checkout-integratie zien waarom een toollijst geen vast menu hoort te zijn. Voor je eigen website vraagt dat om expliciete regels bij iedere overgang in de klantreis.

Wat Stripe heeft toegevoegd

In een technisch artikel van 22 september 2026 beschrijft Stripe zijn WebMCP-integratie voor Checkout. Het bedrijf stelt tools en parameters beschikbaar naargelang de actuele stap: submit_payment verschijnt bijvoorbeeld pas wanneer het formulier compleet en geldig is. De tools hergebruiken bestaande checkoutlogica; Stripe beschrijft zowel JavaScript-tools als declaratieve formuliertools.

De Stripe-documentatie noemt ondersteuning voor de volledige betaalpagina, het ingebedde formulier, Elements en de gehoste factuurpagina. Welke tools verschijnen, hangt af van de betaalinterface en sessiestatus. Het starten van een betaling wordt alleen aangeboden waar Stripe de verzendactie beheert. Dit is geen garantie dat iedere browseragent al deze varianten kan gebruiken.

Ontdek opnieuw na een relevante wijziging

Stripe waarschuwt ontwikkelaars om toolnamen, schema’s en beschikbaarheid niet vast in de agent te programmeren. Een andere betaalmethode kan andere invoervelden vereisen. Haal daarom na een actie die het betaalformulier of de beschikbare betaalmethoden verandert de actuele toolset opnieuw op. De documentatie noemt WebMCP nadrukkelijk experimenteel; ondersteuning en schema’s kunnen wijzigen.

Voor een productowner verandert daarmee de ontwerpvraag. Niet alleen: welke actie wil de klant uitvoeren? Ook: onder welke voorwaarden mag die actie nu worden aangeboden, en welke eerdere keuze maakt haar weer ongeldig? Leg dat vast naast de schermen en validatieregels van je bestaande proces.

Werk één terugstap uit, niet alleen de ideale route

Onderstaande tabel is ons eigen, fictieve ontwerp voor een offerteaanvraag. Het is geen beschrijving van Stripe en geen ingebouwde WebMCP-functie. De klant bekijkt eerst een berekende offerte en kan daarna de aanvraag versturen.

Ons advies: geef de offerte een versie en verbind de definitieve aanvraag aan precies die versie. Controleer op de server of zij nog actueel is en bij het juiste account hoort. Een oude toolverwijzing of een rechtstreeks verzoek mag die controle niet omzeilen. Het laten verdwijnen van een tool is hulp bij de bediening, geen vervanging voor autorisatie of validatie.

Maak hiervan een acceptatietest

Laat in een testomgeving een agent een offerte voor tien producten voorbereiden. Wijzig daarna als gebruiker het aantal naar twintig. Controleer of de zichtbare samenvatting, het invoerschema en de aangeboden vervolgstap dezelfde toestand beschrijven. Probeer ook bewust de oude aanvraagversie: die mag niet stilzwijgend een aanvraag voor het gewijzigde aantal vastleggen.

Dit is een voorgestelde test, geen door ons uitgevoerde proef. Noteer bij uitvoering de browser- en agentversie, de twee offertestanden, aangeboden tools en uiteindelijke serverstatus. Gebruik fictieve klantgegevens. Een test die alleen de eerste succesvolle aanvraag controleert, mist juist de terugstap waarin mens en agent elkaar kunnen inhalen.

Chrome adviseert om bij ontbrekende voorwaarden of een ongeldige toestand een herstelbare uitleg terug te geven. Meld in dit voorbeeld dus dat de offerte is gewijzigd en opnieuw bekeken moet worden. Maak er geen algemene technische fout van en start niet automatisch een nieuwe aanvraag.

De concrete opbrengst voor je team is een testbare overgangstabel: wanneer verschijnt een actie, wanneer verandert haar invoer en wanneer vervalt een eerder akkoord? Stripe levert een actuele implementatiecase; de betrouwbaarheid van jouw klantreis moet je zelf aantonen. Voor onbekende uitkomsten na versturen blijft daarnaast een afzonderlijk herstelpad nodig.