Ödeme akışı simülatörü

Kenetlenme Sekansı

Tek bir kart ödemesini 3-D Secure doğrulamasına gönderip geri getirin, sonra gerçek paraya mal olan el değiştirmeleri bozun.

Kurgusal satıcı · eğitsel model · gerçek ödeme yok

Uçuş öncesi

Eklenecek arızaTemiz yaklaşmaArıza yok. Yönlendirmeli bir kart ödemesinin dayandığı el değiştirmeleri izleyin.Callback başka replikadaCallback bu ödemeyi hiç görmemiş bir replikaya düşer.Doğrulamadan sonra sekme kapandıAlıcı doğrulamayı tamamlar, sonra geri yönlendirmeden önce sekmeyi kapatır.Callback iki kez geliyorAynı sonuç iki kez teslim edilir.Tahsilat zaman aşımına uğruyorSağlayıcı kartı tahsil eder ama yanıt geri gelmez.

SavunmalarPaylaşılan ödeme durumuÖdeme bağlamı, anahtarları belli bir süre sonra silinen paylaşılan bir anahtar-değer deposuna yazılır; böylece ödemeyi herhangi bir replika tamamlayabilir.Idempotency anahtarlarıSağlayıcıya giden istekler bir idempotency anahtarı taşır; gelen callback’ler ödeme ya da olay kimliğine göre tekilleştirilir. Tekrar gelen istek, yeniden çalışmak yerine ilk sonucu döner.Sipariş durum makinesiSipariş yalnızca izinli geçişlerle ilerler ve her geçiş tek bir koşullu güncellemedir (durumu yalnızca hâlâ beklenen değerdeyse değiştirir); böylece aynı anda çalışan iki tekrar bile birlikte geçemez. “Ödendi → ödendi” ve “zaman aşımı → başarısız” reddedilir.Webhook + mutabakat işiSunucu tarafı bildirimler ve düzenli bir tarama, sağlayıcının kayıtlarını siparişlerle karşılaştırır ve düzeltebildiğini düzeltir.

Arızayı ya da bir savunmayı değiştirmek sekansı baştan başlatır. Adres çubuğu kurulumunuzu saklar; böylece paylaşabilirsiniz.

Kenetlenme hattı

Kestrel Supply (kurgusal) · ORD-2048 · 18.400,00 ₺

Alıcının tarayıcısı
Satıcı API’si · A replikası
Ödeme sağlayıcısı
Banka ACS’si

01SiparişAlıcı kurgusal bir B2B siparişi verir.henüz ulaşılmadı
02Ödeme başlatmaSatıcı bir ödeme açar ve neyi başlattığını hatırlar.henüz ulaşılmadı
03DoğrulamaBankanın ACS’si alıcıdan kartın kendisine ait olduğunu kanıtlamasını ister.henüz ulaşılmadı
04Geri dönüşAlıcının tarayıcısı sonucu satıcıya geri getirir.henüz ulaşılmadı
05TahsilatSatıcı provizyonu tahsilata çevirir.henüz ulaşılmadı
06OnayTek ödeme, tek onaylı sipariş, tek sevkiyat.henüz ulaşılmadı

Beklemede. Bir arıza ve savunmalarınızı seçin, ardından Sonraki adım’a basın.

Adım 0/10

Hesap defteri

Provizyonda: 0
Tahsil edilen: 0
İade edilen: 0
Onaylanan sipariş: 0
Sevkiyat: 0

Net tahsilat / onaylı sipariş0 net tahsilat, 0 onaylı siparişUçuşta: sonuç henüz kesin değil.

Satıcıdaki sipariş: Oluşturulmadı
Alıcının gördüğü: Ödeme sayfası

Uçuş kaydı

Henüz mesaj yok. İlk mesajı göndermek için Sonraki adım’a basın.

Değerlendirme

Satıcının ve alıcının elinde ne kaldığını görmek için sekansı sonuna kadar oynatın.

Model sınırları

Kestrel Supply, sipariş, ödeme sağlayıcısı ve buradaki tüm olaylar kurgusaldır. Hiçbir banka ya da ödeme hizmetine bağlanılmaz ve kart formu yoktur. Akış tek sağlayıcı, tek kart ve tek doğrulamaya indirgenmiştir; her arızanın önceden yazılmış sabit bir sonucu vardır. Bu modelde satıcı, belirteç → sipariş eşlemesini yalnızca A replikasının belleğinde tutar. Gerçek sağlayıcılar ödemeye kendi referansınızı eklemenize (iyzico, conversationId değerinizi callback’e geri gönderir) ya da ödemeyi kimliğiyle sorgulamanıza (Stripe bu kimliği dönüş adresine ekler) izin verir; bu da “Callback başka replikada” arızasını önler. Sağlayıcılar başka açılardan da farklıdır: bazıları ödemeyi yalnızca satıcı callback’ten sonra onları çağırdığında tamamlar, bazıları webhook ile bildirir; provizyon süreleri kart ağına göre değişir. Buradaki hiçbir sonuç gerçek bir satıcının yaşadığı bir olayı anlatmaz.

Bu oda neden var

Umut’un projeler bölümündeki B2B pazar yeri çalışması 3-D Secure ve havale/EFT ödeme akışlarını içerir. Ödemeler, kaybolan bir el değiştirmenin gerçek paraya mal olduğu yerdir; bu oda o el değiştirmeler için tasarım yapmakla ilgilidir. Buradaki satıcı, sipariş ve olaylar kurgusaldır.

Kaynaklar

EMVCo: EMV 3-D Secure genel bakış (yeni sekmede açılır)
Düşük riskli ödemeler ek adım olmadan geçebilir; daha riskli ödemelerde banka tek kullanımlık kod gibi ek bir doğrulama isteyebilir.
EMVCo: 3DS mesajları (AReq, ARes, RReq) (yeni sekmede açılır)
3DS Sunucusu Doğrulama İsteğini (AReq) gönderir; Dizin Sunucusu isteğin verilerini bankanın ACS’sine iletir. ACS ek doğrulama isteyebilir ve sonucu bir Sonuç İsteği (RReq) ile bildirir.
Stripe: 3D Secure ile doğrulama (yeni sekmede açılır)
Doğrulamadan sonra müşteri, sorgu dizesinde ödemenin kimliğiyle dönüş adresinize (return URL) gönderilir; ayrı tahsilatta ödeme ardından requires_capture durumunda bekler.
Stripe: Ödeme yönteminde provizyon (yeni sekmede açılır)
Provizyon, siz tahsil edene kadar tutarı bloke eder; çevrim içi kart provizyonları genellikle 7 gün geçerlidir, sonra tutar serbest kalır.
Stripe: Idempotent istekler (yeni sekmede açılır)
Aynı idempotency anahtarıyla yapılan tekrar, ilk isteğin kayıtlı sonucunu döner; işlem iki kez yapılmaz.
Stripe: Webhook’lar, tekrarlar ve sıralama (yeni sekmede açılır)
Bir uç nokta aynı olayı birden fazla kez ve sırasız alabilir; işlediğiniz olay kimliklerini kaydedin ve kayıtlı olanları yeniden işlemeyin.
Stripe: Siparişleri tamamlama (yeni sekmede açılır)
Müşterinin dönüş sayfanıza ulaşması garanti değildir; bu yüzden sipariş tamamlama webhook gerektirir ve birden fazla, hatta eş zamanlı çalışmaya dayanıklı olmalıdır.
iyzico: 3DS entegrasyonu (yeni sekmede açılır)
Banka adımından sonra iyzico sonucu paymentId ve conversationId ile callbackUrl adresinize POST eder; ödemeyi ardından ayrı bir Auth isteği tamamlar.
Redis: NX ve EX ile SET (yeni sekmede açılır)
SET … NX anahtarı yalnızca yoksa yazar, EX ona bir sona erme süresi verir: paylaşılan ödeme bağlamı ve idempotency kayıtları için yapı taşları.