PCI DSS Compliance for eCommerce: Payment Security Guide

Master PCI DSS v4.0 compliance for eCommerce with this complete guide covering SAQ types, cardholder data scoping, network segmentation, and penetration testing.

E
ECOSIRE Research and Development Team
|19 Mart 202612 dk okuma2.7k Kelime|

Compliance & Regulation serimizin bir parçası

Tam kılavuzu okuyun

E-Ticaret için PCI DSS Uyumluluğu: Ödeme Güvenliği Kılavuzu

Bir ödeme kartı içeren her e-Ticaret işlemi, Ödeme Kartı Endüstrisi Veri Güvenliği Standardı olan PCI DSS kapsamında bir uyumluluk yükümlülüğü oluşturur. Uyumsuzluk teorik bir risk değildir: Kart markaları (Visa, Mastercard, Amex), ödeme işleme anlaşmaları yoluyla sorumluluğu doğrudan satıcılara aktaran alıcı bankalara ayda 5.000 ila 100.000 ABD Doları tutarında para cezası uygulayabilir. Bir ihlalin ardından uyumlu olmayan satıcılar, ele geçirilen kart başına 50 ila 90 ABD Doları tutarında para cezasıyla, kart markası adli inceleme masraflarıyla ve - en ciddi durumlarda - satıcı hesaplarının feshedilmesiyle karşı karşıya kalır.

Mart 2025'ten itibaren zorunlu uyumlulukla birlikte Mart 2022'de yayımlanan PCI DSS v4.0, şifreleme gereksinimlerinde, kimlik doğrulama standartlarında ve ödeme sayfalarındaki komut dosyalarının işlenmesinde önemli değişiklikler getirdi. Bu kılavuz, e-Ticaret ekiplerine eksiksiz bir uygulama yol haritası sunar.

Önemli Çıkarımlar

  • PCI DSS v4.0, 31 Mart 2025 itibarıyla zorunludur — tüm e-Ticaret satıcıları yeni sürümle uyumlu olmalıdır
  • Kapsam belirleme en kritik ilk adımdır: kart sahibi verileri ortamınızı (CDE) mümkün olduğunca azaltın
  • Bir ödeme işlemcisinin barındırılan ödeme sayfasını (Stripe, Braintree, Adyen) kullanmak kapsamı önemli ölçüde azaltır
  • SAQ A, barındırılan ödeme sayfası satıcılarının çoğu için geçerlidir - ancak yalnızca sunucularınıza hiçbir kart sahibi verisinin dokunmaması durumunda
  • Yeni v4.0 gereksinimleri, tüm CDE erişimi için MFA'yı, ödeme sayfalarındaki komut dosyası bütünlüğü kontrollerini ve hedeflenen risk analizini içerir
  • Web taraması (Magecart saldırıları), ödeme sayfası komut dosyası envanterindeki yeni Gereksinim 6.4.3 ile giderilmiştir
  • Yıllık sızma testleri ve üç aylık güvenlik açığı taramaları zorunlu olmaya devam ediyor
  • Kart markalarından → satın alan bankalar → üye işyerlerinden uygunsuzluk cezaları kesiliyor

PCI DSS Çerçevesi Temelleri

PCI DSS, American Express, Discover, JCB, Mastercard ve Visa tarafından kurulan Ödeme Kartı Endüstrisi Güvenlik Standartları Konseyi (PCI SSC) tarafından sürdürülmektedir. Mevcut standart PCI DSS v4.0'dır.

Standart, 6 hedefe yönelik 12 gereksinim halinde düzenlenmiştir:

GolGereksinimler
Güvenli bir ağ oluşturun ve sürdürün1 (Güvenlik Duvarları), 2 (Varsayılan şifreler)
Kart sahibi verilerini koruyun3 (Saklanan veriler), 4 (İletilen veriler)
Bir güvenlik açığı yönetimi programı sürdürün5 (Kötü amaçlı yazılımdan koruma), 6 (Güvenli sistemler ve uygulamalar)
Güçlü erişim kontrolü uygulayın7 (Erişim kısıtlaması), 8 (Kimlik Doğrulama), 9 (Fiziksel erişim)
Ağları düzenli olarak izleyin ve test edin10 (Günlüğe kaydetme), 11 (Güvenlik testi)
Bilgi güvenliği politikasını sürdürün12 (Politika)

Uyumluluk, kart sahibi verilerini saklayan, işleyen veya ileten veya kart sahibi verilerinin güvenliğini etkileyebilecek tüm kuruluşlar için geçerlidir. Buna tüccarlar, ödeme işlemcileri, alıcılar, ihraççılar ve hizmet sağlayıcılar dahildir.


Adım 1 — Kapsamınızı Tanımlayın ve Azaltın

Kart sahibi veri ortamı (CDE), kart sahibi verilerini (CHD) veya hassas kimlik doğrulama verilerini (SAD) saklayan, işleyen veya ileten herhangi bir sistemdir. Kapsamı en aza indirmek, atabileceğiniz en etkili adımdır.

Kart sahibi verileri ve hassas kimlik doğrulama verileri:

Veri ÖğesiDepolamaya İzin VerildiŞifreleme Gerekli
Birincil Hesap Numarası (PAN)Evet, gerekirseEvet (okunamaz hale getir)
Kart sahibinin adıEvet, gerekirseÖnerilen
Son kullanma tarihiEvet, gerekirseÖnerilen
Servis koduEvet, gerekirseÖnerilen
Tam manyetik şerit / çip verileriAslaYok
CVV/CVC/CAVİzin alındıktan sonra aslaYok
PIN / PIN bloğuAslaYok

E-Ticaret için kapsam daraltma stratejileri:

  1. Barındırılan bir ödeme sayfası kullanın: Müşterileri ödeme işlemcinizin barındırılan ödeme sayfasına yönlendirin (Stripe Checkout, Braintree Hosted Fields, Adyen Drop-in). Sunucularınıza hiçbir kart sahibi verisi dokunmaz ve en basit öz değerlendirme anketi olan SAQ A'ya hak kazanırsınız.

  2. Jetonlaştırma: Yetkilendirmeden hemen sonra kart numaralarını işlemci tarafından oluşturulan jetonlarla değiştirin. Yalnızca işlemcinin tokenizasyon kasasına erişimi olmayan saldırganlar için faydasız olan token'ı saklayın.

  3. iFrame tabanlı ödeme formları: Ödeme işlemcisinin JavaScript ile oluşturulan formunu ödeme sayfanıza yerleştirin. Kart verileri sizin değil, doğrudan işlemcinin etki alanında barındırılan bir forma girilir.

  4. Ağ segmentasyonu: CDE sistemlerini (ödeme işleme sunucuları, veritabanları) güvenlik duvarlarını kullanarak kapsam dışı sistemlerden yalıtın. Düzgün bir şekilde bölümlere ayrılmış ağlar, denetim kapsamını önemli ölçüde azaltır.


Adım 2 — SAQ Türünüzü Belirleyin

Öz Değerlendirme Anketi (SAQ), Nitelikli Güvenlik Değerlendiricisinin (QSA) yerinde değerlendirmesine ihtiyaç duymayan satıcılar ve hizmet sağlayıcılara yönelik bir doğrulama aracıdır. SAQ türü, ödemeleri nasıl kabul ettiğinize göre belirlenir:

SAQ A — Ödeme işlemini tamamen PCI DSS uyumlu bir üçüncü tarafa yaptıran, kartı bulunmayan (e-ticaret) satıcılar için geçerlidir. Sistemlerinizde veya tesislerinizde hiçbir elektronik kart sahibi verisi saklanmaz, işlenmez veya iletilmez. Ödeme sayfanız tamamen ödeme işlemciniz tarafından teslim edilir. Yaklaşık 22 gereksinim.

SAQ A-EP — Ödeme işlemini kısmen dış kaynak kullanan ancak yine de kendi sunucularında barındırılan ve üçüncü taraf ödeme iframe'ini içeren bir ödeme sayfasına sahip olan e-ticaret satıcıları için. Web sunucunuz ödeme işlemlerinin güvenliğini dolaylı olarak etkiler. SAQ A'dan daha fazla gereksinim. Yeni v4.0 Gereksinimi 6.4.3'ten kritik derecede etkilenmiştir.

SAQ D — Başka herhangi bir SAQ türüne ilişkin kriterleri karşılamayan veya kart sahibi verilerini saklayan satıcılar için. 12 gereksinimin tamamını kapsar. Kendi ödeme işleme altyapısını çalıştıran satıcılar için gereklidir. Tipik olarak ~300+ alt gereksinim.

Seviye kademeleri (Mastercard/Visa standardı):

SeviyeYıllık İşlemlerDoğrulama Gereksinimi
16 milyondan fazlaYıllık QSA yerinde denetimi + üç aylık tarama
21–6 milyonYıllık SAQ veya QSA + üç aylık tarama
320.000–1 milyon (e-ticaret)Yıllık SAQ + üç aylık tarama
420.000'in altında (e-ticaret)Yıllık SAQ (önerilen) + üç aylık tarama

Adım 3 — PCI DSS v4.0 e-Ticaret için Temel Değişiklikler

PCI DSS v4.0, özellikle e-Ticaret tüccarlarını etkileyen çeşitli gereksinimler getirmiştir. 31 Mart 2025'ten itibaren tümü zorunluydu.

Gereksinim 6.4.3 — Ödeme sayfası komut dosyası yönetimi

Bu gereksinim, saldırganların kart sahibi verilerini gerçek zamanlı olarak çalmak için e-Ticaret ödeme sayfalarına kötü amaçlı JavaScript enjekte ettiği Magecart/web skimming saldırılarını doğrudan hedefler. 6.4.3 uyarınca, SAQ A-EP veya üstünü kullanan satıcılar:

  • Ödeme sayfalarında çalıştırılmaya yetkili tüm komut dosyalarının envanterini tutun
  • Her senaryonun ticari veya teknik gerekliliğini gerekçelendirin
  • Her komut dosyasının bütünlüğünü doğrulamak için bir yöntem uygulayın (üçüncü taraf komut dosyaları için Alt Kaynak Bütünlüğü karmaları veya İçerik Güvenliği Politikası direktifleri)

Tamamen dış kaynaklı ödeme sayfasına sahip SAQ A satıcıları için bu gereklilik, ödeme işlemcinizin sayfaları için geçerlidir; sizin adınıza uyumluluğu kanıtlamaları gerekir.

Gereksinim 11.6.1 — Ödeme sayfalarında değişiklik ve kurcalama tespiti

Satıcılar, ödeme sayfalarındaki HTTP başlıklarında ve komut dosyası içeriklerinde yapılan yetkisiz değişiklikleri tespit etmek için bir mekanizma (ör. İçerik Güvenliği Politikası, komut dosyası izleme hizmeti) kurmalıdır. Onaylanmayan değişikliklerden sonraki 7 gün içinde uyarılar oluşturulmalıdır.

Gereksinim 8.4.2 — CDE'ye tüm erişim için MFA

Artık yalnızca uzaktan erişim için değil, CDE'ye erişimi olan tüm kullanıcı hesapları için çok faktörlü kimlik doğrulama gerekiyor. Buna kurumsal ağ içinden üretim ödeme sistemlerine erişen dahili kullanıcılar da dahildir.

Gereksinim 3.3.1.1 — SAD, yetkilendirmeden sonra saklanamaz

Yetkilendirmeden sonra hassas kimlik doğrulama verilerinin (tam izleme verileri, CVV, PIN) saklanmasını açıkça yasaklar. Bu her zaman yasaklanmıştı ancak artık bazı sistemlerin hata ayıklama/tanılama çıktılarında SAD'yi nasıl kaydettiği konusundaki boşlukları kapatmak için daha kesin bir şekilde ifade edildi.

Hedeflenen Risk Analizi (TRA)

v4.0, Hedefli Risk Analizi kavramını getiriyor - satıcılar, eşdeğer korumayı gösteren belgelenmiş bir risk analizi yapmaları halinde bazı gereksinimlere alternatif yaklaşımlar gösterebilirler. Bu daha büyük, daha karmaşık ortamlar için esneklik sağlar.


Adım 4 — Ağ Güvenliği Mimarisi

SAQ A'nın ötesinde sistemlere sahip satıcılar için ağ güvenliği temel bir uyumluluk alanıdır.

Gereksinim 1 — Ağ güvenliği kontrollerini kurun ve sürdürün:

  • Güvenilmeyen ağlar (internet) ve CDE arasında bir güvenlik duvarı uygulayın
  • CDE ile diğer dahili ağlar arasında bir güvenlik duvarı uygulayın (bölümlendirme)
  • Tüm güvenlik duvarı kurallarını iş gerekçesiyle birlikte belgeleyin
  • Güvenlik duvarı kurallarını en az 6 ayda bir gözden geçirin
  • Açıkça gerekli olmayan tüm trafiği reddet (varsayılan-reddetme duruşu)
  • E-Ticaret için: WAF'yi (Web Uygulaması Güvenlik Duvarı) web sunucularının önüne uygulayın

Ağ segmentasyonu testi:

Ağ bölümlendirmesinin kapsamı otomatik olarak azalttığı yaygın bir yanılgıdır. PCI SSC, segmentasyonun etkili olup olmadığını test etmenizi gerektirir; sızma testleri, segmentasyon sınırını aşma girişimlerini içermelidir. Bir penetrasyon test cihazı CDE sistemlerine kapsam dışı ağlardan ulaşabilirse segmentasyon etkili olmaz ve daha geniş bir ortam devreye girer.

e-Ticaret için DMZ mimarisi:

Internet → WAF/Load Balancer → DMZ (Web Servers) → Internal Firewall → CDE (Payment Servers, DB) → Internal Network

DMZ'deki web sunucuları vitrininize hizmet eder. DMZ'den CDE'ye yalnızca belirli, belgelenmiş trafik (HTTPS'den ödeme API'sine, belirli bağlantı noktasındaki SQL'den belirli DB'ye) geçer. Diğer tüm trafik engellenir.


Adım 5 — Uygulama Güvenliği Gereksinimleri

Gereksinim 6 — Güvenli sistemler ve yazılımlar geliştirin ve sürdürün:

  • Kapsam dahilindeki tüm özel ve üçüncü taraf yazılımların envanterini tutun
  • Resmi bir güvenlik açığı yönetimi sürecinin parçası olarak güvenlik açıklarını ele alın
  • Web'e yönelik uygulamaları bilinen saldırılara karşı koruyun (OWASP İlk 10)
  • Önemli değişikliklerin üretime uygulanmasından önce güvenlik kodu incelemeleri veya uygulama sızma testleri gerçekleştirin
  • Yalnızca kararlı güvenlik düzeltme eki işlemlerine sahip saygın satıcıların yazılımlarını kullanın

Web uygulaması güvenlik duvarı (WAF) — Gereksinim 6.3.2 ve 6.4.2:

WAF, saldırıları engelleyecek veya uyarı oluşturacak ve 1 saat içinde inceleyecek şekilde yapılandırılmış, halka açık tüm web uygulamaları için zorunludur. E-Ticaret için WAF'ın şunları kapsaması gerekir:

  • SQL enjeksiyon önleme
  • Siteler arası komut dosyası çalıştırma (XSS) koruması
  • Siteler arası istek sahteciliği (CSRF) koruması
  • Kötü amaçlı bot tespiti
  • Kaba kuvvet önleme için hız sınırlaması

Bağımlılık ve üçüncü taraf yazılım yönetimi:

e-Ticaret platformları (WooCommerce, Magento, Shopify özelleştirmeleri) büyük ölçüde eklentilere ve uzantılara dayanır. Kapsamdaki her eklenti güvenlik açısından değerlendirilmelidir. Bir envanter tutun ve yama SLA'nız dahilinde yamaları uygulayın (kritik: satıcı yamasının yayınlanmasından itibaren 7 gün).


Adım 6 — Erişim Kontrolü ve Kimlik Doğrulama

Gereksinim 7 — Sistem bileşenlerine ve kart sahibi verilerine erişimi kısıtlayın:

  • En az ayrıcalığa dayalı rol tabanlı erişim kontrolünü uygulayın
  • Belgelenen açık izinlerle tüm erişimi varsayılan olarak "tümünü reddet" olarak ayarlayın
  • Kullanıcı erişim haklarını en az 6 ayda bir gözden geçirin

Gereksinim 8 — Kullanıcıları tanımlayın ve erişimi doğrulayın:

  • CDE'ye erişimi olan her kişiye benzersiz bir kimlik atayın
  • Şifreler minimum 12 karakter (v3.2.1'de 7'den v4.0'da artış), karmaşıklık gereksinimleri
  • Maksimum 10 geçersiz denemeden sonra hesapları kilitleyin (v4.0 varsayılanı veya TRA'ya göre)
  • CDE oturumları için maksimum 15 dakika işlem yapılmadığında oturum zaman aşımı
  • Tüm CDE erişimi için MFA gereklidir (yalnızca uzaktan kumandadan v4.0 genişletme)
  • Hizmet hesapları ve sistem hesapları, kullanıcı hesaplarından ayrı olarak yönetilmelidir

Adım 7 — Güvenlik Açığı Yönetimi ve Testi

Gereksinim 11 — Sistemlerin ve ağların güvenliğini test edin:

Üç aylık dahili güvenlik açığı taramaları: Kapsam dahilindeki tüm sistemleri tarayın. Bir sonraki taramadan önce tüm yüksek önemdeki ve kritik güvenlik açıklarını giderin. Taramalar, onaylanmış araçlar (Nessus, Qualys, OpenVAS) kullanılarak dahili personel tarafından yapılabilir.

Onaylı Tarama Satıcısı (ASV) tarafından üç ayda bir yapılan harici güvenlik açığı taramaları: Dışarıdan erişilebilen tüm sistemlerin harici taramaları, PCI SSC onaylı bir ASV tarafından gerçekleştirilmelidir. Uyumluluğu doğrulayabilmeniz için taramanın başarılı olması (açık yüksek/kritik güvenlik açığı olmaması) gerekir.

Yıllık sızma testi: Nitelikli bir iç kaynak veya saygın bir dış firma tarafından gerçekleştirilir. Şunları kapsamalıdır:

  • Kapsam dahilindeki tüm sistemler ve ağlar
  • Segmentasyon kontrolleri (CDE'nin uygun şekilde izole edildiğini doğrulayın)
  • Web'e yönelik uygulamalar için OWASP İlk 10
  • Sosyal mühendislik (daha yüksek riskli ortamlar için)

Tüm sızma testi bulgularını düzeltin ve düzeltmeyi onaylamak için doğrulama testi yapın.

Dosya Bütünlüğü İzleme (FIM): FIM'i tüm kritik sistem dosyalarına, yapılandırma dosyalarına ve içerik dosyalarına dağıtın. Yetkisiz değişiklikler durumunda 1 saat (v4.0) içinde uyarı verin.


E-Ticaret için PCI DSS Uyumluluk Kontrol Listesi

  • Ödeme işleme kapsamı tanımlandı ve azaltıldı (barındırılan ödeme sayfası veya mümkün olduğunda kullanılan tokenizasyon)
  • Ödeme kabul yöntemine göre tanımlanan SAQ türü
  • Ağ segmentasyonu uygulandı ve belgelendi
  • Kart sahibi veri envanteri tamamlandı — hiçbir yerde saklanan SAD yok
  • Tüm kart sahibi veri depolama alanı şifrelenmiştir (AES-256 veya eşdeğeri)
  • Tüm ödeme verileri aktarımı için TLS 1.2+ uygulandı
  • Ödeme sayfası komut dosyası envanterinin belgelenmesi (Gereksinim 6.4.3)
  • Ödeme sayfalarında değişiklik/kurcalama tespiti uygulandı (Gereksinim 11.6.1)
  • WAF, halka açık tüm web uygulamalarının önünde dağıtıldı
  • Tüm CDE erişimi için MFA uygulandı (Gereksinim 8.4.2)
  • Benzersiz kullanıcı kimlikleri, güçlü şifreler, yapılandırılmış hesap kilitleme
  • Üç ayda bir yapılan güvenlik açığı taramaları (dahili + ASV harici) tamamlandı
  • Yıllık penetrasyon testi tamamlandı, bulgular düzeltildi
  • CDE sistemlerinde uygulanan dosya bütünlüğü izleme
  • Son 6 ay içinde incelenen güvenlik duvarı kuralları
  • CDE'ye dokunan tüm personel için güvenlik farkındalığı eğitimi tamamlandı
  • Olay müdahale planı ödeme kartı ihlali senaryolarını kapsar
  • Satıcı/hizmet sağlayıcının PCI DSS uyumluluğu doğrulandı

Sıkça Sorulan Sorular

Mağazamız için Shopify'ı kullanıyoruz — hâlâ PCI DSS uyumluluğuna ihtiyacımız var mı?

Shopify, PCI DSS Düzey 1 sertifikalı bir hizmet sağlayıcıdır. Shopify'ın standart ödeme işlemini (Shopify Payments veya Shopify tarafından barındırılan ödeme) kullanırsanız uyumluluk kapsamınız önemli ölçüde azalır. Shopify hizmetlerini kullanımınızı kapsayan başta SAQ A olmak üzere hâlâ yükümlülükleriniz bulunmaktadır. Shopify ödemenize özel JavaScript eklerseniz veya kart verilerini Shopify ortamı dışında işleyen üçüncü taraf ödeme uygulamalarını kullanırsanız kapsam genişler.

PCI DSS uyumluluğu ile PCI DSS sertifikası arasındaki fark nedir?

Satıcılar için resmi bir "PCI DSS sertifikası" yoktur. Satıcılar, Uyumluluğu Öz Değerlendirme Anketleri veya (Seviye 1 satıcılar) bir QSA tarafından yürütülen Uyumluluk Raporu (RoC) aracılığıyla doğrular. Hizmet sağlayıcılar Visa'nın Küresel Hizmet Sağlayıcıları Sicilinde listelenebilir. "Sertifikalı" ve "uyumlu" terimleri genellikle pazar iletişimlerinde birbirinin yerine kullanılır, ancak teknik olarak satıcılar uyumluluğu kendileri beyan eder veya QSA onaylıdır.

Satıcılar uyumsuzluk nedeniyle hangi cezalarla karşı karşıya kalır?

Cezalar doğrudan PCI SSC'den gelmiyor; kart markalarından, satın alan bankalar aracılığıyla geliyor. Aylık para cezaları, satıcı düzeyine ve uyumsuzluğun süresine bağlı olarak genellikle 5.000 ila 100.000 ABD Doları arasında değişir. Bir ihlalin ardından, kart markaları kart başına para cezaları (Visa kartı başına 50-90 ABD Doları, Mastercard için benzer), adli soruşturma maliyetleri (20.000-200.000 ABD Doları+) ve zorunlu kart yeniden düzenleme maliyetleri uygulayabilir. Ciddi durumlarda, satıcılar kartla ödeme kabul etme yeteneklerini tamamen kaybederler. Tekrarlayan suçlular veya büyük ihlal etkisine sahip satıcılar en yüksek cezalarla karşı karşıya kalır.

Magecart saldırısı nedir ve PCI DSS v4.0 bunu nasıl ele alır?

Magecart, müşteriler yazarken kart sahibi verilerine gerçek zamanlı olarak müdahale etmek için e-Ticaret ödeme sayfalarına kötü amaçlı JavaScript'in enjekte edildiği saldırıları ifade eder. Bu saldırılar, satıcıların ödeme sayfalarına dahil ettiği üçüncü taraf komut dosyalarından (analizler, sohbet widget'ları, etiket yöneticileri) yararlanır. PCI DSS v4.0 Gereksinimleri 6.4.3 ve 11.6.1 doğrudan bu konuya değinmektedir: Satıcılar, ödeme sayfalarındaki tüm komut dosyalarının envanterini çıkarmalı ve bütünlüğünü doğrulamalı ve ödeme sayfası kodundaki yetkisiz değişiklikleri tespit etmek için izleme dağıtmalıdır.

Başsız bir e-Ticaret mimarisi için PCI DSS'yi nasıl ele alacağız?

Başsız e-Ticaret, ön uç sunum katmanını arka uç ticaret motorundan ayırır. PCI DSS amaçları açısından önemli olan, kart sahibi verilerinin nereye aktığıdır. Başsız ön ucunuz Stripe Elements veya benzer bir iFrame tabanlı çözüm kullanıyorsa, kart verileri ön uç sunucularınıza dokunmadan doğrudan tarayıcıdan ödeme işlemcisine gider; bu SAQ A bölgesidir. Başsız mimariniz özel sunucu tarafı ödeme işlemeyi içeriyorsa kapsam önemli ölçüde genişler ve kapsam belirleme rehberliği için bir QSA kullanmalısınız.

PCI DSS değerlendirmemiz için bir QSA'ya ihtiyacımız var mı?

Yalnızca Seviye 1 üye işyerlerinin (Visa/Mastercard için yılda 6 milyondan fazla işlem gerçekleştiren) yıllık Uyumluluk Raporu (RoC) için QSA'ya başvurması gerekmektedir. Seviye 2-4 satıcılar SAQ aracılığıyla kendilerini doğrulayabilirler. Bununla birlikte, birçok satıcı, özellikle kapsamlarından emin olmadıklarında veya karmaşık altyapıya sahip olduklarında, gerekli olmadığında bile rehberlik için gönüllü olarak bir QSA veya Nitelikli Güvenlik Değerlendiricisi Şirketi (QSAC) ile çalışır.


Sonraki Adımlar

PCI DSS uyumluluğu müşterilerinizin ödeme verilerini korur, sorumluluk riskinizi sınırlar ve kart kabulünü sürdürmek için bir ön koşuldur. Shopify veya özel platformlardaki e-Ticaret işletmeleri için ilk adım her zaman kapsamın daraltılmasıdır; barındırılan ödeme sayfalarının doğru kullanımı yoluyla SAQ A'ya ulaşmak en hızlı ve en uygun maliyetli yoldur.

ECOSIRE'ın e-Ticaret uygulama ekibi, CDE kapsamını en aza indirecek şekilde sıfırdan tasarlanmış ödeme mimarisiyle PCI DSS uyumlu Shopify mağazaları ve özel ticaret platformları oluşturma konusunda geniş deneyime sahiptir.

Başlayın: ECOSIRE Shopify Hizmetleri

Sorumluluk reddi: Bu kılavuz yalnızca bilgilendirme amaçlıdır ve yasal veya uyumluluk tavsiyesi niteliğinde değildir. PCI DSS gereksinimleri, kart markasına ve alıcıya göre değişebilir ve değişiklik gösterebilir. Ortamınıza özel kesin uyumluluk rehberliği için bir QSA ile iletişime geçin.

E

Yazan

ECOSIRE Research and Development Team

ECOSIRE'da kurumsal düzeyde dijital ürünler geliştiriyor. Odoo entegrasyonları, e-ticaret otomasyonu ve yapay zeka destekli iş çözümleri hakkında içgörüler paylaşıyor.

WhatsApp'ta Sohbet Et