- Katılım
- 21 May 2023
- Mesajlar
- 468
- Tepki
- 17
- Puan
- 18
Ödeme Sistemlerini Güvenle Hızlandırma Rehberi
Ödeme hızlandırma, “Öde” düğmesinden birkaç yüz milisaniye kazanmakla sınırlı değildir. Müşteri formu açtıktan sonra ödeme isteğinin oluşturulması, 3D Secure doğrulaması, banka/sağlayıcı yanıtı, sipariş durumunun güncellenmesi ve webhook bildiriminin işlenmesi tek bir uçtan uca akıştır.
Başlıktaki 2025 ifadesi arşiv niteliğindedir; rehber 2026’daki güncel güvenlik kaynaklarıyla yenilenmiştir. Temel hedef hız, ödeme bütünlüğü ve kullanıcıya doğru durum bilgisini birlikte korumaktır. Hız uğruna yeniden deneme veya durum kontrolü yanlış tasarlanırsa çift tahsilat ya da ödenmiş siparişin başarısız görünmesi gibi daha ağır sorunlar doğabilir.
Ödeme performansı, hızlı yanıt kadar tekil işlem ve doğru sipariş durumu demektir.
Ödeme Akışını Beş Ayrı Süreye Bölün
Tek bir “checkout süresi” ölçümü, gecikmenin nerede oluştuğunu göstermez. Aşağıdaki aşamaları ayrı zaman damgaları ve ortak bir işlem kimliğiyle izleyin:
- Form hazır olma: Ödeme alanları ne zaman kullanılabilir hâle geliyor?
- İstek oluşturma: Sunucu sipariş ve ödeme niyetini ne kadar sürede hazırlıyor?
- Sağlayıcı yanıtı: API çağrısı veya yönlendirme bilgisi ne zaman dönüyor?
- Müşteri doğrulaması: 3DS yönlendirme/challenge akışı ne kadar sürüyor?
- Kesinleşme: Dönüş URL’si, durum sorgusu ve webhook sonrasında sipariş ne zaman güvenilir son duruma ulaşıyor?
Tarayıcıda görülen başarı ekranı ile finansal kesinleşmeyi aynı olay saymayın. Bazı akışlarda müşteri dönüş sayfasına ulaşmazken sağlayıcının webhook bildirimi daha sonra gelebilir; bazılarında ise tarayıcı geri döndüğü hâlde işlem hâlâ beklemede olabilir.
Ödeme ilkesi' Alıntı:
Durum Makinesini Açıkça Tanımlayın
“Ödendi / ödenmedi” şeklinde iki durum çoğu entegrasyon için yetersizdir. Sağlayıcının terimleri farklı olsa da uygulama içinde açık geçişler kullanın:
- created: Sipariş ve ödeme isteği oluşturuldu.
- pending_authentication: Müşteri doğrulaması bekleniyor.
- processing: Sağlayıcı sonucu henüz kesin değil.
- authorized veya captured: Yetkilendirme/tahsilat sağlayıcıya göre doğrulandı.
- failed veya cancelled: İşlem tamamlanmadı; hata nedeni kaydedildi.
- partially_refunded / refunded: İade tutarı ve referansı işlendi.
İzin verilen geçişleri sunucu tarafında sınırlandırın. Eski veya sırası bozuk bir webhook, kesinleşmiş siparişi geriye taşımamalıdır. Aynı bildirimin iki kez gelmesi de iki stok hareketi ya da iki e-posta üretmemelidir.
Çift Tahsilatı İdempotency ile Önleyin
Mobil bağlantı koptuğunda müşteri düğmeye tekrar basabilir; uygulama sunucusu yanıtı alamadığı için isteği yeniden gönderebilir. İlk çağrı sağlayıcıda başarılı olduysa aynı sipariş için ikinci ödeme oluşturma riski doğar.
Koruma katmanları:
- Her ödeme denemesine siparişten ayrı, benzersiz bir deneme kimliği verin.
- Sağlayıcı idempotency anahtarı destekliyorsa aynı mantıksal denemede aynı anahtarı kullanın.
- Aynı anahtarı farklı tutar, para birimi veya müşteriyle yeniden kullanmayın.
- Veri tabanında sipariş + ödeme denemesi için tekillik kuralı uygulayın.
- Tarayıcı düğmesini kilitlemek yardımcıdır; asıl koruma sunucuda olmalıdır.
İdempotency davranışı sağlayıcıya göre değişebilir. Anahtarın ne kadar saklandığı, hangi HTTP işlemlerinde geçerli olduğu ve hata yanıtlarının tekrarında ne döndüğü ilgili sağlayıcının güncel belgesinden kontrol edilmelidir.
Timeout Sonucunu “Başarısız” Saymayın
Zaman aşımı, ödemenin reddedildiği anlamına gelmez; uygulamanızın belirlenen sürede cevap alamadığı anlamına gelir. Sağlayıcı isteği işlemiş fakat yanıt ağda kaybolmuş olabilir.
Timeout sonrasında yeni tahsilat açmadan önce aynı denemenin durumunu idempotency anahtarı, sağlayıcı işlem kimliği veya durum sorgusu üzerinden kontrol edin. Sonuç hâlâ belirsizse siparişi “inceleme/beklemede” durumuna alın; müşteriye “ödeme başarısız” yerine işlemin kontrol edildiğini söyleyin.
Teknik ağ hataları kontrollü şekilde yeniden denenebilir. Kart reddi, yetersiz bakiye veya doğrulama hatası gibi iş sonuçlarını otomatik olarak tekrar tekrar göndermek doğru değildir. Yeniden denemede artan bekleme, üst sınır ve devre kesici kullanın; sağlayıcının önerdiği hata sınıflarına uyun.
Webhook İşlemeyi Hızlı ve Tekrarlanabilir Kurun
Webhook uç noktası önce bildirimin gerçekten sağlayıcıdan geldiğini doğrulamalıdır. İmza doğrulamasında ham istek gövdesi, zaman toleransı ve sağlayıcıya özel gizli anahtar kuralları önemlidir. Gizli anahtarı kaynak koda veya istemci tarafına koymayın.
- İmzayı ve beklenen sağlayıcı/hesap bilgisini doğrulayın.
- Olay kimliğini daha önce işleyip işlemediğinizi kontrol edin.
- Bildirimi kalıcı kayda aldıktan sonra hızlı başarı yanıtı dönün.
- E-posta, fatura veya ağır rapor işlerini arka plan kuyruğuna bırakın.
- Sırası değişen olayları işlem zamanı yerine ödeme durumuna göre uzlaştırın.
- Başarısız webhook’lar için görünür kuyruk ve yeniden işleme aracı sağlayın.
Webhook’un birkaç kez gelmesini hata varsaymayın; en az bir kez teslim modelinde tekrar normaldir. İşleyicinin aynı olayı güvenle yeniden görebilmesi gerekir.
3D Secure Akışında Sürtünmeyi Doğru Yerde Azaltın
EMV 3-D Secure, kartı veren kuruluş ile işyeri arasında işlem, ödeme yöntemi ve cihaz verilerinin paylaşılmasını sağlayarak kartın bulunmadığı ödemelerde kimlik doğrulamayı destekler. Akış, risk değerlendirmesine göre sürtünmesiz ilerleyebilir veya kullanıcıdan ek doğrulama isteyebilir.
Challenge ekranını uygulama tarafında “atlamaya” çalışmak yerine sağlayıcının güncel SDK/yönlendirme akışını uygulayın. Dönüş URL’sini açıkça tanımlayın, oturum kaybında sipariş kimliğini güvenle geri yükleyin ve kullanıcının geri tuşu/sekme kapatma davranışını test edin.
Başarısızlık mesajı kart numarası veya güvenlik ayrıntısı sızdırmamalı; aynı zamanda kullanıcıya tekrar deneyip deneyemeyeceğini, farklı ödeme yöntemi seçmesini veya destekle iletişime geçmesini anlaşılır biçimde söylemelidir.
Ödeme Sayfasındaki Script Bütçesini Azaltın
Canlı destek, reklam, ısı haritası ve kişiselleştirme scriptleri ödeme alanıyla aynı sayfada çalışıyorsa hem etkileşimi yavaşlatabilir hem güvenlik kapsamını büyütebilir. PCI SSC, e-ticaret ödeme sayfası scriptlerinin yetkilendirilmesi, bütünlüğünün kontrolü ve değişikliklere karşı izlenmesine özellikle dikkat çeker.
- Ödeme sayfasında yalnız gerekli scriptleri yükleyin.
- Her script için sahip, amaç, kaynak ve bütünlük kontrolü kaydı tutun.
- Kart verisini kendi sunucunuzdan geçirmeyen barındırılmış alan/yönlendirme seçeneklerini değerlendirin.
- Entegrasyon biçiminin PCI DSS kapsamını otomatik olarak sıfırladığını varsaymayın.
- Uygun öz değerlendirme formu ve yükümlülükler için edinim bankası/ödeme markası veya yetkin denetçiyle doğrulama yapın.
Kart numarası, CVV veya tam hassas doğrulama verisini uygulama loglarına yazmayın. Destek ve hata ayıklama için sağlayıcı işlem kimliği, kendi sipariş/deneme kimliğiniz, güvenli hata kodu ve zaman bilgisi yeterli olmalıdır.
Performansı Doğru Metriklerle İzleyin
Yalnız ortalama süre, yavaş kullanıcıları gizler. Aşamaları p50, p95 ve p99 dağılımlarıyla; cihaz, sağlayıcı, ödeme yöntemi ve 3DS sonucu kırılımlarında izleyin.
- Ödeme formunun etkileşime hazır olma süresi
- Ödeme oluşturma API’sinin p95 gecikmesi ve timeout oranı
- 3DS dönüşünden kesin sipariş durumuna kadar geçen süre
- Teknik hata, kullanıcı iptali ve banka reddi oranları
- Tekrarlanan webhook ve başarısız işleme kuyruğu
- Aynı sipariş için birden fazla başarılı tahsilat alarmı
- Sağlayıcı raporu ile sipariş/iadelerin mutabakat farkı
Alarm eşiklerini mağazanın kendi normal değerlerinden üretin. Bir sağlayıcıdaki genel yavaşlamayla uygulamanızın yeni sürümünden kaynaklanan gecikmeyi ayırabilmek için dağıtım zamanlarını gözlem sistemine ekleyin.
Örnek Uygulama: Belirsiz Ödeme Sonucu
Varsayımsal bir siparişte uygulama, sağlayıcıya tahsilat isteği gönderiyor fakat bağlantı cevap gelmeden kesiliyor. Eski akış siparişi “başarısız” işaretleyip müşteriye yeniden deneme düğmesi gösteriyor. Bu tasarım ikinci tahsilat riski taşıyor.
Yeni akış aynı ödeme denemesini idempotency anahtarıyla kaydediyor. Timeout oluştuğunda sipariş “işleniyor” durumunda kalıyor; sunucu aynı denemenin durumunu sorguluyor ve doğrulanmış webhook’u bekliyor. Kesin sonuç geldiğinde tek stok hareketi, tek fatura ve tek bildirim üretiliyor. Belirlenen inceleme süresinde sonuç alınamazsa olay operasyon kuyruğuna düşüyor.
Bu örnek belirli bir sağlayıcı davranışı iddia etmez; uygulanacak alan adları, süreler ve imza yöntemi seçilen ödeme kuruluşunun belgesine göre uyarlanmalıdır.
Yayın Öncesi Kontrol Listesi
- Ödeme durumları ve izin verilen geçişler tanımlı mı?
- Çift tıklama ve ağ tekrarında sunucu tarafı tekillik korunuyor mu?
- Timeout sonrası sağlayıcı durumu sorgulanıyor mu?
- Webhook imzası ham gövde üzerinden doğrulanıyor mu?
- Aynı olay ikinci kez geldiğinde yan etki tekrarlanmıyor mu?
- 3DS başarı, başarısızlık, iptal ve geri tuş senaryoları test edildi mi?
- Loglarda kart verisi/CVV bulunmadığı doğrulandı mı?
- İade, kısmi iade ve mutabakat testleri tamamlandı mı?
- Sağlayıcı kesintisinde kullanıcı mesajı ve operasyon kuyruğu hazır mı?
İç Bağlantılar
- E‑ticaret ve ödeme başlangıç rotası
- Sanal POS seçim ölçütleri
- Ödeme sistemlerinde hız ve güvenlik
- E‑ticaret sitesinde uçtan uca performans
Dış Kaynaklar
- Stripe API: idempotent isteklerin çalışma modeli
- Stripe: webhook imzası, teslim ve işleme ilkeleri
- EMVCo: EMV 3-D Secure genel görünümü
- PCI SSC: PCI Veri Güvenliği Standardı
- PCI SSC: ödeme sayfası güvenliği ve e-skimming rehberi
Özetle
Aşamaları ayrı ölçün → işlemi idempotent yapın → timeout’u belirsiz sonuç olarak yönetin → webhook’u doğrulayıp tek kez işleyin → siparişle sağlayıcıyı uzlaştırın. Güvenli ödeme hızlandırma, müşteriye daha çabuk fakat yanlış cevap vermek değil; doğru sonucu mümkün olan en kısa ve izlenebilir akışla sunmaktır.
Güncelleme: 15 Temmuz 2026
Dijital Dünyanıza Yön Veren Pusula
Ekli dosyalar
Son düzenleme:
