E-Ticarette Ödeme Altyapısı Nasıl Çalışır?
Ders 1 / 10 · 30 dakika okuma · İleri
Müşterinin ödeme butonuna basmasından işlem sonucunun siparişe yansımasına kadar ödeme akışını; müşteri, işyeri, ödeme hizmeti ve banka rollerini birlikte ele alarak öğrenin.
Bu Derste Öğrenecekleriniz
- ✓E-ticaret ödeme ekosistemindeki temel tarafları tanımak
- ✓Ödeme başlatma ile gerçek tahsilatın aynı kavram olmadığını açıklamak
- ✓Yetkilendirme ve işlem sonucu akışını adım adım takip etmek
- ✓Sipariş durumu ile ödeme durumunu birbirinden ayırmak
- ✓Başarılı, başarısız, bekleyen, iptal ve iade durumlarını modellemek
- ✓Ödeme callback/webhook bildirimlerinin neden gerekli olduğunu anlamak
- ✓Tekrarlanan ödeme ve belirsiz işlem sonucu risklerini tanımak
Bir müşteri e-ticaret sitesinde 'Öde' butonuna bastığında yalnızca para transferi gerçekleşmez. Siparişin hangi tutar için ödeme beklediği, hangi ödeme yönteminin kullanıldığı, işlemin banka veya ödeme altyapısı tarafından kabul edilip edilmediği ve sonucun siparişe nasıl yansıtılacağı birlikte yönetilir.
Not — Temel ayrım
1. Ödeme ekosistemindeki temel tarafları tanıyın
Kartlı e-ticaret ödemesinde müşteri, e-ticaret işletmesi, ödeme hizmetini sağlayan yapı ve bankacılık/kart altyapısı birlikte çalışır. Teknik mimari kullanılan modele göre değişse de işletme açısından temel ihtiyaç; ödeme isteğini güvenli biçimde başlatmak ve güvenilir işlem sonucunu sipariş sistemiyle ilişkilendirmektir.
| Taraf | Temel rol | İşletmenin gördüğü sonuç |
|---|---|---|
| Müşteri | Ödeme yöntemini seçer ve gerekli doğrulamayı tamamlar | Ödeme denemesi |
| E-ticaret işletmesi | Sipariş ve tahsil edilmesi gereken tutarı oluşturur | Sipariş/ödeme kaydı |
| Ödeme altyapısı / sanal POS | Ödeme isteğini işler ve sonucu iletir | İşlem kimliği ve durum |
| Banka/kart altyapısı | İşlemin yetkilendirme ve finansal akışında rol alır | Onay veya ret sonucu |
2. Ödeme isteğini sipariş tutarından üretin
Ödeme tutarı müşterinin tarayıcısından gelen serbest bir değere güvenilerek belirlenmemelidir. Sepet, kampanya, vergi, kargo ve indirim hesapları sunucu tarafında doğrulandıktan sonra ödenecek nihai tutar sipariş veya ödeme oturumu ile ilişkilendirilmelidir.
Örnek — Tutar bütünlüğü örneği
3. Ödeme başlatma ile başarılı tahsilatı ayırın
Kullanıcının ödeme sayfasına ulaşması veya ödeme formunu göndermesi işlemin başarılı olduğu anlamına gelmez. Ödeme sağlayıcısı/banka tarafından işlem sonucu üretilmeli ve işletme bu sonucu kendi ödeme kaydına işlemelidir.
| Aşama | Örnek durum | Sipariş açısından anlam |
|---|---|---|
| Ödeme oluşturuldu | pending/created | Henüz tahsilat sonucu yok |
| İşlem işleniyor | processing | Sonuç kesinleşmemiş olabilir |
| Başarılı | paid/success | Ödeme doğrulandıktan sonra sipariş ilerleyebilir |
| Başarısız | failed/declined | Yeni ödeme denemesi gerekebilir |
| İptal | cancelled | İşlem tamamlanmadı |
| İade | refunded/partially_refunded | Başarılı tahsilatın tamamı veya bir kısmı geri döndü |
Uyarı — Durum adları sağlayıcıya göre değişebilir
4. Başarı sayfasını ödeme kanıtı olarak kullanmayın
Müşterinin tarayıcısı ödeme sonrası başarı URL'sine yönlendirilebilir. Ancak tarayıcı yönlendirmesi kesilebilir, kullanıcı sekmeyi kapatabilir veya istemci tarafındaki akış manipüle edilebilir. Siparişin ödenmiş sayılması doğrulanmış sunucu tarafı işlem sonucuna dayanmalıdır.
İpucu — İki farklı kanal düşünün
5. Callback veya webhook sonucunu doğrulayın
Ödeme sağlayıcısının gönderdiği bildirim, ilgili işlem kimliği ve siparişle eşleştirilmeli; sağlayıcının sunduğu imza, anahtar veya doğrulama mekanizması kullanılmalıdır. Gelen her HTTP isteğini güvenilir ödeme sonucu kabul etmek ciddi bir güvenlik hatasıdır.
- Sipariş için benzersiz ödeme kaydı/işlem referansı oluşturun.
- Ödeme isteğini doğrulanmış tutarla sağlayıcıya gönderin.
- Müşteri gerekli ödeme/doğrulama adımlarını tamamlasın.
- Sağlayıcının işlem sonucunu sunucu tarafında alın.
- Bildirim bütünlüğünü sağlayıcının yöntemine göre doğrulayın.
- İşlem kimliği, tutar, para birimi ve sipariş ilişkisini kontrol edin.
- Ödeme durumunu güncelleyin.
- Sipariş durumunu yalnız iş kuralı uygunsa ilerletin.
6. Aynı ödemenin iki kez işlenmesini önleyin
Müşteri ödeme butonuna iki kez basabilir, ağ bağlantısı kesilebilir veya callback aynı olay için tekrar gönderilebilir. Sistem aynı ödeme olayını ikinci bir tahsilat ya da ikinci sipariş sonucu gibi işlememelidir.
Örnek — Tekrarlanan callback
7. Belirsiz sonucu 'başarısız' varsaymayın
Ödeme isteği gönderildikten sonra bağlantı koparsa işletme işlemin gerçekten başarısız olduğunu bilmiyor olabilir. Müşteriden hemen yeniden ödeme istemek çift tahsilat riski yaratabilir. Belirsiz işlem sağlayıcı sorgusu veya sonradan gelen doğrulanmış bildirimle uzlaştırılmalıdır.
Uyarı — Timeout ≠ ret
8. Ödeme ve sipariş durumlarını ayrı durum makineleri olarak düşünün
| Ödeme durumu | Olası sipariş davranışı |
|---|---|
| Bekliyor | Sipariş ödeme bekliyor |
| Başarılı | Sipariş hazırlık/işleme alınabilir |
| Başarısız | Sipariş ödeme beklemeye devam edebilir |
| Kısmi iade | Sipariş geçmişi korunur; finansal durum güncellenir |
| Tam iade | Sipariş iade/iptal iş akışına göre güncellenir |
| Chargeback/uyuşmazlık | Finansal risk süreci ayrıca açılır |
9. Her ödeme denemesinin audit izini koruyun
İşletme yalnız 'ödendi' bilgisini değil; ödeme yöntemi, sağlayıcı işlem kimliği, oluşturma zamanı, sonuç zamanı, tutar, para birimi, hata/ret bilgisi, iade ve varsa uyuşmazlık kayıtlarını izleyebilmelidir. Hassas ödeme verilerinin saklanması ise güvenlik ve uyum kurallarına göre sınırlandırılmalıdır.
| Kayıt | Neden önemlidir? |
|---|---|
| İç ödeme ID | Sipariş ile ödeme olaylarını ilişkilendirir |
| Sağlayıcı işlem ID | Mutabakat ve destek incelemesini sağlar |
| Tutar/para birimi | Tahsilat bütünlüğünü kontrol eder |
| Durum zamanları | Operasyon ve hata analizini destekler |
| İade referansları | Net tahsilatı açıklar |
| Hata/ret kodu | Başarısız ödeme analizine veri sağlar |
10. Başarılı ödeme oranını tek başına yorumlamayın
Ödeme başarısı; müşteri davranışı, kart/banka kaynaklı retler, doğrulama adımları, teknik entegrasyon sorunları ve ödeme yöntemi dağılımından etkilenebilir. Düşük başarı oranı görüldüğünde hata kodları, cihaz/kanal, sağlayıcı ve zaman gibi boyutlarla neden analizi yapılmalıdır.
İlgili çözüm: Ödeme Entegrasyonları
Şimdi Uygulayın
Uygulama Görevi — Ödeme Yaşam Döngüsü Haritası
Kullandığınız veya örnek bir e-ticaret sitesini seçin. Sipariş oluşturma, ödeme başlatma, müşteri doğrulaması, başarılı/başarısız sonuç, callback, sipariş güncelleme, iade ve mutabakat adımlarını tek akış üzerinde gösterin. Her adım için sistem kaydını ve hata halinde yapılacak işlemi yazın.
| Adım | Kaynak sistem | Oluşan kayıt | Başarısızlık/istisna aksiyonu |
|---|---|---|---|
| Sipariş oluşturma | … | … | … |
| Ödeme başlatma | … | … | … |
| İşlem sonucu | … | … | … |
| Callback doğrulama | … | … | … |
| Sipariş güncelleme | … | … | … |
| İade | … | … | … |
İpucu — Kabul testi
Bu Derste Ne Öğrendik?
- ✓E-ticarette ödeme, müşterinin kart bilgisini girdiği tek ekranlık bir işlem değildir.
- ✓Sipariş, ödeme isteği, yetkilendirme, sonuç bildirimi ve tahsilat kayıtları ayrı ancak ilişkili süreçlerdir.
- ✓İşletme yalnız tarayıcıdaki başarı ekranına güvenmemeli; ödeme sağlayıcısının doğrulanmış işlem sonucunu kullanmalı ve sipariş ile ödeme durumlarını ayrı izlemelidir.