Otel rezervasyonu sırasında kart bilgisi çağrı merkezine söylenebilir, e-postayla gönderilebilir, OTA ekranından görüntülenebilir veya çevrim içi ödeme sayfasına yazılabilir. Bu temas noktalarından yalnız biri kontrolsüz kaldığında kart numarası PMS notuna, mesaj ekranına, tarayıcı çıktısına ya da ortak dosyaya kopyalanabilir. Güvenli ödeme tasarımı, çalışanların kart verisini daha dikkatli yazmasını istemekle sınırlı değildir. Veri akışını en baştan azaltır; kart bilgisini uygun ödeme sağlayıcısında tutar, otel uygulamalarında token kullanır, görüntülemeyi sınırlar ve her erişimi denetlenebilir hale getirir.

What you will learn in this article
  • Kart numarasının hangi kanaldan geldiği, nerede işlendiği, hangi sisteme aktarıldığı ve ne zaman silindiği uçtan uca haritalanmadan güvenli kapsam belirlenemez.
  • PMS notu, e-posta, sohbet, ekran görüntüsü ve tablo kart verisi saklama alanı değildir; misafire sağlayıcının güvenli ödeme sayfası veya ödeme bağlantısı yönlendirilmelidir.
  • Tokenizasyon, maskeleme ve kısaltma aynı işlem değildir; CVV/CVC gibi hassas doğrulama verileri yetkilendirme sonrasında saklanmamalı, erişim ve değişiklikler loglanmalıdır.

Map the path card data follows through the hotel

PCI DSS, kart sahibi verisini veya hassas doğrulama verisini saklayan, işleyen ya da ileten kuruluşların yanı sıra kart verisi ortamının güvenliğini etkileyebilen sistemleri de kapsar. Otelde bu sınır yalnız sanal POS ekranı değildir. Rezervasyon motoru, çağrı merkezi, ön büro bilgisayarı, PMS, kanal entegrasyonu, ödeme terminali, muhasebe aktarımı, destek aracı ve yedekler aynı akışın farklı noktaları olabilir. Kapsamı ürün adına bakarak değil, verinin gerçekten izlediği yol üzerinden belirlemek gerekir.

İlk çalışma bir veri akış şeması olmalıdır: kart numarası hangi kanaldan geliyor, tam numarayı hangi sistem görüyor, hangi servis yetkilendirme yapıyor, otele ne dönüyor ve kayıt ne kadar tutuluyor? E-posta kutusu, yazıcı, tarayıcı indirme klasörü, çağrı kaydı ve destek ekran paylaşımı gibi görünmeyen kopyalar ayrıca aranmalıdır. Akışın sahibi, kullanılan hizmet sağlayıcı, saklama gerekçesi ve imha kuralı yazılı olmadığında denetim yalnız ana uygulamayı kontrol eder ve en riskli yan yolları kaçırır.

  • Rezervasyondan muhasebeye kadar tüm kart verisi temas noktaları listelendi.
  • Her sistem için saklama, işleme, iletme ve görüntüleme durumu ayrı işaretlendi.
  • E-posta, çağrı kaydı, çıktı, ekran görüntüsü, destek ve yedek kopyaları kapsama alındı.
  • Her veri akışına iş sahibi, hizmet sağlayıcı, saklama süresi ve imha kuralı atandı.

Keep card details out of PMS notes and messages

PMS not alanı hızlı olduğu için çalışanlar kart numarasını, son kullanma tarihini veya güvenlik kodunu rezervasyona yapıştırabilir. Ancak notlar çoğu zaman daha geniş kullanıcı grubuna görünür, raporlara girer, yedeklenir ve olması gerekenden uzun tutulur. Aynı risk e-posta, ekip mesajı, görev açıklaması, çevrim içi formun serbest metin alanı ve elektronik tablo için de geçerlidir. Maskeleme sonradan yapılacak bir temizlik işi değil, verinin bu alanlara hiç girmemesini sağlayan tasarım kuralı olmalıdır.

Misafir kart bilgisini e-postayla ya da mesajla gönderirse çalışan bilgiyi başka sisteme kopyalamamalıdır. Kurum prosedürü; mesajı sınırlı yetkili ekibe yönlendirmeyi, güvenli olmayan kopyayı tanımlı yöntemle kaldırmayı, misafire güvenli ödeme bağlantısı göndermeyi ve olayı loglamayı açıklamalıdır. Formlar kart numarası örüntüsünü serbest metinde algılayıp kaydı engelleyebilir; ancak bu kontrol tek başına yeterli değildir. Eğitim ekran üzerinde kısa uyarılarla desteklenmeli, test kartı kullanılarak sürecin gerçekten çalıştığı doğrulanmalıdır.

  • PMS notu, mesaj, görev, e-posta ve tablo alanlarında kart verisi yasaklandı.
  • Serbest metin alanlarında kart numarası örüntüsü için kayıt engeli ve uyarı uygulandı.
  • Güvensiz kanaldan gelen veri için silme, bildirim ve güvenli bağlantıya yönlendirme akışı yazıldı.
  • Çalışan eğitimi gerçek kart yerine test verisiyle düzenli olarak doğrulandı.

Reduce data with payment links and hosted pages

En güçlü kontrol, otelin kart numarasını hiç almamasıdır. Misafire ödeme hizmet sağlayıcısının barındırdığı sayfa veya tek kullanımlık ödeme bağlantısı gönderildiğinde kart bilgisi doğrudan uygun ödeme ortamına girilebilir. PMS'e tam kart numarası yerine işlem kimliği, durum, tutar, para birimi, zaman ve gerekiyorsa yeniden kullanılabilir bir token döner. Böylece resepsiyon tahsilatı ve iadeyi takip ederken hassas bilgiyi görmez.

Dış sağlayıcı kullanmak otelin bütün sorumluluğunu otomatik olarak ortadan kaldırmaz. Bağlantının doğru rezervasyon ve tutar için üretildiği, tahmin edilemez olduğu, HTTPS kullandığı, süresinin dolduğu ve ödeme sonucu imzalı ya da güvenilir sunucu bildirimiyle doğrulandığı kontrol edilmelidir. Çalışan yalnız tarayıcıdaki başarı sayfasına bakarak folyo kapatmamalıdır. Sağlayıcının PCI DSS uyumluluk kanıtı, hizmet kapsamı, alt hizmet sağlayıcıları ve olay bildirim şartları sözleşme ve yıllık değerlendirmede izlenmelidir.

  • Kart numarası yerine ödeme kimliği ve token döndüren barındırılan akış tercih edildi.
  • Ödeme bağlantıları rezervasyon, tutar, para birimi, son kullanma ve tek kullanımla sınırlandı.
  • Başarılı ödeme sunucu bildirimiyle doğrulanmadan folyo veya rezervasyon durumu değiştirilmedi.
  • Ödeme sağlayıcısının güncel uyumluluk kapsamı ve olay bildirim sorumluluğu izlendi.

Do not confuse tokenization, masking and truncation

Token, kart numarasının yerine kullanılan ve kendi başına hesabı ortaya çıkarmayan değerdir. Sonraki tahsilat veya iade, yetkili sistemin tokenı ödeme sağlayıcısına göndermesiyle yapılabilir. PCI SSC, tokenizasyonun kart verisi ortamını azaltmaya yardımcı olabileceğini; ancak token üretimi, eşleme tablosu, şifreleme anahtarları ve tokenı tekrar kart numarasına çevirebilen sistemlerin kapsam dışında sayılamayacağını açıklar. Otel uygulaması tokenı sıradan metin gibi korumasız paylaşmamalı ve hangi işlemlerde kullanılabileceğini sınırlandırmalıdır.

Maskeleme ekranda gösterilen kart numarasının bir bölümünü gizler; kısaltma ise saklanan değerden belirli hanelerin kaldırılmasıdır. PCI SSC bu iki kavramın farklı olduğunu vurgular. Ekranda yalnız gerekli son haneleri göstermek, veri tabanında tam numaranın bulunduğu gerçeğini değiştirmez. Tersine, kısaltılmış veri de başka kaynaklarla birleştiğinde risk oluşturabilir. Tasarım belgesinde token, maskeli görüntü ve saklanan kısaltılmış değer ayrı isimlerle gösterilmeli; kullanıcı arayüzü tam numarayı varsayılan olarak hiçbir rolde açmamalıdır.

  • Tokenın hangi sistemde üretildiği ve kart numarasına dönüş yolunun kimde olduğu belirlendi.
  • Maskeleme yalnız ekran kontrolü, kısaltma ise saklama kontrolü olarak ayrı tanımlandı.
  • Token kullanım yetkisi işlem türü, tesis, tutar ve kullanıcı rolüne göre sınırlandı.
  • Tam kart numarasını gösteren genel bir kullanıcı arayüzü veya dışa aktarma bırakılmadı.

Manage retention and sensitive authentication data

Kart sahibi verisi yalnız belgelenmiş iş ve mevzuat ihtiyacı kadar tutulmalıdır. Her kayıt türü için gerekçe, süre, saklandığı ortam ve güvenli silme yöntemi tanımlanmalıdır. Yedek, log, rapor ve dışa aktarma dosyaları ana veri tabanından farklı sürede kalıyorsa imha planına ayrıca eklenmelidir. 'İleride gerekebilir' gerekçesi süresiz saklama için yeterli değildir; eski verinin miktarı arttıkça yetkisiz erişim ve olayın etkisi de büyür.

PCI SSC'ye göre tam manyetik şerit veya çip eşdeğeri veri, kart doğrulama kodu ve PIN/PIN bloğu gibi hassas doğrulama verileri yetkilendirme sonrasında, şifrelenmiş olsa bile saklanmamalıdır. Özellikle CVV/CVC kodunu garanti veya no-show gerekçesiyle PMS'e yazmak güvenli bir yöntem değildir. Daha sonraki tahsilat ihtiyacı, ödeme sağlayıcısının uygun token veya kart saklama hizmetiyle çözülmelidir. Yetkilendirme öncesindeki geçici işlem de yalnız gerekli süre ve güçlü korumalarla sınırlandırılmalıdır.

  • Her kart verisi kaydı için gerekçe, süre, ortam ve güvenli imha yöntemi belirlendi.
  • CVV/CVC, PIN ve tam iz verisinin yetkilendirme sonrasında saklanması engellendi.
  • No-show ve sonraki tahsilatlar için güvenli sağlayıcı tokenı kullanıldı.
  • Yedek, log, rapor, çıktı ve dışa aktarma dosyaları aynı imha planına dahil edildi.

Restrict permissions, logs and service-provider access

Kart verisiyle ilişkili işlevlere erişim görev gereğine göre verilmelidir. Resepsiyon tahsilat durumunu görebilirken tam kart numarasını görmemeli; iade, manuel işlem, bağlantı yenileme ve tokenla tahsilat gibi riskli işlemler farklı izinler ve gerektiğinde ikinci onay kullanmalıdır. Ortak kullanıcı hesabı, kimin hangi rezervasyonda işlem yaptığını belirsizleştirir. Çok faktörlü kimlik doğrulama, kısa oturum süresi, cihaz ve ağ kısıtları ile periyodik yetki gözden geçirmesi özellikle yönetici ve uzak erişim hesaplarında önemlidir.

Loglar; kullanıcının kimliğini, zamanı, rezervasyon veya folyo referansını, işlem türünü, sağlayıcı sonucunu ve değişen durumu göstermelidir; kart numarası ya da güvenlik kodu loga yazılmamalıdır. Destek firması veya entegrasyon ekibi üretime bağlanacaksa kişisel hesap, zaman sınırlı onay ve oturum kaydı kullanılmalıdır. Ayrılan personelin hesabı hemen kapatılmalı; hizmet sağlayıcı erişimleri sadece sorun çıktığında hatırlanan kalıcı arka kapılar olarak bırakılmamalıdır.

  • Görüntüleme, tahsilat, iade, token kullanımı ve ayar değiştirme izinleri ayrıldı.
  • Riskli finansal işlemlerde ikinci onay ve tutar sınırı uygulandı.
  • Loglarda kart verisi yerine işlem, kullanıcı ve rezervasyon referansı tutuldu.
  • Destek ve entegrasyon erişimleri kişisel, süreli, onaylı ve denetlenebilir hale getirildi.

Monitor online payment pages for script changes

Kart bilgisi otelin web sayfasında giriliyorsa yalnız ödeme formunun görünmesi yeterli güvence değildir. Sayfaya eklenen analiz, sohbet, etiket yöneticisi veya başka bir üçüncü taraf betiği form alanlarına erişebilir. PCI DSS 4.0.1'in e-ticaret gereksinimleri, tüketicinin tarayıcısında çalışan ödeme sayfası betiklerinin yetkilendirilmesi, bütünlüğünün doğrulanması ve envanterinin tutulması ile yetkisiz değişikliklerin algılanmasına odaklanır. Bu gereksinimler 31 Mart 2025'ten sonra zorunlu hale gelmiştir.

Otelin veya ajansın yönettiği ödeme sayfasında her betiğin iş amacı, sahibi, kaynağı ve bütünlük yöntemi kaydedilmelidir. Gereksiz betikler kaldırılmalı; güvenlik politikası, içerik güvenlik başlıkları ve değişiklik izleme sağlayıcının entegrasyon modeline göre kurulmalıdır. Barındırılan dış ödeme sayfası kullanılsa bile otelin bağlantıyı değiştiren kendi web kodu, DNS hesabı, içerik yönetim sistemi ve yönetici hesapları korunmalıdır. Test ortamında yapılan değişikliğin üretime izinsiz taşınmadığı düzenli kontrol edilmelidir.

  • Ödeme sayfasındaki tüm birinci ve üçüncü taraf betikler envantere alındı.
  • Her betik için iş gerekçesi, onay, bütünlük ve değişiklik sahibi kaydedildi.
  • Sayfa içeriği ve güvenlik başlıklarındaki yetkisiz değişiklikler izlenip uyarıya bağlandı.
  • DNS, içerik yönetimi ve etiket yöneticisi hesapları çok faktörlü doğrulamayla korundu.

Coordinate data protection, incident response and regular verification

Kart verisi çoğu akışta kimliği belirli veya belirlenebilir kişiyle ilişkilendirilebilir. KVKK'nın genel ilkeleri; verinin hukuka ve dürüstlük kurallarına uygun, doğru ve güncel, belirli amaçlarla, amaçla bağlantılı ve gerekli süreyle sınırlı işlenmesini ister. Veri sorumlusu ayrıca hukuka aykırı işlemeyi ve erişimi önlemek, veriyi muhafaza etmek için uygun teknik ve idari tedbirleri almakla yükümlüdür. PCI DSS uyumluluğu bu yükümlülükleri destekleyebilir; fakat KVKK kapsamındaki amaç, aydınlatma, saklama ve veri sahibi süreçlerinin yerine geçen tek başına bir belge değildir.

Olay planı kart verisi şüphesini ayrı senaryo olarak ele almalıdır. İlk adımlar ilgili sistemi izole etmek, log ve delilleri korumak, kart numaralarını yeni raporlara kopyalamamak, ödeme sağlayıcısı ve gerekli taraflarla belirlenmiş kanaldan iletişim kurmak ve hukuki bildirim değerlendirmesini yetkili ekiple yapmaktır. Yılda bir form doldurmak yerine erişim, yama, zafiyet, betik envanteri, saklama ve hizmet sağlayıcı kanıtları düzenli kontrol edilmelidir. Başarılı test; kart numarasının bulunmaması gereken alana yazılamadığını ve ödeme durumunun yanlış bildirimle değişmediğini de göstermelidir.

  • PCI DSS kontrolleri KVKK amaç, erişim, saklama ve veri güvenliği süreçleriyle eşleştirildi.
  • Kart verisi şüphesi için izolasyon, delil koruma, iletişim ve bildirim değerlendirme akışı yazıldı.
  • Tedarikçi kanıtları, yetkiler, yamalar, betikler ve saklama periyodik takvime bağlandı.
  • Olumsuz senaryolar güvenli test verisiyle uçtan uca tekrarlandı ve sonuçlar loglandı.
Short answers

FAQ

May a hotel display the last four digits of a card number?

İş ihtiyacı varsa maskelenmiş görünümde sınırlı hane gösterilebilir; ancak hangi hanenin görüntüleneceği ve hangi rolün göreceği politika ile belirlenmelidir. Ekran maskelemesi, veri tabanında tam numara saklamayı güvenli hale getirmez.

May a hotel store CVV/CVC for a no-show charge?

Hayır. PCI SSC, kart doğrulama kodunu hassas doğrulama verisi sayar ve yetkilendirme sonrasında şifrelenmiş olsa bile saklanmasına izin vermez. Sonraki tahsilat uygun sağlayıcı tokenı ve sözleşmeye uygun işlem akışıyla yapılmalıdır.

Does using a PCI DSS-compliant payment provider remove the hotel from scope entirely?

Her zaman değil. Kapsam entegrasyon modeline, otelin kart verisine temas edip etmediğine ve ödeme ortamının güvenliğini etkileyen sistemlere göre belirlenir. Sağlayıcının uyumluluğu doğrulanmalı, otelin kendi web, erişim, süreç ve tedarikçi sorumlulukları ayrıca değerlendirilmelidir.

Sources and updates

Operasyon önerileri tesisin kendi koşullarına uyarlanmalıdır. PMS ve kanal işleyişiyle ilgili bilgiler 28 Eylül 2026 tarihinde aşağıdaki resmi belgelerden kontrol edilmiştir.