Güven Damgası Nedir, Nasıl Alınır?

Güven Damgası, Türkiye'deki e-ticaret sitelerinin belirli asgari şartları sağladığını gösteren resmî bir işarettir ve mağaza sahiplerinin çoğu bunu "bir rozet alıp footer'a koymak" sanır. Gerçekte olan şey bir denetimdir: başvurduğunuzda siteniz teknik ve hukuki bir kontrol listesine göre incelenir, eksik varsa başvuru reddedilir. Reddedilen site sahiplerinin en çok şikâyet ettiği nokta da tam burada başlıyor — "hangi şartı sağlamadığımı bulamıyorum". Türkçe kaynakların neredeyse tamamı damganın ne olduğunu ve ücret bandını anlatıyor, teknik şart tarafını ise boş bırakıyor: hangi SSL tipinin yeterli olduğu, ödeme sayfasında neye bakıldığı, iletişim bilgilerinin hangi biçimde bulunması gerektiği hiçbir yerde yazmıyor.

Bu yazıda Güven Damgası'nı bir başvuru sahibi gözünden, uygulanabilir bir kontrol listesi olarak ele alıyorum. Damganın ne olduğunu ve kimin alabileceğini kısaca geçip, asıl ağırlığı üç teknik başlığa veriyorum: SSL/HTTPS yapılandırması (ve DV–OV–EV tartışmasının gerçek cevabı), ödeme sayfasının nasıl kurulmuş olması gerektiği, iletişim ve destek kanallarının hangi biçimde bulunması gerektiği. Sonunda da başvurudan önce kendi sitenizi denetleyebileceğiniz komutları ve en sık görülen ret nedenlerini tablo hâlinde veriyorum.

Güven Damgası Nedir ve Ne İşe Yarar#

Güven Damgası, e-ticaret sitelerinin güvenlik, hizmet kalitesi ve tüketici hakları bakımından asgari standartları sağladığını gösteren, Ticaret Bakanlığı mevzuatına dayanan ve TOBB bünyesindeki yetkilendirilmiş kuruluş tarafından verilen bir işarettir. Sitenizde gösterdiğiniz damga tıklanabilirdir; ziyaretçi tıkladığında damganın gerçekten o siteye ait olduğunu doğrulama sayfasından görür.

Damganın işlevi ikili. Tüketici tarafında, karşısındaki satıcının kimliği doğrulanmış ve belirli şartları sağlamış olduğunu gösterir — özellikle marka bilinirliği düşük mağazalar için dönüşüm oranına gözle görülür katkısı olur. İşletme tarafında ise bir disiplin aracıdır: damga şartları, aslında bir e-ticaret sitesinin zaten sağlaması gereken asgari yasal ve teknik gereklilikler listesidir.

Damga zorunlu değildir. Zorunlu olan ETBİS kaydıdır; damga isteğe bağlıdır. Ama ETBİS kaydı damganın ön koşuludur, yani kayıt olmadan başvuru yapamazsınız. ETBİS tarafını hiç yapmadıysanız önce ETBİS kaydı nasıl yapılır yazısındaki adımları tamamlayın.

Güven Damgası Kimler Alabilir: Ön Koşullar#

Başvuru yapabilmek için sağlanması gereken temel koşullar şunlar:

• ETBİS'e kayıtlı olmak. Başvuru sırasında kayıt numarası üzerinden eşleştirme yapılır.
• Alan adının başvuran işletme adına tescilli olması. Alan adı bir çalışan, ajans ya da geliştirici adına kayıtlıysa başvuru bu noktada takılır.
• Faaliyetin fiilen yürütülüyor olması. "Yakında" sayfası yayında olan, ürünleri stokta görünmeyen veya sipariş alınamayan bir site denetimden geçemez.
• Şirket bilgilerinin güncel olması. Ticaret sicil kaydı, vergi bilgileri ve adres bilgisinin sistemdekiyle sitede yazanın birebir tutması gerekir.
• Yasal metinlerin yayında olması. Mesafeli satış sözleşmesi, ön bilgilendirme formu, teslimat–iade koşulları, çerez politikası ve KVKK aydınlatma metni.

Bu listedeki her madde tek başına ret sebebidir. En sık gördüğüm tablo, sitedeki adres bilgisinin eski ofis adresi olarak kalması ve sicil kaydıyla uyuşmaması; küçük görünen bu tutarsızlık başvuruyu doğrudan geri çevirir.

Teknik Şart 1: SSL ve HTTPS Yapılandırması#

En çok sorulan sorunun net cevabı: Güven Damgası için EV (Extended Validation) sertifika zorunlu değildir; güvenilir bir sertifika otoritesinden alınmış, alan adıyla eşleşen ve geçerli bir sertifika yeterlidir. Yani ücretsiz bir DV sertifika da şartı karşılar. Denetimde bakılan şey sertifikanın tipi değil, bağlantının fiilen ve eksiksiz şifreli olmasıdır.

Sertifika tipleri arasındaki farkı ve hangisinin ne zaman anlamlı olduğunu DV, OV ve EV SSL farkı yazısında ayrıntılı anlattım. Damga açısından kritik olan dört nokta şu:

Bu dördü içinde en sinsi olanı eksik ara sertifikadır. Masaüstü tarayıcılar eksik zinciri çoğu zaman kendi önbelleklerinden tamamlar, siz sitenizi açar ve "yeşil kilit var" dersiniz; ama mobil cihazda ya da denetim aracında uyarı çıkar. Zinciri şu komutla kontrol edin:

# Sunulan sertifika sayısı: 1 ise zincir eksiktir
echo | openssl s_client -connect alanadiniz.com:443 -servername alanadiniz.com -showcerts 2>/dev/null \
  | grep -c "BEGIN CERTIFICATE"

# Sertifikanın kime ait olduğu ve geçerlilik tarihleri
echo | openssl s_client -connect alanadiniz.com:443 -servername alanadiniz.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

İkinci sinsi kalem karışık içeriktir (mixed content). Sayfa HTTPS ile açılıyor ama içindeki bir görsel veya betik HTTP ile çağrılıyorsa, tarayıcı kilidi kırık gösterir ve denetimde bu "şifreli olmayan içerik" olarak not edilir. Tespiti kolaydır:

curl -s https://alanadiniz.com/ | grep -oE '(src|href)="http://[^"]+' | sort -u

Çıktı boş değilse, dönen adresleri şablonunuzda ya da veritabanında https:// olacak şekilde düzeltin. WordPress kullanıyorsanız bu düzeltmeyi eklentiyle geçici olarak maskelemek yerine veritabanında kalıcı yapın; eklenti devre dışı kalınca sorun geri gelir.

Üçüncü kontrol, HTTP'den HTTPS'e yönlendirmenin gerçekten çalışması:

curl -sI http://alanadiniz.com/ | head -n 3
# HTTP/1.1 301 Moved Permanently
# Location: https://alanadiniz.com/

200 görüyorsanız site hem şifresiz hem şifreli sunuluyor demektir; bu, denetimde de SEO'da da sorundur. Nginx tarafında doğru biçim şu:

server {
    listen 80;
    server_name alanadiniz.com www.alanadiniz.com;
    return 301 https://alanadiniz.com$request_uri;
}

server {
    listen 443 ssl http2;
    server_name alanadiniz.com;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;

    add_header Strict-Transport-Security "max-age=31536000" always;
}

Yapılandırmanın dışarıdan nasıl göründüğünü ölçmek için SSL Labs testi yazısındaki yöntemi kullanabilirsiniz; başvurudan önce bu testte zincir ve protokol uyarısı görmemeniz gerekir.

Teknik Şart 2: Ödeme Sayfası Denetiminde Nelere Bakılır#

Ödeme adımı, denetimin en dikkatli bakılan bölümüdür. Kontrol edilen başlıklar şunlar:

1. Ödeme sayfası şifreli olmalı. Sepetten ödeme adımına geçişte HTTPS kesintiye uğramamalı, ödeme formu HTTP üzerinden gelen hiçbir kaynak barındırmamalı.
2. Kart bilgileri sizin sunucunuzda tutulmamalı. Kart verisini kendi veritabanınıza yazmak yalnızca damga açısından değil, kart şemalarının kuralları açısından da sorundur. Doğru mimari, ödeme kuruluşunun kendi sayfasına yönlendirmek ya da onun sağladığı barındırılan formu kullanmaktır.
3. 3D Secure desteklenmeli. Ödeme akışında kart doğrulama adımının bulunması beklenir.
4. Kabul edilen ödeme yöntemleri sitede açıkça belirtilmeli. Ziyaretçi, ödeme adımına gelmeden hangi yöntemlerle ödeyebileceğini görebilmeli.
5. Fiyat ve toplam tutar net olmalı. Vergiler dahil toplam tutar, kargo ücreti ve varsa ek ücretler ödeme onayından önce ayrı satırlar hâlinde gösterilmeli. "Kargo ücreti sonra bildirilecektir" ifadesi ret sebebidir.

Bir de sık atlanan altıncı madde var: ödeme sayfasında oturum güvenliği. Ödeme adımındaki çerezlerin Secure ve HttpOnly bayraklarıyla gönderildiğini kontrol edin:

curl -sI https://alanadiniz.com/odeme | grep -i set-cookie
# set-cookie: SESSID=...; path=/; secure; HttpOnly; SameSite=Lax

secure bayrağı yoksa oturum çerezi şifresiz bir istekte de gönderilebilir hâle gelir. Bu, denetimden bağımsız olarak da düzeltilmesi gereken bir açıktır.

Teknik Şart 3: İletişim Bilgileri ve Erişilebilirlik#

Damga şartlarının en çok göz ardı edilen bölümü iletişimdir; oysa ret nedenlerinin önemli bir kısmı buradan çıkar. Sitede bulunması beklenenler:

Buradaki üç pratik uyarı, denetimlerde en çok karşıma çıkanlar:

• Ücretsiz e-posta servisi kullanmayın. [email protected] biçimindeki bir adres, kurumsal kimlik doğrulaması açısından zayıf değerlendirilir. Kendi alan adınız üzerinden bir posta kutusu açmak hem teknik olarak basittir hem de bu şartı doğrudan karşılar.
• Telefon numarası gerçekten çalışmalı. Denetim sırasında aranmadığını varsaymayın; ulaşılamayan numara "yanıltıcı bilgi" olarak değerlendirilebilir.
• İletişim bilgileri sadece iletişim formunda olmasın. Form tek başına yeterli değildir; adres, telefon ve e-postanın metin olarak yazılı bulunması beklenir. Bilgileri görsele gömmek de kabul edilmez, çünkü metin olarak okunamaz.

Ayrıca müşteri taleplerine makul bir süre içinde dönüş yapılması beklenir. Sitede "sorularınıza kaç iş günü içinde döneceğinizi" yazmak ve buna uymak, hem şartı karşılar hem şikâyet oranını düşürür.

Yasal Metinler ve Sipariş Akışı Kontrolü#

Denetimde metinlerin varlığına değil, sipariş akışında doğru anda gösterilmesine bakılır. En sık yapılan hata, mesafeli satış sözleşmesini yalnızca footer'a bir bağlantı olarak koyup, ödeme adımında onay kutusu göstermemektir.

Doğru akış şu sırayla ilerler:

1. Ürün sayfasında fiyat, KDV durumu ve teslimat süresi görünür.
2. Sepette toplam tutar, kargo ücreti ve varsa ek ücretler ayrı satırlarda gösterilir.
3. Ödeme adımında ön bilgilendirme formu ve mesafeli satış sözleşmesi ayrı ayrı okunabilir biçimde sunulur ve onay kutusuyla teyit alınır.
4. Sipariş onayından sonra müşteriye e-posta ile teyit gönderilir; bu e-postada sipariş özeti ve cayma hakkı bilgisi bulunur.
5. İade ve cayma süreci, ayrı bir sayfada adım adım tarif edilir.

Sözleşmenin içermesi gereken maddeler için mesafeli satış sözleşmesi nedir yazısındaki listeyi kontrol listesi gibi kullanabilirsiniz. Metinleri başka bir siteden kopyalamak, en hızlı ret alma yöntemidir: kopyalanan metinlerde çoğu zaman eski firmanın unvanı, adresi veya teslimat süresi kalır ve denetimde bu tutarsızlık hemen görülür.

Başvuru Adımları ve Ücretlendirme Mantığı#

Başvuru süreci şu sırayla işler:

1. ETBİS kaydınızı ve alan adı tescilini doğrulayın. Bu ikisi tutmuyorsa başvuruya hiç başlamayın.
2. Sitenizi bu yazıdaki üç teknik başlığa göre denetleyin. Eksikleri başvurudan önce kapatın; başvuru sırasında düzeltmek süreci uzatır.
3. Yetkilendirilmiş kuruluşun başvuru sistemine kaydolun. Şirket bilgileri, yetkili kişi ve iletişim bilgileri girilir.
4. Belgeleri yükleyin. Genellikle imza sirküleri/yetki belgesi, faaliyet belgesi ve vergi levhası istenir.
5. Beyan ve taahhütleri onaylayın. Şartlara uyacağınıza dair taahhüt verirsiniz.
6. Ücreti ödeyin. Ücret yıllıktır ve sitenin işlem hacmi bandına göre kademelidir; hacim büyüdükçe üst banda geçilir. Rakam vermiyorum, çünkü tarife dönemsel olarak güncellenir — güncel tutarı her zaman yetkilendirilmiş kuruluşun kendi duyurusundan doğrulayın.
7. Denetim sonucunu bekleyin. Eksik bildirilirse süre verilir; düzeltip yeniden gönderirsiniz.
8. Damgayı yerleştirin. Onaydan sonra size verilen kodu sitenin footer alanına, tıklanabilir ve doğrulama sayfasına yönlenen biçimde ekleyin.

Ücret bandının hacme göre değiştiğini bütçelerken unutmayın: cironuz büyüdüğü yıl yenileme ücreti de değişir. Bu kalemin diğer tekrarlayan e-ticaret giderleriyle birlikte nasıl planlanacağını e-ticaret sitesi maliyeti yazısındaki tabloda ele aldım.

Başvuru Neden Reddedilir#

Ret bildirimleri genellikle kısa ve genel ifadelerle gelir, bu yüzden site sahibi hangi maddeye takıldığını çözemez. Aşağıdaki tablo, pratikte en sık karşılaşılan ret nedenlerini ve karşılığında yapılması gerekeni gösteriyor.

Son satır özellikle önemli: kopyalanmış metin hem ret sebebidir hem de gerçek bir uyuşmazlıkta sizi savunmasız bırakır.

Başvuru Öncesi Kendi Kendinize Denetim#

Başvurmadan önce yarım saatinizi ayırıp aşağıdaki komutları çalıştırın. Bunlar denetimde bakılan şeylerin sunucu tarafındaki karşılığıdır.

# 1) HTTP -> HTTPS yonlendirmesi calisiyor mu
curl -sI http://alanadiniz.com/ | head -n 3

# 2) Sertifika gecerli ve zincir tam mi
echo | openssl s_client -connect alanadiniz.com:443 -servername alanadiniz.com -showcerts 2>/dev/null \
  | grep -c "BEGIN CERTIFICATE"

# 3) Ana sayfada karisik icerik var mi
curl -s https://alanadiniz.com/ | grep -oE '(src|href)="http://[^"]+' | sort -u

# 4) Guvenlik basliklari gonderiliyor mu
curl -sI https://alanadiniz.com/ | grep -iE 'strict-transport|x-frame-options|x-content-type'

# 5) Yasal metin sayfalari gercekten 200 donuyor mu
for yol in mesafeli-satis-sozlesmesi on-bilgilendirme-formu iade-kosullari cerez-politikasi kvkk; do
  printf "%-32s %s\n" "$yol" "$(curl -s -o /dev/null -w '%{http_code}' https://alanadiniz.com/$yol)"
done

Beşinci komut, en çok işe yarayanıdır: menüden kaldırılmış ama hâlâ bağlantısı duran bir sayfa 404 dönüyorsa denetimde "metin yok" sayılır ve siz bunu sitede gezerken fark etmezsiniz.

Bir de gözle bakılacak üç şey var: mobil görünümde footer'daki damga ve yasal metin bağlantıları çerez bandının altında kalıyor mu, ödeme adımında onay kutuları görünüyor mu, iletişim sayfasındaki telefon gerçekten aranıyor mu.

Sıkça Sorulan Sorular#

Güven Damgası için EV SSL zorunlu mu#

Hayır, Güven Damgası için EV sertifika zorunlu değildir; güvenilir bir otoriteden alınmış, alan adıyla eşleşen ve süresi geçerli bir sertifika şartı karşılar. Ücretsiz bir DV sertifika da bu tanıma girer. Denetimde bakılan şey sertifikanın doğrulama seviyesi değil, bağlantının kesintisiz şifreli olması, zincirin tam kurulmuş olması ve sayfada şifresiz kaynak bulunmamasıdır. EV sertifika ticari bir tercihtir, damga şartı değildir.

Güven Damgası zorunlu mu#

Hayır, Güven Damgası isteğe bağlıdır; zorunlu olan ETBİS kaydıdır. Damgayı almadan e-ticaret faaliyeti yürütebilirsiniz ve bunun bir yaptırımı yoktur. Buna karşılık damga, marka bilinirliği düşük mağazalarda tüketici güvenini artırdığı için dönüşüme katkı sağlar. Damga başvurusunun ön koşulu ETBİS kaydı olduğu için sıra her zaman önce kayıt, sonra damgadır.

Güven Damgası ücreti neye göre değişiyor#

Ücret, sitenin işlem hacmi bandına göre kademeli olarak belirlenir ve yıllık tahsil edilir. Hacminiz bir üst banda geçtiğinde yenileme ücreti de değişir, bu yüzden bunu sabit bir gider gibi bütçelemek yanıltıcı olur. Tarife dönemsel olarak güncellendiği için güncel tutarı yetkilendirilmiş kuruluşun kendi duyurusundan doğrulamak gerekir. Bütçe planlarken damgayı yıllık tekrarlayan giderler listesine yazın.

Başvurum reddedildi, neden olduğunu nasıl bulurum#

Ret bildirimi genellikle genel ifadelerle geldiği için, sebebi kendi denetiminizle bulmanız gerekir. Sırayla şuna bakın: alan adı tescili işletme adına mı, sitedeki adres sicil adresiyle aynı mı, sertifika zinciri tam mı, sayfada karışık içerik var mı, ödeme adımında sözleşme onay kutusu var mı, iletişim bilgileri metin olarak yazılı mı. Bu altı maddeden en az biri, ret vakalarının büyük çoğunluğunu açıklar. Düzeltme sonrası yeniden başvurabilirsiniz.

Damgayı sitenin neresine koymam gerekir#

Damga, sitenin tüm sayfalarından erişilebilir olacak biçimde genellikle alt bilgi (footer) alanına yerleştirilir. Sadece görsel olarak durması yeterli değildir; tıklandığında doğrulama sayfasına gitmesi gerekir. Görseli kendi sunucunuzda barındırın ve width ile height özniteliklerini yazın, aksi hâlde sayfa yüklenirken düzen kayması oluşur. Mobil görünümde çerez bandı veya sohbet balonunun damgayı kapatmadığını mutlaka kontrol edin.

Kart bilgilerini kendi sunucumda saklayabilir miyim#

Hayır, kart bilgilerini kendi sunucunuzda saklamamalısınız; doğru mimari, ödeme kuruluşunun barındırdığı forma veya yönlendirmeye dayanır. Kart verisini kendi veritabanınıza yazmak hem denetimde sorun çıkarır hem de kart şemalarının kurallarına aykırıdır. Bir veri ihlali durumunda sorumluluğun tamamı size kalır. Ödeme akışını kuracak geliştiriciye bu kuralı en baştan söyleyin; sonradan mimari değiştirmek pahalıdır.

Ortak barındırma (paylaşımlı hosting) üzerinde damga alınabilir mi#

Evet, paylaşımlı hosting üzerinde çalışan bir site de Güven Damgası alabilir; şartlar sunucu tipine değil sitenin kendisine bakar. Önemli olan HTTPS'in düzgün yapılandırılmış olması, sitenin denetim döneminde kararlı biçimde erişilebilir kalması ve yanıt sürelerinin makul olmasıdır. Paketiniz kaynak limitine takılıp sık sık hata veriyorsa bu erişilebilirlik sorunu olarak değerlendirilebilir. Kampanya dönemlerinde limit aşımı yaşıyorsanız başvurudan önce paket yükseltmesini değerlendirin.

Kapanış#

Güven Damgası, alınıp footer'a yapıştırılan bir rozet değil, geçilmesi gereken bir denetimdir; ve o denetimin maddeleri aslında bir e-ticaret sitesinin zaten sağlaması gereken asgari standartlardır. Sertifika zincirinin tam kurulmuş olması, sayfada şifresiz kaynak kalmaması, ödeme adımında toplam tutarın ve sözleşme onayının net biçimde gösterilmesi, iletişim bilgilerinin metin olarak ve sicil kayıtlarıyla tutarlı biçimde yayınlanması — bunların hepsi damgadan bağımsız olarak da doğru olan şeylerdir. Başvurudan önce yazıdaki komutları çalıştırıp altı ret nedenini tek tek kapatırsanız, süreç tek turda kapanır.

Sertifika tarafında zincir eksikliği ya da yenileme takibi sizi uğraştırıyorsa, kurulumu ve otomatik yenilemeyi üstlenen bir SSL sertifikası hizmeti bu kalemi tamamen gündeminizden çıkarır. Denetim döneminde sitenin kararlı biçimde ayakta kalması gerektiği için, kaynak limitine takılmayacak bir e-ticaret hosting paketi başvuru öncesinde yapılacak en mantıklı yatırımdır. Ödeme sayfasını hedef alan otomatik saldırılar erişilebilirliği doğrudan etkilediğinden, trafiği filtreleyen bir web uygulama güvenlik duvarı çözümünü de aynı dönemde devreye almanız işinizi kolaylaştırır.