1. Hər şey artıq ayrı‑ayrılıqda işləyir…
Bu məqama qədər ChatGPT ətrafında commerce‑flow‑un necə döndüyünü artıq təsəvvür edirsiniz. Merchantdə məhsul feed‑i var, ACP endpoint‑ləri (/checkout_sessions və s.), Instant Checkout ödənişi həyata keçirir, backend webhooks qəbul edir və sifarişlər yaradır. Bunların hamısı hətta sizin ChatGPT App‑iniz olmadan da işləyə bilər: Product Feed + ACP‑backend kifayətdir.
Ayrı‑ayrılıqda siz artıq bacarırsınız:
- Product Feed‑i OpenAI spesifikasiyasına görə toplamaq;
- Agentic Checkout / Delegated Payment layihələndirmək və reallaşdırmaq;
- hədiyyə axtarışı üçün widget və MCP tool‑ları olan ChatGPT App yazmaq.
Ayrılıqda hər şey əladır, birlikdə isə asanlıqla “servislər zooparkına” çevrilir. Widget öz yolu ilə yaşayır, MCP serveri — öz yolu ilə, ACP backend başqa biriylə, sifariş və webhook məntiqi — dördüncü ilə. Real alış‑verişi sazlamağa və ya qəribə bir səhvi düzəltməyə ilk cəhddə siz qəfil anlayırsınız ki, ümumi mənzərəni heç kim doğru‑düzgün görmür.
Bu mühazirənin məqsədi — sizi bu vəziyyətdən çıxarmaq və bütöv, eyni zamanda reallaşdırıla bilən arxitektura verməkdir: Product Feed ACP backend ilə necə bağlıdır, onların hər ikisi ChatGPT App və widgetla necə əlaqəlidir, ödəniş təminatçısı şəkilə harada daxil olur və bütün bunlar komanda üçün anlaşılan komponentlərə necə çevrilir: servislər, VB, API.
Eyni zamanda daim vurğulayacağıq: nə SPEC kimi sərt standartdır, nə isə — GiftGenius üçün bizim arxitektura seçimimizdir.
Insight: ChatGPT pulsuz Google kimidir
ChatGPT istifadəçilərlə təxminən Google kimi işləyir: o, sizə uyğun trafiki pulsuz gətirir, çünki başqa yerdən — elə istifadəçilərin özlərindən — qazanır.
Biznes baxımından bu sadə bir şeyi ifadə edir: ChatGPT sizin məhsullarınız üçün pulsuz “reklam kanalı”na çevrilir, şərt odur ki, Product Feed və ACP‑backend qoşulub. Model istifadəçinin sorğusunu yaxşı qarşılayan mövqelərinizi təklif edəcək və sizə göstərişlərə və ya kliklərə ayrıca ödəniş etmək lazım deyil.
Bundan iki praktik nəticə çıxır:
- İmkan pəncərəsi MÜVƏQQƏTİ olaraq çox ucuzdur. Hazırda ACP ekosistemində rəqabət yüksək deyil və yuxarı qiymət seqmentlərinə çıxışı adi reklam büdcələri olmadan əldə etmək olar. Bu, bahalı məhsullar üzrə (avia, daşınmaz əmlak, premium mallar, sığortalar) yüksək konversiyalı trafik heç nəyə başa gəlməyəndə nadir vəziyyətdir.
- Ən çox marjinal vertikallardan başlamaq məntiqlidir. Əgər yüksək çek dəyərli kateqoriyalara çıxışınız varsa, onları birinci qoşmaq rasionaldır:
- təyyarə, yaxta, villa satışı / icarəsi;
- evlərin və premium daşınmaz əmlakın satışı / icarəsi;
- zərgərlik məmulatları, bahalı saatlar, sığorta məhsulları və xidmətləri.
Bu “tez milyonlar”ı zəmanət vermir, amma asimmetriya yaradır: bahalı seqmentlərdə keyfiyyətli Product Feed və etibarlı ACP backend quranlar, kanal dəyərləndirilməmiş və faktiki olaraq pulsuz qaldığı müddətdə qeyri‑mütənasib yüksək qazanc əldə edəcəklər.
2. GiftGenius üçün istinad arxitekturası: böyük xətlərlə
Yuxarıdan görünüşdən başlayaq. Əvvəlki modullardakı ümumi şəkli yada salaq: istifadəçi ChatGPT‑yə yazır, model alətlərinizə müraciət edir, commerce qatı isə ayrı backend‑də yaşayır.
GiftGenius‑un əsas bloklarını formalaşdıraq.
Birincisi, istifadəçi ilə dialoq aparan və lazım olduqda GiftGenius App‑i qoşan ChatGPT UI və GPT modelidir (hətta App olmadan — yalnız Product Feed ilə də işləyə bilər).
İkincisi, GiftGenius widget‑i (Next.js + Apps SDK), hədiyyə kartlarını və lazım olduqda checkout prosesini göstərir. O, window.openai sandbox‑unda yaşayır və real ödəniş rekvizitləri barədə heç nə bilmir.
Üçüncüsü, kataloq (Product Feed) üzrə hədiyyə axtarışı və bəlkə də sifariş tarixçəsini oxumaq üçün modelə alətlər verən MCP qatı.
Dördüncüsü, commerce / ACP backend, hansı ki:
- Product Feed‑i məhsullar və SKU üzrə həqiqət mənbəyi kimi oxuyur;
- Agentic Checkout Spec‑i reallaşdırır (/checkout_sessions, webhooks, statuslar);
- ödəniş təminatçısı ilə (məsələn, Stripe) Delegated Payment Spec üzrə danışır.
Beşincisi, kataloq bazaları (əgər feed VB‑dən formalaşdırılırsa), sifarişlər və köməkçi strukturlar (istifadəçilər, tənzimləmələr).
Və nəhayət, ödəniş təminatçısı, hansı ki, ödəniş məlumatlarını saxlayır və emal edir, həmçinin ödəniş nəticələri barədə webhooks göndərir.
Sxematik olaraq bunu belə çəkmək olar:
graph LR U[İstifadəçi ChatGPT-də] --> GPT[GPT modeli] GPT -->|render edir| W[GiftGenius Widget
Next.js + Apps SDK] GPT -->|MCP tools| MCP[MCP serveri
hədiyyə axtarışı] MCP --> PF["Product Feed
(VB/JSON)"] GPT -->|ACP HTTP| ACP[GiftGenius Commerce Backend
Agentic Checkout] ACP --> ORDERS[Sifarişlər bazası] ACP --> PSP["Ödəniş təminatçısı
(Stripe və s.)"] PSP --> ACP ACP -->|webhooks/hadisələr| GPT
Bu diaqram GiftGenius arxitekturasını realizasiya nümunəsi kimi təsvir edir. Product Feed formatı, /checkout_sessions müqaviləsi və Delegated Payment protokolu ACP standartının bir hissəsi olaraq qalır; servislərin yerləşməsi, VB sxemləri və proseslərə bölünmə — sizin arxitektura seçiminizdir.
3. Product Feed, ACP və widget məntiqcə necə bağlıdır
Oxları çoxaltmamaq üçün sadə, amma prinsipial fikri sabitləyək: sizin cəmi bir məhsul həqiqət mənbəyiniz var.
GiftGenius dünyasında bu, PostgreSQL‑də products + skus cədvəli olsun. Buradan siz:
- OpenAI spesifikasiyasına görə (birbaşa və ya ixrac yolu ilə) Product Feed formalaşdırırsınız.
- MCP tool‑ları üçün axtarış indeksini qurursunuz (məsələn, search_gifts).
- ACP backend sorğularını doğrulayırsınız — gələn sku_id ümumiyyətlə mövcuddurmu və düzgün qiymətə və valyutaya malikdirmi, yoxlayırsınız.
Beləliklə, MCP axtarışı və ACP checkout eyni məlumatlara baxır, widget isə sadəcə MCP tool‑larından və ya dolayı olaraq ACP‑dən gələn nəticələri (məsələn, sifariş məlumatı) göstərir.
Bunu eyni kataloqa iki “pəncərə” kimi təsəvvür etmək olar: bir pəncərə — axtarış və tövsiyələr üçün, ikinci — alışı rəsmiləşdirmək üçün. Bu pəncərələr müxtəlif bazalara baxırsa, sizi uyğunsuzluqlarla “əyləncəli” həyat gözləyir.
Məlumatların modelləşdirilməsi: Product Feed‑dən sifarişə
GiftGenius repozitoriyanızda yaşayacaq sadə TypeScript tipləri ilə başlayaq (məsələn, src/domain/commerce.ts faylında). Bu tiplər spesifikasiyaların sözbəsöz kopyası deyil, lakin onların əsas ideyalarını tətbiq üçün əlverişli formada əks etdirir.
// src/domain/commerce.ts
export interface ProductSku {
id: string; // stabil SKU ID (Product Feed ilə üst‑üstə düşür)
title: string; // insan üçün oxunaqlı ad
priceCents: number; // qiymət sent/qəpiklə
currency: string; // ISO kodu, məsələn "usd"
}
export type CheckoutStatus = "pending" | "succeeded" | "failed";
export interface CheckoutSession {
id: string;
skuId: string;
totalCents: number;
currency: string;
status: CheckoutStatus;
}
Burada CheckoutSession daxilində skuId və sabit valyuta/məbləğə istinad edirik. Bu bizim daxili modelimizdir; real Agentic Checkout Spec daha zəngindir, amma əsas fikir eynidir: sessiya — “nə qədər, nəyə görə və hansı statusda”.
Sonra sifariş tipi lazımdır:
export interface Order {
id: string;
userId: string;
skuId: string;
totalCents: number;
currency: string;
checkoutSessionId: string;
status: "awaiting_payment" | "paid" | "canceled" | "refunded";
}
Burada əvvəlki modulun ümumi entitilərinin təsiri duyulur: intent, checkout_session, order. Tədris layihəmizdə entitiləri çoxaltmamaq üçün intent və order‑i bir az birləşdiririk, amma checkoutSessionId ilə əlaqəni saxlayırıq.
5. GiftGenius widget‑i commerce dünyasına necə “göz gəzdirir”
Vacib məqam: widget özü ödəniş tərəfinə getmir və hətta ACP detalları haqda bilməyə borclu deyil; onun rolu — backendlərdə hesablanmış və sabitlənmiş vəziyyəti istifadəçiyə göstərməkdir.
Ən sadə faydalı ssenari: uğurlu alışdan sonra istifadəçi çata qayıdıb “GiftGenius‑də son sifarişlərimi göstər” deyə bilər. GPT get_user_orders kimi MCP tool çağıracaq, o da backendinizə müraciət edəcək, widget isə siyahını göstərəcək.
Təsəvvür edək ki, son sifarişləri qaytaran Next.js API marşrutu var (sadələşdirilmiş):
// 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 });
}
getRecentOrdersForUser funksiyası artıq commerce qatınızda yaşayır, VB ilə işləyir və sifarişlərin strukturunu bilir. Öz növbəsində widget bu marşrutu window.fetch vasitəsilə çağırıb (bunu əvvəlki modullarda etmişdik) alış kartlarını göstərə bilər.
“Kombinasiya “MCP tool → sizin API → sifarişlər VB‑si → widget” istifadəçiyə elə təəssürat yaradır ki, guya App alışlar barədə “yaddaşa” malikdir, halbuki widget sadəcə backendin vəziyyətini göstərir.
6. Next.js üslubunda sadə ACP endpoint reallaşdırması
İndi əsas ACP endpointlərindən birinin — checkout_session yaradılmasının — tədris reallaşdırmasının necə görünə biləcəyini təsvir edək. Spesifikasiyada müqavilə kifayət qədər zəngindir, amma kurs üçün yalnız mahiyyəti saxlaya bilərik: skuId gəlir, biz onu feed/VB üzrə yoxlayırıq, sessiya yaradırıq və onun ID‑sini və məbləği qaytarırıq.
Qoy bizdə POST /api/checkout-sessions marşrutu olsun:
// 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 });
}
Burada bir neçə vacib məqam var.
Birincisi, məhz burada commerce qatı Product Feed/VB ilə tutuşdurulur: findSkuById feed ilə formalaşan eyni mənbəyə baxmalıdır. “Havadan” gələn heç nəyə — nə GPT‑yə, nə də widgeta — etibar etmirik.
İkincisi, yalnız ChatGPT/ACP kliyeninə gərək olanı qaytarırıq: sessiyanın ID‑si, məbləğ, valyuta və status (susmaya görə pending və ya seçilən terminologiyadan asılı olaraq not_ready_for_payment). Real ACP‑də bu sahələr daha çoxdur, o cümlədən əlçatan ödəniş metodları və fulfillment haqqında məlumat, amma tədris nümunəsi ilkin sessiya yaradılmasına fokuslanır.
Üçüncüsü, bu cür marşrutu müqavilə testləri ilə əhatə etmək rahatdır: sabah Product Feed strukturu dəyişsə, findSkuById və createCheckoutSession üçün testlər ChatGPT istifadəçilərə qəribə xətalar verməyə başlamazdan əvvəl bunu tutmalıdır.
7. ACP sessiyaları və ödəniş təminatçısı arasındakı əlaqə
Hələ ki, ödəniş təminatçısına toxunmadıq. Real inteqrasiyada təxminən belə baş verir (sadələşdirilmiş ssenari).
Əvvəlcə ChatGPT (ACP vasitəsilə) sizin POST /checkout_sessions endpointinizi çağırır. Backendiniz öz VB‑nizdə lokal sessiya yaradır. İstifadəçi Instant Checkout UI‑ində ödənişi təsdiq edəndə, platforma konkret merchant və məbləğ üçün PSP‑dən deleqasiya olunmuş ödəniş tokeni (Shared Payment Token) soruşur. Bu token sizə complete sorğusunda (və ya Delegated Payment Spec üzrə oxşar çağırışda) gəlir.
Bundan sonra siz real ödəniş məlumatlarına çıxış olmadan token istifadə edərək PSP‑də ödəniş yaradırsınız. PSP nəticə barədə webhook göndərir; siz sifarişin və/və ya checkout sessiyasının statusunu yeniləyirsiniz.
Tədris kodumuzda bu addımı imitasiya etməklə kifayətlənə bilərik. Məsələn, completeCheckoutSession funksiyası belə görünə bilər:
// src/lib/checkout.ts
export async function completeCheckoutSession(sessionId: string, spt: string) {
// Burada reallıqda deleqasiya olunmuş tokenlə (SPT) PSP API çağırılır
const paymentOk = await mockChargeWithToken(spt);
return paymentOk
? { status: "succeeded" as const }
: { status: "failed" as const };
}
PSP çağırışı və Shared Payment Token istifadəsi — Delegated Payment standartının hissəsidir, mockChargeWithToken isə bu spesifikanı imitasiya edən tədris arxitektura qatımızdır.
8. GiftGenius‑un uçdan‑uca axını: sorğudan ödənilmiş hədiyyəyə
İndi hər şeyi addımlar ardıcıllığı şəklində birləşdirək. Bu, məhz GiftGenius‑un “döyüş” hekayəsidir və bu səbəbdən bütün qatları kombinə edirik. İki fərqli dünyanı qarışdırmamaq üçün onları ayrı‑ayrılıqda nəzərdən keçirək.
Sxem A: Appsiz, yalnız Product Feed + ACP
Bu ssenaridə sizdə Product Feed və ACP backend var, amma nə ChatGPT App, nə də widget yoxdur. Bu, klassik Instant Checkout merchantıdır.
İstifadəçi ChatGPT‑yə belə yazır: “50 $‑dək rəqəmsal hədiyyə seç”. GPT uyğun SKU tapmaq üçün sizin Product Feed‑dən istifadə edir və onları öz native UI‑ində alış kartları şəklində göstərir. Burada hələ heç bir React kodunuz yoxdur — kartları tam olaraq ChatGPT çəkir.
İstifadəçi “Buy” düyməsinə klikləyir. Bu klik elə ChatGPT‑nin özünün tərəfindən emal olunur. Platforma:
- Product Feed əsasında line_items formalaşdırır.
- Sizin POST /checkout_sessions endpointinizi Agentic Checkout Spec üzrə çağırır.
- İstifadəçiyə Instant Checkout UI‑ni göstərir (ödəmə üsulu, ünvan və s.).
- Təsdiqdən sonra PSP‑dən Shared Payment Token alır və sizin .../complete endpointinizi çağırır.
- Sizdən checkout_session üçün yekun vəziyyəti alır və lazım gələrsə, sifariş barədə webhooku gözləyir.
Sizin kodunuz baxımından burada yalnız ACP endpoint‑lər və Product Feed işləyir. Heç bir Apps SDK, window.openai və widget ümumiyyətlə mövcud deyil. Və bu, tamamilə keçərli, “təmiz” ACP merchant ssenarisidir.
Sxem B: ChatGPT App və GiftGenius widget‑i ilə
İndi üzərinə ChatGPT App və GiftGenius widgetını əlavə edək. Product Feed və ACP backend yerindədir: onlar hələ də axtarış və ödənişi təmin edir. Fərq ondadır ki, artıq App daxilində öz UI və addımlar məntiqimiz yaranır.
Dialoqu təsəvvür edək: istifadəçi ChatGPT‑yə “Ana üçün 50 $‑dək hədiyyə seç” yazır. GPT bunun commerce sorğusu olduğunu anlayır və GiftGenius App‑dən istifadə etməyi təklif edir. Widget bir neçə dəqiqləşdirici sual verir: yaş, maraqlar, ölkə. Bundan sonra GPT sizin search_gifts adlı MCP tool‑unuzu filtrlərlə çağırır, MCP server kataloqa (VB və ya hazırlanmış indeksə) müraciət edir, bir neçə uyğun SKU tapır və onları strukturlaşdırılmış şəkildə qaytarır.
GPT bu məlumatları widgeta ötürür və widget öz xüsusi hədiyyə kartlarını (React komponentləri, karusellər və s.) göstərir. Bu artıq sizin dizaynınız və UX‑inizdir, ChatGPT‑nin standart alış UI‑i deyil.
İstifadəçi widgetdakı “Al” düyməsinə klikləyəndə, A sxemindən fərqli hadisə baş verir. Bu klik widget tərəfindən emal olunur:
- Widget istifadəçinin hansı SKU seçdiyini anlayır.
- Öz API‑si vasitəsilə (məsələn, POST /api/checkout-sessions) backendinizə müraciət edir ki, checkout_session yaratsın (və ya artıq hazırlanmış sessiyanın ID‑sini alsın).
- Daha sonra widget Apps SDK‑da belə bir runtime metod çağırır:
// Metodun aktual siqnatürünü Apps SDK sənədlərində baxın await window.openai.requestCheckout({ checkoutSessionId: session.id, ... });Bu çağırış — widgetın təşəbbüsüdür. ChatGPT üçün bu bir siqnaldır: “Bu checkout_session üçün Instant Checkout açmağın vaxtıdır”.
Sonra ChatGPT platforması artıq A sxeminə çox bənzər şəkildə, amma kulis arxasında işləyir:
- istifadəçiyə native Instant Checkout UI göstərir;
- PSP‑dən Shared Payment Token alır;
- sizin sessiya tamamlanma ACP endpointinizi (.../complete) çağırır;
- backendinizdən gələn webhookların qəbulu və emalında iştirak edir.
Yəni B sxemində checkout‑u Apps SDK vasitəsilə widget işə salır və ACP çağırışları (checkout_session yaratmaq/bitirmək) ya bundan əvvəl (sessiyanı backenddə özünüz yaradanda), ya da requestCheckout sonrası baş verir, amma həmişə server tərəfində.
Eyni zamanda widget sizin API‑nizə (/api/orders/...) və MCP tool‑larına əsaslanaraq paralel şəkildə “Alışın rəsmiləşdirilməsi”, statuslar və sifarişin önbaxışını göstərə bilər.
Əgər B sxemini diaqramla təsvir etsək, təxminən belə alınar:
sequenceDiagram
participant User as İstifadəçi
participant GPT as ChatGPT / GPT
participant W as GiftGenius Widget
participant MCP as MCP serveri
participant ACP as Commerce Backend
participant PSP as Ödəniş təminatçısı
User->>GPT: "50 $‑dək hədiyyə seç"
GPT->>MCP: search_gifts(...)
MCP-->>GPT: SKU siyahısı
GPT->>W: kartların renderi üçün məlumatlar
User->>W: klik "Al"
W->>ACP: POST /api/checkout-sessions (skuId)
ACP-->>W: checkout_session (id, məbləğ, valyuta)
W->>GPT: window.openai.requestCheckout({ checkoutSessionId })
GPT->>User: Instant Checkout UI
User->>GPT: ödəmənin təsdiqi
GPT->>PSP: Shared Payment Token sorğusu
PSP-->>GPT: SPT
GPT->>ACP: complete(sessionId, SPT)
ACP->>PSP: charge(SPT)
PSP-->>ACP: ödəniş nəticəsi
ACP->>GPT: sifariş statusu
GPT->>User: uğurlu/uğursuz ödəniş barədə mesaj
Əsas fərq A sxemi ilə belədir:
- A‑da kartları və “Buy” düyməsini elə ChatGPT‑nin özü çəkir və məhz o, birbaşa ACP çağırışı edir.
- B‑də kartları və “Al” düyməsini sizin widget çəkir və məhz o, window.openai.requestCheckout(...) çağırır. Bundan sonra isə ChatGPT səhnə arxasında sizin ACP backend və PSP ilə danışır.
Insight
ChatGPT öz SDK‑sında tezliklə tətbiqlərdə monetizasiya olacağını yazıb. Elə də olacaq. Widgetlara artıq bir neçə hələ elan olunmamış metod əlçatandır. Onlardan ən maraqlısı — requestCheckout().
Çağırış belə görünür:
window.openai.requestCheckout({
id: "checkout_session_123",
payment_provider: {
merchant_id: "stripe",
supported_payment_methods: ["card"]
},
...
}
Bu, istifadəçiyə ödənişi tamamlamağa imkan verən dialoq pəncərəsi göstərir. Odur ki, tətbiqinizi sanki monetizasiya artıq aktivdir kimi layihələndirin: siz işi bitirənə qədər elə belə də olacaq.
9. Kurs üçün mini reallaşdırma: monolit backend
Arxitektura ilə bağlı modullarda artıq sual verilmişdi: hər şeyi bir servisdə etmək, yoxsa dərhal MCP server, commerce backend və ayrıca ödəniş inteqrasiyası servisinə bölmək? Tədris məqsədləri üçün çox vaxt “demək olar ki, monolit” kifayətdir: bir repozitoriya, bir deploy, amma məntiq qatlara səliqə ilə bölünür.
Tədris üçün GiftGenius variantı belə görünə bilər: Next.js tətbiqi, burada:
- widget app/widget/page.tsx daxilində yaşayır;
- ACP endpointləri — app/api/checkout-sessions və qonşu marşrutlarda;
- MCP alətləri — app/api/mcp/route.ts və ya ayrıca qovluqda;
- sifarişlərlə iş — src/lib/orders.ts, src/lib/checkout.ts və yaxın modullarda.
Fiziki olaraq bu bir serverdir (xüsusən dev/staging mərhələsində), amma məntiqi olaraq artıq üç rolda düşünürsünüz: UI (widget), MCP (GPT üçün alətlər/resurslar) və ACP (commerce backend).
Daha sonra, prodakşn modullarında bu “monolit” bir neçə servisə və mühitə bölünəcək, onların qarşısında isə MCP Gateway yaranacaq. Amma 14‑cü modul səviyyəsində belə “düzgün qatlarla monolit” artıq çox inandırıcı arxitektura verir.
10. Praktiki tapşırıq: ACP ətrafında sizin arxitekturanız
Yuxarıda deyilənlərin nəzəriyyədə qalmaması üçün bunu öz domeninizə tətbiq etməyin mənası var. Mühazirə çərçivəsində iki mini məşq etmək olar.
Birincisi, öz ssenarinizi seçin: SaaS abunəsi, bronlama, yemək çatdırılması, onlayn kurslar — məhsul/xidmət, qiymət və məntiqli checkout olan istənilən iş. Fazalı modeli xatırlayın: discovery → decision → checkout → post‑payment.
İkincisi, GiftGenius arxitekturasına söykənərək sərbəst formada təsvir edin: Product Feed‑i necə quracaqsınız (SKU və qiymətlər harada yaşayır, kim onları yeniləyir), ACP müqaviləsini harada reallaşdıracaqsınız (ayrıca servis, yoxsa mövcud backendin bir hissəsi), ödəniş təminatçısını necə qoşacaqsınız və widgetınız (əgər varsa) MCP və Apps SDK vasitəsilə bütün bunlarla necə qarşılıqlı əlaqədə olacaq.
Aydınlaşdırmaq faydalıdır: layihəniz yalnız A sxemindən (App olmadan Instant Checkout), yalnız B sxemindən (App + widget), yoxsa hər iki ssenaridən eyni vaxtda istifadə edəcək. Hətta belə mətn eskizi real inteqrasiya mərhələsində gözlənilməzlik riskini xeyli azaldır.
11. Product Feed, ACP və widget inteqrasiyasında tipik səhvlər
Səhv №1: iki fərqli kataloq — biri axtarış, digəri checkout üçün.
Bəzən komanda əvvəlcə GPT üçün sürətli “axtarış” feed‑i qaldırır (məsələn, kiçik JSON), sonra isə ayrıca sifarişlər üçün commerce VB qurur. Onları ümumi ID və ümumi yeniləmə məntiqi ilə bağlamasanız, GPT istifadəçiyə artıq satıla bilməyən və ya köhnə qiymətə olan məhsulları təklif edə bilər. Düzgün yanaşma — həm Product Feed‑in formalaşdığı, həm də ACP endpointləri üçün daxili cədvəllərin çıxdığı bir həqiqət mənbəyidir.
Səhv №2: GPT və ya widgetdan gələn məlumatlara etibar.
checkout_session daxilinə skuId və qiymət gələndə bu dəyərlərə inanmaq çox cəlbedici olur: “axı GPT yalan danışmaz”. Amma model asanlıqla “yaradıcı” ola və ya SKU‑ları səhv sala bilər, istifadəçi isə sorğunu sındırmağa cəhd edə bilər. Gələn məlumatları Product Feed/VB ilə tutuşdurmadan siz yanlış şeyi və yanlış qiymətə sata bilərsiniz. Hər bir ACP endpoint ilkin kataloq saxlancına görə validasiya ilə başlamalıdır.
Səhv №3: widget və commerce backend rollarının qarışdırılması.
Bəzən tərtibatçılar vərdiş üzrə front‑enddən dərhal ödəniş SDK‑sını çağırır, Stripe‑də sessiyalar yaradır və ümumiyyətlə adi sayt kimi yaşayırlar. ChatGPT Apps kontekstində bu, təhlükəsizlik modelini pozur və ACP‑yə ziddir: ödəniş axını ChatGPT və sizin commerce backendinizdən keçməlidir, widget isə yalnız vəziyyəti göstərməli və hadisələri (məsələn, requestCheckout) göndərməlidir. Widget ödəniş konturu haqqında həddindən artıq məlumatlıdırsa, həm mürəkkəblik, həm də risklər artır.
Səhv №4: ACP müqaviləsini həddən artıq sadələşdirmək.
Tədris nümunəsində detallarda batmamaq üçün yalnız skuId, məbləğ və status saxlayırıq. Problem o zaman başlayır ki, belə “demo müqavilə” hiss etmədən prodakşna sızır. Birdən məlum olur ki, ünvan, vergilər, çatdırılma metodları, promokodlar üçün sahələr çatmır və siz onları xaotik şəkildə “bəndləməyə” başlayırsınız. Daxili modelləri real ssenarilərə ehtiyatla layihələndirmək daha yaxşıdır, hətta bəzi sahələr ilk vaxtlar istifadə olunmasa belə.
Səhv №5: sifarişlərlə istifadəçilər arasında əlaqənin olmaması.
Demonun özündə yalnız orderId və skuId ilə kifayətlənmək asandır, amma istifadəçinin bir həftə sonra qayıdıb “Alışlarımı göstər” deyəcəyini düşünməmək də olar. Əgər başlanğıcdan sifariş və checkout sessiyasına userId (və ya digər dayanıqlı identifikator) daxil edilməsə, sonra miqrasiyalar və mürəkkəb körpülər qurmaq lazım gələcək. ChatGPT ətrafında commerce arxitekturası demək olar ki, həmişə GPT‑nin cari dialoqu istifadəçinin sifariş tarixçəsi ilə əlaqələndirə biləcəyini nəzərdə tutur — bunu öncədən nəzərə almağa dəyər.
Səhv №6: webhooks və idempotentliyin əhəmiyyətini az qiymətləndirmək.
Mühazirədə webhooks barədə yalnız danışdıq, dərin təhlili növbəti modullarda olacaq. “Webhook bir dəfə gələcək, sifarişi yeniləyərik — vəssalam” düşünmək asandır. Təcrübədə ödəniş sistemləri hadisələri təkrar göndərməyi sevir, şəbəkə isə cavabları itirir. Əgər sifarişləri və checkout sessiyalarını checkoutSessionId və ya paymentId üzrə idempotent strukturlar kimi layihələndirməsəniz, cüt silinmələr, təkrarlanan sifarişlər və PSP ilə VB arasında aydın olmayan uyğunsuzluqlar əldə edə bilərsiniz.
Səhv №7: Product Feed‑də məhdudiyyətlər və siyasəti nəzərə almamaq.
Sürətli demo feed arxasınca yaş məhdudiyyətləri, ölkələr üzrə əlçatanlıq, qadağan olunmuş kateqoriyalar və digər “xırdalıqlar” haqda asanlıqla unutmaq olur. Sonra elə çıxır ki, GPT istifadəçiyə onun regionunda və ya yaşında satılmayan məhsulu şadyanalıqla təklif edir. Siyasət və məhdudiyyətlərlə bağlı sahələri ilk gündən layihələndirmək və doldurmaq lazımdır, hətta hələlik yalnız zərərsiz rəqəmsal hədiyyələr satsanız belə.
GO TO FULL VERSION