ODTÜ’lüden Yazılım
Menü

Entegrasyon Eğitimleri · Adım adım eğitim

Ödeme Sistemi Entegrasyonu Nasıl Yapılır?

Web sitesi veya uygulamaya ödeme alma özelliği eklerken sağlayıcı seçimi, ödeme durumu, webhook, tekrar kontrolü, iade ve mutabakat akışının nasıl tasarlanacağını anlatıyoruz.

Yazar: ODTÜ’lüden Yazılım Ekibi 10 dk okuma Yayın: 25 Temmuz 2026 Güncelleme: 25 Temmuz 2026
Önce kısa cevabı okuyun

Kısa cevap

Bu eğitimin en kısa, uygulanabilir yanıtı.

Ödeme sistemi entegrasyonu, yalnız ödeme formunu açmak değildir. Güvenilir akışta sipariş ve tutar şirketin sunucusunda oluşturulur, kullanıcı yetkili sağlayıcının ödeme adımına geçer, sonuç sunucudan sunucuya bildirim veya sağlayıcı API’siyle doğrulanır ve sipariş ancak tutar, para birimi ve işlem kimliği eşleştiğinde ilerletilir. Tekrar gelen bildirim, başarısız ödeme, iptal, iade ve mutabakat davranışı da ilk sürümün parçasıdır.

01

Tarayıcının dönüş sayfası ödeme kanıtı değildir; sipariş durumu sağlayıcının imzalı bildirimi veya sunucu API’si üzerinden doğrulanmalıdır.

02

Aynı webhook birden fazla kez gelebilir; idempotency ve durum geçişi kontrolü olmadan ikinci teslimat, üyelik veya bakiye oluşabilir.

03

Hazır ödeme sayfası, gömülü alan veya doğrudan kart akışı seçimi yalnız tasarımı değil; güvenlik, sorumluluk ve uyum kapsamını da değiştirir.

Eğitim adımları

Konuyu adım adım netleştirelim.

01

Ödeme sistemi entegrasyonu neyi kapsar?

Entegrasyon; ödeme sağlayıcısında işlem başlatma, kullanıcıyı güvenli ödeme adımına taşıma, sonucu doğrulama ve şirket içindeki sipariş, üyelik, rezervasyon ya da tahsilat kaydını güncelleme işidir. Kart formunun açılması yalnız görünen yüzdür. Tutarın hangi kayıttan geldiği, ödeme sonucu alınamazsa ne olacağı, iadenin kim tarafından başlatılacağı ve finans ekibinin mutabakatı nasıl yapacağı da aynı kapsamın içindedir.

02

Önce ödeme yöntemi değil, iş akışı seçilmeli

Tek seferlik sipariş, ödeme linki, abonelik, bayi tahsilatı ve pazaryeri benzeri çok taraflı akışlar aynı veri modelini kullanmaz. Kimden hangi tutarın, hangi para birimiyle, hangi sipariş veya sözleşme için alınacağı yazılmalıdır. Kısmi ödeme, taksit, kupon, vergi, kargo, yenileme ve başarısız tahsilat ihtiyacı varsa sağlayıcı seçimi bu gerçek senaryolar üzerinden yapılmalıdır.

03

Sipariş ve tutar şirket sunucusunda hazırlanmalı

Tarayıcıdan gelen ürün adı, fiyat, indirim veya toplam doğrudan doğru kabul edilmemelidir. Sistem ürün ve fiyatı güvenilir kaynaktan yeniden okumalı, kampanya kurallarını sunucuda uygulamalı ve ödeme başlatmadan önce benzersiz bir sipariş kaydı oluşturmalıdır. Sağlayıcıya gönderilen tutar ile dönüşte doğrulanan tutar, para birimi ve sipariş kimliği aynı kayda bağlanmalıdır.

04

Dönüş sayfası ile webhook aynı görevde değildir

Kullanıcı ödeme sonrasında başarı veya hata sayfasına dönebilir; fakat tarayıcı kapanabilir, bağlantı kesilebilir ya da dönüş parametreleri değiştirilebilir. Bu nedenle siparişi yalnız dönüş URL’sine bakarak tamamlamak güvenli değildir. Sunucudan sunucuya gelen bildirimin imzası doğrulanmalı ve gerektiğinde sağlayıcının API’sinden işlem durumu tekrar okunmalıdır. Kullanıcı ekranı sonuç bilgisini gösterir; ticari kaydı güvenilir sunucu doğrulaması ilerletir.

05

Tekrar gelen bildirim ikinci işlem üretmemeli

Ödeme sağlayıcısı yanıt alamadığında aynı bildirimi yeniden gönderebilir. Uygulama her bildirimi yeni ödeme gibi işlerse sipariş iki kez hazırlanabilir, üyelik süresi iki kez uzayabilir veya hesaba ikinci kez bakiye yazılabilir. Sağlayıcı işlem kimliği, sipariş kimliği ve beklenen durum birlikte kontrol edilmeli; daha önce başarıyla işlenen olay güvenli biçimde aynı sonucu vermelidir.

06

Ödeme durumu tek bir başarılı/başarısız alanına sığmaz

İşlem başlatıldı, kullanıcı doğrulaması bekleniyor, ödeme alındı, reddedildi, süre doldu, iptal edildi, kısmen veya tamamen iade edildi gibi durumlar farklı operasyon kararları doğurur. Hangi geçişlerin sağlayıcıdan, hangilerinin yetkili kullanıcıdan geleceği belirlenmelidir. Geçersiz bir geri geçiş veya tutarsız bildirim sessizce kabul edilmemeli; inceleme kaydı üretmelidir.

07

İade, iptal ve mutabakat ilk faza dahil edilmeli

Ödeme almak çalışsa bile operasyon, iade sırasında dağılabilir. Tam ve kısmi iade yetkisi, iade nedeni, sağlayıcı işlem kimliği, sipariş durumu, müşteriye gösterilen sonuç ve muhasebe kaydı aynı zincirde tutulmalıdır. Gün veya dönem sonunda şirket sistemi ile sağlayıcı raporu farklıysa farkı bulacak referans numaraları ve müdahale ekranı bulunmalıdır.

08

Kart verisi kapsamını mümkün olduğunca dar tutun

Çoğu ürün için kart verisini şirket sunucusuna almak yerine sağlayıcının yönlendirmeli ödeme sayfası veya uygun gömülü bileşenini kullanmak daha kontrollü bir başlangıçtır. Bununla birlikte üçüncü taraf kullanmak sorumluluğu kendiliğinden ortadan kaldırmaz. Ödeme sayfasını etkileyen scriptler, erişim anahtarları, yönlendirme bütünlüğü, güncellemeler ve sağlayıcının PCI kapsamı proje özelinde doğrulanmalıdır.

09

Örnek senaryo: ödeme alındı ama sipariş hazırlanmadı

Bir e-ticaret siparişinde kullanıcı ödemeyi tamamlar, ancak dönüş anında şirket sunucusu kısa süreli erişilemez olur. Sağlayıcının webhook’u tekrar gönderdiğinde sistem imzayı doğrular, işlem durumunu API’den okur, tutar ve sipariş kimliğini eşleştirir ve daha önce işlenmediğini görerek siparişi hazırlama kuyruğuna alır. Finans kaydı ile operasyon kaydı aynı sağlayıcı referansını taşır; kullanıcı tekrar ödeme yapmak zorunda kalmaz.

10

Canlıya geçiş yalnız başarılı testle bitmez

Test planı; başarılı ödeme kadar reddedilen kart, kullanıcı vazgeçmesi, zaman aşımı, yinelenen webhook, yanlış imza, tutar uyuşmazlığı, kısmi iade ve sağlayıcı kesintisini de kapsamalıdır. Canlıda başarısız işlem oranı, doğrulanamayan bildirim, mutabakat farkı ve iade hatası izlenmeli; API anahtarı yenileme, sağlayıcı sürüm değişikliği ve olay müdahalesi için sorumlu belirlenmelidir.

Karar kontrolü

Bu konu sizin için ne zaman gündeme gelmeli?

  1. 01

    Web sitesi, mobil uygulama veya portal içinde gerçek bir sipariş, üyelik, rezervasyon ya da tahsilat kaydı bulunuyor.

  2. 02

    Ödeme sonucu bugün manuel kontrol ediliyor veya sağlayıcı paneli ile şirket sistemi farklı durum gösteriyor.

  3. 03

    Tekrarlı bildirim, başarısız dönüş veya kesinti sırasında siparişin ne olacağı tanımlı değil.

  4. 04

    Tam veya kısmi iade, iptal, abonelik yenileme ya da ödeme linki gibi ana akış dışında durumlar gerekiyor.

  5. 05

    Finans ve operasyon ekipleri aynı sağlayıcı işlem referansını kullanarak mutabakat yapmak istiyor.

  6. 06

    İlk fazda tek bir ödeme türünü uçtan uca güvenilir çalıştırıp sonra yeni yöntemleri eklemek kabul ediliyor.

Ödeme akışı karar haritası

Ödeme ekranını değil, siparişten mutabakata kadar bütün karar zincirini tasarlayın.

Doğru entegrasyon yöntemi yalnız kullanıcı arayüzüne göre seçilmez. Kart verisinin geçtiği sınır, sipariş kaydının sahibi, ödeme sonucunun nasıl doğrulandığı ve canlı operasyonun hangi hataları toparlayacağı birlikte değerlendirilir.

Entegrasyon yöntemi

Üç yaygın ödeme deneyimi farklı sorumluluk sınırları getirir.

01

Yönlendirmeli ödeme veya ödeme linki

Kullanıcı sağlayıcının barındırdığı sayfada öder; hızlı ve kontrollü başlangıç isteyen tek seferlik akışlarda değerlendirilebilir.

Sınırı: Marka deneyimi ve dönüş akışı daha sınırlıdır; yönlendirme bütünlüğü, sipariş eşleşmesi ve sunucu doğrulaması yine şirket sisteminde yönetilir.

02

Gömülü sağlayıcı bileşeni

Ödeme alanları sağlayıcıdan gelirken kullanıcı şirket sayfasında kalır; deneyim ile veri kapsamı arasında denge kurulabilir.

Sınırı: Kart verisiyle ilişkili bütün alanların kaynağı, sayfa script güvenliği ve güncel PCI uygunluk şartları sağlayıcıyla birlikte doğrulanmalıdır.

03

Doğrudan veya ileri seviye API akışı

Abonelik, kayıtlı yöntem, çok taraflı ödeme veya özel tahsilat kuralı gibi ürün gereksinimleri daha fazla kontrol isteyebilir.

Sınırı: Güvenlik, uyum, sertifika, kart verisi ve canlı işletim sorumluluğu büyüyebilir; yalnız arayüz esnekliği için seçilmemelidir.

İşlem yaşam döngüsü

Siparişten teslimata altı doğrulanabilir adım

  1. 01

    Siparişi oluştur

    Ürün, tutar, para birimi ve müşteri bağlamını güvenilir sunucu verisiyle kaydet.

  2. 02

    Ödemeyi başlat

    Benzersiz sipariş referansıyla sağlayıcıda işlem veya ödeme oturumu oluştur.

  3. 03

    Kullanıcıyı doğrula

    Gerekli ödeme ve 3D Secure adımlarını sağlayıcının tanımladığı güvenli akışta tamamlat.

  4. 04

    Bildirimi doğrula

    Webhook imzasını, işlem durumunu, tutarı, para birimini ve sipariş kimliğini sunucuda eşleştir.

  5. 05

    Tek kez işle

    Idempotency kontrolüyle sipariş, üyelik veya teslimat aksiyonunu yalnız bir kez başlat.

  6. 06

    Mutabakatı izle

    Ödeme, iade ve operasyon kayıtlarını ortak referansla karşılaştır; farkı müdahale kuyruğuna taşı.

Canlıya çıkış kontrolü

Canlıya çıkmadan önce altı kontrol alanını kapatın.

01

Güvenilir tutar

Fiyat, indirim, vergi, kargo ve para birimi tarayıcıdan değil şirketin güvenilir kayıtlarından hesaplanır.

Kontrol sorusu: Kullanıcı tarayıcıdaki tutarı değiştirirse sunucu yanlış bedelle işlem başlatabilir mi?

02

Bildirim doğrulama

Webhook imzası veya sağlayıcının belirlediği kimlik doğrulama yöntemi kontrol edilir; gerekirse durum API’den tekrar okunur.

Kontrol sorusu: Sahte bir başarı isteği siparişi teslimata geçirebilir mi?

03

Idempotency

Aynı işlem veya bildirim yeniden geldiğinde mevcut sonuç döner; ikinci ticari aksiyon oluşmaz.

Kontrol sorusu: Aynı webhook on kez gelirse kaç sipariş, üyelik veya bakiye hareketi oluşur?

04

Durum geçişleri

Bekleyen, başarılı, başarısız, iptal ve iade durumlarının izin verilen yönleri açıkça tanımlanır.

Kontrol sorusu: İade edilmiş işlem yeniden başarılı duruma dönebilir mi; bu istek nasıl reddedilir?

05

İade ve mutabakat

Tam/kısmi iade, sipariş güncellemesi, finans kaydı ve sağlayıcı raporu ortak işlem referansında buluşur.

Kontrol sorusu: Sağlayıcı raporu ile sistem toplamı farklıysa fark hangi ekranda ve kim tarafından çözülür?

06

Sır, log ve alarm

Canlı/test anahtarları ayrılır, sırlar loglanmaz, hassas veri maskelenir ve doğrulama hataları alarm üretir.

Kontrol sorusu: Anahtar sızması, yoğun hata veya sessiz webhook kesintisi ne kadar sürede fark edilir?

Resmî ve teknik kaynaklar

Teknik ve düzenleyici sınırı resmî kaynaklardan doğrulayın.

Kaynaklar 25 Temmuz 2026 tarihinde kontrol edildi.

EMVCo — EMV 3-D Secure

Kartın fiziksel olarak bulunmadığı ödemelerde kullanıcı doğrulaması ve işlem verisi değişimine ilişkin standart özeti.

Sık sorulanlar

Kısa cevaplarla netleşen sorular.

Web sitesine veya mobil uygulamaya ödeme sistemi eklenebilir mi?

Uygun sağlayıcı API, SDK, ödeme sayfası veya link desteği sunuyorsa eklenebilir. Önce sipariş, tutar, kullanıcı, iade ve doğrulama akışı tanımlanmalı; web ve mobil istemci aynı güvenilir backend kaydı üzerinden ilerlemelidir.

Yönlendirmeli ödeme sayfası mı, gömülü ödeme formu mu daha doğru?

Tek bir doğru yoktur. Yönlendirmeli sayfa veri kapsamını ve ilk geliştirmeyi sadeleştirebilir; gömülü bileşen daha bütünlüklü deneyim sunabilir. Kart verisinin kaynağı, sağlayıcının güncel PCI dokümantasyonu, script güvenliği ve ürün gereksinimi birlikte değerlendirilmelidir.

Kullanıcının başarı sayfasına dönmesi ödemeyi doğrular mı?

Hayır. Dönüş parametreleri tek başına güvenilir ödeme kanıtı sayılmamalıdır. Sağlayıcının imzalı sunucu bildirimi doğrulanmalı ve gerektiğinde işlem durumu sağlayıcı API’sinden okunarak tutar, para birimi ve sipariş kimliği eşleştirilmelidir.

Webhook neden birden fazla kez gelir?

Sağlayıcı önceki bildirimin işlendiğine dair beklediği yanıtı alamadığında tekrar deneyebilir. Bu normal olabilecek davranış idempotent işlenmeli; aynı sağlayıcı işlemi ikinci sipariş, üyelik, teslimat veya bakiye oluşturmamalıdır.

3D Secure kullanmak ödeme entegrasyonunu tamamen güvenli yapar mı?

3D Secure, kartın fiziksel olarak bulunmadığı işlemlerde kullanıcı doğrulamasına yardımcı olur; ancak tutar manipülasyonu, sahte webhook, sızan API anahtarı, tekrar işleme veya hatalı iade gibi uygulama risklerini tek başına çözmez.

Ödeme entegrasyonunda kart bilgisi saklamak gerekir mi?

Çoğu projede kart verisini şirket sistemine almak yerine sağlayıcının barındırdığı sayfa, alan veya token yaklaşımı tercih edilebilir. Kayıtlı ödeme yöntemi gerekiyorsa sağlayıcının desteklediği güvenli token modeli ve güncel PCI sorumlulukları ayrıca doğrulanmalıdır.

Ödeme sistemi entegrasyonu ne kadar sürer?

Süre; tek seferlik ödeme, abonelik, taksit, iade, 3D Secure, mobil SDK, muhasebe bağlantısı, sağlayıcı test ortamı ve kabul senaryolarına göre değişir. Tek bir başarılı ödeme yerine hata, tekrar, iade ve mutabakat kapsamı birlikte tahmin edilmelidir.

İlgili hizmet

Otomasyon ve Entegrasyon

Hizmeti inceleyin

İlgili çözüm

E-ticaret Operasyon ve Entegrasyon Yazılımı

Çözümü inceleyin

Destekleyici rehberler

Bu konuyu tamamlayan rehberler.

Tüm eğitimleri görün

Dashboard rehberi

Dashboard Nedir? Ne İşe Yarar, Ne Zaman Gerekir?

Dashboard nedir, rapordan ve yönetim panelinden nasıl ayrılır? Doğru metrik, güvenilir veri ve aksiyon ilişkisiyle ne zaman gerekli olduğunu anlatıyoruz.

Yazıyı okuyun

Otomasyon rehberi

İş Süreçleri Otomasyonu Nedir? Nereden Başlanır?

İş süreçleri otomasyonu nedir, hangi süreç önce seçilmeli ve pilotun işe yaradığı nasıl ölçülür? Teklif, onay, görev, stok ve raporlama örnekleriyle açıklıyoruz.

Yazıyı okuyun

Tanım ve entegrasyon rehberi

API Entegrasyonu Nedir, Ne Zaman Gerekir?

API entegrasyonunun ne olduğunu; sistemlerin API, webhook veya zamanlanmış aktarım yoluyla nasıl konuştuğunu ve güvenilir veri akışının nasıl kurulduğunu anlatıyoruz.

Yazıyı okuyun

Sonraki adım

Bu konuyu kendi projenizde netleştirelim.

Problemi, mevcut akışı ve ilk beklentiyi anlatın. İlk görüşmede riski ve uygulanabilir başlangıç sınırını birlikte görünür hale getirelim.

Projenizi anlatın