1. Tout fonctionne déjà séparément…
À ce stade, vous voyez déjà comment le flux e‑commerce tourne autour de ChatGPT. Le marchand dispose d’un Product Feed, les endpoints ACP sont implémentés (/checkout_sessions et consorts), Instant Checkout gère le paiement, et le backend reçoit des webhooks et crée des commandes. Tout cela peut fonctionner même sans votre ChatGPT App : Product Feed + backend ACP suffisent.
Separément, vous savez déjà :
- construire un Product Feed selon la spécification d’OpenAI ;
- concevoir et implémenter Agentic Checkout / Delegated Payment ;
- écrire une ChatGPT App avec widget et outils MCP pour la recherche de cadeaux.
Pris isolément, tout semble parfait, mais l’ensemble peut vite tourner au « zoo de services ». Le widget vit sa vie, le serveur MCP la sienne, le backend ACP encore une autre, et la logique des commandes et des webhooks — une quatrième. À la première tentative de déboguer un achat réel ou de corriger un bug étrange, vous réalisez soudain que personne ne voit vraiment la vue d’ensemble.
L’objectif de cette leçon est de vous sortir de cet état et de proposer une architecture cohérente mais réalisable : comment le Product Feed est relié au backend ACP, comment tous deux se rapportent à la ChatGPT App et au widget, où intervient exactement le prestataire de paiement, et comment tout cela se traduit pour l’équipe en composants clairs : services, bases de données, API.
En parallèle, nous soulignerons constamment : ce qui relève du SPEC (standard strict) et ce qui n’est que notre choix d’architecture pour GiftGenius.
Insight : ChatGPT, c’est un Google gratuit
ChatGPT fonctionne avec les utilisateurs à peu près comme Google : il vous apporte gratuitement du trafic pertinent, car il se rémunère autrement — sur les utilisateurs eux‑mêmes.
D’un point de vue business, cela signifie une chose simple : ChatGPT devient un « canal publicitaire » gratuit pour vos produits, à condition d’avoir branché le Product Feed et le backend ACP. Le modèle proposera vos références si elles répondent bien à la demande de l’utilisateur, et vous n’avez pas à payer séparément pour les impressions ou les clics.
Deux conclusions pratiques en découlent :
- La fenêtre d’opportunité est TEMPORAIREMENT très peu coûteuse. Aujourd’hui, la concurrence dans l’écosystème ACP est faible, et accéder aux segments de prix supérieurs est possible sans les budgets publicitaires habituels. Situation rare où un trafic à forte conversion sur des produits chers (aérien, immobilier, produits premium, assurances) peut ne rien coûter.
- Il est judicieux de commencer par les verticales à plus forte marge. Si vous avez accès à des catégories avec un panier élevé, il est rationnel de les connecter en premier :
- vente / location d’avions, de yachts, de villas ;
- vente / location de maisons et d’immobilier haut de gamme ;
- bijoux, montres de luxe, produits et services d’assurance.
Cela ne garantit pas des « millions rapides », mais crée une asymétrie : ceux qui mettront en place en premier un Product Feed de qualité et un backend ACP fiable sur des segments chers obtiendront un gain disproportionné de ce canal, tant qu’il reste sous‑estimé et de fait gratuit.
2. Architecture de référence GiftGenius : à grands traits
Commençons par une vue d’ensemble. Rappelons le schéma global des modules précédents : l’utilisateur parle à ChatGPT, le modèle appelle vos outils, et la couche commerce vit dans un backend séparé.
Formulons les blocs principaux de GiftGenius.
Premièrement, l’UI de ChatGPT et le modèle GPT, qui mènent le dialogue avec l’utilisateur et, si nécessaire, activent l’app GiftGenius (ou fonctionnent sans app — uniquement via le Product Feed).
Deuxièmement, le widget GiftGenius (Next.js + Apps SDK), qui affiche des cartes cadeaux et, au besoin, la progression du checkout. Il vit dans le sandbox window.openai et ne connaît rien des véritables informations de paiement.
Troisièmement, la couche MCP, qui fournit au modèle des outils pour rechercher des cadeaux dans le catalogue (Product Feed) et, éventuellement, pour lire l’historique des commandes.
Quatrièmement, le backend commerce / ACP, qui :
- lit le Product Feed comme source de vérité sur les produits et les SKU ;
- met en œuvre Agentic Checkout Spec (/checkout_sessions, webhooks, statuts) ;
- communique avec le prestataire de paiement (par exemple Stripe) selon le Delegated Payment Spec.
Cinquièmement, les bases de données du catalogue (si le feed est formé depuis une BD), des commandes et des structures auxiliaires (utilisateurs, paramètres).
Enfin, le prestataire de paiement, qui stocke et traite les données de paiement, et envoie des webhooks sur les résultats des paiements.
Schématiquement, on peut le dessiner ainsi :
graph LR U[Utilisateur dans ChatGPT] --> GPT[Modèle GPT] GPT -->|rend| W[Widget GiftGenius
Next.js + Apps SDK] GPT -->|outils MCP| MCP[Serveur MCP
recherche de cadeaux] MCP --> PF["Product Feed
(BD/JSON)"] GPT -->|ACP HTTP| ACP[Backend commerce GiftGenius
Agentic Checkout] ACP --> ORDERS[Base de commandes] ACP --> PSP["Prestataire de paiement
(Stripe, etc.)"] PSP --> ACP ACP -->|webhooks/événements| GPT
Ce diagramme décrit l’architecture de GiftGenius comme exemple d’implémentation. Le format du Product Feed, le contrat /checkout_sessions et le protocole Delegated Payment restent partie intégrante du standard ACP ; l’emplacement des services, les schémas de BD et le découpage en processus — ce sont vos choix d’architecture.
3. Comment le Product Feed, l’ACP et le widget sont liés logiquement
Pour ne pas nous noyer dans les flèches, fixons une idée simple mais fondamentale : vous avez exactement une source unique de vérité sur les produits.
Dans le monde GiftGenius, disons qu’il s’agit des tables products + skus dans PostgreSQL. À partir d’elles, vous :
- Formez le Product Feed selon la spécification OpenAI (directement ou via export).
- Construisez un index de recherche pour les outils MCP (par exemple, search_gifts).
- Effectuez la validation des requêtes du backend ACP — vous vérifiez que le sku_id entrant existe bien et possède un prix et une devise corrects.
Ainsi, la recherche MCP et le checkout ACP s’appuient sur les mêmes données, et le widget ne fait qu’afficher les résultats qui proviennent soit des outils MCP, soit indirectement d’ACP (par exemple, des informations de commande).
On peut l’imaginer comme deux « fenêtres » sur un même catalogue : une fenêtre pour la recherche et les recommandations, l’autre pour l’achat. Si ces fenêtres regardent des bases différentes, attendez‑vous à une joyeuse vie de désynchronisations.
4. Modéliser les données : du Product Feed à la commande
Commençons par de simples types TypeScript, qui vivront dans votre dépôt GiftGenius (par exemple dans src/domain/commerce.ts). Ces types ne sont pas une copie littérale des spécifications, mais en reflètent les idées principales sous une forme pratique pour l’application.
// src/domain/commerce.ts
export interface ProductSku {
id: string; // identifiant SKU stable (correspond à Product Feed)
title: string; // intitulé lisible par l’humain
priceCents: number; // prix en centimes
currency: string; // code ISO, par exemple "usd"
}
export type CheckoutStatus = "pending" | "succeeded" | "failed";
export interface CheckoutSession {
id: string;
skuId: string;
totalCents: number;
currency: string;
status: CheckoutStatus;
}
Ici, nous tirons explicitement dans CheckoutSession un lien vers skuId et une devise/somme figée. C’est notre modèle interne ; la spécification réelle d’Agentic Checkout est plus riche, mais l’idée de base reste la même : une session, c’est « combien, pour quoi et dans quel statut ».
Ensuite, il nous faut un type de commande :
export interface Order {
id: string;
userId: string;
skuId: string;
totalCents: number;
currency: string;
checkoutSessionId: string;
status: "awaiting_payment" | "paid" | "canceled" | "refunded";
}
On sent ici l’influence des entités communes du module précédent : intent, checkout_session, order. Dans notre projet pédagogique, nous fusionnons légèrement intent et order pour ne pas multiplier les entités, mais nous conservons le lien avec checkoutSessionId.
5. Comment le widget GiftGenius « jette un œil » au monde commerce
Point important : le widget, en lui‑même, n’appelle pas le PSP et n’a même pas besoin de connaître les détails d’ACP ; son rôle est d’afficher à l’utilisateur un état calculé et figé côté backend.
Le scénario utile le plus simple : après un achat réussi, l’utilisateur peut revenir dans le chat et demander « Montre‑moi mes dernières commandes dans GiftGenius ». GPT appellera un outil MCP du type get_user_orders, qui contactera votre backend, et le widget affichera la liste.
Imaginons une route API Next.js qui renvoie les dernières commandes (simplifié) :
// app/api/orders/recent/route.ts
import { NextRequest, NextResponse } from "next/server";
import { getRecentOrdersForUser } from "@/lib/orders";
export async function GET(req: NextRequest) {
const userId = req.headers.get("x-giftgenius-user-id")!;
const orders = await getRecentOrdersForUser(userId);
return NextResponse.json({ orders });
}
La fonction getRecentOrdersForUser vit déjà dans votre couche commerce, travaille avec la BD et connaît la structure des commandes. De son côté, le widget peut appeler cette route via window.fetch (nous l’avons déjà fait dans les modules précédents) et afficher les cartes d’achats.
La combinaison « outil MCP → votre API → BD des commandes → widget » donne à l’utilisateur l’impression que l’app a une « mémoire » de ses achats, alors que le widget ne fait qu’afficher l’état du backend.
6. Implémentation simple d’un endpoint ACP à la Next.js
Esquissons maintenant à quoi peut ressembler une implémentation pédagogique de l’un des endpoints ACP clés — la création de checkout_session. La spécification prévoit un contrat assez riche, mais pour le cours, on peut garder l’essentiel : un skuId arrive, nous le vérifions via le feed/BD, nous créons une session et renvoyons son ID et le montant.
Supposons que nous ayons la route POST /api/checkout-sessions :
// app/api/checkout-sessions/route.ts
import { NextRequest, NextResponse } from "next/server";
import { findSkuById, createCheckoutSession } from "@/lib/checkout";
export async function POST(req: NextRequest) {
const body = await req.json(); // { skuId: string }
const sku = await findSkuById(body.skuId);
if (!sku) {
return NextResponse.json(
{ error: "SKU not found" },
{ status: 400 },
);
}
const session = await createCheckoutSession(sku);
return NextResponse.json({ session });
}
Voici quelques points importants.
Premièrement, c’est ici que la couche commerce s’aligne sur le Product Feed/BD : findSkuById doit regarder la même source que celle qui forme le feed. Nous ne faisons confiance à rien qui viendrait « de l’air » — ni de GPT, ni du widget.
Deuxièmement, nous ne renvoyons que ce qui est nécessaire à ChatGPT/au client ACP : l’ID de la session, le montant, la devise et le statut (par défaut pending ou not_ready_for_payment, selon la terminologie choisie). Dans un ACP réel, il y a plus de champs, y compris les moyens de paiement et le fulfillment, mais l’exemple pédagogique se concentre sur la création initiale de la session.
Troisièmement, une telle route se prête bien aux tests de contrat : si demain la structure du Product Feed change, les tests sur findSkuById et createCheckoutSession doivent le détecter avant que ChatGPT ne commence à renvoyer des erreurs étranges aux utilisateurs.
7. Lien entre les sessions ACP et le prestataire de paiement
Jusqu’ici, nous n’avons pas touché au prestataire de paiement. Dans une intégration réelle, il se passe à peu près ceci (scénario simplifié).
D’abord, ChatGPT (via ACP) appelle votre POST /checkout_sessions. Votre backend crée une session locale dans sa BD. Quand l’utilisateur confirme le paiement dans l’UI Instant Checkout, la plateforme demande au PSP un jeton de paiement délégué (Shared Payment Token) pour le marchand et le montant donnés. Ce jeton vous est transmis dans la requête complete (ou un appel analogue selon le Delegated Payment Spec).
Ensuite, vous créez un paiement chez le PSP en utilisant le jeton, sans accéder aux véritables données de paiement. Le PSP envoie un webhook sur le résultat ; vous mettez à jour le statut de la commande et/ou de la session de checkout.
Dans notre code pédagogique, nous pouvons nous contenter d’une simulation de cette étape. Par exemple, la fonction completeCheckoutSession peut ressembler à ceci :
// src/lib/checkout.ts
export async function completeCheckoutSession(sessionId: string, spt: string) {
// En réalité, ici on appelle l’API du PSP avec le jeton délégué (SPT)
const paymentOk = await mockChargeWithToken(spt);
return paymentOk
? { status: "succeeded" as const }
: { status: "failed" as const };
}
L’appel au PSP et l’utilisation du Shared Payment Token relèvent du standard Delegated Payment, tandis que la fonction mockChargeWithToken est notre couche d’architecture pédagogique qui en mime la spécificité.
8. Flux de bout en bout GiftGenius : de la requête au cadeau payé
Assemblons maintenant le tout sous forme de séquence d’étapes. C’est l’histoire « terrain » de GiftGenius, pour laquelle nous combinons toutes les couches. Il est important de ne pas mélanger deux mondes différents, donc examinons‑les séparément.
Schéma A : sans App, uniquement Product Feed + ACP
Dans ce scénario, vous avez un Product Feed et un backend ACP, mais pas de ChatGPT App ni de widget. C’est le marchand Instant Checkout classique.
L’utilisateur écrit à ChatGPT quelque chose comme : « Trouve un cadeau numérique jusqu’à 50 $ ». GPT utilise votre Product Feed pour trouver des SKU adaptés et les affiche dans son UI native sous forme de cartes shopping. Ici, aucun code React ne vous appartient — les cartes sont entièrement rendues par ChatGPT.
L’utilisateur clique sur le bouton « Buy » sur l’une de ces cartes. Ce clic est géré par ChatGPT lui‑même. La plateforme :
- Forme les line_items sur la base du Product Feed.
- Appelle votre POST /checkout_sessions selon l’Agentic Checkout Spec.
- Affiche à l’utilisateur l’UI Instant Checkout (moyen de paiement, adresse, etc.).
- Après confirmation, obtient un Shared Payment Token auprès du PSP et appelle votre .../complete.
- Reçoit de votre part l’état final de la checkout_session et, si nécessaire, attend le webhook de commande.
Du point de vue de votre code, seuls les endpoints ACP et le Product Feed travaillent ici. Aucun Apps SDK, pas de window.openai, ni de widget. Et c’est un scénario ACP parfaitement valide et « pur ».
Schéma B : avec ChatGPT App et widget GiftGenius
Ajoutons maintenant la ChatGPT App et le widget GiftGenius par‑dessus. Le Product Feed et le backend ACP ne disparaissent pas : ils assurent toujours la recherche et le paiement. La différence, c’est que nous avons notre propre UI et la logique des étapes dans l’App.
Imaginons le dialogue : l’utilisateur écrit à ChatGPT : « Trouve un cadeau pour ma mère jusqu’à 50 $ ». GPT comprend que c’est une demande commerce et propose d’utiliser l’app GiftGenius. Le widget pose quelques questions de précision : âge, centres d’intérêt, pays. Ensuite, GPT appelle votre outil MCP search_gifts avec des filtres, et le serveur MCP interroge le catalogue (BD ou index préparé), trouve plusieurs SKU adaptés et les renvoie sous forme structurée.
GPT transmet ces données au widget, et celui‑ci affiche ses cartes cadeaux « maison » (composants React, carrousels, etc.). C’est déjà votre design et votre UX, pas l’UI shopping standard de ChatGPT.
Quand l’utilisateur clique sur le bouton « Acheter » dans le widget, il se passe autre chose qu’au schéma A. Ce clic est géré par le widget :
- Le widget identifie le SKU choisi par l’utilisateur.
- Via son API (par exemple POST /api/checkout-sessions), il contacte votre backend pour créer une checkout_session (ou obtenir l’ID d’une session déjà préparée).
- Puis le widget appelle une méthode runtime de l’Apps SDK du type :
// Consultez la doc de l’Apps SDK pour la signature à jour await window.openai.requestCheckout({ checkoutSessionId: session.id, ... });Cet appel est à l’initiative du widget. Pour ChatGPT, c’est un signal : « Il est temps d’ouvrir Instant Checkout pour cette checkout_session ».
Ensuite, la plateforme ChatGPT fonctionne très semblablement au schéma A, mais en coulisses :
- affiche à l’utilisateur l’UI Instant Checkout ;
- obtient le Shared Payment Token auprès du PSP ;
- appelle votre endpoint ACP de finalisation (.../complete) ;
- participe à la réception et au traitement des webhooks de votre backend.
Autrement dit, dans le schéma B, le widget déclenche le checkout via l’Apps SDK, et les appels ACP (création/finalisation de la checkout_session) ont lieu soit avant (quand vous créez la session côté backend), soit après requestCheckout, mais toujours côté serveur.
Le widget peut en parallèle afficher les étapes « Passage de commande », les statuts et l’aperçu de la commande, en s’appuyant sur votre API (/api/orders/...) et les outils MCP.
Si l’on représente le schéma B par un diagramme, on obtient quelque chose comme :
sequenceDiagram
participant User as Utilisateur
participant GPT as ChatGPT / GPT
participant W as Widget GiftGenius
participant MCP as Serveur MCP
participant ACP as Commerce Backend
participant PSP as Prestataire de paiement
User->>GPT: "Trouve un cadeau jusqu’à 50 $"
GPT->>MCP: search_gifts(...)
MCP-->>GPT: liste des SKU
GPT->>W: données pour rendre les cartes
User->>W: clic « Acheter »
W->>ACP: POST /api/checkout-sessions (skuId)
ACP-->>W: checkout_session (id, montant, devise)
W->>GPT: window.openai.requestCheckout({ checkoutSessionId })
GPT->>User: UI Instant Checkout
User->>GPT: confirmation du paiement
GPT->>PSP: requête Shared Payment Token
PSP-->>GPT: SPT
GPT->>ACP: complete(sessionId, SPT)
ACP->>PSP: charge(SPT)
PSP-->>ACP: résultat du paiement
ACP->>GPT: statut de la commande
GPT->>User: message de paiement réussi/échoué
Différence clé avec le schéma A :
- Dans A, les cartes et le bouton « Buy » sont rendus par ChatGPT lui‑même, et c’est lui qui initie l’appel ACP directement.
- Dans B, les cartes et le bouton « Acheter » sont rendus par votre widget, et c’est lui qui appelle window.openai.requestCheckout(...). Ensuite, ChatGPT discute sous le capot avec votre backend ACP et le PSP.
Insight
Dans leur SDK, ChatGPT a indiqué que la monétisation arrivera bientôt dans les applications. C’est bien le cas. Plusieurs méthodes encore non annoncées sont déjà accessibles aux widgets. La plus intéressante d’entre elles est requestCheckout().
Son appel ressemble à ceci :
window.openai.requestCheckout({
id: "checkout_session_123",
payment_provider: {
merchant_id: "stripe",
supported_payment_methods: ["card"]
},
...
}
Il affiche une boîte de dialogue permettant à l’utilisateur de finaliser le paiement. Donc concevez votre application comme si la monétisation était déjà activée : lorsque vous aurez fini, ce sera le cas.
9. Mini‑implémentation pour le cours : backend monolithique
Dans les modules sur l’architecture, nous avons déjà posé la question : tout faire dans un seul service ou découper d’emblée en serveur MCP, backend commerce et service séparé pour l’intégration paiement ? À des fins pédagogiques, un « quasi‑monolithe » suffit le plus souvent : un dépôt, un déploiement, mais une logique proprement séparée par couches.
La variante pédagogique de GiftGenius peut ressembler à ceci : une application Next.js où :
- le widget vit dans app/widget/page.tsx ;
- les endpoints ACP — dans app/api/checkout-sessions et les routes voisines ;
- les outils MCP — dans app/api/mcp/route.ts ou un dossier séparé ;
- la gestion des commandes — dans src/lib/orders.ts, src/lib/checkout.ts et modules proches.
Physiquement, c’est un seul serveur (surtout en dev/staging), mais logiquement vous raisonnez déjà en trois rôles : UI (widget), MCP (outils/ressources pour GPT) et ACP (backend commerce).
Plus tard, dans les modules sur la production, vous verrez comment ce « monolithe » est réparti sur plusieurs services et environnements, avec un MCP Gateway en frontal. Mais au niveau du module 14, un « monolithe aux bonnes couches » offre déjà une architecture très crédible.
10. Exercice pratique : votre architecture autour d’ACP
Pour que tout ce qui précède ne reste pas théorique, il est pertinent de l’appliquer dès maintenant à votre domaine. Dans le cadre de la leçon, vous pouvez faire deux mini‑exercices.
Premièrement, choisissez votre propre scénario : abonnement SaaS, réservation, livraison de repas, cours en ligne — tout cas où il y a produit/service, prix et un checkout raisonnable. Souvenez‑vous du modèle par phases : discovery → decision → checkout → post‑payment.
Deuxièmement, en vous appuyant sur l’architecture GiftGenius, décrivez librement : comment vous allez construire le Product Feed (où vivent les SKU et les prix, qui les met à jour), où vous implémentez le contrat ACP (service séparé ou partie du backend existant), comment vous branchez le prestataire de paiement et comment votre widget (s’il existe) interagit avec l’ensemble via MCP et l’Apps SDK.
Il est utile de préciser si votre projet n’utilisera que le schéma A (Instant Checkout sans App), uniquement le schéma B (App + widget), ou les deux scénarios. Même une esquisse textuelle de l’architecture réduit fortement le risque de surprises lors de l’intégration réelle.
11. Erreurs typiques lors de l’intégration du Product Feed, d’ACP et du widget
Erreur n° 1 : deux catalogues distincts — l’un pour la recherche, l’autre pour le checkout.
Parfois, l’équipe met d’abord en place un feed « recherche » rapide pour GPT (par exemple un petit JSON), puis développe à part une BD commerce pour les commandes. Sans les relier par des ID communs et une logique d’actualisation commune, GPT peut proposer à l’utilisateur des produits déjà invendables ou à un ancien prix. La bonne approche — une source unique de vérité, à partir de laquelle sont formés à la fois le Product Feed et les tables internes pour les endpoints ACP.
Erreur n° 2 : faire confiance aux données venant de GPT ou du widget.
Quand un checkout_session reçoit un skuId et un prix, la tentation est grande de croire ces valeurs : « GPT ne va pas mentir ». Mais le modèle peut facilement « créer » ou confondre un SKU, et l’utilisateur peut tenter de falsifier la requête. Sans recouper les données entrantes avec le Product Feed/BD, vous risquez de vendre autre chose et au mauvais prix. Tout endpoint ACP doit commencer par une validation sur le stockage primaire du catalogue.
Erreur n° 3 : mélanger les rôles du widget et du backend commerce.
Il arrive que les développeurs, par habitude, appellent directement le SDK de paiement depuis le front, créent des sessions dans Stripe et vivent comme sur un site classique. Dans le contexte des ChatGPT Apps, cela casse le modèle de sécurité et contredit ACP : le flux de paiement doit passer par ChatGPT et votre backend commerce, tandis que le widget doit seulement afficher l’état et envoyer des événements (comme requestCheckout). Si le widget en sait trop sur le périmètre paiement, vous accumulez complexité et risques.
Erreur n° 4 : simplifier excessivement le contrat ACP.
Dans l’exemple pédagogique, nous gardons volontairement seulement le skuId, le montant et le statut pour ne pas nous perdre dans les détails. Le problème commence quand ce « contrat démo » glisse subrepticement en production. Vous découvrez soudain qu’il manque des champs pour l’adresse, les taxes, les modes de livraison, les codes promo, et vous commencez à les « bricoler » de manière chaotique. Mieux vaut concevoir dès le départ des modèles internes dimensionnés pour les scénarios réels, même si certains champs restent inutilisés au début.
Erreur n° 5 : absence de lien entre commandes et utilisateurs.
En démo, il est facile de se limiter à orderId et skuId, sans penser à l’utilisateur qui reviendra une semaine plus tard demander : « Montre‑moi mes achats ». Si vous ne prévoyez pas dès le départ un userId (ou un autre identifiant pérenne) dans la commande et la session de checkout, vous devrez plus tard faire des migrations et des ponts complexes. L’architecture commerce autour de ChatGPT suppose presque toujours que GPT pourra relier la conversation en cours à l’historique des commandes — tenez‑en compte.
Erreur n° 6 : sous‑estimer l’importance des webhooks et de l’idempotence.
Dans la leçon, nous n’avons fait qu’évoquer les webhooks ; vous les étudierez en profondeur dans les modules suivants. On peut croire : « le webhook viendra une fois, on mettra à jour la commande — et c’est tout ». En pratique, les PSP aiment retenter l’envoi d’événements, et le réseau perd des réponses. Sans concevoir les commandes et les sessions de checkout comme des structures idempotentes (par checkoutSessionId ou paymentId), vous risquez les doubles débits, les doublons de commandes et des divergences peu évidentes entre le PSP et votre BD.
Erreur n° 7 : ignorer les contraintes et la politique dans le Product Feed.
À courir après un feed « démo » rapide, on oublie facilement les restrictions d’âge, la disponibilité par pays, les catégories interdites et autres « détails ». On découvre ensuite que GPT propose avec enthousiasme à l’utilisateur un produit qui ne peut pas lui être vendu dans sa région ou à son âge. Les champs liés aux politiques et aux restrictions doivent être pensés et renseignés dès le départ, même si vous ne vendez pour l’instant que des cadeaux numériques inoffensifs.
GO TO FULL VERSION