Checkout agentique

TL;DR — Le checkout agentique est la partie « achetez à ma place » du shopping par IA. Quand un assistant trouve un produit et termine l’achat, cette dernière étape de transaction est le checkout agentique. Dans le flux de paiement délégué d’OpenAI, l’agent utilise un jeton limité plutôt qu’un numéro de carte brut et s’arrête pour rendre la main à un humain en cas de connexion ou de vérification supplémentaire. C’est une pièce des protocoles ACP et UCP, pas un objet autonome.

Qu’est-ce que le checkout agentique ?

La plus grande partie du « shopping IA » relève de la découverte : vous demandez à un assistant de trouver quelque chose, il lit les flux produits des marchands et propose des options. Le checkout agentique vient ensuite : l’agent crée réellement la commande, choisit la livraison, calcule les taxes et les frais, transmet le paiement et finalise l’achat.

Le mot important est étape. Le checkout agentique n’est ni un produit ni une entreprise distincte. C’est la capacité de finaliser une transaction intégrée aux deux grands standards du commerce par agents : l’Agentic Commerce Protocol (ACP) d’OpenAI et Stripe, et l’Universal Commerce Protocol (UCP) de Google et Shopify. Les articles voisins détaillent les protocoles ; cette page se concentre sur les mécanismes du checkout.

Trois idées souvent fausses

• « L’IA achète sans aucune intervention humaine. » Pas vraiment. Les deux protocoles prévoient un arrêt pour demander une connexion, une vérification de carte ou une confirmation. Un checkout totalement sans intervention n’est pas la forme des spécifications.
• « L’IA voit ma carte bancaire. » Non. Le paiement passe par un jeton limité, attaché à un marchand, un montant et une fenêtre donnés, utilisable une seule fois. Le numéro de carte brut ne parvient jamais à l’agent.
• « C’est déjà normal : la plupart des boutiques le proposent. » Non plus. À mi-2026, l’adoption reste précoce : environ une douzaine de boutiques Shopify avaient activé le checkout ChatGPT avant le recul d’OpenAI sur la version entièrement intégrée au chat en mars 2026.

Qui est responsable en cas de problème ?

La boutique auprès de laquelle vous avez acheté reste la boutique : c’est le marchand de référence (merchant of record). Elle gère la commande, les remboursements et les contestations comme pour un achat en ligne classique. La vraie difficulté, encore non résolue, est la contestation d’un débit dont l’« acheteur » était un agent IA. La section Avancé y revient.

Vous voulez la machine d’état, les limites des jetons de paiement, les points d’intervention humaine et les tests à réaliser avant l’activation ? Passez à Avancé.

TL;DR — Le checkout agentique est la capacité transactionnelle du commerce par agents : créer, mettre à jour, terminer ou annuler une session, déléguer le paiement et confirmer la commande. C’est un composant d’ACP et d’UCP, pas un protocole autonome. Sa colonne vertébrale technique est une machine d’état : ACP passe de not_ready_for_payment à ready_for_payment, puis à requires_escalation ou authentication_required si nécessaire, avant completed, en miroir de incomplete → requires_escalation → ready_for_complete dans UCP. Les états d’escalade sont le point d’intervention humaine. Les paiements délégués utilisent des jetons limités au marchand, au montant, à la durée et à un seul usage. Les webhooks de commande HMAC signés contiennent l’objet complet. Le marchand reste responsable du règlement, des remboursements et des litiges ; la preuve nécessaire pour un litige impliquant un acheteur-agent reste ouverte. Testez l’idempotence, la signature des webhooks et toutes les voies d’escalade avant l’activation.

Périmètre : l’étape transactionnelle, pas tout le protocole

Le checkout agentique est une capacité. Dans ACP, c’est le bloc Agentic Checkout, l’un des cinq avec Product Feed, Delegate Payment, Delegate Authentication et Orders/Webhooks. Dans UCP, c’est la capacité de checkout au sein d’une spécification plus large négociée par capacités. Les articles ACP et UCP couvrent le contexte voisin — qualité du flux, profil /.well-known/ucp et implications du virage de mars 2026. Ici, l’objectif est de terminer la transaction : cycle de session, délégation du paiement, intervention humaine, confirmation de commande et responsabilité.

Un point à reprendre de l’article ACP sans le redémontrer : les agents transactent avec des flux et des API, pas avec votre HTML exploré. On optimise donc la fiabilité du checkout, pas le texte des pages.

La machine d’état de la session de checkout

Le point le plus important, souvent oublié, est qu’un checkout est une session avec un statut et que ce statut avance dans une machine définie.

La référence Checkout d’ACP liste les statuts incomplete, not_ready_for_payment, requires_escalation, authentication_required, ready_for_payment, pending_approval, complete_in_progress, completed, canceled, in_progress et expired. Le chemin heureux est court : not_ready_for_payment → ready_for_payment → in_progress → completed, avec canceled comme autre état terminal. Ajouter une option de livraison obligatoire fait passer la session de not_ready_for_payment à ready_for_payment ; un paiement échoué peut revenir à ready_for_payment pour une nouvelle tentative.

Les états intéressants sont ceux qui sortent du chemin heureux :

• requires_escalation / authentication_required — l’agent ne peut pas continuer seul ; une personne ou une vérification supplémentaire est nécessaire.
• pending_approval — une approbation est attendue, par exemple pour un bon de commande B2B.
• expired — la session a expiré (CheckoutSession contient expires_at).

UCP suit une conception sous-jacente comparable : incomplete → requires_escalation → ready_for_complete, avec un continue_url qui rend la main à l’acheteur. Deux protocoles, un même schéma : un checkout ne peut pas toujours se terminer sans demander quelque chose à un humain. Ce n’est pas une limitation ajoutée après coup, mais la forme centrale du design.

Un point pratique pour toute intégration ACP : une requête mal formée renvoie un objet d’erreur au niveau HTTP (type égal à invalid_request, request_not_idempotent, processing_error ou service_unavailable). En revanche, un problème de logique métier dans une session valide revient dans un objet MessageError du tableau messages[], pas comme erreur HTTP. Il faut gérer les deux, car ils sont faciles à confondre au début d’une intégration.

Comment fonctionne la délégation du paiement ?

Le but de la couche de délégation est que les données brutes de carte n’atteignent jamais l’agent. Au lieu de transmettre un numéro de carte, les informations de paiement sont transformées en jeton limité.

Selon la spécification de paiement délégué d’OpenAI, la charge utile est envoyée directement au PSP ou au coffre du marchand, qui renvoie un jeton de paiement limité au paiement délégué et situé hors du périmètre PCI. Ce jeton est borné selon quatre axes :

• reason — actuellement "one_time" : usage unique.
• max_amount — plafonne le débit au total du checkout ; le jeton ne peut pas surfacturer.
• expires_at (RFC 3339) — le jeton possède une expiration ferme.
• merchant_id + checkout_session_id — il est attaché à un marchand et à une session.

Un jeton délégué est donc lié au marchand, plafonné par le montant, limité dans le temps et à usage unique. C’est ce mécanisme qui permet à l’agent de « dépenser » sans lui confier un identifiant de carte réutilisable. Côté ACP, le Shared Payment Token de Stripe est présenté comme la première implémentation compatible ; d’autres PSP devraient suivre. UCP sépare de façon comparable les instruments de paiement et leurs handlers.

Le périmètre PCI est une vraie décision. La spécification d’OpenAI précise qu’une intégration directe traite les données du titulaire et peut modifier le périmètre PCI ; l’intégration directe requiert le niveau PCI DSS 1. Pour la plupart des marchands, la voie tokenisée — jetons réseau ou PSP qui gère la délégation — maintient les données de carte hors de l’environnement. Le choix entre « traiter directement les données » et « laisser le PSP tokeniser » est la première décision d’architecture ; l’onglet Décision l’examine.

Où un humain doit-il encore intervenir ?

« Le client autorise toujours l’achat » est vrai mais vague. Les déclencheurs au niveau du protocole sont précis ; les nommer permet de concevoir la remise de contrôle plutôt que d’aboutir à une impasse :

• 3-D Secure / step-up. ACP le modélise avec InterventionCapabilities (types comme 3ds et address_verification), un niveau enforcement (always / conditional / optional) et un display_context (native / webview / modal / redirect). Le résultat revient comme AuthenticationResult avec des valeurs telles que authenticated, denied, rejected, abandoned, canceled ou not_supported.
• États requires_escalation / authentication_required. Ils indiquent qu’une personne ou un contrôle supplémentaire est nécessaire avant de continuer.
• B2B approval_required. L’objet PaymentData transporte purchase_order_number, payment_terms, due_date et approval_required : le checkout agentique ne concerne pas seulement le DTC.
• Remise UCP par continue_url. L’état requires_escalation expose une URL que l’acheteur termine lui-même pour une connexion, une confirmation ou un contrôle d’âge. Même point d’arrêt, protocole différent.

La leçon est simple : une transaction qui escalade proprement vaut mieux qu’une transaction qui se termine silencieusement. Faites de ces parcours des flux de premier ordre, pas des cas d’erreur.

La confirmation de commande est poussée, pas interrogée

Après l’achat, la plateforme de l’agent ne reste pas à interroger l’API de commande. Le marchand envoie des webhooks signés.

Selon la référence des webhooks ACP, le marchand publie des événements afin que la plateforme reste alignée sur la vérité d’exécution. Deux types les portent : order_create pour une nouvelle commande et order_update pour les changements d’état. Les statuts incluent created, manual_review, confirmed, canceled, shipped et fulfilled. Trois détails sont essentiels :

• Les requêtes doivent être signées par HMAC dans l’en-tête Merchant-Signature. Une signature absente ou incorrecte reçoit 401.
• Le champ data doit contenir l’objet Order complet, pas des deltas. Envoyez l’état entier à chaque fois.
• Codes à gérer : 200 pour le succès, 401 pour une signature invalide et 429 en cas de limitation de débit.

La réponse à « comment la plateforme sait-elle que la commande est passée ? » est concrète : vous le lui dites avec un POST signé contenant l’objet complet, puis vous gérez la contre-pression 429 de la plateforme.

Fraude, litiges et responsabilité : ce qui est établi et ce qui ne l’est pas

C’est la partie où il faut être le plus honnête : distinguer clairement le « réglé » de l’« ouvert ».

Établi : le marchand de référence. La spécification de paiement d’OpenAI indique qu’OpenAI n’est pas le marchand de référence ; dans ACP, les marchands apportent leur propre PSP et le règlement, les remboursements, les litiges et la conformité restent chez le marchand et son PSP. Arjun Bhargava de Rye le confirme indépendamment : les deux protocoles laissent le marchand responsable de l’exécution, des litiges et des contestations.

Non établi : la preuve nécessaire pour un litige. Le marchand de référence indique qui assume normalement le litige, pas comment le gagner lorsque le « client » a été médié par un agent IA. La défense traditionnelle s’appuie sur des traces produites par un humain — IP, appareil, navigation, clic sur « acheter ». Les journaux d’autorisation produits par un agent sont d’une autre nature et les règles des réseaux de cartes n’ont pas été écrites pour eux. Les spécialistes de Chargeflow décrivent une nouvelle couche de fraude et de confusion que les systèmes hérités interprètent mal ; les réponses propres n’existent pas encore.

Les cadres émergents ne sont pas terminés. Le Trusted Agent Protocol de Visa est décrit comme un cadre permettant de vérifier en temps réel l’identité et l’intention d’un agent. L’Agent Pay de Mastercard, annoncé en avril 2025, utilise des « Agentic Tokens ». Des articles tiers suggèrent une responsabilité proche des transactions tokenisées ; considérez cette allocation comme rapportée, non confirmée, tant que la documentation Mastercard ne l’établit pas. La garantie zéro responsabilité de Visa protège les titulaires contre les débits non autorisés, mais ne résout pas la question du litige côté marchand.

Ce que les marchands doivent implémenter et tester

Les conseils stratégiques — flux propres, programmes de fidélité — ne suffisent pas. Voici la couche opérationnelle à construire et à vérifier :

• Décidez votre posture PCI. Voie tokenisée ou réseau contre traitement direct des données de carte (niveau 1). La plupart des marchands veulent laisser le PSP détenir la délégation.
• Rendez les nouvelles tentatives idempotentes. ACP prévoit request_not_idempotent pour une raison. Un agent ou un réseau instable réessaiera un appel de création ou de finalisation ; envoyez une clé d’idempotence et rendez les appels répétés sûrs pour éviter double débit ou double commande.
• Vérifiez les signatures de webhook. Contrôlez le HMAC Merchant-Signature, rejetez les incohérences et renvoyez correctement 200 ou 429 sous charge.
• Simulez l’escalade dans le bac à sable. Forcez requires_escalation / authentication_required, exécutez un step-up 3DS et testez denied / rejected / abandoned, pas seulement authenticated.
• Réconciliez les prix du flux et du checkout. Une divergence de prix détruit rapidement la confiance ; elle est particulièrement visible au moment de payer.
• Attribuez les commandes issues d’agents. Un checkout terminé peut n’avoir aucune session GA4. Suivez-le au niveau commande/OMS, sans attendre une visite du site.

Les onglets SOP de test et Aide-mémoire transforment ces points en contrôle concret.

Situation à mi-2026

Appuyez-vous sur la réalité de l’adoption, pas sur un argumentaire. Le président de Shopify a indiqué qu’environ une douzaine de marchands utilisaient activement des outils de checkout IA — un volume négligeable face à la base Shopify — et OpenAI a ramené la version entièrement dans le chat vers une découverte suivie d’une redirection en mars 2026, après des difficultés d’intégration, de précision et de paniers multi-articles. La normalisation en temps réel de catalogues contenant des dizaines de millions de références reste un problème de longue haleine, et les clients font encore confiance aux parcours qu’ils connaissent.

Cela ne signifie pas que le checkout agentique est fictif. La capacité du protocole — créer, mettre à jour et terminer une session avec paiement délégué et webhooks signés — est réelle et spécifiée. Elle n’est simplement pas encore normale, et la dernière étape peut se fermer dans le chat ou sur votre site selon une implémentation qui a déjà changé une fois.

Résumé par IA

Voici la synthèse de la version Avancée :

• Le checkout agentique est l’étape transactionnelle du commerce par agents : l’agent crée, met à jour, termine ou annule une session au nom du client. C’est un composant d’ACP et d’UCP, pas un protocole autonome.
• C’est une machine d’état. ACP suit not_ready_for_payment → ready_for_payment → (requires_escalation / authentication_required) → completed, avec canceled, expired et pending_approval hors du chemin heureux. UCP suit une forme incomplete → requires_escalation → ready_for_complete.
• Les états d’escalade sont le point humain : connexion, step-up 3DS, contrôle d’adresse, approval_required B2B et continue_url UCP. Un checkout sans aucun humain n’est pas la forme des spécifications.
• Le paiement utilise des jetons limités : liés à merchant_id et checkout_session_id, plafonnés par max_amount, expirant via expires_at et à usage unique avec reason: one_time. L’agent ne reçoit jamais une carte brute. Le traitement direct des données touche le périmètre PCI ; la voie PSP/tokenisée est généralement préférable.
• La confirmation est poussée : webhooks HMAC signés par Merchant-Signature, contenant l’objet complet via order_create / order_update, avec gestion de 200, 401 et 429.
• Responsabilité : le marchand reste marchand de référence pour règlement, remboursements et litiges, selon la spécification OpenAI ; la preuve à fournir lorsqu’un agent a acheté reste ouverte à mi-2026. Visa TAP et Mastercard Agent Pay sont des cadres émergents.
• À tester : nouvelles tentatives idempotentes (request_not_idempotent), signatures de webhook, escalade/3DS, parité prix-flux/checkout et attribution au niveau commande sans session GA4.
• Adoption précoce : environ une douzaine de marchands Shopify actifs avant le virage de mars 2026 vers découverte et redirection.

Documentation officielle

Documentation de première source pour les mécanismes du checkout.

ACP — checkout, cycle de vie et webhooks

• Référence API ACP Checkout — endpoints de session, statuts, champs CheckoutSession, objets d’erreur et MessageError, RiskSignals, AuthenticationResult et InterventionCapabilities.
• Cycle de vie et concepts ACP — transitions d’état, notamment ready_for_payment, et nouvelle tentative après paiement échoué.
• Webhooks de commande ACP — order_create/order_update, HMAC Merchant-Signature, objets complets et codes de réponse.
• Spécification ACP sur GitHub — OpenAPI, schéma JSON et versions datées.

OpenAI / Stripe — délégation de paiement

• Spécification de paiement délégué OpenAI — jeton limité, objet d’autorisation (max_amount, expires_at, merchant_id, checkout_session_id, reason), périmètre PCI et marchand de référence.
• Documentation Commerce OpenAI — vue d’ensemble de l’intégration marchand.
• Stripe — commerce agentique (ACP) — Shared Payment Token, première implémentation compatible.
• Stripe — spécification du protocole ACP — construction des endpoints de checkout.

UCP (machine de checkout parallèle)

• Guide UCP de Google for Developers — marchand de référence et critères d’éligibilité côté Google/Shopify.

Plateforme et réseau de paiement

• Shopify — exigences des vitrines agentiques — conditions supplémentaires et statut d’accès anticipé à Google AI Mode/Gemini au moment de la recherche.
• Visa — commerce agentique : menaces et risques — cadre Trusted Agent Protocol.

Citations de la source

Déclarations attribuées sur le fonctionnement du checkout agentique et ses questions ouvertes. Les liens profonds mènent au passage cité lorsqu’un ancrage de source est disponible.

ACP / OpenAI — la spécification

• “Merchant maintains full control over inventory, pricing, tax calculations, and payment processing.” (traduction) « Le marchand conserve le contrôle complet de l’inventaire, des prix, des taxes et du traitement du paiement. » — Référence API ACP Checkout. Lien vers la citation
• L’énumération de statuts du checkout, mot pour mot : “incomplete not_ready_for_payment requires_escalation authentication_required ready_for_payment pending_approval complete_in_progress completed canceled in_progress expired.” (traduction) « Les statuts couvrent l’incomplétude, la préparation du paiement, l’escalade, l’authentification, l’approbation, le traitement, la finalisation, l’annulation et l’expiration. » — Référence API ACP Checkout. Lien vers la citation
• “OpenAI is not the merchant of record.” (traduction) « OpenAI n’est pas le marchand de référence. » Dans ACP, les marchands apportent leur PSP ; règlement, remboursements, litiges et conformité restent chez eux et leur PSP. — Spécification de paiement délégué OpenAI. Lien vers la citation
• Pour le jeton : le PSP ou le coffre renvoie un “payment token scoped to the delegated payment” (traduction) « jeton de paiement limité au paiement délégué », hors périmètre PCI. — Spécification de paiement délégué OpenAI. Lien vers la citation

Voix du secteur — la question de la responsabilité

• “Agentic commerce brings efficiency, but also a new layer of fraud and confusion that legacy systems cannot interpret.” (traduction) « Le commerce agentique apporte de l’efficacité, mais aussi une couche de fraude et de confusion que les systèmes hérités ne savent pas interpréter. » — Ben Herut, spécialiste fraude et litiges, Chargeflow. Lire l’analyse
• Sur le caractère établi des règles, l’analyse Chargeflow conclut : “there are no clean answers yet” (traduction) « il n’existe pas encore de réponses nettes » ; réseaux, émetteurs et plateformes travaillent encore sur ces questions. Lire l’analyse
• “Both protocols keep the merchant as the merchant of record — responsible for fulfillment, chargebacks, and disputes.” (traduction) « Les deux protocoles gardent le marchand comme marchand de référence, responsable de l’exécution, des litiges et des contestations. » — Arjun Bhargava, cofondateur et directeur général de Rye. Lire l’analyse

Réseaux de paiement — cadres émergents

• Selon Visa, le Trusted Agent Protocol est “a standards-based framework enabling merchants to verify agent identity and intent in real time, preventing impersonation without degrading user experience.” (traduction) « un cadre fondé sur des standards qui permet aux marchands de vérifier en temps réel l’identité et l’intention d’un agent, en empêchant l’usurpation sans dégrader l’expérience. » — Visa, commerce agentique : menaces et risques. Lien vers la citation

Réalité de l’adoption

• Sur le retard du checkout totalement autonome : “Real-time catalog normalization across tens of millions of SKUs is a decade-scale problem Google already solved with Merchant Center, and consumers still default to checkout flows they trust—Apple Pay, Google Wallet, and Amazon one-click.” (traduction) « Normaliser en temps réel des catalogues de dizaines de millions de références est un problème à l’échelle d’une décennie ; les consommateurs reviennent encore aux parcours qu’ils connaissent. » — Leigh McKenzie, Semrush, par l’intermédiaire de Search Engine Land. Lire l’analyse

Quelle voie d’intégration du paiement choisir ?

La première décision d’architecture est de savoir comment déléguer le paiement : elle détermine directement votre périmètre PCI et la quantité de code à construire. Suivez l’arbre :

Parcours de test avant lancement

Exécutez ce parcours en bac à sable avant d’activer le checkout agentique en production. C’est la couche opérationnelle que les conseils stratégiques sur les flux propres oublient :

1. Créer une session et suivre le chemin heureux. Faites POST /checkout_sessions, vérifiez le 201 et l’état not_ready_for_payment ou incomplete, puis ajoutez une option de livraison et contrôlez le passage à ready_for_payment.
2. Vérifier les totaux faisant autorité. Comparez totals[] (sous-total, taxe, livraison, remises, total) au calcul du backend et au prix du flux. Une divergence de prix détruit la confiance.
3. Finaliser la session. Appelez POST /checkout_sessions/{id}/complete, vérifiez le paiement, la création de la commande et l’état completed.
4. Annuler une session. Appelez POST /checkout_sessions/{id}/cancel et vérifiez que le stock réservé est libéré.
5. Forcer les escalades. Simulez requires_escalation / authentication_required, faites un step-up 3DS et testez AuthenticationResult avec denied, rejected, abandoned, canceled et not_supported, pas seulement authenticated.
6. Tester l’idempotence. Envoyez deux fois la même création ou finalisation avec la même clé ; vérifiez qu’il n’existe qu’une commande et qu’une nouvelle tentative non idempotente expose request_not_idempotent au lieu de débiter deux fois.
7. Séparer erreurs métier et erreurs HTTP. Déclenchez un problème de session (article épuisé) et vérifiez un MessageError dans messages[], puis une requête mal formée et son objet d’erreur HTTP.
8. Vérifier les signatures de webhook. Envoyez un order_create valide, contrôlez la signature HMAC Merchant-Signature, acceptez 200, refusez une signature altérée avec 401 et vérifiez que l’objet Order complet, pas un delta, est envoyé.
9. Tester la contre-pression. Vérifiez qu’un 429 de la plateforme déclenche une nouvelle tentative avec temporisation au lieu de perdre l’événement.
10. Confirmer l’attribution. Vérifiez que la commande terminée est marquée comme issue d’un agent au niveau OMS, puisqu’aucune session GA4 ne sera nécessairement présente.

Erreurs fréquentes et meilleure approche

Supposer que « checkout agentique » signifie achat entièrement autonome. Pourquoi c’est faux : toute implémentation crédible conserve un point d’autorisation — requires_escalation, authentication_required, step-up 3DS ou approval_required B2B. Une autonomie sans intervention n’est ni la forme des spécifications ni celle attendue aujourd’hui par les réseaux de cartes. À faire : concevoir continue_url, 3DS et approbation comme des flux de premier ordre pour qu’une transaction nécessitant un humain aboutisse proprement.

Traiter le checkout comme déjà normal parce que les titres sont nombreux. Pourquoi c’est faux : environ une douzaine de marchands Shopify seulement avaient activé le checkout ChatGPT avant le recul de mars 2026. À faire : construire sur la capacité du protocole, qui est réelle et spécifiée, mais planifier comme un adopteur précoce.

Croire que la responsabilité des litiges est réglée parce que le marchand de référence est établi. Pourquoi c’est faux : le marchand assume règlement, remboursements et conformité, mais la preuve d’une transaction autorisée par un agent IA reste explicitement non résolue. À faire : conserver journaux d’autorisation et signaux de risque, considérer Visa TAP et Mastercard Agent Pay comme émergents et ne pas supposer que les preuves classiques suffiront.

Supposer que l’agent contourne toujours le site, donc que le checkout hébergé n’a plus d’importance. Pourquoi c’est faux : le discours initial de ChatGPT Instant Checkout a évolué vers découverte puis redirection en mars 2026 ; la capacité du protocole ne dépend pas d’une interface unique. À faire : garder le checkout hébergé solide et prendre en charge le flux de session programmatique.

Penser que l’agent manipule le numéro de carte du client. Pourquoi c’est faux : les données brutes ne lui parviennent jamais ; les jetons délégués et le modèle instrument/handler d’UCP sont précisément la raison d’être de la délégation. À faire : faire porter la délégation par le PSP, avec un jeton lié au marchand, plafonné et à usage unique, en gardant le périmètre PCI réduit.

Négliger l’idempotence des nouvelles tentatives. Pourquoi c’est faux : agents et réseaux réessaient. Le type d’erreur request_not_idempotent existe parce qu’une tentative naïve peut créer deux commandes ou débiter deux fois. À faire : exiger une clé d’idempotence lors de la création et de la finalisation, puis rendre les appels répétés avec la même clé sûrs.

Aide-mémoire du checkout agentique

Énumération des statuts de session ACP

Machine parallèle UCP : incomplete → requires_escalation (humain via continue_url) → ready_for_complete.

Endpoints de checkout ACP

• POST /checkout_sessions — créer (201)
• GET /checkout_sessions/{id} — récupérer
• POST /checkout_sessions/{id} — mettre à jour
• POST /checkout_sessions/{id}/complete — traiter le paiement et créer la commande
• POST /checkout_sessions/{id}/cancel — annuler et libérer le stock

Les quatre limites du jeton de paiement

• merchant_id + checkout_session_id → lié au marchand et à la session
• max_amount → plafond de montant
• expires_at (RFC 3339) → durée limitée
• reason: "one_time" → usage unique

Webhooks de commande ACP

• Événements : order_create, order_update
• Signature : en-tête HMAC Merchant-Signature obligatoire
• Charge utile : objet Order complet, pas de delta
• Réponses : 200 succès · 401 signature invalide · 429 débit limité
• Statuts : created · manual_review · confirmed · canceled · shipped · fulfilled

Déclencheurs d’intervention humaine

• états requires_escalation / authentication_required
• InterventionCapabilities (3ds, address_verification, niveaux always/conditional/optional)
• résultats AuthenticationResult (authenticated/denied/rejected/abandoned/…)
• approval_required B2B et continue_url UCP

Responsabilité en un coup d’œil

• Marchand = marchand de référence → règlement/remboursements/litiges avec marchand + PSP ✅ établi
• Règles de preuve des litiges pour les acheteurs-agents ⚠️ non résolues à mi-2026
• Visa TAP / Mastercard Agent Pay → cadres émergents, non terminés

Extraits pour travailler avec le checkout agentique

Ces extraits servent à inspecter et tester votre intégration, pas à conduire des achats réels. Utilisez des identifiants de bac à sable.

Vérifier une signature de webhook (Node.js, HMAC)

Rejetez toute requête dont Merchant-Signature ne correspond pas et comparez en temps constant.

import crypto from "node:crypto";

// secret = your shared webhook signing secret; rawBody = the exact bytes received
function verifyMerchantSignature(rawBody, signatureHeader, secret) {
  const expected = crypto
    .createHmac("sha256", secret)
    .update(rawBody)          // sign the raw body, not the parsed JSON
    .digest("hex");
  const a = Buffer.from(expected);
  const b = Buffer.from(signatureHeader || "");
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}
// In your handler: if (!verify) return res.status(401).end();  // else 200

Interroger le statut d’une session (shell)

Observez une session de bac à sable parcourir la machine d’état pendant le test.

# Retrieve a session and print just its status field (needs jq)
SESSION_ID="cs_test_123"
curl -s "https://api.example.com/checkout_sessions/$SESSION_ID" \
  -H "Authorization: Bearer $ACP_TEST_KEY" \
  | jq -r '.status'          # e.g. not_ready_for_payment → ready_for_payment → completed

Envoyer une création avec une clé d’idempotence (Python)

Prouvez qu’une nouvelle tentative avec la même clé produit une commande, pas deux.

import uuid, requests

key = str(uuid.uuid4())  # reuse this SAME key on retry
headers = {
    "Authorization": f"Bearer {ACP_TEST_KEY}",
    "Idempotency-Key": key,
    "Content-Type": "application/json",
}
payload = {"line_items": [{"id": "sku_1", "quantity": 1}]}
r1 = requests.post(f"{BASE}/checkout_sessions", json=payload, headers=headers)
r2 = requests.post(f"{BASE}/checkout_sessions", json=payload, headers=headers)  # retry
print(r1.json().get("id") == r2.json().get("id"))  # expect True — same session, no dupe

Console : rechercher un profil UCP .well-known

Contrôle rapide dans les outils de développement pour vérifier si un marchand expose la découverte UCP ; collez-le dans la console du navigateur sur l’origine du marchand :

fetch("/.well-known/ucp")
  .then(r => (console.log("status:", r.status), r.ok ? r.json() : null))
  .then(p => console.log("capabilities:", p && p.capabilities));

Bookmarklet : ouvrir l’énumération des statuts ACP

Déposez ceci dans un favori pour ouvrir la référence ACP au niveau de la liste des statuts :

javascript:location.href='https://www.agenticcommerce.dev/docs/reference/checkout#:~:text=incomplete';

Échecs fréquents du checkout agentique

Une nouvelle tentative crée deux commandes ou deux débits

Symptôme : une session produit des doublons après un délai ou une nouvelle tentative réseau. Cause probable : les appels de création ou de finalisation ne sont pas protégés contre la relecture. Correction : exigez une clé d’idempotence, renvoyez le résultat initial pour la même clé et vérifiez que deux appels identiques en bac à sable produisent une session et une commande.

Le checkout ne devient jamais prêt pour le paiement

Symptôme : la session reste not_ready_for_payment ou incomplete. Cause probable : une option de livraison, une adresse ou une règle métier obligatoire manque. Correction : examinez les champs requis et messages[], fournissez la donnée manquante et vérifiez l’état ready_for_payment ou ready_for_complete.

Une requête valide semble réussir, mais le panier ne se termine pas

Symptôme : la requête HTTP réussit alors que la session contient une rupture de stock ou une erreur métier. Cause probable : le client ne gère que les erreurs HTTP et ignore les entrées MessageError. Correction : traitez les erreurs de transport et les messages de session, puis vérifiez que le client ou l’agent reçoit l’échec exploitable.

La vérification humaine aboutit à une impasse silencieuse

Symptôme : le checkout entre dans requires_escalation ou authentication_required sans revenir. Cause probable : la remise 3DS, connexion, approbation ou continue_url a été traitée comme une erreur exceptionnelle. Correction : persistez la session pendant la remise, gérez chaque résultat d’authentification et testez les flux réussis comme abandonnés.

Le statut de commande ne se met plus à jour après le paiement

Symptôme : le marchand possède la commande, mais l’interface agent reste en attente. Cause probable : signature de webhook invalide, delta au lieu d’objet complet ou réponse 429 perdue. Correction : signez la charge utile exacte, envoyez l’objet Order complet, réessayez les événements limités avec temporisation et vérifiez que le récepteur accepte l’événement.

Modèles mentaux du checkout agentique

Le checkout est une machine d’état, pas un appel API unique

Chaque réponse doit conduire la session vers un état connu ou expliquer pourquoi elle ne peut pas avancer. Concevez les clients autour des transitions, états terminaux, nouvelles tentatives et escalades, pas autour d’un unique appel « acheter ».

L’autorité reste chez le marchand

L’agent exprime une intention, mais le marchand reste la source d’autorité pour le prix, le stock, les taxes, la livraison, l’état de commande et ses obligations de marchand de référence. Traitez le panier demandé par l’agent comme une entrée et le panier renvoyé par le marchand comme la vérité.

La délégation réduit la permission

Un jeton limité est sûr parce qu’il est lié au marchand et à la session, plafonné, limité dans le temps et à usage unique. Pour chaque capacité déléguée, demandez ce qu’elle peut faire, pour qui, pour quel montant et pendant combien de temps.

L’escalade est une branche réussie

Une intervention humaine n’est pas un checkout autonome raté. Une remise 3DS, une connexion, un contrôle d’adresse ou une approbation B2B bien gérés sont le protocole qui fonctionne comme prévu.

La livraison est asynchrone après la finalisation

La fin du paiement ne termine pas l’intégration. Les webhooks signés et complets transportent la vérité de commande après le checkout ; vérification de signature, protection contre la relecture et nouvelles tentatives font partie de la fiabilité.

Mesures du checkout agentique

Finalisation par état terminal

• Métrique : sessions terminées, annulées ou expirées, rapportées aux sessions initiées.
• Ce qu’elle indique : où la machine d’état s’arrête et quelle intention est perdue avant la création d’une commande.
• Comment l’obtenir : agrégez les changements d’état des sessions depuis l’API commerciale ou la plateforme de commande, par protocole et surface marchand.
• Référence réaliste : établissez une base pour votre propre mélange de produits et comparez des parcours équivalents ; aucun taux universel n’est défendable à ce stade d’adoption.
• Cadence : surveillance quotidienne et tendance hebdomadaire.

Taux de reprise après escalade

• Métrique : sessions escaladées qui reviennent et se terminent après 3DS, connexion, adresse ou approbation.
• Ce qu’elle indique : si la remise humaine est utilisable ou constitue une impasse.
• Comment l’obtenir : reliez les événements d’escalade aux transitions ultérieures par l’identifiant de session.
• Référence réaliste : établissez une base par type d’intervention ; authentification et approbation B2B ont des frictions différentes.
• Cadence : chaque semaine et après chaque changement de parcours.

Doublons de commande et échecs de webhook

• Métrique : commandes dupliquées par nouvelles tentatives de même clé, plus livraisons de webhook refusées ou épuisées.
• Ce qu’elle indique : si idempotence et synchronisation asynchrone restent sûres en cas d’échec.
• Comment l’obtenir : comparez clés d’idempotence, identifiants de commande, signatures échouées, 401, 429, nouvelles tentatives et événements en file morte dans les journaux.
• Référence réaliste : les doublons doivent être nuls ; établissez la base des nouvelles tentatives transitoires et enquêtez sur toute dérive persistante.
• Cadence : alerte immédiate, synthèse hebdomadaire.

Ressources utiles

Mes articles associés

• Les deux protocoles auxquels appartient le checkout agentique sont détaillés dans les articles Agentic Commerce Protocol (ACP) et Universal Commerce Protocol (UCP) ; cette page approfondit uniquement les mécanismes de checkout.
• Guide du débutant sur le référencement e-commerce — place du checkout destiné aux agents dans l’écosystème e-commerce.

Mes présentations

• Fonctionnement de la recherche (présentation) — exploration, indexation et classement, contexte utile pour comprendre la couche transactionnelle médiée par agent. (Ma réserve habituelle s’applique : “This is my understanding of systems… not going to be 100% complete or accurate.” (traduction) « Voici ma compréhension des systèmes… elle ne sera pas complète ni exacte à 100 %. »)

Dans le secteur

• Agentic Commerce Protocol — référence Checkout (OpenAI/Stripe) — statuts, champs de session et objets d’intervention/authentification.
• Spécification de paiement délégué OpenAI — jetons limités et langage sur marchand de référence et PCI.
• Référence des webhooks de commande ACP (OpenAI/Stripe) — synchronisation poussée, HMAC et objet complet.
• Litiges du commerce agentique : qui est responsable ? (Chargeflow) — analyse prudente de l’absence de réponses nettes.
• Commerce agentique : menaces et risques (Visa) — Trusted Agent Protocol et identité d’agent.
• Le projet ChatGPT Instant Checkout d’OpenAI vient de changer (Search Engine Land) — virage de mars 2026 et chiffres d’adoption.
• Qu’est-ce que le checkout agentique ? (Rye) — définition indépendante et confirmation du marchand de référence.
• Analyse : Mastercard Verifiable Intent contre Visa Trusted Agent Protocol (Fintech Wrap Up / Finextra) — comparaison des cadres de réseau ; l’allocation précise reste rapportée, non confirmée.

Statistiques à citer

Ces chiffres situent le checkout agentique ; les données rapportées par des marchands ou relayées par la presse sont directionnelles et doivent être vérifiées avant réutilisation.

• Environ une douzaine de marchands Shopify utilisaient activement des outils de checkout IA, volume décrit comme négligeable face à la base globale de Shopify, selon la couverture de Search Engine Land du virage de mars 2026. Couverture
• Mars 2026 : le virage. OpenAI est passé d’un achat complet dans le chat à une découverte puis redirection, après des frictions d’intégration, de précision et de panier multi-articles. Couverture
• Portée du jeton : quatre limites. max_amount, expires_at, merchant_id/checkout_session_id et reason: one_time empêchent que l’agent détienne une carte réutilisable. Source
• Webhook : objet complet, toujours. ACP exige que data contienne l’objet Order complet et que chaque requête soit signée par HMAC. Source

Testez vos connaissances : checkout agentique

Cinq questions rapides sur les mécanismes du checkout. Choisissez une réponse pour chacune, puis vérifiez vos choix.

Journal des modifications