Ödeme Sistemleri 2025: 7 Adımda Uygulama

Ödeme Entegrasyonu: 7 Adımda Güvenli Uygulama​

Ödeme entegrasyonu, forma kart alanı ekleyip “başarılı” yanıtını siparişe yazmaktan ibaret değildir. Sağlayıcı seçimi, kart verisi kapsamı, işlem durumları, 3D Secure, idempotency, webhook, iade ve mutabakat aynı tasarımın parçalarıdır. Bu zincirdeki belirsizlikler çift tahsilata, ödenmemiş siparişin hazırlanmasına veya başarılı ödemenin müşteriye başarısız gösterilmesine yol açabilir.

Başlıktaki 2025 ifadesi arşiv niteliğindedir; uygulama adımları Temmuz 2026'da güncellenmiştir. Sağlayıcıya özgü alan adları değişse de aşağıdaki yöntem, iş gereksiniminden canlı izlemeye kadar yedi doğrulanabilir kapı kurar.

---

Güvenli ödeme entegrasyonu; istek, kimlik doğrulama, asenkron sonuç ve finansal kayıtları tek durum modeliyle birleştirir.

1. Gereksinimi ve Para Akışını Haritalayın​

Kod yazmadan önce satış modelini tanımlayın. Tek seferlik ödeme, abonelik, pazar yeri, ön provizyon/sonradan tahsilat veya kısmi teslimat aynı akışı kullanmaz. Ülkeler, para birimleri, taksit, iade, kısmi iade, iptal, ödeme vadesi ve raporlama ihtiyacını yazın.

Para akışını şu sorularla görünür hâle getirin:

• Müşteriden hangi anda ve hangi tutar için yetki alınacak?
• Tahsilat, sipariş oluşturma ve stok ayırma hangi sırada gerçekleşecek?
• Ücret, vergi, kargo ve indirim hangi sistemde hesaplanacak?
• Başarılı ödeme hangi kanıtla kesinleşecek?
• İade veya iptali kim başlatacak, hangi kimlikle izleyecek?
• Sağlayıcı ödemesi, banka hareketi ve sipariş kaydı nasıl eşleşecek?

Sağlayıcı karşılaştırmasını reklam sayfasındaki özelliklerle değil bu gereksinimlerin test ortamında kanıtlanmasıyla yapın. Ücret, destek, ödeme yöntemi ve sözleşme koşullarını doğrudan sağlayıcıdan yazılı alın.

2. Entegrasyon Modelini ve Güvenlik Kapsamını Seçin​

Kart bilgisinin mağaza sunucusuna hiç uğramadığı sağlayıcı tarafından barındırılan sayfa veya alanlar, doğrudan kart verisi işleyen özel forma göre kapsamı azaltabilir; fakat mağaza otomatik olarak bütün PCI sorumluluklarından çıkmaz. Tarayıcıya hangi ödeme öğelerinin kim tarafından sunulduğu ve mağaza betiklerinin bu sayfayı etkileyip etkileyemediği ayrıca değerlendirilmelidir.

• Mümkünse sağlayıcının güncel, desteklenen SDK veya barındırılan bileşenini kullanın.
• Gizli API anahtarını tarayıcıya, mobil uygulamaya veya repoya koymayın.
• Test ve canlı ortam anahtarlarını, endpoint'lerini ve webhook sırlarını ayırın.
• Ödeme sayfasındaki üçüncü taraf betikleri en aza indirin; envanter ve değişiklik kontrolü kurun.
• Kart verisi, hassas kimlik doğrulama verisi ve token kavramlarını birbirinden ayırın.
• Uygun PCI doğrulama yolunu bankanız, ödeme markası veya yetkili değerlendiriciyle belirleyin.

PCI SSC'nin e-ticaret yönlendirmeleri, ödeme sayfasını etkileyen betiklerin yetkilendirilmesi, bütünlüğü ve izlenmesi üzerinde durur. “Sağlayıcımız uyumlu” ifadesi, mağazanın kendi uygulama biçimini değerlendirme ihtiyacını ortadan kaldırmaz.

3. Sunucuda Tek İşlem ve Durum Modeli Kurun​

Her ödeme denemesine mağazanızda benzersiz, tahmin edilmesi zor olmayan bir iş kimliği; sağlayıcı tarafında ise işlem kimliği atayın. Tutarı ve para birimini tarayıcıdan gelen değere güvenerek tahsil etmeyin: sepeti, indirimi, kargoyu ve vergiyi sunucuda yeniden hesaplayın.

İşlem durumlarını açık tanımlayın. Örnek bir model `created`, `requires_action`, `processing`, `paid`, `failed`, `cancelled`, `refunded` olabilir. Bu adlar sağlayıcıdan bağımsız iş durumlarıdır; sağlayıcı yanıtları bu sözlüğe eşlenir.

Ödeme oluşturan veya değiştiren isteklerde idempotency kullanın. Aynı işleme ait ağ hatasında yeni bir anahtar üretmek yerine sağlayıcının kurallarına uygun biçimde aynı anahtarla sonucu sorgulayın veya güvenli tekrar yapın. Farklı tutar ya da sepet için eski anahtarı yeniden kullanmayın.

Belirsiz sonuç kuralı' Alıntı:

İstemci timeout gördüğünde ödeme başarısız sayılmaz; sağlayıcı durumu veya doğrulanmış webhook sonucu görülmeden müşteriye ikinci tahsilat başlatmayın.

Genişletmek için tıkla ...

4. Checkout ve 3D Secure Akışını Uygulayın​

Checkout'ta yalnız gerekli alanları gösterin; ancak toplam tutar, para birimi, ödeme yöntemi ve işlem sonrası beklenen adım net olsun. Form gönderimini iki kez tıklamaya karşı kilitleyin fakat kullanıcıya görünür işlem durumu sunun. Tarayıcı kapansa bile ödeme sonucu sunucu tarafında izlenebilmelidir.

EMV 3-D Secure iki temel akış tanımlar: risk değerlendirmesiyle ilave etkileşim gerektirmeyen frictionless akış ve kart sahibinin doğrulama yaptığı challenge akışı. Hangi işlemin challenge'a gireceğini mağaza arayüzündeki bir düğmeyle “hızlandırmaya” çalışmayın; sağlayıcı, banka ve uygulanabilir kurallar belirler.

Yönlendirme veya challenge dönüşünde yalnız URL parametresine bakarak siparişi ödenmiş yapmayın. Dönüş ekranı müşteriye bilgi sunar; nihai işlem durumu sunucu–sağlayıcı doğrulamasıyla belirlenir. Kullanıcı geri dönemese bile webhook veya durum sorgusu akışı tamamlayabilmelidir.

5. Webhook'u Doğrulanmış ve Tekrarlanabilir İşleyin​

Ödeme sonucu, iade, itiraz veya abonelik gibi olaylar asenkron gelebilir. Webhook endpoint'i internetten erişilebildiği için gelen her isteğe güvenmemelidir.

1. İmza doğrulamasını sağlayıcının resmî SDK'sı ve ham istek gövdesiyle yapın.
2. Zaman damgası veya replay korumasını sağlayıcının önerisine göre uygulayın.
3. Olay kimliğini kaydedip daha önce işlendi mi kontrol edin.
4. Olayların sıralı gelmeyebileceğini varsayın; güncel kaynağı gerektiğinde API'den doğrulayın.
5. Karmaşık işi kuyrukta yürütmek üzere endpoint'ten hızlı `2xx` dönün.
6. İşleme başarısızsa gözlemlenebilir retry ve dead-letter/manuel inceleme yolu kurun.

Webhook'u yalnız sipariş durumunu değiştiren gizli bir yan yol olarak bırakmayın. Hangi olayın hangi iş durumunu, e-postayı, stok hareketini ve muhasebe kaydını tetiklediğini belgeleyin.

6. Olumsuz Senaryoları ve Mutabakatı Test Edin​

Başarılı test kartı, canlıya çıkmak için yeterli değildir. Sağlayıcının resmî test ortamı ve senaryolarıyla aşağıdakileri doğrulayın:

• Başarılı, reddedilen ve doğrulama gerektiren ödeme
• Yanlış/eksik alan, yetersiz bakiye benzeri güvenli hata sınıfları
• İstek sırasında bağlantı kesilmesi ve belirsiz sonuç
• Aynı isteğin tekrarlanması ve eşzamanlı çift tıklama
• Geciken, yinelenen, imzası geçersiz ve sırası değişmiş webhook
• Tam/kısmi iade, iptal ve iadenin başarısız olması
• Farklı para birimi, yuvarlama ve en küçük para birimi hesabı

Sonra finansal mutabakat provası yapın. Sipariş brüt tutarı, sağlayıcı işlem kimliği, komisyon/ücret, iade, net ödeme ve banka hareketi aynı kayıt zincirinde eşleşmelidir. Fark bulunduğunda otomatik olarak “ödendi” yazmak yerine neden kodu ve inceleme kuyruğu oluşturun.

7. Kontrollü Yayın ve Canlı İzleme Yapın​

Canlı geçiş için özellik bayrağı veya sınırlı trafik kullanın; eski yönteme güvenli dönüş planını önceden deneyin. Test anahtarının canlıda, canlı webhook sırrının testte kullanılmadığını dağıtım kontrolüyle doğrulayın.

Tek bir “dönüşüm oranı” bütün ödeme sağlığını anlatmaz. En az şu sinyalleri sağlayıcı, yöntem, cihaz ve sürüm boyutunda izleyin:

• Başlatılan, action gereken, processing, başarılı ve başarısız işlem dağılımı
• Teknik hata, banka reddi ve kullanıcı iptali ayrımı
• API gecikmesi, timeout ve güvenli retry sayısı
• Webhook teslim/işleme gecikmesi ve yinelenen olay sayısı
• Durumu belirsiz veya manuel incelemede kalan işlemler
• Mutabakat farkı, iade gecikmesi ve çift tahsilat alarmı

Alarm eşiğini genel bir internet sayısından kopyalamayın; normal tabanı ölçün, müşteri ve para kaybı etkisine göre belirleyin. Olay kayıtlarında kart verisi, sır veya gereksiz kişisel veri tutmayın.

Yedi Kapılık Canlıya Geçiş Kontrolü​

• İş ve para akışı ürün/finans tarafından onaylandı mı?
• Kart verisi akışı ile PCI kapsamı yetkili tarafça doğrulandı mı?
• Sunucu tutarı, durum modeli ve idempotency test edildi mi?
• 3DS dönüşü ile nihai ödeme doğrulaması birbirinden ayrıldı mı?
• Webhook imza, tekrar, sıra ve hata senaryolarından geçti mi?
• İade, iptal ve mutabakat uçtan uca çalıştı mı?
• Canlı anahtar, alarm, rollback ve olay sorumluları hazır mı?

İç Bağlantılar​

• Ödeme operasyonu ve dayanıklı durum yönetimi
• Ödeme içeriği ve teknik belge planı
• Sanal POS hata çözüm kılavuzu
• Ödeme sistemi bakım rutini

Dış Kaynaklar​

• Stripe: idempotent istekler
• Stripe: webhook güvenliği ve işleme
• Stripe: entegrasyon testleri
• EMVCo: EMV 3-D Secure akışları
• PCI Security Standards Council: PCI DSS

Özetle​

Para akışını tanımlayın → güvenlik kapsamını seçin → tek işlem/durum modeli kurun → checkout ve 3DS'yi uygulayın → webhook'u doğrulayın → olumsuz senaryolarla mutabakatı test edin → kontrollü yayın ve canlı izleme yapın. Başarı, yalnız ödeme ekranının açılması değil; her işlemin güvenli, tekrarlanabilir ve finansal olarak açıklanabilir olmasıdır.

Güncelleme: 15 Temmuz 2026

---