Adım Adım Ödeme Sistemleri: Sıfırdan Kurulum (Güncel)

Ödeme Sistemleri Sıfırdan Kurulum Rehberi​

Ödeme sistemi kurmak, yalnızca sanal POS başvurusu yapıp eklenti etkinleştirmek değildir. Sağlayıcı seçimi, sözleşme, test ortamı, API anahtarı, 3D Secure, webhook, sipariş durumu, iade ve mutabakat akışı birlikte düşünülmelidir.
Bu rehber, e-ticaret sitesinde ödeme altyapısını sıfırdan kuracak ekipler için adım adım bir kontrol planı sunar. Amaç canlıya çıkmadan önce hem başarılı ödeme hem de hata, iptal, iade ve zaman aşımı senaryolarını kanıtla test etmektir.

---

Başlangıç Planı​

• İş modeli: Tek çekim, taksit, abonelik, pazaryeri, B2B tahsilat veya bağış gibi ödeme türü netleştirilir.
• Para birimi: TL, çoklu para birimi ve yurt dışı kart kabulü gereksinimi belirlenir.
• Platform: WooCommerce, Shopify, özel yazılım veya mobil uygulama entegrasyon ihtiyacı çıkarılır.
• Risk: Ürün türü, ortalama sepet, iade oranı ve fraud riski sağlayıcı seçimini etkiler.
• Operasyon: Fatura, stok, kargo, muhasebe ve destek akışının ödeme sonucuna nasıl bağlanacağı yazılır.

Sağlayıcı ve Sözleşme Kontrolü​

Sağlayıcı seçerken yalnızca komisyon oranına bakmak eksik karar üretir. Ödeme vadesi, taksit desteği, iade süresi, chargeback süreci, teknik destek, hazır eklenti kalitesi ve API dokümantasyonu aynı tabloda değerlendirilmelidir.
Sözleşme imzalanmadan önce hangi veri mağazada tutulacak, hangi veri sağlayıcı tarafında kalacak, PCI sorumluluğu nasıl paylaşılacak ve 3D Secure zorunluluğu hangi işlemlerde uygulanacak netleşmelidir. Bu sorular teknik ekip kadar finans ve operasyon ekibini de ilgilendirir.

Test Ortamı Kurulumu​

Test ortamında canlı kart kullanılmamalı; sağlayıcının sunduğu test kartları ve test API anahtarları tercih edilmelidir. Başarılı ödeme, yetersiz bakiye, yanlış CVV, 3DS başarısızlığı, iptal, iade ve zaman aşımı ayrı ayrı denenmelidir.

• Test ve canlı API anahtarlarını ayrı ortam değişkenlerinde tutun.
• Webhook URL'sini test ortamında da erişilebilir hale getirin.
• Sipariş durumlarının ödeme sonucuna göre doğru değiştiğini kontrol edin.
• Başarısız ödeme sonrası kullanıcıyı sepete güvenli şekilde döndürün.
• Logların kart verisi saklamadığını doğrulayın.

Webhook ve Sipariş Durumu​

Ödeme sağlayıcıları çoğu zaman işlem sonucunu webhook ile bildirir. Webhook imzası doğrulanmalı, aynı bildirim ikinci kez gelirse sipariş bozulmamalı ve geç gelen bildirimler için işlem sonucu sorgulanabilmelidir.
Sipariş durumu akışı sade olmalıdır: ödeme bekleniyor, ödeme alındı, başarısız, iptal edildi, iade edildi gibi durumlar ekip tarafından aynı anlamda kullanılmalıdır. Belirsiz durumlar hem müşteri desteğini hem muhasebeyi zorlaştırır.

3D Secure, Retry ve İade​

3D Secure ekranından dönüş, mobil tarayıcılarda ve uygulama içi tarayıcılarda ayrıca test edilmelidir. Kullanıcı banka ekranından döndüğünde sipariş kaybolmamalı, hatalı işlemde açık mesaj gösterilmeli ve tekrar deneme yolu kontrollü sunulmalıdır.
Retry tasarımında idempotency önemlidir. Aynı sipariş için kontrolsüz tekrar ödeme isteği göndermek çift çekime yol açabilir. İade tarafında ise kısmi iade, tam iade, stok güncelleme ve müşteri bildirimi birlikte test edilmelidir.

Canlıya Alma Kontrolü​

• Test API anahtarları canlı anahtarlarla güvenli biçimde değiştirildi mi?
• Canlı webhook URL'si, imza doğrulaması ve IP/secret kontrolleri çalışıyor mu?
• Başarılı ödeme sonrası stok, fatura, e-posta ve kargo akışı tetikleniyor mu?
• Başarısız ödeme sonrası kullanıcıya anlaşılır seçenek sunuluyor mu?
• Günlük mutabakat raporu finans ekibi tarafından okunabiliyor mu?
• İade ve iptal yetkileri rol bazlı sınırlandı mı?

Mikro Vaka​

Bir mağaza ödeme sistemini canlıya almadan önce sadece başarılı kartı test etmişti. İlk kampanyada 3DS dönüşünde bazı mobil kullanıcıların siparişi beklemede kaldı. Sonraki sürümde test senaryoları genişletildi, webhook imza kontrolü ve tekrar sorgulama eklendi; destek talepleri belirgin şekilde azaldı.

Basit Formül​

SSS​

• Ödeme entegrasyonuna nereden başlanır? İş modeli, platform, para birimi, taksit ve iade gereksinimi çıkarılarak başlanır.
• Test kartı kullanmak şart mı? Evet. Sağlayıcının test ortamı ve test kartları canlı risk oluşturmadan senaryo denemeyi sağlar.
• Webhook neden kritik? Sipariş durumunu ödeme sonucuyla güvenilir şekilde eşleştirir.
• İdempotency ne işe yarar? Aynı ödeme denemesinin kontrolsüz tekrarlanıp çift işlem üretmesini önler.
• Loglarda kart bilgisi tutulur mu? Hayır. Hassas kart verisi saklanmamalı; yalnızca güvenli işlem ve hata referansları tutulmalıdır.
• Canlıya almadan önce son kontrol nedir? Başarılı, başarısız, timeout, iptal, iade ve webhook senaryolarını uçtan uca test etmektir.

Ortam Ayrımı ve Yayın Disiplini​

Ödeme entegrasyonunda test ve canlı ortamın karışması ciddi risktir. Test anahtarıyla canlı sipariş almak, canlı anahtarı test verisiyle kullanmak veya webhook URL'lerini karıştırmak sipariş kayıtlarını bozabilir. Bu nedenle her ortam için ayrı API anahtarı, ayrı webhook secret, ayrı log etiketi ve ayrı yapılandırma dosyası kullanılmalıdır.
Canlıya alma günü değişiklik listesi kısa tutulmalıdır. Aynı anda tema, checkout, ödeme eklentisi ve kargo entegrasyonu değiştirilirse sorun çıktığında neden ayrıştırılamaz. Önce ödeme akışı stabil hale getirilir; diğer iyileştirmeler ayrı sprintlerde uygulanır.

Muhasebe ve Operasyon Bağlantısı​

Ödeme sistemi teknik olarak çalışsa bile operasyon tarafı hazır değilse süreç aksar. Başarılı ödeme sonrası fatura, stok, kargo, iade ve müşteri bildirimi hangi sırayla ilerleyecek yazılmalıdır. Finans ekibi sağlayıcı panelindeki tahsilatla mağaza raporunu nasıl eşleştireceğini bilmelidir.

• Günlük mutabakat için sipariş id ve sağlayıcı işlem id aynı raporda görünmelidir.
• Kısmi iade yetkisi rol bazlı sınırlandırılmalıdır.
• Chargeback bildirimleri destek ve finans ekibine aynı gün düşmelidir.
• Ödeme beklemede kalan siparişler için otomatik takip listesi hazırlanmalıdır.

Canlı Sonrası İlk 72 Saat​

Canlıya aldıktan sonra ilk 72 saat izleme dönemi kabul edilmelidir. İlk gün ödeme başarı oranı, başarısız hata kodları, webhook gecikmesi ve sipariş durumu uyuşmazlığı saatlik kontrol edilir. İkinci gün iade/iptal denemesi ve e-posta bildirimleri tekrar test edilir. Üçüncü gün finans raporu ile sağlayıcı paneli karşılaştırılır.
Bu dönem sonunda bulgular yazılı hale getirilirse entegrasyon kalıcı olarak iyileşir. Aksi halde canlıya alma telaşı bitince küçük uyuşmazlıklar alışkanlık haline gelir ve kampanya döneminde büyür.
İlk 72 saat içinde çıkan her hata için tek bir kayıt tutulmalıdır: ne oldu, hangi kullanıcıyı etkiledi, ödeme sağlayıcı yanıtı neydi, mağaza sipariş durumu ne gösterdi ve kalıcı çözüm hangi değişiklikle yapıldı? Bu kayıt sonraki sağlayıcı güncellemelerinde test senaryosu olarak tekrar kullanılır.
Bu kayıtlar aynı zamanda destek ekibinin cevap kalitesini artırır. Müşteriye tahsilat durumu, iade süresi ve tekrar deneme önerisi daha net aktarılır.

İç Bağlantılar​

• Sanal POS hata çözüm kılavuzu
• Ödeme sistemleri teknik SEO
• E-ticaret sıfırdan kurulum
• E-ticaret audit rehberi

Dış Kaynak​

• iyzico resmi dokümantasyonu
• Stripe Docs: idempotent requests
• PCI Security Standards Council

Özetle​

Ödeme sistemi kurulumu; sağlayıcı seçimi, test ortamı, webhook, 3DS, retry, iade ve mutabakat birlikte doğrulandığında güvenli hale gelir. Canlıya çıkmadan önce başarısız senaryoları da başarılı ödeme kadar ciddiye alın.

Güncelleme: 2026-06-16

---