Oturumlar
Bir CheckoutSession, alıcının etkileşim kurduğu şeydir — barındırılan checkout URL’sini barındıran TTL’li, tek kullanımlık bir nesnedir. Üç temel varlıktan en hafif olanıdır; ağır iş Orders ve Payment Intent’lerde (aşağıya bakınız) gerçekleşir.
Üç varlıklı veri modeli
CheckoutSession ← 1:1 → Order ← 1:N → PaymentIntent
(alıcı) (katalog) (her ödeme denemesi)| Varlık | Amaç | Ömür |
|---|---|---|
| CheckoutSession | Alıcıya yönelik — session_key, checkout_url, TTL içerir | Dakikalar (varsayılan 30) |
| Order | Katalog durumunuz — line item’lar, toplamlar, iadeler | Kalıcı kayıt |
| PaymentIntent | Bir zincir/varlık üzerinde bir ödeme denemesi | Saatler; tahsil edilir veya süresi dolar |
Bir oturum ve siparişi birlikte oluşturursunuz (POST /b2b/v1/checkout-sessions/quick
aracılığıyla). Alıcı checkout sayfasında her varlık seçtiğinde, doğru zincire
karşı yeni bir PaymentIntent açılır. Checkout sırasında varlık değiştirirlerse,
önceki intent EXPIRED durumuna geçer ve yenisi başlar.
Tanımlayıcı
Bir oturum session_key’i ile tanımlanır:
cst_G-SO92J7HNWkwMHEHjD4oO1ZURL güvenli, önekten sonra ~24 karakter (18 rastgele bayt, base64url ile
kodlanmış, padding yok). Barındırılan checkout sayfası
https://checkout.infraio.xyz/<session_key> adresindedir — oturum
anahtarını, o tek checkout için bir bearer kimlik bilgisi olarak değerlendirin.
Yaşam döngüsü — CheckoutSession
| Durum | Anlamı |
|---|---|
ACTIVE | Oturum oluşturuldu ve açık. Checkout URL’si kullanılabilir. |
COMPLETED | Bu oturumdaki bir PaymentIntent tahsil edildi. Order artık PAID (veya eksik ödendiyse PARTIAL_PAID). |
EXPIRED | expires_at tahsil edilmeden geçti. Cleanup worker durumu değiştirdi ve açık Order’ları iptal etti. |
CANCELED | Açık iptal — ya alıcı “iptal” butonuna bastı ya da siz iptal uç noktasını çağırdınız. |
Üç son durum karşılıklı olarak özel ve nihaidir. Yeniden denemek isterseniz (örn. eksik ödeme sonrası) aynı Order’a karşı yeni bir CheckoutSession oluşturulabilir.
TTL
- Varsayılan: 30 dakika (oluşturma sırasında
expires_inalanı ile saniye cinsinden yapılandırılabilir). - Sınırlar: Sunucu tarafında sert bir min/max uygulaması yoktur. Mantıklı değerler kullanın — 60 saniyenin altı, meşru alıcıların zaman aşımına uğrama riskini taşır; 7 günün üzeri, neredeyse kesinlikle terk edilmiş bir token üzerinde kapasite tutar. Alıcınızın beklenen karar penceresine uygun bir sayı seçin.
- Satıcı başına varsayılan: Panel üzerinden yapılandırılabilir, ancak
yalnızca eski
POST /b2b/v1/checkout-sessions(iki adımlı) yolu buna uyar.POST /b2b/v1/checkout-sessions/quickyolu, satıcı başına ayardan bağımsız olarakexpires_inbelirtilmezse her zaman 30 dakika olarak geri döner. Quick yolunda farklı bir varsayılana ihtiyacınız varsa, her çağrıdaexpires_in’i açıkça gönderin. - Uygulama: Okumada tembel + periyodik bir cleanup worker.
expires_atgeçmiş bir oturum, durum alanı henüz yazılmamış olsa bileEXPIREDolarak değerlendirilir, bu yüzden tam süre dolma anında API üzerinden durumu okumaya güvenmeyin.
Eksik ödeme
Bir alıcı oturum tutarından daha az gönderirse, PaymentIntent yine de kısmi
tutar için tahsil edilir ve Order PARTIAL_PAID durumuna geçer.
CheckoutSession COMPLETED durumuna geçer (bir PaymentIntent tahsil edildi),
dolayısıyla artık yeniden kullanılabilir değildir.
Eksikliği tam ödeme olarak kabul etmek için, sipariş PAID durumuna
çözümlenebilir — bkz. Kavramlar → Siparişler (bugün
herkese açık bir resolve API’si yok; self-servis bir akış için bunun yerine
kalanı tahsil edin). Kalanı tahsil etmek için aynı Order’a karşı kalan
tutarda yeni bir CheckoutSession oluşturun.
Fazla ödeme
Alıcı oturum tutarından daha fazla gönderirse (nadir, ama manuel transferlerde olur), zincir üstü tarayıcı 24 saat içinde fazla ödemeyi yakalar ve bir satıcı uyarısı yayar. Otomatik bir iade yoktur — iade API’si veya panel üzerinden manuel olarak verin.
Yanlış varlık ödemeleri
Depozito adresi (session, chain, asset) tuple başına oluşturulur. Bir
alıcı adrese yanlış varlık gönderirse, zincir üstü eşleştirici onu tanımaz
ve PaymentIntent, TTL süresi dolana kadar açık kalır. Fonları geri
alabiliriz ama bu bir destek akışıdır, otomatik değil — alıcılara checkout
sayfasında gösterilen tam varlığı göndermelerini söyleyin.
Oluşturmada idempotency
POST /b2b/v1/checkout-sessions/quick istek gövdesinde bir
idempotency_key alanı kabul eder (not: gövde alanı, HTTP başlığı
değil). Müşterinizin doğal bir anahtarı yoksa, bunun için otomatik bir
UUID oluşturun — SDK varsayılan olarak bunu yapar.
Anahtar Order’ı tekrar etmeyi engeller, CheckoutSession’ı değil. Aynı
anahtarla yeniden denemede, /quick orijinal siparişi döndürür
(order_id stabildir) ancak yeni bir CheckoutSession üretir — her
seferinde yeni bir session_key ve checkout_url. Bu kasıtlıdır: bir
Order birden fazla checkout denemesini destekleyebilir (bkz.
Siparişler), bu nedenle yeniden denenen bir /quick,
siparişi tekrarlamadan alıcıya temiz bir oturum verir.
İki davranış Stripe stili bir idempotency katmanından farklıdır — dikkat edin:
- Gövde hash’lenmez veya karşılaştırılmaz. Bir anahtarı farklı bir
gövde ile yeniden kullanmak
409döndürmez — sunucu, o anahtarın altında zaten saklanan siparişi sessizce döndürür ve yeni gövdeyi yok sayar. Bu yüzden biridempotency_key’i tek bir mantıksal sipariş için tek atışlık bir token olarak değerlendirin; farklı sepetler arasında asla yeniden kullanmayın. - Yalnızca Order tekrar etmez, oturum değil. Aynı checkout URL’sini
geri istiyorsanız, ilk yanıttan
session_key/checkout_url’yi saklayın —/quick’i yeniden çağırmak eskisini döndürmez. Bir siparişe karşı üretilen her oturumu listelemek içinGET /b2b/v1/checkout-sessions/by-order/:order_idkullanın.
API uç noktaları
| Method | Path | Notlar |
|---|---|---|
POST | /b2b/v1/checkout-sessions/quick | Tek çağrıda sipariş + oturum oluştur |
POST | /b2b/v1/checkout-sessions | Mevcut bir siparişe karşı oturum oluştur |
GET | /b2b/v1/checkout-sessions/by-order/:order_id | Bir sipariş için tüm oturumları listele (yeniden deneme geçmişi için) |
GET | /checkout/:session_key | Public — alıcının tarayıcısının vurduğu uç |
Tam oluşturma istek gövdesi ve imzalama için Hızlı başlangıç sayfasına bakın.
Sırada ne var
- Kavramlar → Siparişler — Order varlığı (sipariş karşılama için gerçek kaynak olarak ele aldığınız varlık).
- Kavramlar → Zincirler ve varlıklar — desteklenen ağlar ve zincir başına kesinlik varsayımları.
- Webhook’lar → Genel bakış — her oturum durum geçişinde hangi event’ler tetiklenir.