Global Payment Infrastructure Atlas: Türkiye Uyumluluk Haritası

Bir e-ticaret ya da SaaS projesine başlayan hemen herkes aynı soruyla karşılaşıyor: "Hangi ödeme altyapısını seçmeliyim?" Bu sorunun cevabı bir marka adı değil, bir veri seti. Ödeme sağlayıcı uyumluluk bilgisi — yani bir sağlayıcının Türkiye'de kurulu şirketlerle çalışıp çalışmadığı, onboarding sırasında hangi KYC belgelerini istediği, parayı hangi ülkedeki hesaba ödediği, API'sinin hangi senaryoları desteklediği — internette dağınık, hızla bayatlayan ve çoğu zaman pazarlama diliyle yazılmış sayfalarda duruyor. Ben de bu dağınıklığı düzenli tazelenen bir envantere dönüştürmeye karar verdim: dünya genelindeki finansal işlem sağlayıcılarını Türkiye penceresinden karşılaştırılabilir hâle getiren bir atlas.

Bu yazı size "en iyi sağlayıcı şudur" demeyecek. Anlatacağım şey yöntem: hangi alanları izliyorum, kayıtları nasıl normalize ediyorum, hangi alanın ne kadar sürede bayatladığını nasıl takip ediyorum ve hukuki boyutu hangi kontrol listesiyle ele alıyorum. Stripe, PayPal, Adyen, Wise, iyzico, PayTR ya da Param gibi isimler örnek olarak geçecek; ama hiçbirine ait komisyon oranı, tarih ya da "serbest/yasak" hükmü bu yazıda yok. Çünkü o bilgiler ancak kaynağından, güncel hâliyle doğrulandığında değer taşıyor; ikinci elden aktarıldıkları anda risk hâline geliyorlar.

Neden liste değil, atlas?

İnternette "Türkiye'de çalışan ödeme sağlayıcıları" başlıklı onlarca liste var ve neredeyse hepsi aynı üç zaafı taşıyor. Birincisi, tek boyutlular: genellikle sadece komisyon oranına odaklanıyorlar, oysa karar en az beş boyutlu. İkincisi, tarihsizler: sayfanın ne zaman yazıldığı, hangi bilginin ne zaman kontrol edildiği belli değil. Üçüncüsü, teşvikliler: çoğu liste bir affiliate geliriyle besleniyor, sıralama da ona göre şekilleniyor.

Atlas derken kastettiğim şey bunun tersi: her hücresinin kaynağı ve doğrulama tarihi kayıtlı, alan bazında tazelenen, sıralama yapmayan bir envanter. Bu kurgu, daha önce anlattığım veri zenginleştirme motoru yaklaşımının doğrudan bir uzantısı: dış kaynaklardan gelen ham bilgiyi şemaya oturt, kaynağını yanına iliştir, tazeliğini ayrı bir alan olarak izle. İzlediğim ana boyutlar şunlar:

• Türkiye'de kurulu tüzel kişiliği müşteri olarak kabul edip etmediği (evet / hayır / belirsiz)
• KYC ve onboarding yükü: istenen belgeler, süreç uzunluğu, ret gerekçeleri
• Ödeme akışı: paranın hangi ülkedeki hesaba, hangi para biriminde ödendiği
• API olgunluğu: dokümantasyon dili, test ortamı, webhook davranışı
• Maliyet alanları: komisyonun kendisi değil, komisyonun yayınlandığı kaynak sayfa

Son maddeye dikkat: envantere komisyon oranını sayı olarak yazmıyorum. Sayı yerine sağlayıcının güncel fiyat sayfasının adresini ve son kontrol tarihini tutuyorum; çünkü bu, atlasın en hızlı bayatlayan alanı ve ikinci elden kopyalanan her oran birkaç ay içinde yanlışa dönüşüyor.

Veri modeli: şema ve doğrulama

Atlasın değeri, kayıtların ne kadar disiplinli girildiğine bağlı. Serbest metin alanlar hızla çöplüğe dönüştüğü için her kaydı bir şemadan geçiriyorum. Python tarafında bunu basit bir dataclass ve doğrulama fonksiyonuyla çözüyorum:

from dataclasses import dataclass
from datetime import date

GECERLI_KYC = {"tam", "kismi", "belirsiz"}

@dataclass
class SaglayiciKaydi:
    ad: str
    merkez_ulke: str          # ISO 3166-1 alpha-2
    tr_tuzel_kisi_kabul: str  # "evet" / "hayir" / "belirsiz"
    kyc_seviyesi: str
    komisyon_kaynak_url: str  # sayiyi degil, kaynagi sakliyorum
    son_dogrulama: date

    def dogrula(self):
        hatalar = []
        if not self.ad.strip():
            hatalar.append("ad bos olamaz")
        if len(self.merkez_ulke) != 2:
            hatalar.append("merkez_ulke ISO alpha-2 olmali")
        if self.kyc_seviyesi not in GECERLI_KYC:
            hatalar.append("kyc_seviyesi gecersiz: " + self.kyc_seviyesi)
        if not self.komisyon_kaynak_url.startswith("https://"):
            hatalar.append("komisyon alani kaynak URL olmadan kabul edilmez")
        return hatalar

kayit = SaglayiciKaydi(
    ad="Ornek Saglayici",
    merkez_ulke="NL",
    tr_tuzel_kisi_kabul="belirsiz",
    kyc_seviyesi="tam",
    komisyon_kaynak_url="https://ornek-saglayici.example/pricing",
    son_dogrulama=date(2026, 8, 15),
)
print(kayit.dogrula())  # bos liste = kayit temiz

Burada iki tasarım kararı önemli. Birincisi, "belirsiz" değeri meşru bir değerdir; bilmediğim şeyi "hayır" diye kodlamak atlası sessizce yanlışa sürükler. İkincisi, komisyon alanı kaynak URL olmadan kabul edilmiyor: doğrulanamayan bilgi envantere hiç girmiyor. Ayrıca aynı sağlayıcı farklı kaynaklarda farklı adlarla görünebiliyor — tüzel kişilik adı, marka adı, eski adı. Kayıtları birleştirirken bulanık şirket eşleştirme tarafında anlattığım normalizasyon adımlarını aynen burada da uyguluyorum; yoksa aynı sağlayıcı envantere üç ayrı satır olarak giriyor.

Alan bayatlaması: asıl mühendislik problemi

Bu tür bir envanterde en zor kısım veriyi toplamak değil, taze tutmak. Her alanın farklı bir raf ömrü var: fiyat sayfası ayda bir değişebilirken, bir sağlayıcının merkez ülkesi yıllarca sabit kalıyor. Bu yüzden tek bir "son güncelleme" tarihi yetmiyor; alan bazında doğrulama tarihi tutuyorum ve her alana bir raf ömrü atıyorum. Raf ömrü dolan alan, o hafta kontrol edilecekler kuyruğuna düşüyor:

from datetime import date

RAF_OMRU_GUN = {
    "komisyon": 30,
    "kyc_seviyesi": 90,
    "tr_tuzel_kisi_kabul": 60,
    "mevzuat_notu": 45,
}

def bayat_alanlar(kayit, bugun):
    """Raf omru dolan alanlari dondurur."""
    bayatlar = []
    for alan, omur in RAF_OMRU_GUN.items():
        tarih = kayit.get(alan + "_dogrulama")
        if tarih is None or (bugun - tarih).days > omur:
            bayatlar.append(alan)
    return bayatlar

kayit = {
    "ad": "Ornek Saglayici",
    "komisyon_dogrulama": date(2026, 6, 1),
    "kyc_seviyesi_dogrulama": date(2026, 8, 1),
}
print(bayat_alanlar(kayit, date(2026, 8, 31)))
# ['komisyon', 'tr_tuzel_kisi_kabul', 'mevzuat_notu']

Buradaki raf ömrü değerleri benim çalışma tercihim; evrensel bir doğru değil. Önemli olan ilke: hiç doğrulanmamış alan da bayat sayılıyor. "Veri yok" ile "veri taze" asla aynı kefeye konmuyor. Haftalık kontrol kuyruğu bu fonksiyondan besleniyor ve çıktıyı CSV olarak alıp elle ya da yarı otomatik tarama turlarına dağıtıyorum.

Karşılaştırma: skor değil, profil

İlk denemede sağlayıcılara tek bir "Türkiye uyum skoru" hesaplamıştım; sonra vazgeçtim. Tek sayı, ağırlıkları benim seçtiğim gizli bir görüşe dönüşüyor ve okuyan kişi kendi önceliğini göremiyor. Onun yerine her sağlayıcı için bir profil çıkarıyorum: boyut başına ayrı değer, her değerin yanında kaynak ve tarih. Karşılaştırma yaparken de şu soruları soruyorum:

• İş modeli hangi boyuta duyarlı? Abonelik satan bir SaaS için tekrarlayan ödeme desteği, fiziksel ürün satan site için iade akışı öne çıkıyor.
• Para nerede birikiyor? Yurt dışında biriken bakiyenin Türkiye'ye getirilme yolu ayrı bir maliyet ve süreç kalemi.
• Onboarding reddi hâlinde B planı ne? Tek sağlayıcıya bağlı mimari, ret ya da hesap dondurma durumunda işi tamamen durduruyor.
• Alanların kaçı "belirsiz"? Belirsizlik oranı yüksek bir sağlayıcı, kötü bir sağlayıcı değil; henüz araştırılmamış bir sağlayıcıdır.

Hukuki çerçeve: görüş değil, kontrol listesi

Burası atlasın en dikkatli davrandığım bölümü. Türkiye'de ödeme hizmetleri 6493 sayılı kanun çerçevesinde düzenleniyor ve bu alandaki yetki zaman içinde BDDK'dan TCMB'ye geçti; lisanslı kuruluşların güncel listesi de düzenleyici kurumun kendi yayınlarından takip ediliyor. Kart verisi işleyen her akış PCI-DSS kapsamına giriyor; sağlayıcının barındırdığı (hosted) ödeme sayfası kullanmak bu yükün büyük kısmını sağlayıcıya devrediyor. KVKK tarafında ise yurt dışı merkezli bir sağlayıcı kullanmak, kişisel verinin yurt dışına aktarımı boyutunu gündeme getiriyor ve bunun sözleşme ile aydınlatma metinlerine yansıması gerekiyor.

Bunların hiçbirini atlasım "hüküm" olarak tutmuyor. Her sağlayıcı kaydında hukuki alanlar birer soru olarak duruyor: lisans durumu düzenleyicinin güncel listesinden kontrol edildi mi, veri aktarım mekanizması sözleşmede tanımlı mı, kart verisi bizim sunucumuza hiç uğruyor mu? Açıkça söyleyeyim: bu bir hukuki görüş değil, teyit edilmesi gereken bir kontrol listesidir. Madde numarası ezberlemek yerine, canlıya çıkmadan önce bu soruların her birinin güncel resmi kaynaktan ve gerekiyorsa bir hukukçuyla birlikte cevaplanmasını şart koşuyorum.

İşleyiş: atlası canlı tutan rutin

Sistemin bütünü üç parçadan oluşuyor: şemadan geçen kayıtlar, alan bazlı bayatlama kontrolü ve haftalık tarama rutini. Rutin her hafta bayat alan listesini üretiyor; ben ya da yarı otomatik bir tarama, yalnızca o alanları güncelliyor. Böylece "tüm envanteri baştan tara" gibi sürdürülemez bir işe hiç girmiyorum. Çıktı tarafında ise atlas JSON olarak duruyor, karşılaştırma görünümleri bu tek kaynaktan üretiliyor. Aynı desen — tek doğru kaynak, üretilen görünümler, alan bazlı tazelik — ana sayfada anlattığım veri ve otomasyon işlerinin neredeyse tamamında karşıma çıkıyor; ödeme sağlayıcıları sadece iyi bir örnek.

Benzer bir envantere ihtiyacınız varsa — ödeme sağlayıcıları için ya da bambaşka bir alanda — sıfırdan liste kopyalamak yerine bu yapıyı kurmanızı öneririm: şema, kaynak zorunluluğu, alan bazlı raf ömrü. Kurulumu konuşmak isterseniz iletişim bölümünden bana ulaşabilirsiniz; elinizdeki veri kaynaklarına bakıp tazeleme rutinini birlikte tasarlayabiliriz.