Kartlı Ödeme ve 3D Secure Süreci Nasıl Yönetilir?
Ders 3 / 10 · 30 dakika okuma · İleri
Kartlı ödeme akışında ödeme oluşturma, müşteri doğrulaması, 3D Secure, işlem sonucu ve sipariş güncelleme adımlarını güvenilir bir durum modeliyle yönetmeyi öğrenin.
Bu Derste Öğrenecekleriniz
- ✓Kartlı ödeme akışının temel adımlarını sıralamak
- ✓3D Secure doğrulaması ile ödeme sonucunu birbirinden ayırmak
- ✓Müşteri yönlendirmesi ve sunucu tarafı işlem bildirimlerinin rollerini açıklamak
- ✓Ödeme tutarı, sipariş ve işlem kimliği bütünlüğünü kontrol etmek
- ✓Doğrulama sırasında terk edilen ve sonucu belirsiz işlemleri yönetmek
- ✓Tekrarlanan callback ve kullanıcı retry senaryolarında mükerrer işleme karşı kontrol kurmak
- ✓Ödeme deneyimi ile güvenlik kontrollerini birlikte değerlendirmek
Kartlı ödeme akışı yalnız kart numarasının girilip bankadan onay alınmasından ibaret değildir. Sipariş tutarının hazırlanması, ödeme oturumunun oluşturulması, gerekiyorsa müşteri doğrulaması, işlem sonucunun alınması ve bu sonucun siparişe güvenli biçimde yansıtılması ayrı kontrol noktalarıdır.
1. Kartlı ödeme yaşam döngüsünü adımlara ayırın
- Sepet ve sipariş toplamını sunucu tarafında doğrulayın.
- Siparişe bağlı benzersiz ödeme kaydı oluşturun.
- Ödeme sağlayıcısına tutar, para birimi ve gerekli işlem bilgilerini gönderin.
- Gerekliyse müşteriyi 3D Secure/doğrulama adımına yönlendirin.
- Doğrulama ve ödeme işlem sonucunu sağlayıcı akışına göre alın.
- Sunucu tarafı bildirimi veya API sorgusuyla sonucu doğrulayın.
- Ödeme durumunu güncelleyin.
- İş kuralı uygunsa siparişi ödenmiş duruma taşıyın.
Not — İki ayrı soru
2. 3D Secure'ün rolünü doğru konumlandırın
3D Secure, kartlı e-ticaret işlemlerinde kart sahibinin doğrulanmasına yönelik bir güvenlik katmanıdır. Doğrulama deneyimi ve teknik akış kart, banka, sağlayıcı ve kullanılan protokol/entegrasyon modeline göre farklılaşabilir.
Uyarı — Doğrulama başarısı = tahsilat başarısı değildir
3. Ödeme durumlarını doğrulama durumlarından ayırın
| Katman | Örnek durum | Ne anlatır? |
|---|---|---|
| Doğrulama | Başladı | Müşteri doğrulama akışına girdi |
| Doğrulama | Tamamlandı | Gerekli doğrulama adımı tamamlandı |
| Doğrulama | Başarısız/terk | Doğrulama tamamlanamadı |
| Ödeme | Bekliyor/işleniyor | Nihai ödeme sonucu henüz kesin değil |
| Ödeme | Başarılı | İşlem sağlayıcı tarafından başarılı sonuçlandı |
| Ödeme | Başarısız | İşlem onaylanmadı |
| Ödeme | İade edildi | Önceki başarılı işlemin tamamı/kısmı geri döndü |
4. Sipariş, ödeme ve doğrulama kayıtlarını ilişkilendirin
Bir sipariş için birden fazla ödeme denemesi olabilir. Her deneme kendi işlem referansına sahip olmalı; hangi denemenin 3D Secure'e girdiği, hangisinin başarılı olduğu ve hangisinin başarısız kaldığı izlenebilmelidir.
Örnek — Bir sipariş, üç ödeme denemesi
5. Return URL ile callback/webhook'u aynı amaçla kullanmayın
Return URL müşterinin tarayıcı deneyimini sürdürür. Callback/webhook veya sağlayıcı API doğrulaması ise sistemler arasında işlem sonucunu güvenilir biçimde aktarmaya hizmet eder. Kullanıcının tarayıcısı kapansa bile sunucu tarafı ödeme sonucu işlenebilmelidir.
| Kanal | Temel amaç | Tek başına ödeme kanıtı mı? |
|---|---|---|
| Return/redirect URL | Müşteriyi siteye geri getirmek | Hayır |
| Callback/webhook | Sunucuya işlem olayı/sonucu bildirmek | Doğrulama sonrası kullanılmalı |
| Sağlayıcı işlem sorgusu | İşlemin güncel durumunu kontrol etmek | Sağlayıcı cevabı doğrulanarak kullanılabilir |
6. Callback bütünlüğünü kontrol edin
Ödeme sağlayıcısından geldiği iddia edilen bir isteğin içeriğine doğrudan güvenilmemelidir. Sağlayıcının dokümantasyonunda belirtilen imza/hash, secret veya diğer doğrulama mekanizması uygulanmalı; işlem ID, tutar, para birimi ve sipariş referansı beklenen kayıtla karşılaştırılmalıdır.
Uyarı — Tutar kontrolünü atlamayın
7. Doğrulama sırasında terk edilen işlemi tanımlayın
Müşteri doğrulama ekranına geçip işlemi tamamlamadan ayrılabilir. Bu durum gerçek bir banka reddiyle aynı olmayabilir. Analitik ve yeniden deneme deneyimi için terk, teknik hata ve finansal ret mümkün olduğunca ayrı sınıflandırılmalıdır.
| Sonuç | Müşteriye yaklaşım | Operasyonel kayıt |
|---|---|---|
| Kullanıcı terk etti | Güvenli biçimde yeniden ödeme seçeneği sunulabilir | Abandoned/cancelled nedeni |
| Doğrulama başarısız | Uygun açıklama ve yeni deneme | Authentication failure |
| Kart/banka reddi | Alternatif kart/yöntem önerilebilir | Decline kodu |
| Teknik hata | Durum doğrulanmadan çift ödeme tetiklenmemeli | Technical/unknown |
| Başarılı | Sipariş doğrulanmış sonuçla ilerletilir | Provider transaction ID |
8. Retry politikasını hata türüne göre tasarlayın
Her başarısız ödemede aynı isteği otomatik tekrar göndermek doğru değildir. Kesin ret, doğrulama başarısızlığı, geçici servis hatası ve sonucu belirsiz timeout farklı aksiyonlar gerektirir.
Örnek — Timeout sonrası riskli retry
9. İdempotent sonuç işleme kurun
Aynı başarılı callback birden fazla kez gelebilir. Sipariş hazırlama, stok düşme, e-posta gönderme veya fatura oluşturma gibi downstream işlemler aynı ödeme olayı için tekrar tekrar çalışmamalıdır.
İpucu — Olay kimliği kullanın
10. Müşteri deneyimini hata mesajlarıyla iyileştirin
Kullanıcıya teknik banka veya gateway hata kodlarını aynen göstermek yerine güvenli ve anlaşılır mesajlar kullanılmalıdır. Bununla birlikte destek ve analiz ekipleri gerçek sağlayıcı hata kodunu arka planda görebilmelidir.
| Teknik sınıf | Müşteri mesajı yaklaşımı | İç kayıt |
|---|---|---|
| Kart/banka reddi | Ödeme tamamlanamadı; kart bilgilerinizi kontrol edin veya başka yöntem deneyin | Gerçek decline kodu |
| Doğrulama başarısız | Doğrulama tamamlanamadı; tekrar deneyebilirsiniz | Authentication sonucu |
| Geçici teknik hata | İşlem sonucunu kontrol ediyoruz / kısa süre sonra tekrar deneyin | Gateway/timeout detayı |
| Bilinmeyen sonuç | Yeni ödeme başlatmadan önce sonuç doğrulanır | Reconciliation required |
11. Funnel'ı ödeme adımlarına göre ölçün
Checkout dönüşümünü yalnız 'sipariş tamamlandı' metriğiyle izlemek sorunun nerede olduğunu göstermez. Ödeme başlatma, doğrulamaya geçiş, doğrulama tamamlama, yetkilendirme/ödeme başarısı ve sipariş tamamlanma oranları ayrı ölçülebilir.
| Aşama | Örnek KPI |
|---|---|
| Ödeme başlatıldı | Checkout → payment start oranı |
| Doğrulama başladı | 3DS giriş oranı |
| Doğrulama tamamlandı | Authentication completion |
| Ödeme başarılı | Payment success rate |
| Sipariş tamamlandı | Paid order conversion |
İlgili çözüm: Ödeme Entegrasyonları
Şimdi Uygulayın
Uygulama Görevi — 3D Secure Ödeme Durum Matrisi
Ödeme entegrasyonunuz veya örnek bir akış için doğrulama başladı, doğrulama başarısız, müşteri terk etti, ödeme reddedildi, timeout oluştu ve ödeme başarılı senaryolarını yazın. Her senaryoda ödeme durumu, sipariş durumu, müşteriye gösterilecek aksiyon ve arka planda yapılacak doğrulamayı tanımlayın.
| Senaryo | Ödeme durumu | Sipariş durumu | Müşteri aksiyonu | Sistem kontrolü |
|---|---|---|---|---|
| Doğrulama terk | … | … | … | … |
| Doğrulama başarısız | … | … | … | … |
| Banka reddi | … | … | … | … |
| Timeout | … | … | … | … |
| Başarılı | … | … | … | … |
İpucu — Kabul testi
Bu Derste Ne Öğrendik?
- ✓3D Secure, kartlı ödeme sürecindeki müşteri doğrulama katmanlarından biridir; tek başına tahsilatın başarılı olduğunu göstermez.
- ✓E-ticaret sistemi doğrulama, ödeme yetkilendirme/sonuç, callback ve sipariş durumunu ayrı ama ilişkili kayıtlarla yönetmelidir.
- ✓Başarı URL'si yerine doğrulanmış sunucu tarafı sonuç esas alınmalı; tekrar bildirim, timeout ve terk edilen doğrulama gibi durumlar açık iş kurallarıyla ele alınmalıdır.