Mevzuat ve Kılavuzlar


        VERGİ USUL KANUNU GENEL TEBLİĞİ

(Sıra No: 507)

Giriş

MADDE 1 – (1) Günümüzde bilgi-iletişim ve finansal teknoloji alanındaki hızlı gelişmeler ile elektronik belge uygulamalarında kat edilen önemli mesafeler, mükelleflerimizin iş süreçlerini, ödeme ve tahsilat süreçlerini, müşterilerine düzenlemekte oldukları belgelerin oluşturulması, iletilmesi ve muhafazasında sağlamakta olduğu verimlilik, maliyet avantajı, işlem kolaylığı ve etkin analiz ve denetim kolaylığı nedeniyle, yeni uygulamaların mükelleflerimizin kullanımına sunulmasının önemini artırmaktadır.

Bu kapsamda, bankalar, elektronik para kuruluşları, ödeme kuruluşlarınca sunulan yeni teknolojik gelişmelere uygun, kullanımı kolay ve mobilitesi yüksek ve fiziksel/klasik tahsilat araçları (fiziki POS cihazları) gerektirmeyen daha düşük maliyetli çözümler uygulamada ortaya çıkmaya başlamaktadır. Bu gelişime uygun olarak vergi mevzuatı çerçevesinde mal ve hizmetlerin satışına yönelik işlemlerle buna yönelik tahsilatların güvenliğinin ve belge düzeninin sağlanması hususu da son derece önem arz etmektedir.

Bu Tebliğ ile yukarıda belirtilen yeni teknolojik gelişmelere uygun ve “Güvenli Mobil Ödeme ve Elektronik Belge Yönetim Sistemi” olarak tanımlanan sistem çerçevesinde, mal ve hizmet satışlarına ait bedellerin tahsilatı ile mali belgelerin elektronik ortamda oluşturulmasına ilişkin satış, tahsilat ve elektronik belge uygulamalarının Hazine ve Maliye Bakanlığınca yetkilendirilen kurum ve kuruluşlar tarafından mükelleflerin kullanımına sunumu ve mükellefler tarafından kullanımı sırasında uyulması gereken usul ve esaslara yer verilmiştir.

Dayanak

MADDE 2 – (1) 213 sayılı Vergi Usul Kanununun mükerrer 242 nci maddesinin ikinci fıkrasında Hazine ve Maliye Bakanlığının, “…elektronik defter, belge ve kayıtların oluşturulması, kaydedilmesi, iletilmesi, muhafaza ve ibrazı ile defter ve belgelerin elektronik ortamda tutulması ve düzenlenmesi uygulamasına ilişkin usul ve esasları belirlemeye, elektronik ortamda tutulmasına ve düzenlenmesine izin verilen defter ve belgelerde yer alması gereken bilgileri internet de dahil olmak üzere her türlü elektronik bilgi iletişim araç ve ortamında Maliye Bakanlığına veya Maliye Bakanlığının gözetim ve denetimine tabi olup, kuruluşu, faaliyetleri, çalışma ve denetim esasları Bakanlar Kurulunca çıkarılacak bir yönetmelikle belirlenecek olan özel hukuk tüzel kişiliğini haiz bir şirkete aktarma zorunluluğu getirmeye, bilgi aktarımında uyulacak format ve standartlar ile uygulamaya ilişkin usul ve esasları tespit etmeye, bu Kanun kapsamına giren işlemlerde elektronik imza kullanım usul ve esaslarını düzenlemeye ve denetlemeye…”

yetkili olduğu hüküm altına alınmıştır.

(2) 213 sayılı Kanunun mükerrer 257 nci maddesinin birinci fıkrasının (1) numaralı bendinde  “Mükellef ve meslek grupları itibariyle muhasebe usul ve esaslarını tespit etmeye, bu Kanuna göre tutulmakta olan defter ve belgeler ile bunlara ilaveten tutulmasını veya düzenlenmesini uygun gördüğü defter ve belgelerin mahiyet, şekil ve ihtiva etmesi zorunlu bilgileri belirlemeye, bunlarda değişiklik yapmaya; bedeli karşılığında basıp dağıtmaya veya üçüncü kişilere bastırıp dağıtmaya veya dağıttırmaya, bunların kayıtlarını tutturmaya, bu defter ve belgelere tasdik, muhafaza ve ibraz zorunluluğu getirmeye veya kaldırmaya, bu Kanuna göre tutulacak defter ve düzenlenecek belgelerin tutulması ve düzenlenmesi zorunluluğunu kaldırmaya,”

(3) numaralı bendinde; “Tutulması ve düzenlenmesi zorunlu defter, kayıt ve belgelerin mikro film, mikro fiş veya elektronik bilgi ve kayıt araçlarıyla yapılması veya bu kayıt ortamlarında saklanması hususunda izin vermeye veya zorunluluk getirmeye, bu şekilde tutulacak defter ve kayıtların kopyalarının Maliye Bakanlığında veya muhafaza etmekle görevlendireceği kurumlarda saklanması zorunluluğu getirmeye, bu konuda uygulama usul ve esaslarını belirlemeye,”

(4) numaralı bendinde; “Bu Kanunun 149 uncu maddesine göre devamlı bilgi vermek zorunda olanlardan istenilen bilgiler ile vergi beyannameleri ve bildirimlerin, şifre, elektronik imza veya diğer güvenlik araçları konulmak suretiyle internet de dahil olmak üzere her türlü elektronik bilgi iletişim araç ve ortamında verilmesi, beyanname ve bildirimlerin yetki verilmiş gerçek veya tüzel kişiler aracı kılınarak gönderilmesi hususlarında izin vermeye veya zorunluluk getirmeye, beyanname, bildirim ve bilgilerin aktarımında uyulacak format ve standartlar ile uygulamaya ilişkin usul ve esasları tespit etmeye, bu zorunluluğu beyanname, bildirim veya bilgi çeşitleri, mükellef grupları ve faaliyet konuları itibarıyla ayrı ayrı uygulatmaya, kanuni süresinden sonra kendiliğinden veya pişmanlık talepli olarak verilen beyannameler üzerine düzenlenen tahakkuk fişi ve/veya ihbarnameleri mükellefe, vergi sorumlusuna veya bunların elektronik ortamda beyanname gönderme yetkisi verdiği gerçek veya tüzel kişiye elektronik ortamda tebliğ etmeye ve buna ilişkin usûl ve esasları belirlemeye,”

(6) numaralı bendinde; “Vergi güvenliğini sağlamak amacıyla niteliklerini belirleyip onayladığı elektrikli, elektronik, manyetik ve benzeri cihazlar ve sistemleri kullandırmaya,”

Hazine ve Maliye Bakanlığının yetkili olduğuna ilişkin hükümlere yer verilmiştir.

(3) Ayrıca 3100 sayılı Katma Değer Vergisi Mükelleflerinin Ödeme Kaydedici Cihazları Kullanmaları Mecburiyeti Hakkında Kanunun “Yetki” başlıklı 10 uncu maddesinin birinci fıkrasının (a) bendine göre ödeme kaydedici cihazların kullanılmalarıyla ilgili olarak, bu Kanunla belli edilen hususlar dışında uyulması gereken usul ve esasları belirlemeye ve bunlarda değişiklik yapmaya Bakanlığımız yetkili kılınmıştır.

Tanımlar ve kısaltmalar

MADDE 3 – (1) Bu Tebliğde geçen;

a) Bakanlık: Hazine ve Maliye Bakanlığını,

b) Başkanlık: Gelir İdaresi Başkanlığını,

c) Elektronik belge (e-Belge): Usul ve esasları Vergi Usul Kanunu genel tebliğleri ile belirlenen elektronik belgeleri,

ç) Finans kuruluşu: 19/10/2005 tarihli ve 5411 sayılı Bankacılık Kanununa göre faaliyet gösteren Bankalar ile 20/6/2013 tarihli ve 6493 sayılı Ödeme ve Menkul Kıymet Mutabakat Sistemleri, Ödeme Hizmetleri ve Elektronik Para Kuruluşları Hakkında Kanuna göre faaliyet gösteren elektronik para kuruluşları ve ödeme kuruluşlarından Hazine ve Maliye Bakanlığınca yetkilendirilen ve bu Tebliğde belirtilen sistemin işletilmesi nedeniyle Bakanlık, Başkanlık ve sistem kapsamındaki hizmetlerden yararlananlara karşı asli sorumlu olan kuruluşları,

d) Güvenli Mobil Ödeme ve Elektronik Belge Yönetim Sistemi (Sistem): Finans kuruluşları ya da ödeme kaydedici cihaz üreticileri ile birlikte özel entegratör kuruluşlar tarafından bu Tebliğde belirtilen usul ve esaslara uygun gerçekleştirilen satış, ödeme/tahsilat işlemleri ile bu işlemlere ilişkin mali belgelerin elektronik belge olarak oluşturulması, iletilmesi, muhafaza ve ibraz edilmesi süreçlerine ilişkin olarak Bakanlıkça izin verilen sistemi,

e) Ödeme aracı: Bankalar, elektronik para kuruluşları ve ödeme kuruluşlarınca ödeme işlemlerinin yapılmasına olanak sağlayan fiziki/sanal kartları ya da bu kuruluşların hesaplarından ödemeyi gerçekleştirebilecek bilgileri barındıran ve fiziki niteliği bulunmayan yazılımsal uygulamaları (QR, NFC vb.),

f) Ödeme kabul eden araç: Ödeme aracını kabul ederek ödemeyi gerçekleştirebilen fiziki donanım veya yazılımsal uygulamaları,

g) Ödeme kaydedici cihaz: 3100 sayılı Kanunun 2 nci maddesinde ve 213 sayılı Kanunun mükerrer 257 nci maddesi hükümleri uyarınca yayımlanan 426 Sıra No.lu Vergi Usul Kanunu Genel Tebliğinde belirtilen teknik dokümanlardaki nitelikleri haiz cihazları,

ğ) Ödeme kaydedici cihaz üreticisi: 426 Sıra No.lu Vergi Usul Kanunu Genel Tebliğinde belirtilen yeni nesil ödeme kaydedici cihazların üretim ve ithalatına ilişkin Bakanlıktan onay alan ve bu Tebliğde belirtilen sistemin işletilmesi nedeniyle Bakanlık, Başkanlık ve sistem kapsamındaki hizmetlerden yararlananlara karşı asli sorumlu olan kuruluşları,

h) Özel entegratör: Elektronik belgelerin (e-Fatura, e-Arşiv Fatura, e-Serbest Meslek Makbuzu vb. diğer elektronik belgeler) düzenlenmesi, iletilmesi, alınması ve saklama hizmetleri ile ilgili mükelleflere hizmet verme konusunda Başkanlıktan alınmış özel entegratörlük izni bulunan kuruluşları, 

ifade eder.

Güvenli Mobil Ödeme ve Elektronik Belge Yönetim Sistemi yoluyla elektronik belge düzenlenebilmesine ilişkin usul ve esaslar

MADDE 4 – (1) Ödeme kabul eden araçlar, finans kuruluşu ya da ödeme kaydedici cihaz üreticisi tarafından güvenliği sağlanmış ve bu Tebliğ kapsamındaki satış-tahsilat-belge oluşturma süreçlerine ilişkin işlemlerin doğru bir şekilde yapılmasına ait sorumluluğu bunlar tarafından kabul edilmiş nitelikte olmalıdır. Ödeme kabul eden araçların bu Tebliğde belirtilen elektronik belgelerin oluşturulması sürecinde belgelerde yer alması gereken zorunlu bilgileri temin edecek özellikte olması zorunludur.

(2) Ödeme kabul eden araçlar sadece bu Tebliğde tanımlanan finans kuruluşları ya da ödeme kaydedici cihaz üreticileri tarafından bu Tebliğde belirtilen sistemden yararlanmak isteyen mükelleflere verilebilir. 

(3) Ödeme kabul eden araçların kullanılması suretiyle gerçekleştirilen mal ve hizmet satışlarına ait ödeme işlemlerinin,  özel entegratör kuruluşları aracılığıyla,  belge düzenleyecek mükellefin mükellefiyet türüne uygun şekilde, anlık olarak, mevzuatta öngörülen elektronik belgelere dönüştürülmesi ve düzenlenen bu belgenin elektronik (e-posta, sms, bankacılık uygulamaları vb.)  ve/veya kağıt ortamda muhatabına iletilmesi zorunludur.

(4) Uygulama kapsamında mükelleflere hizmet vermek isteyen finans kuruluşlarının e-belge düzenlenmesi konusunda işbirliği yapacağı özel entegratör ile birlikte, ödeme kaydedici cihaz üreticilerinin ise işbirliği yapacağı banka, elektronik para kuruluşu ya da ödeme kuruluşu ve özel entegratör ile birlikte gerekli teknik, yazılım ve altyapı hazırlıklarını yaparak Başkanlığa yazılı olarak başvurması gerekmektedir. Başkanlık, yapılan başvuruların değerlendirilmesi sürecinde sistemin unsurlarına ilişkin her türlü bilgi, belge veya ilgili diğer kamu kurum veya kuruluşların uygunluğunu finans kuruluşları, ödeme kaydedici cihaz üreticileri ile özel entegratör kuruluşlardan talep edebilir. Başkanlık tarafından yapılan değerlendirme süreçlerini başarılı şekilde tamamlayan ve Bakanlık tarafından da izin verilen finans kuruluşları ile ödeme kaydedici cihaz üreticileri kendilerine izin yazısında bildirilen tarihten geçerli olmak üzere Tebliğle belirtilen sistem kapsamında ödeme/tahsilat ve elektronik belgelerin düzenlemesi hususunda işbirliği yapacakları özel entgeratörlerle birlikte mükelleflere hizmet verebilirler. İzin verilen finans kuruluşları ile ödeme kaydedici cihaz üreticilerine ve özel entegratörlere ilişkin bilgiler www.efatura.gov.tr internet adresinde yayınlanır.

(5) Bakanlık veya Başkanlık,  ödeme kabul eden araçlar, bu araçları sunan kurum ve kuruluşlar ile sisteme ilişkin başvuru, test değerlendirme, izin, onay, güvenlik, denetim ve sorumluluğa ilişkin usul ve esaslar ile ilgili olarak uyulması gerekli kural ve standartları belirlemeye ve bunları Teknik Kılavuzlarla www.efatura.gov.tr internet adresinde yayınlamaya veya yazılı olarak finans kuruluşları ya da ödeme kaydedici cihaz üreticileri ile özel entegratörlere bildirmeye, izin verilen sistem unsurlarını denetlemeye ya da denetlettirmeye, sistem kapsamında sunulacak hizmetler nedeniyle mükelleflerden ya da özel entegratörlerin finans kuruluşları ile ödeme kaydedici cihaz üreticilerinden talep edebileceği komisyon, ücret vb. bedellerin azami tutarını belirlemeye ve bu hususta finans kuruluşları, ödeme kaydedici cihaz üreticileri ile özel entegratörlerden yazılı taahhütname almaya yetkilidir.

Sistemden yararlanabilecekler ve belge düzeni

MADDE 5 – (1) Bu Tebliğde belirtilen finans kuruluşları ya da ödeme kaydedici cihaz üreticileri tarafından sunulan Sistemden aşağıdaki belirtilen mükellef grupları ihtiyari olarak yararlanabilirler:

a) Ticari kazancı basit usulde tespit edilen mükellefler,

b) İşletme hesabı esasına göre defter tutan mükellefler,

c) Bilanço esasına göre defter tutan mükellefler,

ç) Serbest meslek kazancı elde eden mükellefler, 

d) Gerçek usulde vergilendirilen zirai kazancı elde eden mükellefler,

e) Vergiden muaf esnaf.

(2) Bu maddenin birinci fıkrasında yer alan mükelleflerden bu Tebliğle getirilen Sisteme dahil olanlar, Sistem kapsamında gerçekleştirdikleri mal satışı ve hizmet ifasına ilişkin 213 sayılı Kanun gereğince kendilerine düzenleme zorunluluğu getirilen mali belgeleri elektronik belge olarak düzenlemek ve müşterilerine belgenin türü ve niteliğine bağlı olarak elektronik ve/veya kağıt ortamda iletmek zorundadırlar. Vergiden muaf esnaflar, belge düzenleme zorunlulukları bulunmadığından, format ve standardı Başkanlık tarafından belirlenen ve www.efatura.gov.tr internet adresinde yayınlanan Teknik Kılavuzda belirlenen mali değeri bulunmayan, bilgi amaçlı “Bilgi Fişi” düzenleyeceklerdir.

(3) Sisteme dahil olan mükelleflerin, faaliyetlerinde ödeme kaydedici cihaz kullanma mecburiyetleri bulunmamaktadır. Ancak sisteme dahil olan mükelleflerden hali hazırda ödeme kaydedici cihaz kullanmakta olanlar, söz konusu cihazlarını perakende satış fişi ile belgelendirilebilecek satışlarında kullanmaları mümkündür. Bununla birlikte söz konusu ödeme kaydedici cihazların Sistem kapsamında gerçekleştirilen ve e-Belge düzenlenen hallerde kullanılması durumunda, elektronik belgelere ilişkin olarak “Bilgi Fişi” (usul ve esasları Başkanlıkça www.ynokc.gib.gov.tr internet adresinde yayımlanan Bilgi Fişleri Teknik Kılavuzunda belirtilen) düzenlemeleri gerekmektedir.

(4) Sisteme dahil olan mükellefler, sistem kapsamında verilmeyen banka vb. kuruluşlara ait EFT-POS cihazlarını,  ödeme kaydedici cihazlarla 483 Sıra No.lu Vergi Usul Kanunu Genel Tebliğinde ve bu Tebliğe dayanılarak Başkanlık tarafından yayımlanan Teknik Kılavuzlar, Protokol dokümanları ve Başkanlık tarafından www.ynokc.gib.gov.tr internet adresinde yapılan duyurularla belirlenen kurallara uygun kullanılması şartıyla kullanmaya devam edebilirler.

(5) Sistem kapsamında düzenlenen e-Belgelerin kağıt ortamda verilmesi gereken nüshalarının verilmesinde, ÖKC’lerin, EFT-POS cihazlarının ve Başkanlıkça izin verilen diğer cihazların kullanılması mümkündür.

Sorumluluk ve ceza uygulaması

MADDE 6 – (1) Bu Tebliğde usul ve esasları belirlenen Sistemi mükelleflere sunan finans kuruluşları, ödeme kaydedici cihaz üreticileri ile bu sistem kapsamında elektronik belgelerin oluşturulmasına yönelik hizmet sunan özel entegratörler, hizmet verdikleri mükelleflere ait tahsilat ve elektronik belge bilgilerini, tahsilatın yapılması ile elektronik belgelerin oluşturulması, imzalanması, gönderilmesi ve alınması amacı dışında (ilgili diğer mevzuatlarında izin verilen haller hariç) kullanamazlar ve işleme taraf olanların yazılı izni olmaksızın üçüncü kişilerle paylaşamazlar. Bu kuruluşlar bu faaliyetler kapsamında elde ettiği ticari sır niteliğindeki bilgilerin güvenliğinden ve gizliliğinden sorumludurlar.

(2) Bu maddenin birinci fıkrasına aykırı olarak işleme taraf olmayan üçüncü kişilerle gizli kalması gereken bilgileri paylaştığı ya da bu Tebliğ ve bu Tebliğde belirtilen Teknik Kılavuzlarda açıklanan usul ve esaslara uymadığı tespit olunan, finans kuruluşları, ödeme kaydedici cihaz üreticileri ile özel entegratörlerin diğer Kanunların öngördüğü cezai sorumlulukları dışında ayrıca Bakanlık ve Başkanlık tarafından bu Tebliğ kapsamında verilen faaliyet izinleri iptal edilebilir. 

(3) Sistemi mükelleflere sunan finans kuruluşları tahsilata ilişkin bilgileri, özel entegratörler ise bu sistem kapsamında oluşturulan elektronik belgeleri 10 yıl süre ile gizliliği ve güvenliği sağlanacak şekilde muhafaza etmek zorundadırlar.  Bu zorunluluk, hizmetten yararlanan mükelleflerin 213 sayılı Kanunla getirilen muhafaza ve ibraz yükümlülüğünü ortadan kaldırmaz.

(4) Sistemi mükelleflere sunan finans kuruluşları tahsilata ilişkin bilgileri, özel entegratörlerin ise bu sistem kapsamında oluşturulan elektronik belgeleri Başkanlığa,  Başkanlıkça belirlenen süreler dahilinde elektronik ortamda sunma, iletme veya uzaktan erişime açma sorumluluğu bulunmaktadır. Elektronik ortamda sunum, iletim veya uzaktan erişime ilişkin usul ve esaslar www.efatura.gov.tr internet adresinde Başkanlık tarafından yayınlanan Teknik Kılavuzda açıklanacaktır. 

(5) Sistem kapsamında elektronik belge hizmeti sunan özel entegratörler, düzenlenen elektronik belgelerin bir örneğini sistemi kullanan mükelleflerin erişimine kağıt ve/veya elektronik ortamda sunmak zorundadırlar.

(6) Sisteme dahil olan mükellefler mücbir sebepler ve 494 Sıra No.lu Vergi Usul Kanunu Genel Tebliğinde belirtilen haller dışında, Sistem kapsamında elektronik ortamda düzenlenmesi gereken belgeleri kağıt ortamında düzenleyemezler. Bu nedenle mücbir sebep veya zorunlu durumlarda kullanılmak üzere yeterli miktarda matbu belge bulundurulması zorunludur.

Sistemin uygulamaya başlama zamanı

MADDE 7 – (1) Bu Tebliğle belirlenen Sistem, 1/9/2019 tarihinden itibaren uygulamaya girer.

Yürürlük

MADDE 8 –  (1) Bu Tebliğ yayımı tarihinde yürürlüğe girer.

Yürütme

MADDE 9 – (1) Bu Tebliğ hükümlerini Hazine ve Maliye Bakanı yürütür.


 

GÜVENLİ MOBİL ÖDEME VE ELEKTRONİK BELGE YÖNETİM SİSTEMİ BAŞVURU KILAVUZU

GELİR İDARESİ BAŞKANLIĞI

Uygulama ve Veri Yönetimi Daire Başkanlığı (III)

Temmuz 2021 ANKARA

 

 

Versiyon

Yayım

Tarihi

Eklenen/Silinen/Değişen Bölüm

Açıklama

1.0

06.07.2021

--

Kılavuzun ilk yayım tarihi

 

İçindekiler Tablosu

  1. Giriş......................................................................................................................... 4
  2. Tanımlar ve Kısaltmalar......................................................................................... 4
  3. Sistemin Temel Özellikleri...................................................................................... 5
  4. Güvenli Mobil Ödeme ve Elektronik Belge Yönetim Sistemi Uygulamasından Yararlanabilecek Mükellefler........................................................................................ 6
  5. Sisteme Dahil Olan Mükelleflerin Belge Düzeni.................................................... 6
  6. Uygulamaya Başvuru.............................................................................................. 7

 

  1. Giriş

Bu kılavuz, 507 Sıra No.lu Vergi Usul Kanunu Genel Tebliği kapsamında mükelleflerimizin kullanımına sunulan Güvenli Mobil Ödeme ve Elektronik Belge Yönetim Sistemi’nden yararlanmak üzere başvuru yapacak mükelleflerin yapması gereken işlemleri açıklamak amacıyla hazırlanmıştır.

  1. Tanımlar ve Kısaltmalar

Bakanlık: Hazine ve Maliye Bakanlığı

Başkanlık: Gelir İdaresi Başkanlığı

Elektronik Belge (e-Belge): Usul ve esasları Vergi Usul Kanunu Genel Tebliğleri ile belirlenen elektronik belgeleri,

Güvenli Mobil Ödeme ve Elektronik Belge Yönetim Sistemi (GMÖEBYS) (Sistem): Finans kuruluşları ya da ÖKC üreticileri ile birlikte özel entegratör kuruluşlar tarafından 507 Sıra No.lu VUK Genel Tebliğinde belirtilen usul ve esaslara uygun gerçekleştirilen satış, ödeme/tahsilat işlemleri ile bu işlemlere ilişkin mali belgelerin elektronik belge olarak oluşturulması, iletilmesi, muhafaza ve ibraz edilmesi süreçlerine ilişkin olarak Bakanlıkça izin verilen sistemi,

Güvenli Mali Uygulama (GMU): GMÖEBYS kapsamında yapılan tüm işlemlerin güvenli bir şekilde başlamasını ve güvenli bir şekilde sonlanmasını sağlayan ve ayrıca diğer uygulamaların bağlı olarak çalıştığı merkezi sistem ve uç nokta yazılımlarının tamamını içeren ana uygulama,

İşletici Kuruluş: 507 Sıra No.lu VUK Genel Tebliğinde tanımlanan Finans Kuruluşu veya Ödeme Kaydedici Cihaz Üreticilerinden, sistemi işletmek üzere Hazine ve Maliye Bakanlığınca yetkilendirilen ve Sistemin işletilmesi nedeniyle Bakanlık, Başkanlık ve sistem kapsamındaki hizmetlerden yararlananlara karşı asli sorumlu olan kuruluşlardan her biri,

Finans Kuruluşu: 507 Sıra No.lu VUK Genel Tebliği kapsamında; 19/10/2005 tarihli ve 5411 sayılı Bankacılık Kanununa göre faaliyet gösteren Bankalar ile 20/6/2013 tarihli ve 6493 sayılı Ödeme ve Menkul Kıymet Mutabakat Sistemleri, Ödeme Hizmetleri ve Elektronik Para Kuruluşları Hakkında Kanuna göre faaliyet gösteren elektronik para kuruluşları ve ödeme kuruluşlarından Hazine ve Maliye Bakanlığınca yetkilendirilen ve bu Tebliğde belirtilen sistemin işletilmesi nedeniyle Bakanlık, Başkanlık ve sistem kapsamındaki hizmetlerden yararlananlara karşı asli sorumlu olan kuruluşları,

Ödeme Kaydedici Cihaz Üreticisi: 426 Sıra No.lu Vergi Usul Kanunu Genel Tebliğinde belirtilen yeni nesil ödeme kaydedici cihazların üretim ve ithalatına ilişkin Bakanlıktan onay alan ve bu Tebliğde belirtilen sistemin işletilmesi nedeniyle Bakanlık, Başkanlık ve sistem kapsamındaki hizmetlerden yararlananlara karşı asli sorumlu olan kuruluşları,

Özel Entegratör: 509 Sıra No.lu Vergi Usul Kanunu Genel Tebliği kapsamında elektronik belgelerin (e-Fatura, e-Arşiv Fatura, e-Serbest Meslek Makbuzu vb. diğer elektronik belgeler) düzenlenmesi, iletilmesi, alınması ve saklama hizmetleri ile ilgili mükelleflere hizmet verme konusunda Başkanlıktan almış kuruluşları,

ifade eder.

  1. Sistemin Amacı

Sisteminin amacı, vergi doğuran mal ve hizmet satış işlemleri ile bunlara bağlı olarak yapılan ödemeleri / tahsilatları vergi kayıp ve kaçağına yol açmayacak şekilde, donanım bağımsız güvenli mobil uygulamalar aracılığıyla gerçekleştirmek ve sonuçlarını işlemin mahiyetine uygun düzenlenecek mali nitelikli e-Belgeler yoluyla kayıt altına almaktır.

  1. Güvenli Mobil Ödeme ve Elektronik Belge Yönetim Sistemi Uygulamasından Yararlanabilecek Mükellefler

Gelir İdaresi Başkanlığınca faaliyet izni verilen İşletici Kuruluşların yönetmiş oldukları Güvenli Mobil Ödeme ve Elektronik Belge Yönetim Sisteminden aşağıda belirtilen mükellef grupları ihtiyari olarak yararlanabilir:

  • Ticari kazancı basit usulde tespit edilen mükellefler,
  • İşletme hesabı esasına göre defter tutan mükellefler,
  • Bilanço esasına göre defter tutan mükellefler,
  • Serbest meslek kazancı elde eden mükellefler,
  • Gerçek usulde vergilendirilen zirai kazancı elde eden mükellefler,
  • Vergiden muaf esnaf yararlanabilir.

     5. Sisteme Dahil Olan Mükelleflerin Belge Düzeni

Güvenli Mobil Ödeme ve Elektronik Belge Yönetim Sistemine dahil olan mükellefler, sistem kapsamında;

  • Ödeme Kaydedici Cihaz kullanma mecburiyetleri bulunmamaktadır.
  • Tek noktadan sağlanan yönetim kolaylığı sayesinde tek bir cihaz ya da aplikasyon ile satış, ödeme ve belge düzenleme işlemlerini yapabilirler.
  • ÖKC, POS vb. cihazlara bağımlılığı ortadan kaldırmaktadır.
  • Tüm satışlarını e-Belge ile belgelendirebilecekleri için kağıt belge bastırma ve bulundurma mecburiyetleri bulunmamaktadır.
  • e-Belge uygulamalarına mali mühür ya da e-İmza sahibi olmadan da dahil olabileceklerinden ayrıca bu maliyetlerle de karşılaşmayacaklardır.
  • E-Belge uygulamalarına daha önce dahil olan mükellefler GMÖEBYS kapsamında var olan e-imza veya mali mühürlerini sistem kapsamında kullanabileceklerdir.
  • Mal teslimi veya hizmet ifasında bulunduklarında düzenleyecekleri elektronik belgeleri muhataplarına elektronik ortamda iletebileceklerdir.
  • 500 TL tutara kadar düzenleyecekleri e-Arşiv Faturalarla ilgili olarak nihai tüketicinin adını yazmak zorunluluğu bulunmamaktadır.
  1. Uygulamaya Başvuru

GMÖEBYS uygulamasından yararlanmak isteyen mükellefler, Başkanlık tarafından İşletici Kuruluş olarak yetkilendirilmiş şirketler ile üyelik anlaşmaları yapmaları ve Başkanlık tarafından sunulan İnteraktif Vergi Dairesi üzerinden 507 Sıra No.lu VUK Genel Tebliği kapsamında e-Belge uygulamalarına dahil olacaklarını beyan etmeleri ve hizmet alacakları işletici kuruluşu seçmeleri gerekmektedir. Güvenli Mobil Ödeme ve Elektronik Belge Yönetim Sistemi kapsamında Başkanlığımızdan “İŞLETİCİ KURULUŞ İZNİ” alan kurumlara https://ebelge.gib.gov.tr/gmoebysisleticikuruluslistesi.html linkten ulaşılabilmektedir.

GMÖEBYS uygulamasından yararlanmak isteyen mükellefler başvurularını, Başkanlık tarafından sunulan İnteraktif Vergi Dairesi üzerinden yapabilirler.

Başkanlık tarafından sunulan https://ivd.gib.gov.tr/ adresinden İnteraktif Vergi Dairesine giriş işlemi yapıldıktan sonra “İşlem Başlat” menüsünden “E- DEFTER VE E- BELGE İŞLEMLERİ” menüsündeki “GMÖEBYS Güvenli Mobil Ödeme Sistemleri Başvuru” kutucuğu seçilerek Güvenli Mobil Ödeme ve Elektronik Belge Yönetim Sistemi Başvuru Talebi sayfası açılır.

Açılan sayfada 1. Adım olarak Başkanlıktan Güvenli Mobil Ödeme ve Elektronik Belge Yönetim Sistemini işletmek için yetki belgesi almış İşletici Kuruluşların listesi sunulur. Listeden üyelik sözleşmesi imzalanan “İşletici Kuruluş” seçilmek ve mükellefiyetinize ilişkin bilgileri ilgili alanlara doldurmak suretiyle 2. Adıma geçilecektir.

2. Adımda Şirket Sorumlu Bilgileri alanları doldurularak Özet adımına geçilecektir.

Özet Adımında 1. Ve 2. Adımda girilen bilgiler kontrol edikten sonra, sayfanın alt bölümünde yer alan taahhüt bilgileri onaylanarak başvuru işleminiz gerçekleşmiş olacaktır.

İnteraktif Vergi Dairesi içinde yer alan “İşlem Durumlarım ve Sonuçları” menüsünden yapılan başvuru belgesinin çıktısı alınarak başvuruda seçilen işletici kuruluşa iletilmesi gerekmektedir.

Daha sonra işletici kuruluşlar, çalıştıkları özel entegratörler aracılığıyla, Özel Entegrasyon Kılavuzunda yer alan açıklamalara uygun bir şekilde mükellef adına e-Belge kullanıcı açma işlemini gerçekleştireceklerdir.


SIRA NO İŞLETİCİ KURULUŞ YETKİ ALMA BAŞVURU ŞARTLARI VE BELGELERİ ZORUNLU / OPSİYONEL DURUMU AÇIKLAMA 
1 Finans Kuruluşu veya Yeni Nesil Ödeme Kaydedici Cihaz Üreticisi olmak ZORUNLU  
2 Başvuru Dilekçesi ZORUNLU Başvuru yapanlar dilekçe içeriğinde; GMÖEBYS Teknik Kılavuzunda tariflenen şekilde sistemi kurarak işleteceklerini ve içerisindeki tüm sorumlulukları eksiksiz yerine getireceklerini (Kılavuz Madde 10 kapsamında verilmesi gereken taahhütnameyi de içerecek şekilde) gayrikabili rücu şekilde kabul, beyan ve taahhüt etmek zorundadırlar.
3 İşletici Kuruluş Faaliyet İzni Başvuru Formu  ZORUNLU Islak İmzalı, Tarih ve Kaşeli olması gerekmektedir.
4 Başvuru Yapan Firma İmza Sirküleri ZORUNLU Aslı veya Noter Onaylı Sureti
5 Başvuru Yapan Firma Vergi Levhası ZORUNLU  
6 Başvuru Yapan Firma Ticaret Sicil Gazetesi ZORUNLU  
7 Kurum Tipini Tevsik Edici Belgeler ZORUNLU Ticaret Odası, Sanayi Odası Faaliyet Belgesi vb. 
8 Özel Entegratör Protokolü ZORUNLU En az bir Özel Entegratör ile anlaşma imzaladığına dair protokol (Özel Entegratör kontrol linki: https://ebelge.gib.gov.tr/efaturaozelentegratorlerlistesi.html)
9 Dış Hizmet Sağlayıcısı Protokolü OPSİYONEL Dış Hizmet Sağlayıcısı kullanılıyorsa, Dış Hizmet Sağlayıcısı ile anlaşma imzaladığına dair protokol aslı veya noter onaylı sureti
10 İkincil Merkez İçin Dış Hizmet Sağlayıcısı Anlaşması OPSİYONEL  
11 Kılavuz Madde 10 kapsamında verilmesi gereken Sistem Mimarisine ait Dosya ZORUNLU Sistem mimarisi; network topolojisi, uçtan uca güvenlik altyapısı ile sertifika ve anahtar saklama yöntemini içerir.
12 HSM Cihazına ait EAL4+ Sertifikası ZORUNLU Cihaz seri numaraları bilgisinin başvuru formunda ilgili alana girilmesi gerekmektedir.
13 Başvuru Sahibinin Sunmak İstediği Ek Sertifika ve Belgeler OPSİYONEL EMV, PCI, vb. sunulmak istenen belgeler ek olarak iletilmelidir.
Sertifikaların geçerlilik süreleri kontrol edilir.
14 Özel Entegratör İmza Sirküleri ZORUNLU Aslı veya Noter Onaylı Sureti
15 Dış Hizmet Sağlayıcısı Firma İmza Sirküleri OPSİYONEL Dış Hizmet Sağlayıcısı kullanılıyorsa, Dış Hizmet Sağlayıcısı Firmanın imza sirkülerinin aslı veya noter onaylı sureti 

 

GELİR İDARESİ BAŞKANLIĞI

Güvenli Mobil Ödeme ve Elektronik Belge Yönetim

Sistemi

 

İşletici Kuruluş Faaliyet İzni Başvuru Formu

 

 

Versiyon 1.0

(21.05.2020)

 

GÜVENLİ MOBİL ÖDEME VE ELEKTRONİK BELGE YÖNETİM SİSTEMİ

İŞLETİCİ KURULUŞ FAALİYET İZNİ BAŞVURU FORMU

A.   BAŞVURU YAPAN KURUM TİPİ

Finans Kuruluşu

☒

Ödeme Kaydedici Cihaz Üreticisi

☐

B.   BAŞVURU YAPAN FİRMA BİLGİLERİ

Firma Unvanı

 

Firma VKN

 

Firma Adresi

 

Yetkili Kişi Adı-Soyadı

 

Yetkili Kişi TCKN

 

Yetkili Kişi Bölüm / Görev/ Unvan 

 

Yetkili Kişi İrtibat Tel No

 

Yetkili Kişi İrtibat GSM No

 

Yetkili Kişi e-Posta Adresi              

 

C. İŞLETİCİ KURULUŞ MERKEZİ SİSTEMİNE AİT BİLGİLER (Başkanlığa iletilecek irtibat noktası tek olmalıdır.)

İşletici Kuruluş Merkezi Sistemi Test

Ortamına Ait Adres ve IP Bilgisi

 

İşletici Kuruluş Merkezi Sistemi

Birincil Canlı Ortamına Ait Adres ve

IP Bilgisi

 

İşletici Kuruluş Merkezi Sistemi

İkincil Canlı Ortamına Ait Adres ve

IP Bilgisi

 

 

Yetkili Kişi Adı-Soyadı

 

Yetkili Kişi TCKN

 

Yetkili Kişi Bölüm / Görev/ Unvan 

 

Yetkili Kişi İrtibat Tel No

 

Yetkili Kişi İrtibat GSM No

 

Yetkili Kişi e-Posta Adresi              

 

D. SİSTEME AİT BİLGİLER

Dış Hizmet Sağlayıcısı Kullanılıyor mu?

☐     Evet

☐     Hayır

Sistem üzerinden düzenlenecek/ düzenlenmesi planlanan e-Belge türlerini yazınız.

 

Sistemin destekleyeceği/desteklemesi planlanan ödeme türlerini yazınız.

 

Faaliyet İzni Alınmak İstenen Sistemin Tipi (Her iki tip için de faaliyet izni isteniyorsa, her iki seçenek de işaretlenmeli ve bunlara ait bilgiler doldurulmalıdır.)

☐     Sertifikalı Cihazlar Üzerinde Çalışan Sistem

☐     Sertifikasız Cihazlar Üzerinde Çalışan Sistem

Sistem Çağrı Merkezi Numarası  (Başvuru Sahibinin faaliyet izni alacağı

Sistemden faydalanmak isteyen mükelleflerin ulaşabileceği bir çağrı merkezi olmak zorundadır.)

 

Sistem Destek Portali (Başvuru Sahibinin faaliyet izni alacağı Sistemden faydalanmak isteyen mükelleflerin ulaşabileceği bir destek portalı olmak zorundadır.)

 

 

Sistemin Adı / Markası

 

Sertifikalı Cihazlar Üzerinde Çalışan Sistem için Onay Alınacak Cihaz Marka ve Modeli (Sertifikalı cihazlar kullanılacaksa, başvuru esasında en az bir adet cihaz marka/model belirtilmelidir.)

 

Sertifikasız Cihazlar Üzerinde Çalışan Sistem için Desteklenen İşletim Sistemi (Birden fazla işletim sistemi destekleniyorsa işaretlenmelidir. İşletim sistemlerinin altına desteklenen en düşük versiyon bilgisi yazılmalıdır. Diğer seçeneğini işaretleyen başvuru sahipleri, işletim sisteminin adı ve destelenen en düşük versiyon bilgisini de yazmalıdır.)

 

☐     Android

(…………………………………………………………..)

☐     iOS 

(…………………………………………………………..)

☐     Diğer

(…………………………………………………………..)

Harici Donanım Entegrasyon Desteği

 

☐     Var

☐     Yok

Harici Yazılım Entegrasyon Desteği

 

☐     Var

☐     Yok

Harici Satış Uygulaması

Entegrasyon Desteği

☐     Var

☐     Yok

 

E.  DIŞ HİZMET SAĞLAYICISI BİLGİLERİ (Dış Hizmet Sağlayıcısı kullanılıyor ise

aşağıdaki bilgiler girilmelidir.)

Firma Unvanı

 

Firma VKN

 

Firma Adresi

 

Yetkili Kişi Adı-Soyadı

 

Yetkili Kişi TCKN

 

Yetkili Kişi Bölüm / Görev/ Unvan 

 

Yetkili Kişi İrtibat Tel No

 

Yetkili Kişi İrtibat GSM No

 

Yetkili Kişi e-Posta Adresi              

 

F.  ÖZEL ENTEGRATÖR BİLGİLERİ (Başvuru esnasında en az bir Özel Entegratör bilgisi girilmelidir.)

Firma Unvanı

 

Firma VKN

 

Firma Adresi

 

Yetkili Kişi Adı-Soyadı

 

Yetkili Kişi TCKN

 

Yetkili Kişi Bölüm / Görev/ Unvan 

 

Yetkili Kişi İrtibat Tel No

 

Yetkili Kişi İrtibat GSM No

 

Yetkili Kişi e-Posta Adresi              

 

G. BAŞVURU FORMU EKLERİ

Başvuru Ekinde Yer Alan Belgeler

Belge Zorunluluğu

 

Var

 

Yok

 

Başvuru Dilekçesi

Zorunlu

☐

☐

 

(Kılavuz Madde 10 kapsamında verilmesi gereken taahhütnameyi de içerecek şekilde)

 

 

 

Başvuru Yapan Firma İmza Sirküleri

Zorunlu

☐

☐

Başvuru Yapan Firma Vergi Levhası

Zorunlu

☐

☐

Başvuru Yapan Firma Ticaret Sicil

Gazetesi

Zorunlu

☐

☐

Kurum Tipini Tevsik Edici Belgeler

Zorunlu

☐

☐

Özel Entegratör Protokolü

(En az bir Özel Entegratör ile anlaşma imzaladığına dair)

Zorunlu

☐

☐

Dış Hizmet Sağlayıcısı Protokolü

(Dış Hizmet Sağlayıcısı kullanılıyorsa, Dış Hizmet Sağlayıcısı ile anlaşma imzaladığına dair)

Opsiyonel

☐

☐

İkincil Merkez İçin DHS Anlaşması

Opsiyonel

☐

☐

Kılavuz Madde 10 kapsamında verilmesi gereken Sistem Mimarisine ait Dosya

Zorunlu

☐

☐

HSM Cihazına ait EAL4+ Sertifikası

(Cihaz Seri Numaraları Bilgisini

Giriniz)

Zorunlu

☐

☐

Başvuru Sahibinin Sunmak İstediği Ek Sertifika ve Belgeler

(EMV, PCI, vb. sunulmak istenen

belgeler ek olarak iletilmelidir.)

Opsiyonel

☐

☐

Özel Entegratör İmza Sirküleri

Zorunlu

☐

☐

DHS Firma İmza Sirküleri

Opsiyonel

☐

☐

Bu form ve eklerinde yer alan tüm bilgi ve belgelerin doğruluğunu beyan ve taahhüt ederiz.

(BAŞVURU SAHİBİ FİRMA ÜNVANI)

.......................................................................................................................

Yetkili İmzalar

 

 

 

Tarih

...................................................

 

 


 

GELİR İDARESİ BAŞKANLIĞI

 

Güvenli Mobil Ödeme ve Elektronik Belge Yönetim Sistemi

Başvuru, İzin, Onay ve Denetim Süreçleri Kılavuzu

 

Versiyon 1.2

(10.07.2020)

Versiyon

Yayım Tarihi

Açıklama

1.0

30.12.2019

Kılavuzun ilk yayım tarihi

1.1

21.05.2020

Sistem kapsamında düzenlenecek ve tutarı 500 TL ye kadar olacak e-Arşiv

Faturalarla ilgili 515 SN VUK Genel

Tebliği ile yapılan değişikliklerin

işlenmesi,

Güvenli Mali Sertifika yönetimi teknik süreçlerinin açıklığa kavuşturulması,

GMÖEBYS Uyumluluk Test Adımları Tablosunun güncellenmesi,

İşletici Kuruluş Faaliyet İzni Başvuru

Formunun eklenmesi,

İşletici Kuruluş Sistemi Fonksiyonel Test Süreçleri Dokümanının hazırlanması,

İşletici Kuruluş Sistemi Güvenlik Test

Süreçleri Dokümanının hazırlanması,

amacıyla düzenleme yapılmıştır.

1.2

10.07.2020

İşletici Kuruluş İzin Başvurusu, Uyumluluk Testleri Denetimi ve İznin Verilmesi bölümü güncellenmiştir.

 

 

İÇİNDEKİLER  

Giriş          4

Tanımlar ve Kısaltmalar   4

Sistemin Temel Özellikleri           7

a. Güvenli Mali Uygulama (GMU)         8

b. e-Belge Entegrasyonu 14

c. Ödeme Kabul Eden Araç        15

ç. Mali Raporlar    17

d. Güvenli Mali Sertifika ve İmza Yönetimi       17

e. Yazılım Güvenliği        22

f. Erişim Kontrolü            22

g. Kimlik Doğrulama       23

ğ. Oturum Açma ve Oturum Kimliği Doğrulama           23

h. Uçtan Uca Güvenlik    24

ı. Olay Kayıt Özelliği       24

i. PCI Güvenlik Sertifikası          24

j. EMV Sertifikaları         25

k. Satış Yazılımı ve Harici Satış Uygulamaları ile Entegrasyonu           25

4. Sistemin Genel Güvenlik Gereksinimleri        25

5. Mülkiyet           31

6. Sistem Üzerinden Düzenlenebilecek e-Belgeler         32

7. Ödeme Türleri 34

8. Avans Ödeme ve Cari Hesap Tahsilatı İşlemleri        35

9. Fatura Tahsilatı İşlemleri         35

     10. İşletici Kuruluş İzin Başvurusu, Uyumluluk Testleri Denetimi ve İznin Verilmesi 36

      11. Sistemden Yararlanmak İsteyen Mükelleflerin Üyelik Başvurusu ve Sisteme Dahil Edilmesi          38

12. Sistem İle Birlikte ÖKC/YNÖKC Kullanımı           39

13. Denetim          39

14. Sorumluluk ve Ceza Uygulaması      40

15. Dış Hizmet Alımı       42

16. Değişiklik Hakkı        42

 

1. Giriş

Bu Teknik Kılavuz, Güvenli Mobil Ödeme ve Elektronik Belge Yönetim Sistemine (Sistem) ilişkin 01.06.2019 tarih ve 30791 sayılı Resmi Gazete’de yayımlanan 507 Sıra No’lu Vergi Usul Kanunu Genel Tebliğinin 4 üncü Maddesinin 5 inci fıkrası hükmü uyarınca hazırlanmış olup, Sisteme ilişkin teknik gereklilikler ile Sistem kapsamında hizmet sunacak İşletici Kuruluşların izin başvuru, onayı süreçleri ve Sistem işletilmesi sürecinde güvenlik, denetim, sorumluluk ve uygulamaya ilişkin uyulması gereken diğer usul ve esasları düzenlemektedir.

2. Tanımlar ve Kısaltmalar

 

TANIM

AÇIKLAMA

Bakanlık

 

Hazine ve Maliye Bakanlığı

 

Başkanlık

 

Gelir İdaresi Başkanlığı

 

BDDK

 

Bankacılık Düzenleme ve Denetleme Kurumu

 

TCMB

 

Türkiye Cumhuriyet Merkez Bankası

 

BSDHY

 

13/01/2010 tarihli ve 27461 sayılı Resmi Gazete’de yayımlanan Bağımsız Denetim Kuruluşlarınca Gerçekleştirilecek Banka Bilgi Sistemleri ve Bankacılık Süreçlerinin Denetimi Hakkında Yönetmeliği

 

Diğer

Regülasyon Otoriteleri

 

Başkanlık dışında kalan, Merkez Bankası ile

Uluslararası Ödeme Sistemleri Güvenlik

Sertifikasyon ve Regülasyon kuruluşları olan PCI (Payment Card Industry) ve EMVCo ile TROY veya Türkiye sınırları dahilinde kart işlemi kabul edilen Uluslararası (VISA, Mastercard, Amex, JCB vb.) şema sahibi kuruluşlar ı

 

EFT-POS

 

EMV Sertifikaları ile uyumlu kartlı ödeme sistemleri terminali (Electronic Funds Transfer – Point of Sale)

 

 

Elektronik Belge (e-belge)

 

Usul ve esasları Vergi Usul Kanunu genel tebliğleri ile belirlenen elektronik ortamda düzenlenebilen belgeler

 

 

EMV Sertifikaları

 

 

EMVCo kuruluşu tarafından verilen EMV sertifikaları

 

 

Finansal Kuruluş

 

507 No.lu VUK Genel Tebliği kapsamında;

19/10/2005 tarihli ve 5411 sayılı Bankacılık Kanununa göre faaliyet gösteren Bankalar ile 20/6/2013 tarihli ve 6493 sayılı Ödeme ve Menkul Kıymet Mutabakat Sistemleri, Ödeme Hizmetleri ve Elektronik Para Kuruluşları Hakkında Kanuna göre faaliyet gösteren elektronik para kuruluşları ve ödeme kuruluşlarından Hazine ve Maliye Bakanlığınca yetkilendirilen ve bu Tebliğde belirtilen sistemin işletilmesi nedeniyle Bakanlık, Başkanlık ve sistem kapsamındaki hizmetlerden yararlananlara karşı asli sorumlu olan kuruluşları, 

 

Güvenli Mobil Ödeme ve Elektronik Belge Yönetim Sistemi 

(Sistem) (GMÖEBYS) 

 

 

Finans kuruluşları ya da ÖKC üreticileri ile birlikte özel entegratör kuruluşlar tarafından bu Tebliğde belirtilen usul ve esaslara uygun gerçekleştirilen satış, ödeme/tahsilat işlemleri ile bu işlemlere ilişkin mali belgelerin elektronik belge olarak oluşturulması, iletilmesi, muhafaza ve ibraz edilmesi süreçlerine ilişkin olarak Bakanlıkça izin verilen sistemi, 

 

Güvenli Mali Uygulama (GMU)

 

e-Belgelendirme Sisteminde yapılan tüm işlemlerin güvenli bir şekilde başlamasını ve güvenli bir şekilde sonlanmasını sağlayan ve ayrıca diğer uygulamaların bağlı olarak çalıştığı merkezi sistem ve uç nokta yazılımlarının tamamını içeren ana uygulama

 

İşletici Kuruluş

 

507 Sıra No.lu Tebliğde tanımlanan Finans Kuruluşu veya Ödeme Kaydedici Cihaz Üreticilerinden, sistemi işletmek üzere Hazine ve Maliye Bakanlığınca yetkilendirilen ve Sistemin işletilmesi nedeniyle Bakanlık, Başkanlık ve sistem kapsamındaki hizmetlerden yararlananlara karşı asli sorumlu olan kuruluşlardan her biri 

 

Mali Raporlar

 

Başkanlık tarafından bu kılavuzda belirtilen ve İşletici Kuruluşlardan istenebilecek raporlar 

 

 

 

 

Mobil İmza

 

 

 

 

 

 

 

 

Cep telefonu ve GSM SIM kart kullanılarak 5070 sayılı Elektronik İmza Kanunu ve ilgili yasal mevzuata uygun olarak ıslak imza niteliğinde güvenli bir biçimde elektronik imza işlemi yapılmasına imkân sağlayan uygulama

 

Ödeme Aracı

 

Bankalar, elektronik para kuruluşları ve ödeme kuruluşlarınca ödeme işlemlerinin yapılmasına olanak sağlayan fiziki/sanal kartları ya da bu kuruluşların hesaplarından ödemeyi gerçekleştirebilecek bilgileri barındıran ve fiziki niteliği bulunmayan yazılımsal uygulamalar (QR, NFC vb.)

 

Ödeme Kabul Eden Araç

 

Bir fiziki donanım üzerinden, Ödeme Aracını kabul ederek ödemeyi gerçekleştirebilen yazılımsal uygulamalar.

 

ÖKC / YNÖKC

 

3100 sayılı Kanunun 2 nci maddesinde ve 213 sayılı Kanunun mükerrer 257 nci maddesi hükümleri uyarınca yayımlanan 426 Sıra No.lu Vergi Usul Kanunu Genel Tebliğinde belirtilen teknik dokümanlardaki nitelikleri haiz cihazlar

 

ÖKC Üreticisi

 

426 Sıra No.lu Vergi Usul Kanunu Genel Tebliğinde belirtilen yeni nesil ödeme kaydedici cihazların üretim ve ithalatına ilişkin Bakanlıktan onay alan ve bu Tebliğde belirtilen sistemin işletilmesi nedeniyle Bakanlık, Başkanlık ve sistem kapsamındaki hizmetlerden yararlananlara karşı asli sorumlu olan kuruluşlar 

 

Özel Entegratör Kuruluş

 

Elektronik belgelerin (e-Fatura, e-Arşiv Fatura, e-Serbest Meslek Makbuzu vb. diğer elektronik belgeler) düzenlenmesi, iletilmesi, alınması ve saklama hizmetleri ile ilgili mükelleflere hizmet verme konusunda Başkanlıktan alınmış özel entegratörlük izni bulunan kuruluşlar

PCI Güvenlik Sertifikası

 

PCI (Payment Card Industry) SSC (Security Standarts Counciel) tarafından PCI PTS (PIN Transaction Security) ve / veya Software-based PIN Entry on COTS (SPoC),  PCI Contactless Payments on COTS (CPoC)  vb. çözümleri kapsamında verilen güvenlik sertifikaları

 

 

 

Üye İşyeri Anlaşması  Yapan Kuruluş

 

5464 Sayılı Banka ve Kredi Kartları Kanunu ile 6493 Sayılı Ödeme ve Menkul Kıymet Mutabakat Sistemleri, Ödeme Hizmetleri ve Elektronik Para Kuruluşları Hakkındaki Kanundan yetki almış kuruluşları ve 382 Sıra No.lu Vergi Usul Kanunu Genel Tebliği’nde belirtilen kurallara göre faaliyet gösteren Özel Kart ve Yemek Çeki Kuruluşları

Yetkili Servis

 

 

İşletici Kuruluş tarafından, sorumluluğu kapsamındaki yazılımları için kurulum, güncelleme, anahtar yükleme, bakım, eğitim gibi hizmetleri vermek üzere yetkilendirilen servisler

 

 

3. Sistemin Temel Özellikleri

Sisteminin amacı, vergi doğuran mal ve hizmet satış işlemleri ile bunlara bağlı olarak yapılan ödemeleri / tahsilatları vergi kayıp ve kaçağına yol açmayacak şekilde, donanım bağımsız güvenli mobil uygulamalar aracılığıyla gerçekleştirmek ve sonuçlarını işlemin mahiyetine uygun düzenlenecek mali nitelikli e-Belgeler yoluyla kayıt altına almaktır.

Sistem üzerinden yapılacak her tür işlemin, Güvenli Mali Uygulama üzerinden (veya Güvenli Mali Uygulama ile entegrasyonu İşletici Kuruluş sorumluluğunda gerçekleştirilmiş ve satışa başlama işleminin güvenli mali uygulama tarafına yapılan başlangıç bildirimi ile  tetiklendiği harici satış uygulama yazılımları üzerinden) başlaması ve ödeme/tahsilat da dâhil olmak üzere ilgili e-Belgelendirme süreçlerinin Güvenli Mali Uygulama aracılığıyla sonlandırılması esastır. Sistem bünyesinde bulunan satış uygulaması tarafından ya da Güvenli Mali Uygulama ile entegrasyonu İşletici Kuruluş sorumluluğunda sağlanmış harici satış uygulama yazılımları tarafından satışa ve müşteriye ait verilerinin girişi yapılarak güvenli mali uygulama da tetiklenebilir. 

İzin verilen Sistem, üzerinde çalıştığı fiziki donanım tipine göre değişmek üzere iki farklı versiyon olarak sunulabilir. Bu versiyonlar ve bunlara ait temel özellikler aşağıdaki “Temel Teknik Özellikler Tablosu”nda gösterilmektedir:

Sisteminin Temel Teknik Özellikler Tablosu

Temel Teknik Özellikler

Sertifikalı Cihazlar üzerinden

çalışan    

Sistem

Sertifikasız Cihazlar üzerinden

çalışan      

Sistem

Güvenli Mali Uygulama

X

X

e-Belge Entegrasyonu

X

X

Ödeme Kabul Eden Araç

X

X

Mali Raporlar

X

X

Güvenli Mali Sertifika

X

X

Yazılım Güvenliği

X

X

Erişim Kontrolü

X

X

Kimlik Doğrulama

X

X

Oturum açma ve oturum kimliği doğrulama

X

X

Uçtan Uca Güvenlik

X

X

Olay Kayıt Özelliği

X

X

PCI Güvenlik Sertifikası

X

İ

EMV Sertifikaları

X

İ

Harici Uygulamalar ile Entegrasyon

İ

İ

 

      X = Zorunlu    İ = İhtiyari    - = Yok

 

a. Güvenli Mali Uygulama (GMU)

Güvenli Mali Uygulama, İşletici kuruluşların 507 Sıra No.lu VUK Genel Tebliği, bu Kılavuz, 509 Sıra No.lu e-Belge uygulamalarına ilişkin VUK Genel Tebliği ve İlgili Teknik kılavuzları, satış uygulaması ve ödeme süreçleri ile Sistem kapsamında sürdürülmesi gereken iş, işlem ve entagrasyon süreçlerini sağlayan merkezi ve uç nokta yazılım sistemlerinin bütününü ifade etmekte olup, Sistem içindeki tek bir modül veya fonksiyonu tariflememektedir.  

Sistem kapsamında gerçekleştirilen tüm işlemler ile bu işlemlere bağlı olarak yapılan ödeme / tahsilat işlemleri ve ilgili işlem uyarınca düzenlenmesi gereken e-Belgenin oluşturulması, vergi kayıp ve kaçağına yol açmayacak şekilde vergi ve ödeme / tahsilat güvenliğini sağlanması amacıyla Güvenli Mali Uygulamanın kontrolü ve yönetimi altında yapılır. İşletici Kuruluş bu sistem içerisinde, dâhili bir satış uygulaması çalıştırabileceği gibi isterse harici satış uygulaması da sunabilir. Harici Satış Uygulamalarının, İşletici Kuruluş sorumluluğunda, Güvenli Mali Uygulama ile entegre edilmesi zorunludur.

İşletici Kuruluş Güvenli Mali Uygulamasını ( veya bu uygulamanın bir parçası olan Satış Uygulamasını), kendisine ait bir bilgi işlem merkezinden olmak koşuluyla Web tarayıcılar üzerinden erişilebilecek şekilde web tabanlı veya bulut sistemler yoluyla da sunabilir. Ancak ilgili satış uygulaması, uygulama marketleri ya da Yetkili Servisler aracılığı ile bir cihaza indirilerek / kurularak çalıştırılan bir uygulama ise, bu tip satış uygulamaları dâhili satış uygulaması olarak değerlendirilir. Güvenli mali uygulamanın bir parçası olmayan ve mükelleflerin faaliyetlerinde halihazırda kullandığı harici satış uygulama yazılımlarının işletici kuruluşa ait bilgi işlem sistemlerinde kurulması ve işletilmesi zorunluluğu bulunmamaktadır. Bu tür harici satış uygulama yazılımlarının güvenli mali uygulama ile entegrasyonu sağlanarak (satışa başlama işleminin güvenli mali uygulama tarafına yapılan başlangıç bildirimi ile tetiklenecek şekilde) ödeme ve mali e-belgeye dönüştürülmesi işlemlerinin işletici kuruluşlar tarafından yapılması gereği bulunmaktadır.

İster dâhili ister harici olsun, Satış uygulamalarının mali anlamdaki asli görevi ilgili işleme ait verilerin girişinin sağlanmasıdır. 

Sistem üzerinden yapılacak satış ve diğer tüm işlemlerin, Güvenli Mali Uygulama üzerinden  (veya Güvenli Mali Uygulama ile entegrasyonu İşletici Kuruluş sorumluluğunda gerçekleştirilmiş ve satışa başlama işleminin güvenli mali uygulama tarafına yapılan başlangıç bildirimi ile tetiklendiği harici satış uygulama yazılımları üzerinden) başlaması ve Güvenli Mali Uygulama üzerinden / aracılığıyla sonlandırılması esastır. Buna tahsilat işlemleri de dâhildir. Bu çerçevede, sistem kapsamında yapılan tahsilatların da vergisel işlemle ilişkilendirilmesi zorunludur. Satış ve diğer tüm işlemlerin Güvenli Mali Uygulama ile İşletici Kuruluş tarafından entegre edilen harici satış uygulama yazılımları üzerinden başladığı ve Güvenli Mali Uygulama üzerinden / aracılığıyla sonlandırıldığı durumlardaki işlemlerin güvenliği ve mali sorumluluğu İşletici Kuruluşa aittir. Ancak bu durum İşletici Kuruluşa eBelge ile ilgili tüm süreçlerin gerçekleştirilmesine hizmet veren özel entegratör kuruluşların kendi görev, yetki ve hizmet sunumundan kaynaklanan idari, mali ve güvenlik sorumluluğundan İşletici kuruluşa karşı sorumlu olup, ayrıca GİB’e karşı İşletici Kuruluşla birlikte müşterek ve müteselsil sorumluluğu da bulunmaktadır. 

Güvenli Mali Uygulamanın İdareye karşı asli sorumlusu İşletici Kuruluştur. İşletici Kuruluş sorumluluğunda Güvenli Mali Uygulama ile entegrasyonu gerçekleştirilerek Sistem kapsamında kullandırılan harici satış uygulama yazılımından alınan e-Belge verilerini doğru şekilde e-Belgeye (bilgi fişi düzenlenmesi gereken hallerde bilgi fişlerine) dönüştürülmesinden (İşletici Kuruluşlar satış uygulamasından-harici satış uygulamaları dahil- alınan verileri doğru bir şekilde özel entegratöre iletmekten ve özel entegratörün de kendisine iletilen verileri doğru bir şekil ve şemada e-Belge’ye yerleştirerek dönüştürmesi ve e-Belgeyi oluşturmasından) asli olarak İşletici Kuruluşlar sorumlu olup, bununla birlikte e-Belge ile ilgili süreçlerin gerçekleştirilmesine hizmet veren özel entegratör kuruluşlar da GİB’e karşı İşletici Kuruluşla birlikte müşterek ve müteselsil sorumluluğu da bulunmaktadır. Güvenli mali uygulamanın aşağıdaki özellikleri desteklemesi gerekir: 

Düzenlenecek e-Belgenin türüne uygun zorunlu bilgileri kendi üzerinden ya da satış uygulaması vasıtasıyla temin edecek nitelikte olmalı, 

Satışı gerçekleştirilecek mal ve hizmetlere ilişkin bilgiler ile vergi oran veya tutarları tanımlanabilmeli veya satış uygulamasından gelen bilgileri desteklemeli,

Mal ve hizmet detayları, tutarları ile vergi hesapları doğru bir şekilde yapılabilmeli, 

İndirim/Artırımların vergi hesabı doğru dağılımında yapılabilmeli 

Yazılım versiyon kontrolü yapabilmeli (İşletici kuruluş uç noktada yapılan işlemlerin hangi güvenli mali uygulama yazılımı versiyonu ile yapıldığını takip edebilir, gösterebilir olmalıdır),

Güvenli Mali uygulama sistem kapsamında gerçekleştirilen satış/ödeme/tahsilat işlemleri (iptal ve gerçekleşmeme dâhil) ve e-Belge düzenleme ve iptal etme ile ilgili log kayıtlarının oluşturulmasına ve işletici kuruluş tarafından takip edilmesine imkân sağlayacak nitelikte olmalı, 

Özel Entegratör ile güvenli iletişim sağlamalı, 

Kılavuzda tanımlanan tüm ödeme türlerini desteklemeli, Kılavuzda belirtilen mali Raporları üretebilmelidir.  

Güvenli Mali Uygulamanın cihazlar ve web tarayıcı üzerinden çalıştığı durumların genel örnek topolojisi aşağıda gösterilmektedir. Ancak bu topoloji içinde yer alan her bir modül (mavi kutular), işletici kuruluş tarafından alt modüller olarak kırılabilir, detaylandırılabilir, yeni topolojiler tasarlanabilir. 

Genel Sistem Topolojisi:

 

Genel İşlem Akışı:

Güvenli Mali Uygulama işlem akışları, aşağıdaki iki farklı senaryoda da yapılabilecektir. İşletici kuruluş bu senaryolardan dilediğini uygulayabilir.

Senaryo 1: Ödeme Onayından Önce e-Belge Taslağının Oluşturulduğu Senaryo:

 

Senaryo 2: Ödeme Onayından Sonra e-Belgenin Oluşturulduğu Senaryo:

 

Güvenli Mali Uygulama tarafından yapılan tüm mali ve finansal işlemlerin, belge düzenleyecek mükellefin mükellefiyet türüne uygun şekilde, İşletici Kuruluşun sorumluluğunda ve Özel Entegratör aracılığıyla anlık olarak, mevzuatta öngörülen elektronik belgelere dönüştürülmesi ve düzenlenen bu belgenin elektronik (ticari sır, müşteri sırrı, kişisel veri vb. ilgili mevzuatlarında uygunluğu belirtilen e-posta, sms, bankacılık uygulamaları vb.) veya kâğıt ortamda muhatabına iletilmesi zorunludur.

e-Belge’lerin düzenlenmesi, iletilmesi, sunulması, erişime açılması, raporlanması saklanması vb. süreçlerindeki sorumluluk, asli olarak İşletici Kuruluşta olmakla birlikte Özel Entegratör Kuruluşların da GİB’e karşı İşletici Kuruluşla birlikte müşterek ve müteselsil sorumluluğu da bulunmaktadır. 

İşletici Kuruluş Güvenli Mali Uygulamasını Sistem kapsamında anlaşmalı olduğu Özel Entegratör kuruluş / kuruluşlar ile entegre etmek ve kesintisiz şekilde çalıştırılmasını temin etmek zorundadır. Sisteminin çevrimiçi çalışması esastır. Bir başka ifade ile Sistem kapsamında gerçekleştirilen mali ve finansal işlemlerin, Güvenli Mali Uygulama aracılığıyla tamamlanmasıyla birlikte anlık olarak Özel Entegratör kuruluşa iletilmesi ve yine anlık olarak e-Belge oluşturularak müşteriye elektronik veya kâğıt ortamda iletiminin / sunumunun gerçekleştirilmesi zorunludur. Özel Entegratör ile çevrim içi olunmayan durumlarda Güvenli Mali Uygulamanın, mali ve finansal işlemleri gerçekleştirmemesi; çevrim içi olunması ile birlikte mali ve finansal işlemler ile bunlara bağlı olarak ilgili e-Belge düzenleme işleminin gerçekleştirilmesi gerekmektedir. İşletici Kuruluş, Güvenli Mali Uygulama ile Özel Entegratör sistemleri arasındaki iletişimin ve Özel Entegratörün e-Belge servislerinin aylık %99,75 kullanılabilirlik oranı ile hizmet sunacağını taahhüt etmeli ve bunu sağlamalıdır. Her iki kurum bu taahhüdün yerine getirilebilmesi için gerekli kendi servislerini taahhüde uygun şekilde çalıştırmaktan sorumludur. İşletici Kuruluş, uçtan uca güvenli çalışma esaslarını tanımlaması, oluşturması ve taahhüt etmesi koşuluyla, sistemin çevrimdışı çalışmasına yönelik usuller hususunda da Başkanlıktan izin alabilir. Bu durumda İşletici Kuruluş, Çevrimdışı Sistem Mimarisini ve Çevrimdışı İş Akışlarını ayrı bir doküman ile Başkanlığa sunacak ve uyumluluk onayı alacaktır.

Sistem kapsamında düzenlenen e-Belgeler, ödeme türü ve detaylarına (ilgili mevzuatlarında belirtilen şekilde) ilişkin bilgileri de içermelidir. Ödeme kredi kartı/banka kartı gibi slip belgesi ile belgelendirilmesi gereken ödeme tipi ile yapılmış ise, bu ödemeye dair slipte yer alan temel ödeme bilgileri de e-Belgenin içerisinde bulunmalıdır.

Bunun yanı sıra, her e-Belge üzerinde işlemi gönderen Güvenli Mali Uygulamanın sürüm numarası da yer almak zorundadır.

İşletici Kuruluş ve bu kuruluşla birlikte çalışacak Özel Entegratör Kuruluşları, Sistem kapsamında düzenlenen e-Belgelerin (Bilgi Fişleri dâhil), değiştirilemeyecek ve silinemeyecek şekilde 507 Sıra No.lu Tebliğde öngörülen sürelerde muhafaza edilmesini taahhüt etmeli ve sağlamalıdır. Bu işlemlerin sorumluluğu, asli olarak İşletici Kuruluşta olmakla birlikte Özel Entegratör Kuruluşların da GİB’e karşı İşletici Kuruluşla birlikte müşterek ve müteselsil sorumluluğu da bulunmaktadır.

 

c. Ödeme Kabul Eden Araç

Ödeme Kabul Eden Araç, bir fiziksel donanım üzerinde çalışan ve Ödeme Aracını kabul ederek ödemeyi gerçekleştirebilen yazılımsal uygulamalardır.

Sistem kapsamında, Ödeme Kabul Eden Araçların yüklenebileceği / kullanılabileceği fiziksel donanımlar aşağıdaki şekilde iki tipte olabilir:

Sertifikalı Fiziki Donanımlar: Bir Ödeme Kabul Eden Araç aracılığıyla, Ödeme Araçlarını kabul etmek ve ödeme işlemlerini, üzerinden güvenli bir şekilde gerçekleştirmek amacıyla özel olarak tasarlanmış, bu nedenle de diğer Regülasyon Otoriteleri tarafından sertifika zorunluluğu getirilen cihazlardır. Bu cihazlara örnek olarak, PCI ve EMV sertifikaları bulunan EFT-POS cihazları gösterilebilir.

Sertifikasız Fiziki Donanımlar: Asıl kullanım amacı Ödeme Aracı kabul etmek olmayan, ancak finansal kuruluşlar tarafından sağlanan yazılımsal uygulamalar ile bu işlemleri de yapabilen, bu işlemleri yapmak için kendisine ait bir sertifikasyon gerekmeyen tablet, cep telefonu gibi cihazlardır.SoftPOS, TaptoPhone, TapOnPhone gibi isimlerle adlandırılan yazılım tabanlı yeni ödeme teknolojilerinin sertifikasız cihazlar üzerinde çalışacağı kabul edilir. Ancak bu ödeme teknolojilerin kullanımında,  Diğer Regülasyon Otoriteleri tarafından belirlenen ödeme sistemleri için gerekli olan izin ve onayların alınması ve Başkanlığa bildirilmesi gerektiği açıktır.  

Ödeme Kabul Eden Araç, Güvenli Mali Uygulama ile aynı fiziki ortamda bulunmak ve buna bağlı olarak çalışmak zorundadır. Ödeme Kabul Eden Araç, Güvenli Mali Uygulamadan bağımsız olarak ve farklı bir fiziki ortamda çalışamaz. Fiziki ortam kavramından; aynı cihaz ya da donanım kastedilmemektedir.

İşletici kuruluş, kendi sorumluluğunda olmak üzere, gerekli güvenlik önlemlerini alınması koşulu ile sahibi olduğu güvenli mali uygulamaya harici Ödeme Kabul Eden Araç bağlantısını kablolu veya kablosuz olarak dilediği protokol ile yapabilir.  

İşletici Kuruluşlar, Sistem kapsamında kullanılabilecek tahsilat yöntemi (ödeme türleri) olarak sadece belli ödeme türleri ile sınırlandırarak değil bu kılavuzun “Ödeme Türleri” başlığı altında tanımlanan diğer ödeme türlerini tanımlamak zorundadır. İşletici Kuruluşların, bu kılavuzun “Ödeme Türleri” başlığı altında tanımlanan nakit dışındaki diğer ödeme türlerinde; uygulamadan yararlanan mükelleflerin ilgili ödeme türünden tahsilat yapmasına ilişkin ilgili üye işyeri anlaşması yapan kuruluşlarla gerekli üye işyeri anlaşmalarının bulunup bulunmadığını göz önünde bulundurarak, bu ödeme tipi için bir başka uygulama kullanılmak ve bu uygulama ile entegrasyon yapılmak zorunlu ise İşletici kuruluş gerekli entegrasyonu sağlamadan söz konusu ödeme/tahsilat yöntemini müşterinin kullanımına açamaz. Bir başka ifade ile İşletici Kuruluşların, bu kılavuzun “Ödeme Türleri” başlığı altında tanımlanan nakit dışındaki diğer ödeme türlerini sunabilmeleri için; sistemden yararlanan mükellefin, üye işyeri anlaşması yapan kuruluşlarla üye işyeri anlaşmasının bulunması ve ayrıca buna ilişkin Ödeme Kabul Eden Araç gerekmesi durumunda, öncelikle ilgili kuruluş ile buna ait entegrasyonun İşletici Kuruluş tarafından sağlanması gerekmektedir. Bu entegrasyon sağlanmadan bu ödeme türleri mükellefe sunulamaz. Mükellefin ilgili Ödeme Kabul Eden Aracı kullanabilmesi için ise, Üye İşyeri Anlaşmasının bulunup bulunmadığı göz önüne alınmak zorundadır.

Ayrıca, Sistemden faydalanmak isteyen ya da faydalanmaya başlayan mükellefler, belli bir Ödeme Kabul Eden Araç kullanmaya zorlanamazlar. Mükellef, sahibi olduğu sertifikalı ya da sertifikasız fiziki donanımı üzerinden kabul edeceği ödeme türlerini özgür iradesi ile seçmekte serbesttir. İşletici kuruluşlar, Sistemlerini kullanmayı talep eden ve hizmet sunumu konusunda anlaştığı mükelleflerin, mülkiyetine sahip olduğu fiziki donanımları üzerine (işletici kuruluş sisteminin çalıştırılmasına teknik bir engeli bulunmayan cihazlar olmalıdır) Güvenli Mali Uygulamalarını kurmak zorundadırlar.

Sertifikalı cihazlar üzerinden çalışan sistemi sunmak isteyen İşletici Kuruluşlar, bu iş için mükellefin sahibi olduğu EFT-POS, mPOS gibi özel bir fiziki donanım üzerinden bu işlemleri yapacağından, ilgili fiziki donanımın diğer Regülasyon Otoritelerinin uygulamaları nedeniyle, PCI Güvenlik Sertifikası ve EMV sertifikasyonlarına sahip olması zorunludur. 

Sistem kapsamında gerçekleştirilen tüm ödeme / tahsilat işlemlerinin ilgili vergisel işlemle (e-Belgeyle veya mevzuata uygun düzenlenmiş Bilgi Fişi ile ) eşlenme zorunluluğu, vergi güvenliği bakımından önemli ve gereklidir. Bu eşleme Güvenli Mali Uygulama aracılığıyla yapılır. İşletici Kuruluş, uçtan uca güvenlikten sorumlu olacağından, ödeme sistemleri ile yapılacak entegrasyonun yazılımsal metodunu seçmekte özgür ve bağımsızdır.

 

ç. Mali Raporlar

Sistemi sunan İşletici Kuruluş, sistemi üzerinden gerçekleştirilen satışlara ait verileri içeren aşağıdaki mali raporları destekleyecek yapıda bir sisteme sahip olmalı ve güvenli mali uygulama aracılığı ile bu raporları uygulamadan yararlanan mükelleflere sunabilmeli ve talep edildiğinde Gelir İdaresi Başkanlığına elektronik ortamda iletebilmelidir.

  1. Günlük Satış Raporu (Belge Türü, Ödeme Türü, KDV oranları itibariyle Toplam Adedi, Toplam Satış Tutarı ile Toplam KDV Tutarları) 
  2. Aylık Satış Raporu (Belge Türü, Ödeme Türü, KDV oranları itibariyle Toplam Adedi, Toplam Satış Tutarı ile Toplam KDV Tutarları) 
  3. İki Tarih Aralığı Satış Raporu (Belge Türü, Ödeme Türü, KDV oranları itibariyle Toplam Adedi, Toplam Satış Tutarı ile Toplam KDV Tutarları) 

   ç. Düzenlenen Belgeler Raporu (Belgenin Türü, Tarihi, Belge No’su, Kime Düzenlendiği, Belge Toplam Tutarı (Vergi Hariç), Oranlar İtibariyle Belgedeki KDV Tutarları ve Toplamı) 

  1. Bilgi Fişleri Raporu (Günlük/Aylık/İki Tarihi Aralığı) (Bilgi Fişi Türü –Yemek Kartı Çeki / Fatura Tahsilatı / Cari Hesap Tahsilatı-, Tarihi, Belge No’su, Tutarı) 
  2. Başkanlıkça belirlenebilecek, mükellefler veya sektörler bazında anlık veya dönemsel verilere ait raporlar

 

d. Güvenli Mali Sertifika ve İmza Yönetimi

İşlem, Güvenli Mali Uygulama, İşletici Kuruluş ve Sertifika Otoritesi süreçleri uçtan uca yürütülürken, içerik/kimlik doğrulaması ve bütünlük kontrollerinin yapılabilmesi için bu başlık altında detayları açıklanan Güvenli Mali Sertifika ve İmza Yönetimi tasarlanmıştır.

Sertifika ve imza kullanımı ile yapılan her bir işlem için; işleme ait bilgiler, işlemin yapıldığı uygulama, uygulamanın ait olduğu İşletici Kuruluş ve uygulamayı kullanan mükellef bilgileri ile mühürlenmiş olacaktır.

Sertifika ve imza altyapısı temel olarak; kimlik doğrulama, işlem bilgileri doğrulama, mükellef doğrulama, Güvenli Mali Uygulama doğrulama, İşletici Kuruluş doğrulama ve uygulama lisansının geçerlilik süresini denetleme amacıyla kullanılacaktır. 

Genel sertifika ve imza süreç akışı aşağıdaki şekildedir:

 

İşletici Kuruluş yapacağı işlemleri imzalamak amacı ile kullanılmak üzere, Kamu SM ‘den en fazla 3 yıl süreli X.509 standardında bir son kullanıcı sertifikası tedarik edecektir. Bu sertifikanın ismi İşletici Kuruluş Güvenli Mali Sertifikası olarak adlandırılacaktır. İşletici Kuruluş Güvenli Mali Sertifikası içerisinde aşağıdaki veriler bulunacaktır. 

İşletici Kuruluş sertifika talep dosyasını Kamu SM’ye PKSCS#10 standardında elektronik olarak gönderecektir. İşletici Kuruluş sertifika talep dosyasını oluştururken “Subject” alanı altına aşağıdaki değerleri set edilecektir:

Common Name alanına, İşletici Kuruluş Adı

Serial Number alanına, İşletici Kuruluş Vergi Kimlik Numarası

Sertifika alanlarıyla ilgili düzenlemeleri yapmaya yetkili kuruluş Kamu SM’dir.

 

 İşletici Kuruluş Dijital İşlem İmzası:

İşletici Kuruluşlar kendi yönettikleri platformlarda, verilerin uç noktadan merkezi sistemlerine doğrulanarak, güvenli ve bütünlüğü korunarak ulaşmasından sorumludurlar. İşletici Kuruluş kendi sertifikasına(İşletici Kuruluş Güvenli Mali Sertifikası) ait özel anahtarı(private) ile yaptığı her bir işlemi kendi sunucularında imzalamak zorundadır. Bu imzanın ismi, İşletici Kuruluş Dijital İşlem İmzası olarak adlandırılacaktır. İşletici Kuruluş Dijital İşlem İmzası içeriği başkanlık tarafından belirlenecek olup, aşağıdaki veriler bulunacaktır:

o Versiyon

o İmza Algoritması

o Güvenli İmza Özet Algoritması

o İşletici Kuruluş Vergi Kimlik Numarası

o Mükellef Vergi Kimlik Numarası/TCKN

o Terminal Numarası

o Uygulama Versiyon Numarası

o Uygulama Tekil Numarası

o e-Belge Numarası

o Özel Entegratör Numarası

o Satış Sipariş Numarası (Satış Uygulamasından Alınan)

o Ödeme Provizyon Kodu (Bankacılık Kanalları İçin)

o İşlem Numarası

o İşlem Tutarı

o İşlem Zamanı

o Rasgele Sayı

o Sertifika Özet Değeri

o İmza Özet Değeri

İşletici Kuruluş tarafından yapılan her bir işlem için yukarıdaki bilgileri de ihtiva eden bir işlem paketi (xml) oluşturulacak olup, asgari XADES-BES standardı kullanılarak imzalanacaktır. İmzalama için “Enveloped“ tekniği kullanılmalıdır. “Enveloping” ve “Detached” teknikleri kabul edilmeyecektir. 

Gün içinde tekil bazda oluşturulan ve XADES-BES standardı ile imzalanmış bu işlem paketleri, gün sonunda yine bir pakete (xml) eklenmeli ve bu paket (tüm güne ait XADES-BES imzalı işlem paketlerini ihtiva eder) XADES-A standardı kullanılarak zaman damgalı olarak imzalanmalıdır.  Böylelikle imza için kullanılan elektronik imza içerisindeki sertifikaların ve iptal bilgilerinin süreleri dolsa dahi işlemlerin içinde bulunduğu paketin imza doğrulaması yapılabilecektir.

Güvenli Mali Sertifika Temin ve Kullanım Süreci aşağıdaki şekilde yürütülür:

İşletici Kuruluş, Başkanlıktan gerekli izni alır.

İşletici Kuruluş, Ortak Kriterler EAL4+ Sertifikalı HSM Cihazları kullanarak anahtar çifti üretir. Bu anahtar çiftinin Private olan eşleniği HSM cihazından çıkarılamaz özellikte tanımlanmalıdır. Başkanlık veya Tübitak Kamu SM tarafından yayınlanacak formatta sertifika talep dosyası üretir ve elektronik ortamda Tübitak Kamu SM’ ye iletir.

Tübitak Kamu SM; Başkanlık tarafından İşletici Kuruluş’un izin almış olması şartı ile,

İşletici Kuruluş Güvenli Mali Sertifikası’nı üretir ve İşletici Kuruluşa elektronik ortamda iletir.

İşletici Kuruluş, Sertifikayı doğrular ve HSM Cihazlarına bu sertifikayı yükler.

İşletici Kuruluş, merkezi sisteminde kendisine ait Private anahtar ile her bir işlemin HSM üzerinde imzalanmasını sağlar.

Yapılan her bir işleme ait imza, İşlem Verileri ile birlikte İşletici kuruluş merkezi sisteminde saklanacaktır ve istenildiğinde Başkanlığa iletilecektir.

Sertifika ve imza yönetimi teknik olarak aşağıdaki şekilde açıklanmıştır:

KSMpub : Kamu SM otorite public anahtarı.

KSMpri   : Kamu SM otorite private anahtarı.

 Asimetrik Anahtar Çiftleri: Algoritma ve anahtar boyutları aşağıdaki şekilde olmalıdır:

o RSA için;

 2048 bit ve üzeri anahtar boyutu, exponent olarak 65537(0x10001) kullanılacaktır.

 o ECC için; 

256 bit, NIST-secp256r1 curve

384 bit, NIST-secp384r1 curve

 Özet Algoritması olarak kullanılabilecek algoritmalar: SHA2-256, SHA2-384, SHA2-

512, SHA3-256, SHA3-384, SHA3-512

İşletici Kuruluş; 

RSA kullanması durumunda, Özet algoritması olarak SHA2-256 veya SHA2-512 kullanmalıdır.

ECC kullanması durumunda, Özet algoritması olarak; o ECC 256 için, SHA2-256 veya SHA3-256 o ECC 384 için, SHA2-384 veya SHA3-384 

kullanmalıdır.  

İKpub     : İşletici Kuruluş public anahtarı.

İKpri       : İşletici Kuruluş private anahtarı.  

İKcert      : İşletici Kuruluş Setifikası

TXNsign: İşletici Kuruluş Güvenli Mali Uygulama İşlem İmzası  

 

İşlem Adımları:

Kamu SM; otorite anahtar çiftini HSM cihazında üretecektir.

KSMpub

KSMpri

İşletici Kuruluş; kendisine ait anahtar çiftini HSM cihazında üretecektir.

İKpub

İKpri 

İşletici Kuruluş; sertifika talep dosyasını Kamu SM ile paylaşacaktır.

Kamu SM; Teknik olarak, sertifika dosyasında yer alan İKcertInput verilerini KSMpri ile Sign edecek(İKcert) ve oluşturduğu sertifikayı(İKcert) İşletici

Kuruluş ile paylaşacaktır.

İşletici Kuruluş; Kamu SM’den aldığı sertifikasını(İKcert) kendi sisteminde tanımlayacaktır. 

İşletici Kuruluş; Kendi sisteminde yapılan her bir işlemi İşletici Kuruluş’a ait özel anahtar ile(İkpri ) imzalayacaktır. Teknik olarak, TXNsingInput verilerini İKpri ile Sign edecek(TXNsign) ve oluşturduğu dijital imzalı veriyi(TXNsign) merkezi sisteminde kaydedecektir. (Talep edildiğinde Başkanlığa gönderilecek veri, 

 

Böylece; yapılan her bir işlem için;

İşletici Kuruluş’a ait bir Güvenli Mali Uygulama tarafından,

İşletici Kuruluş’a ait bir terminalde,  

İşletici Kuruluş’tan hizmet alan mükellefte,

İlgili İşlem Zamanında,  

İlgili İşlem Tutarında,   ...

Kamu SM’ tarafından sertifikalanmış bir İşletici Kuruluş’a,

ait olduğu kayıt altına alınmış olacaktır. Bu kayıt, hem İşletici Kuruluşu hem de mükellefi korumak amaçlıdır.

Mükellefin birden fazla İşletici Kuruluş ile çalışmayı tercih ettiği durumlarda bir cihaz üzerine birden fazla Güvenli Mali Uygulama kurulabilir. Bu durumda her bir uygulamanın kendine özel ayrı bir sertifikası olması gerekmektedir.

Güvenli Mali Sertifikaların, mükellefin Sistemi kullanacağı ve aynı zamanda Güvenli Mali Uygulama ile Ödeme Kabul eden Aracın bulunacağı fiziki donanım üzerinde olması ve doğrulanması zorunluluğu vardır. Satış Uygulamasının harici ya da dâhili olması, bu zorunluluğu değiştirmez.

İşletici Kuruluş tarafından sunulan Sistem, özel bir uygulama olmadan sadece standart web tarayıcılar üzerinden (Internet Explorer, Chrome, Firefox vb.) erişilebilen bir altyapı üzerinden çalışıyor ise, oturum açma ve kimlik doğrulama koşullarını sağlaması durumda, Güvenli Mali Sertifika, Güvenli Mali Uygulama ve Ödeme Kabul Eden Aracın da kendisine ait olan Bilgi İşlem Merkezi’nde çalışacağı tabiidir. Bu durumda, söz konusu bilgi işlem merkezi servislerinin aylık %99,75 kullanılabilirlik ile hizmet sunmasını temin edecek şekilde mimari tasarımının ve testlerinin yapıldığını taahhüt eder. Bu kapsamda sunulacak taahhüt ve raporlamalar asgari olarak Uptime Institute Tier 2 standartlarını sağlamalı/yerine getirmelidir. Web sunucularının Türkiye Cumhuriyeti sınırları içerisinde olması gerektiği tabidir.

Elektronik ortamda sertifikaları teslim alacak olan İşletici Kuruluşlar, söz konusu sertifikaların güvenli olarak saklanması, HSM cihazlarına yüklenmesi, gerekmesi durumunda imha edilmesi gibi işlemleri güvenli bir şekilde yapabilmek için gerekli altyapıyı kurmak zorundadır.

 

e. Yazılım Güvenliği

İşletici Kuruluş, sunmuş olduğu Sistem içerisinde var olan uygulamalar ve bunların güvenli mali uygulama ile entegrasyonundan sorumludur. İşletici kuruluşun sunmuş olduğu uygulamalar vasıtasıyla üretilen ve iletilen verilerin güvenliği önemlidir.   

Bu kapsamda, İşletici Kuruluş sunmuş olduğu sisteme ait Güvenli Mali Uygulama, Ödeme

Kabul Eden Araç ve e-Belge Entegrasyon yazılımları için;

Güvenli şekilde yüklenme yöntemini sağlanmasından, 

Bu yazılımların arşivlenmesinden,

Yazılım sürümü takibinden,

Yazılım sürümünü tekil olarak ifade etmek üzere yazılım özet bilgisi değeri (HASH) oluşturmaktan ve saklamaktan,

Yazılım sürüm güncellemesinin amacına ve yapılan değişikliklere dair bilgileri saklamaktan,

Yazılım sürümünü onaylayan yetkili personel bilgisini saklamaktan,

Talep edildiği anda ilgili yazılımları (geçmiş sürümleri de dahil olmak üzere) denetime açmak üzere güvenli bir merkezde saklamaktan sorumludurlar. 

Başkanlık, gerek görmesi halinde yazılımların güncel ve geçmiş tüm sürümlerine ait kaynak kodlarını yerinde inceleyebilir. 

Bu maddede sayılan şartları karşılamayan ve Sistem kapsamındaki yazılımın vergi ziyaına yol açılacak şekilde kullandırıldığı tespit edilen İşletici Kuruluşlar hakkında Vergi Usul Kanununda yer alan cezai hükümler uygulanabileceği gibi yapılan yazılı uyarıya rağmen gerekli önlemleri almayan işletici kuruluşların Bakanlıkça verilen faaliyet izinleri belli bir süreyle durdurulabileceği gibi iptal de edilebilir.

  

f. Erişim Kontrolü

Sisteminin temel araçları olan Güvenli Mali Uygulama, Ödeme Kabul Araç ve e-Belge

Entegrasyonuna ait olan yazılımların yüklenmesini, güncellenmesini, anahtar yüklemelerini, gerekmesi durumunda sistemin yerinde kurulumunu, bakım ve onarım gibi hizmetleri İşletici Kuruluş kendisi sağlayabileceği gibi asli sorumluluk İşletici Kuruluş’ta olmak kaydı ile Yetkili Servisleri üzerinden de sağlayabilir.

Sistem ile ilgili teknik destek vermek için sadece yetkili kişilerin erişimi olmalı ve bu kişilerin yaptığı tüm iş ve işlemlerin log kaydı tutulmalıdır. Sistemde hem mali hem de finansal işlemler söz konusu olduğu için, İşletici Kuruluşların farklı yetkilendirme tipleri ile erişim yetkileri ve alanları tanımlamaları mümkündür. Ancak bu durum, İşletici Kuruluş’un sistemin uçtan uca güvenliğine ilişkin asli sorumluluğunu ortadan kaldırmaz. 

Kullanım esnasında, Sistemin ana yazılım bileşenleri olan Güvenli Mali Uygulama, Ödeme Kabul Eden Araç ve Özel Entegratör Kuruluş ile olan entegrasyon üzerinde yapılacak manipülasyonlar, tahsilat ile düzenlenen e-Belge arasındaki uyumsuzluklar, usulsüz işlemler için kullanıma uygun çalışma ortamı gibi durumlardan İşletici Kuruluş aslen sorumludur. 

Sistemin üzerinde çalışacağı cihazın kendi özel işletim sistemine ait otomatik bir saat ayarı yok ise, her açılışta NTP ile saatlerinin doğruluğunu kontrol etmesi gerekir.

 

g. Kimlik Doğrulama

Sistemden yararlanmak isteyen mükelleflerin bilgilerinin doğruluğundan, bu bilgilerin sisteme doğru kaydedilmesinden ve Başkanlığa bildirilmesinden İşletici Kuruluşlar sorumludur. 

İşletici kuruluşlar, ister sertifikalı ister sertifikasız cihazlar üzerinden çalışan sistemin lisans ve mükellef eşlemesini yaptığı cihazların, marka, model ve seri numarası kaydının tutulmasından sorumludur. Herhangi bir Uygulamanın kayıtlı olmadığı bir cihaz üzerinde Sistemin çalışmaması gerektiğinden, İşletici Kuruluş buna yönelik tedbirleri almak ve uygulamak zorundadır. 

İşletici Kuruluş, bu bilgileri kaydedecek bir altyapı kurmakla yükümlüdür. Başkanlıkça talep edilmesi halinde işletici kuruluş tarafından Başkanlığa iletilmesi zorunludur.

 

ğ. Oturum Açma ve Oturum Kimliği Doğrulama

Tablet, cep telefonu gibi mobil Sertifikasız Cihazlar Üzerinde Çalışan Sistemlerini sunan İşletici Kuruluşlar, sistemin kusursuz ve manipülasyona yol açmayacak şekilde çalışmasından sorumludurlar.

Kötü niyetli kullanımlara engel olmak ve işlemi gerçekleştiren kişileri kayıt altına almak amacıyla, sertifikasız cihazlar üzerinde çalışacak olan Güvenli Mali Uygulamanın ilgili mükellefini kullanımına sunulduğunun doğrulanması amacıyla;  mobil imza, tek kullanımlık şifre (OTP) ya da İşletici Kuruluşun belirlediği güvenli doğrulama metodu gibi güvenlik yöntemi kullanım zorunluluğu vardır. Bu sayede uygulamanın ilgili mükellefe yüklenmiş ve işlemi yapan mükellefin işlemi ilişkin rızasının olduğu kayıt altına alınmış olacaktır.

İşletici Kuruluş, sadece Web tarayıcısı üzerinden erişilebilen bir Sistem sunuyor ise, İşletici Kuruluş Sisteme giriş yöntemini kendi sorumluluğunda olmak koşuluyla serbestçe belirleyebilir. Bu durumda, bir oturum açıldıktan sonra işlem yapılmama süresi 180 saniyeyi geçemez. Bu süre dolduktan sonra oturum otomatik olarak kapatılmak zorundadır. 

 

h. Uçtan Uca Güvenlik

İşletici Kuruluş sistemin uçtan uca güvenli şekilde çalışmasından aslen sorumludur. Bu sorumluluk kapsamında işlemlerin vergi kaybı ve kaçağına sebep vermeyecek ve güvenli şekilde yapıldığını ve sürdürüleceğini taahhüt eder.

İşletici Kuruluş, satış işlemenin başlayıp, ödemenin alınarak, mükellefiyet ve işlemin türüne uygun e-Belgenin düzenlenerek satışın sonlandırılmasından ve düzenlenen e-Belgenin Özel Entegratör Kuruluşa iletilmesine kadar geçen süreçte uçtan uca güvenli bir zincir ve iletim sistemi kurmakla mükelleftir.

İşletici kuruluş, uçtan uca kurulan bu güvenli zincir ile hassas mali verilerin kaynağının, doğruluğunun, değişmezliğinin ve bütünlüğünün kontrolünü ve bu arada bir manipülatif işlemin gerçekleştirilmemesini sağlamaktan sorumludur. 

İşletici Kuruluş, uçtan uca güvenliği taahhüt ederken kullanacağı yazılımsal metotları seçmekte özgür ve bağımsızdır.

 

ı. Olay Kayıt Özelliği

Usulsüzlük iddiası olması durumunda gerekli kontrollerin yapılabilmesi için, bu konuda sorumluluğu bulunan İşletici Kuruluşun bazı kritik olay kayıtlarını sisteminde saklaması ve kamu otoritelerinin talep etmesi halinde de sunması zorunludur. Bu nedenle, aşağıda listelenmiş olan kritik olay kayıtları İşletici Kuruluş tarafından ilgili kanun ve tebliğlerde belirtilen süre boyunca saklanmalıdır:

İlgili mali işleme ait Güvenli Mali Uygulama sürüm numarası

İlgili mali işlem sonunda üretilen e-Belge tipi, tarih ve numarası

İlgili mali işlemin Özel Entegratör Kuruluşa iletim zamanı

İlgili mali işlem için Özel Entegratörden dönen cevap zamanı

Harici uygulamalar ile entegrasyon mevcut ise bağlantının yapıldığı ve kesildiği / koptuğu zaman bilgileri

Mükellefin kullandığı Güvenli Mali Uygulamanın güncelleme bilgileri

Mükellefin kullandığı, Ödeme Kabul Aracının güncelleme bilgileri 

 

i. PCI Güvenlik Sertifikası

Sertifikasız cihazlar üzerinde çalışan, Ödeme Kabul Araçlar kısıtlı işlem yapabilme hakları olan araçlardır. Buna mukabil tablet, cep telefonu şeklinde olabilen bu cihazların PCI Güvenlik Sertifikası zorunluluğu yoktur. Ancak sertifikasız cihazlar üzerinde ödeme teknolojilerin kullanımında,  Diğer Regülasyon Otoriteleri tarafından belirlenen ödeme sistemleri için gerekli olan izin ve onayların alınması ve Başkanlığa sunulması gerektiği açıktır. 

Ticari hayatın devamını sağlamak amacıyla, ticari işletmelerin çok büyük bir kısmı için sertifikalı cihaz kullanma zorunluluğu doğacağı açıktır. Sertifikalı Cihazlar için diğer

Regülasyon Otoritelerinin koymuş olduğu kurallar gereğince, PCI Güvenlik Sertifikası bir zorunluluktur.

 

j. EMV Sertifikaları

Sertifikalı Cihazlar üzerinden çalışan Sisteminin çalışacağı fiziki donanımların, diğer Regülasyon Otoritelerinin koymuş olduğu kurallar gereğince gerekli EMV sertifikalarına sahip olması gerekmektedir.

 

k. Satış Yazılımı ve Harici Satış Uygulamaları ile Entegrasyonu

Sistem, kendi bünyesinde, mal ve hizmet satışı yapan mükelleflerin satış işlemini gerçekleştiren (mal ve hizmetlerin tanımlanması, satışa başlama, müşteri seçimi, satılan mal ve hizmet seçimi, belgede yer alan tutarların hesaplaması ve işlem sonucunda e-Belge düzenlenmesi için gerekli olan bilgileri temin eden) temel bir satış uygulama yazılımını barındırmalıdır.

İster sertifikalı ister sertifikasız cihazlar üzerinden çalışan Sistem olsun, her iki tipteki sistemde de İşletici Kuruluşlar, harici satış yazılımları, perakende otomasyon yazılımları, stok ve muhasebe programları gibi uygulamalarla entegrasyon da yapabilirler.

Burada önemli olan nokta, bu entegrasyonun Güvenli Mali Uygulama aracılığıyla yapılmasının ve harici / dâhili satış uygulamaları üzerinden (satışa başlama işleminin güvenli mali uygulama tarafına yapılan başlangıç bildirimi ile tetiklendiği harici satış uygulama yazılımları üzerinden) tetiklenecek işlemlerin Güvenli Mali Uygulama aracılığıyla başlatılması ve sonlanması kuralına riayet edilmesinin zorunlu olmasıdır. Bunun dışında, sistemin uçtan uca güvenliğini taahhüt eden İşletici Kuruluş entegrasyonun hangi yazılımsal metotlarla yapılacağı konusunda özgür ve bağımsızdır. Bu tip harici uygulamalar ile yapılan entegrasyonlar sonucu gerçekleşen iş ve işlemlerden de İşletici Kuruluş aslen sorumludur.  

 

4. Sistemin Genel Güvenlik Gereksinimleri

Güvenli ve güvenilir mali/satış/finansal işlemlerin yapılmasını sağlamak için, Hassas bilgileri korumak için, “rooted” veya “jailbroken” cihazlara ilişkin tehditleri, kötü niyetli veya yetkisiz kullanıcılardan gelen tehditleri ve aynı ortamda çalışan (ve paylaşılan kaynaklara erişimi olan) diğer uygulamalardan gelen tehditleri önlemek için, sistemde kullanılan veri ögelerinin bütünlüğünü korumak için, önleyici ve koruyucu mekanizmalar uygulanmalı/geliştirilmelidir. 

Bu başlık altındaki maddeler, güvenlik gereksinimleri ile ilgili yalnızca temel prensipleri içermektedir. Bu temel prensiplere ait detaylar; Ortak Kriterler, OWASP, PCI, EMVCo vb. kuruluşlar tarafından yayınlanan standart dokümanlarında da mevcuttur. Başkanlık ve

Uyumluluk Testi Yapmaya Yetkili Kuruluşlar, değişen/güncellenen güvenlik gereksinimlerine istinaden ek güvenlik testleri uygulayabilir.

Bu madde kapsamında Güvenli Mali Uygulamanın sağlaması gereken uç nokta cihaz güvenlik önlemlerinin uygulanabilirlik durumu Web tabanlı uygulamalar için test otoritesi tarafından değerlendirilecektir. 

Uç noktada kullanılan cihazların güvenlik gereksinimi açısından cihaz üreticisi tarafından sağlanan güvenlik önlemleri, sertifikaları, ve/veya çözümleri de İşletici Kuruluş tarafından test otoritesine sunulabilir.

a) Bir Bütün Olarak Sistemi Korumaya Yönelik Mekanizmalar:

İşletici Kuruluş, uygulamalarına yönelik güvenli kullanım kılavuzu hazırlamalı ve bu kılavuzu kullanıcılarının erişimine açmalıdır.

Güvenli Mali Uygulama yaşam döngüsü içerisinde; geliştirme ortam güvenliği, kaynak kod güvenliği, versiyon yönetimi, değişiklik yönetimi, erişim kontrolü için gerekli prosedürler tanımlanmalı ve uygulanmalıdır.

Güvenli Mali Uygulama konfigürasyon yönetimi kapsamında olası uygulama hataları ve güvenlik açıklarının İşletici Kuruluşa bildirilebileceği bir arayüz (portal, e-posta adresi, vb.) sunulmalıdır. İşletici Kuruluş, bu bildirimleri değişiklik yönetimi prosedürleri kapsamında yönetir.

b) Uygulama Bütünlüğünü Korumaya Yönelik Mekanizmalar:

Güvenli Mali Uygulama; güvenilir bir uygulama mağazasından yüklenip yüklenmediğini kontrol eder. Bu mağaza İşletici kuruluşun kendi uygulama yönetim sistemi olabileceği gibi, Google Play, iTunes ve Microsoft App store, vb. de olabilir. Kontrollerin sonuçlarını Merkezi Sistemine iletir.

Güvenli Mali Uygulama; Aşağıdaki cihaz güvenlik kontrollerini yapar kontrollerin sonuçlarını Merkezi Sistemine iletir.

Cihaz “rooted” veya “jailbroken” yapılmış mı?

Uygulama emülatör, sanal makina veya simülatör ortamda çalışıyor mu?  Bir hata ayıklayıcı(debugger) ekli mi?

Uygulama kurcalaması yapılmış mı?

Güvenli Mali Uygulama; Çalışma zamanı bütünlüğü kontrolleri yapmalıdır. (run-time integrity checks) Fonksiyonal değişiklik tespit etmesi halinde kontrollerin sonuçlarını Merkezi Sistemine iletir.

Güvenli Mali Uygulama; uygulama dosyaları tersine mühendislikten korunmalıdır.

Güvenli Mali Uygulama; hassas ve referans olarak kullanılan verileri yetkisiz değişiklikleri önlemek için uygulama kodu içerisinde güvenli bir şekilde saklamalıdır.

c) Hassas Verileri Korumaya Yönelik Mekanizmalar:

Güvenli Mali Uygulama tarafından işlenen veriler doğası gereği oldukça hassastır ve yetkisiz erişimlerden korunmalıdır. Bu bilgiler arasında mali veriler, finansal veriler, kişisel veriler, kimlik doğrulama verileri, şifreleme anahtarları ve tüketici cihazı bilgileri vb. veriler yer alabilir.

Güvenli Mali Uygulama; Kişisel Veri, Tutar, Mali Veri, TCKN vb. hassas verinin alınma anı ile ilgili güvenlik önlemlerini sağlamalıdır. Bu her veri için ayrı bir hassasiyet içerebilir. (Örn: ödeme bilgisinin satış uygulaması, finansal uygulama ve mali uygulama arasındaki güvenli girdi oluşturma yöntemi)

Güvenli Mali Uygulama; hassas veriler kullanımı sonrasında güvenli bir şekilde silmelidir. İşlem sırasındaki izinler dışında asla uygulama belleğinde tutmamalıdır.

Güvenli Mali Uygulama; hassas verileri sistemin bir parçası olanlar(özel entegratör, finans kuruluşu vb.) dışında hiç bir şekilde üçüncü parti sistem ve yazılımlar ile paylaşmamalıdır.

Güvenli Mali Uygulama; hassas verileri kaynak koduna gömemez.

Güvenli Mali Uygulama; diğer uygulama ve kullanıcıların erişimini engellemek amacıyla çalışma zamanı veri koruması (run-time data protection) yapmalıdır.

Güvenli Mali Uygulama tarafından oluşturulan (hem native/yerel hem de web/HTML modlarında) kullanıcı arayüzü (UI), hassas bilgilere güvenli mali uygulama dışındaki yetkisiz kişi, işlem ve uygulamaların erişilemeyeceği şekilde izolasyon sağlar ve verileri güvence altına alır.  (UI Protection)

Güvenli Mali Uygulama, Web tabanlı bir arayüze sahipse, HTML üzerinden yapılan tüm yetkisiz ve harici URL isteklerini durdurmalıdır. Bu isteklerin işletim sistemine veya internete iletilmesini engellemelidir.

Güvenli Mali Uygulama, Web tabanlı bir arayüze sahipse, kendisine ait olmayan herhangi bir JavaScript kodunun başka bir kişi/uygulama/işlem tarafından enjeksiyonunu ve yürütülmesini önlemelidir.

ç) Şifreleme Mekanizmaları:

Temel güvenlik gereksinimi olarak, kriptografik algoritmaların ve uygun anahtar yönetim tekniklerinin doğru şekilde uygulanması gereklidir. Bu uygulama, bilgilerin bütünlüğünü ve gizliliğini sağlamak için kritik öneme sahiptir. Yalnızca onaylı ve doğruluğu kanıtlanmış ve başkanlık tarafından tanınan algoritmalar ve anahtar yönetimi teknikleri kullanılmalıdır. Özel algoritmalar kullanılmamalıdır.

Yalnızca onaylı ve doğruluğu kanıtlanmış ve başkanlık tarafından tanınan algoritmalar kullanılmalıdır. Örneğin: Tübitak, NIST, ANSI, ISO, EMVCo, vb.  

Güvenli Mali Uygulama tarafından kullanılan tüm rastgele sayılar, yalnızca onaylı (Tübitak, Ortak Kriterler, NIST vb.) rastgele sayı üretme (RNG) algoritmaları veya kütüphaneleri kullanılarak üretilmelidir. 

Merkezi Sistemde Seritifka yönetimine ilişkin işlemler için ve veritabanında saklanan hassas veriler için donanımsal şifreleme yöntemleri kullanılmalıdır. Bunun için Ortak Kriterler EAL4+ Sertifikalı HSM cihazları kullanılmalıdır.

Tüm simetrik ve asimetrik kök/ana anahtarlar Doğrudan İşletici Kuruluşu temsil ettiği için güvenli bir şekilde HSM cihazları içerisinde saklanmalıdır.

Uç nokta yazılımlarında şifreleme ve anahtar yönetimi için SAM, Secure Element vb.

donanımsal güvenlik ortamları varsa bu alanlar kullanılabilir. Mobil Telefon, tablet, PC vb. uç noktalar için donanımsal bir güvenlik ortamı yoksa yazılımsal kütüphane ve ortamlar ile belirtilen tüm güvenlik adımları sağlanmalıdır.

d) Güvenli İletişim Mekanizmaları:

Güvenli Mali Uygulamaya ait tüm bileşenler güvenli iletişim kanalları üzerinden haberleşmelidir.

Güvenli Mali Uygulama uç nokta yazılımları ve merkezi sistemi haberleşirken tcp, ssl, tls vb protokollerin içinde akan veriler için şifreli olarak özel bir kanal oluşturmalıdır ve bu kanal içerisinden giden/gelen veriler özel anahtarlarla şifrelenmelidir.

Güvenli Mali Uygulama ve özel entegratör sistemleri merkezi sistemleri üzerinden iletişim kurmalıdır. Bu sayede, merkezi sistemler arasında IP tanımı yapılmalı ve güvenli bir kanal üzerinden  veri iletişimi sağlanmalıdır. (Host-To-Host)

Harici satış uygulamaları ile entegrasyon uç nokta üzerinde veya merkezi sistemler arasında olabilir. Verinin uygulamalar arasında şifreli aktarılması ve güvenli kanal oluşturulması gerekmektedir.

e) Uç Nokta Güvenliği:

Sisteme ait uç nokta güvenliği ile ilgili; gerekli dokümanlar ve akış diagramları Başkanlığa ve test otoritesine sunulmalıdır.

Sistem bir bütün olarak; uç noktada çalışan (web tabanlı olsun veya olmasın) her bir uygulama için, uygulamanın çalıştığı ortama ait fingerprint verilerini kullanarak, mali uygulamanın uç noktada güvenli bir şekilde çalışmasını ve uç nokta doğrulamasını sağlayabiliyor olmalıdır.

Uç nokta ile merkezi sistemin SSL iletişiminde en az TLS 1.2 vb. güvenlik seviyesindeki mekanizmalar kullanılmalıdır. 

Uç nokta ile merkezi sistemin iletişiminde TLS 1.2 vb. iletişim mekanizmaları içerisinde akan verinin şifrelenmesi için işleme özel türetilmiş minimum 128 bit ve üzeri AES bir anahtar kullanılmalıdır.

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalar bir veri tutuyorsa, bu verilerin saklanmasında anahtar kullanılmalıdır.

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda; kullanıcı adı, şifre, anahtar, kişisel veriler, mali veriler vb. hassas bilgiler saklanıyorsa veya işleniyorsa bu veriler güvenli bir şekilde saklanmalıdır/korunmalıdır.

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, Root Detection yapılmalıdır. (Uygulamanın rootlanmış cihazlarda çalışması engellenmelidir.)

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, Device Identification yapılmalıdır. (uygulama kurulduğu cihazı tanımlayabilecek veriler sağlamalıdır)

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, Geolocation yapılmalıdır. (Başarılı kurulmuş bir uygulama gibi davranıp farklı lokasyondan işlem yapmasına müsade etmemeli)

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, Device Binding yapılmalıdır. (Uygulaması ile kurulduğu cihazı birbirine bağlayan eşsiz bir imza üretmeli ve yapılan bir işlemin ilgili cihaza kurulu uygulamadan gerçekleştirildiğini garanti etmelidir)

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda,  Yazılımsal veya Donanımsal Güvenli Alan/Cryptography Storage/Secure Storage yapılmalıdır. Uygulama üzerinde saklanması gereken hassas verileri güvenli şifreleme algoritmaları ile şifreli ve sadece uygulamanın güvenli bir şekilde okuyabileceği ve başka hiç şekilde ulaşılamayan bir alt yapı ile saklar) (Uygulama güvenli sanal veri deposu alanı oluşturabilecek, uygulamaya ait gizli özel anahtarı ve sertifikayı (X509) burada saklayacaktır. Uygulama, uygulamaya ait özel anahtarı güvenlik sunucusu ile ilişkilendirecek, hiçbir şekilde açık olarak veya çevrim dışı şifreleme yöntemler ile cihaz üzerinde depolamayacaktır.)

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda,  Secure Channel kurulmalıdır. (Uygulamanın sunucu ile olan iletişimini gizlilik ve bütünlük açısından gerekli asimetrik ve simetrik şifreleme algoritmaları ile koruyacağı güvenli bir kanal üzerinden sağlar )

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, Anti-Debugging yapılmalıdır. (uygulamasının herhangi bir debugger ile analiz edilmesini engellemelidir)

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, Detect Emulator yapılmalıdır. (uygulamasının herhangi bir emulator üzerinde çalışmasını engellemelidir)

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, Detect-Hooking yapılmalıdır. (uygulamasına ait fonksiyonlarının harici bir fonksiyonla çalışma zamanında değiştirilmesini engeller)

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, Detect Repackaging yapılmalıdır. (uygulamasının kodlarınının çözülüp tekrar paketlenmesini tespit edip çalışmasını engeller)

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, Secure RunTime Memory yapılmalıdır. (uygulamasının çalışma zamanında kullandığı hafıza alanından hassas verilerin alınmasını engelleyecek şifreleme, karıştırma ve diğer sisteme bağlı tedbirleri içerir)

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, Runtime CRC Check yapılmalıdır. (Uygulama, uygulama çalışma zamanında yüklenen uygulama kodunun değişmesini kontrol edip çalışmasını durduracak ve bu durumu uzak sunucuya raporlayacaktır)

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, gerekli durumlarda ve cihaz izin veriyorsa Soft OTP yapılmalıdır. (uygulama ihtiyaç duyduğu işlemlerde Soft OTP doğrulamasını yapabilmelidir)

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, gerekli durumlarda ve cihaz izin veriyorsa Push Notification yapılmalıdır. (uygulama ihtiyaç duyduğu işlemlerde Push Notification doğrulaması yapabilmelidir)

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, Applicationbinding yapılmalıdır. (Uygulama içerisindeki fonksiyonlar dışarıdan izinsiz bir şekilde tetiklenmemelidir. Fonksiyonlar kendi uygulamasının dışında bir uygulama ile çalışmamalıdır.)

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, Code Obfuscation and Diversification / Code Lifting yapılmalıdır.(Uygulama kodları tersine mühendislik ve statik kod analizleri ile açığa çıkmamalıdır)

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, SSL-pining yapılmalıdır. (Uygulamasının sunucu ile olan iletişiminde kendi özel sertifikalarını kullanacak ve bunların güvenliğini ve bütünlüğünü garanti edecektir. Uygulama, kendi şifreli sertifika deposunu kullanacak, işletim sistemine ait sertifika deposunu kullanmayacak ve tanımlı kök sertifika otoritelerine güvenmeyecektir )

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, Transaction Data Signing yapılmalıdır. (Uygulama, işlemlerin takibi için dijital olarak her işlemi imzalayacak ve bu imzayı sunucuda saklayacaktır)

f) Genel Gereksinimler:

İşlemler; satış, ödeme, e-Belge oluşturma süreçleri bütüncül olarak yönetilmelidir.

 Satış İşlemleri (Satışın başarılı olabilmesi için her üç işlemin de başarılı olduğu)  İptal İşlemleri (İptal işleminin her üç işlem için de ortak yapıldığı; satış iptal, ödeme iptal, e-Belge iptal.)  İade İşlemleri (İade işleminin her üç işlem için de ortak yapıldığı; satış iade, ödeme iade, e-Belge iptal.)

Veri bütünlüğü uç noktadan merkezi sisteme, oradan da 3rd servislere kadar, uçtan uca ve güvenli bir şekilde sağlanmalıdır. (Uç noktadaki verilerin, (örneğin tutar verisi) merkezi sistemde ve verinin aktığı her yerde aynı değerde olması kontrolü sağlanmalıdır.)

TCKN, email, telefon numarası, adres, kart numarası gibi hassas veriler saklandığı noktalarda anahtar kullanılarak şifreli bir şekilde güvenli ortamlarda saklanmalıdır.

TCKN, email, telefon numarası, adres, kart numarası gibi hassas verilerin yetki bazlı olarak erişilebildiği, erişen sistem kullanıcının iz takibinin yapılabildiği bir altyapı kurgulanmalıdır.

TCKN, email, telefon numarası, adres, kart numarası gibi hassas verilerin raporlara veya yetki bazlı olmayan erişimlere açık değer olarak değil, maskeli olarak veya özet/hash değerleri ile yansıtılması sağlanmalıdır.

Sisteme ait Sertifika Yönetimi ile ilgili; gerekli dokümanlar ve akış diagramları sunulmalıdır.

Sertifikasyon sürecinde kullanılmak üzere, İşletici Kuruluşa ait anahtarlar güvenli olarak oluşturulmalıdır.

GİB'in belirlediği sertifika otoritesine gönderilmek üzere sertifika talebi güvenli bir şekilde yapılabilmelidir.

GİB'in belirlediği sertifika otoritesinden gelen sertifika sisteme güvenli bir şekilde yüklenebilmelidir.

Sistem bir bütün olarak; uç noktada çalışan (web tabanlı olsun veya olmasın) her bir uygulama için sertifika üretebilmelidir.

Sistem bir bütün olarak; uç noktada çalışan (web tabanlı olsun veya olmasın) her bir uygulama için ürettiği sertifikaları, GİB'in belirlediği sertifika otoritesinden aldığı sertifikadan türetebilmelidir.

"Sistem bir bütün olarak; uç noktada çalışan (web tabanlı olsun veya olmasın) her bir uygulama için ürettiği sertifika içeriği Bu kılavuzda geçen zorunlu verileri kapsamaldır.

Üretilen tüm sertifikalar kılavuzda belirtilen formatlar ile uyumlu olmalıdır.

Sistem ve güvenli mali uygulama, sertifikalar için sertifika geçerlilik süresi kontrolü yapmalıdır.

Sistemin kurulu olduğu merkezde tüm anahtar yönetimi ve şifreleme işlemleri için HSM cihazları kullanılmalıdır.

Kullanılan HSM cihazları Ortak Kriterler EAL4+ veya üzeri sertifikaya sahip olmalıdır.  

 

5. Mülkiyet  

Mükelleflerin Sistem kapsamında kullanacakları fiziki donanımın mülkiyeti, cihazların üzerinde çalışabilecek Ödeme Kabul Eden Araç da dâhil her türlü uygulamanın mükellefler tarafından serbestçe belirlenebilmesi bakımından (İşletici Kuruluşlar, bankalar ya da ödeme kuruluşları tarafından talep edilen ücret, komisyon vb. gibi ücretlerin değişkenliği ve rekabet koşulları içinde istenilen uygulamaların seçiminin serbestçe yapılabilmesi bakımından) uygulama kapsamına dâhil olan mükelleflere ait olması esastır. Bununla birlikte, kullanılacak fiziki donanımda diğer İşletici Kuruluşların Sistemlerine ilişkin uygulamalarının çalıştırılmasına işletici kuruluşlar arasında cihazın ortak kullanımına ilişkin ticari anlaşmanın yapılmış olması ve herhangi bir engel konulmaması şartıyla, söz konusu cihazların mülkiyeti İşletici Kuruluşa ait olarak mükellefe bedeli mukabilinde ya da bedelsiz olarak kullandırılması da mümkündür.

Güvenli Mali Uygulamanın mülkiyeti İşletici Kuruluşlarda olacaktır. İşletici Kuruluş ile mükellef arasındaki hizmet ilişkisinin sona ermesi durumunda, cihaz üzerindeki Güvenli Mali Uygulamanın İşletici Kuruluş tarafından kullanıma kapatılması gerekmektedir.

Sistemden faydalanmak isteyen mükellefler, bir cihaza ve / veya İşletici Kuruluşa bağımlı olmadan ticari birlikteliklerini ve iş ortaklıklarını kendi özgür iradeleri ile belirleyebilmesi bakımından uygulama kapsamında kullanacağı fiziki donanımın mülkiyetine sahip olması ya da mülkiyeti İşletici Kuruluşta bulunsa dahi fiziki donanım üzerinde İşletici Kuruluş tarafından diğer İşletici Kuruluşların uygulamalarının çalıştırılabilmesine işletici kuruluşlar arasında cihazın ortak kullanımına ilişkin ticari anlaşmanın yapılmış olması halinde her hangi bir engel konulmamış olması gereklidir. 

Mükelleflerin özgür iradelerini kısıtlayıcı, pazarlık gücünü düşürücü ve cihaz bağımlılığı üzerinden zorunlu ticari birlikteliğe yol açmaya dayalı iş modeli 507 Sıra No’lu Vergi Usul Kanunu Genel Tebliğinin özüne ve amacına aykırıdır. Bu nedenle mükellefleri cihaz bağımlılığı üzerinden zorunlu ticari birlikteliğe zorunlu kılmamak üzere, ister sertifikalı ister sertifikasız olsun Sisteminin üzerinde çalıştığı tüm fiziki donanımların mülkiyeti mükelleflerin kendisine ait olmalı ya da fiziki donanım üzerinde diğer İşletici Kuruluşların uygulamalarının da çalıştırılabilmesine yönelik her hangi bir engel konulmamış olması işletici kuruluşlar arasında cihazın ortak kullanımına ilişkin ticari anlaşmanın yapılmış olması halinde zorunludur.

Ayrıca mükellefler, İşletici Kuruluşlar tarafından bir Ödeme Kabul Eden Araç entegrasyonu yapmaya zorlanamazlar. Mükellefler, nakit ya da Ödeme Kabul Eden Araç dışında kalan diğer yöntemlerle tahsilat yapabilir, mülkiyeti kendisinde olan sertifikalı ya da sertifikasız cihazından Ödeme Kabul Eden Araç uygulaması ve / veya buna yönelik entegrasyonun kaldırılmasını talep edebilirler.    

 

6. Sistem Üzerinden Düzenlenebilecek e-Belgeler

Sistem kapsamında düzenlenecek olan e-Belgelerin veri girişi, işletici kuruluş tarafından sunulan Güvenli Mali Uygulama üzerinden ya da İşletici kuruluş sorumluluğunda Güvenli Mali Uygulama ile entegrasyonu yapılmış harici satış uygulama yazılımları ile birlikte Güvenli Mali Uygulama aracılığıyla yapılabilir. İşletici Kuruluşlar, sistem kapsamında hizmet sunacakları mükelleflerin mükellefiyet türüne uygun olarak mevzuatta öngörülen ilgili e-Belgeleri desteklemek zorundadır. Bu sorumluluk Asli olarak işletici kuruluşa ait olmakla birlikte Özel Entegratör kuruluşların da e-Belge ile ilgili süreçlere ilişkin GİB’e karşı İşletici Kuruluşla birlikte müşterek ve müteselsil sorumluluğu da bulunmaktadır. 

Güvenli Mali Uygulama üzerinden ya da Güvenli Mali Uygulama ile entegrasyonu ile düzenlenecek olan e-Belgelerin, e-Belge uygulamalarına ilişkin olarak ilgili mevzuatlarında

(Kanun, Genel Tebliğ ve Teknik Kılavuzlarda) belirtilen şekil şartlarına uyması zorunludur.

İlgili mevzuatlarında belirtilen ve e-Belgelerde yer alması zorunlu tutulan bilgilerin, e-

Belgenin düzenlenebilmesi için Özel Entegratör Kuruluşa güvenli bir şekilde iletilmesi ve eBelgenin doğru içerikle oluşturulması sorumluluğu asli olarak işletici kuruluşa ait olmakla birlikte Özel Entegratör kuruluşların da e-Belge ile ilgili süreçlere ilişkin GİB’e karşı İşletici Kuruluşla birlikte müşterek ve müteselsil sorumluluğu da bulunmaktadır. 

e-Belgelerde bulunması gereken bilgilerin hiç ya da gerektiği gibi Sistem tarafından Özel Entegratör kuruluşlara iletilmemesi, uygulamayı kullanan mükelleflerin kusurundan kaynaklanmaması ve işletici kuruluş veya Özel Entegratör kuruluşun gerekli önlemleri almamasından kaynaklaması halinde, işletici kuruluşların ve Özel Entegratör Kuruluşların Bakanlıkça veya Başkanlıkça verilen faaliyet izinleri, Başkanlıkça yapılan değerlendirme ve kontroller çerçevesinde belli bir süreyle durdurulabileceği gibi iptal de edilebilir.

Sistemin, vergiden muaf esnaflara kullandırılması durumunda, gerçekleştirilen satış işlemi için vergiden muaf esnafın, belge düzenleme zorunluluğu bulunmadığından, satış işlemine ait bilgilerin (Satışı gerçekleştiren vergiden muaf esnafın bilgileri, satışa konu mal veya hizmetin bilgileri, tutarları) yer alacığı ve mali değeri bulunmayan, bilgi amaçlı “Bilgi Fişi” düzenlenmesi gerekecek olup, Güvenli mali uygulamanın bunu sağlaması gerekmektedir.

Ayrıca, ticari kazancı basit usulde tespit edilen gelir vergisi mükelleflerin ve gerçek usulde vergiye tabi olmayan çiftçilerin de gerçekleştirdikleri mal teslimleri ile hizmet ifaları KDV den istisna olduğundan, bu durumdaki mükelleflerce tanzim olunacak fatura, müstahsil makbuzu belgelerde KDV tutarının yer almamasının sağlanması gerekmektedir.

Ayrıca Sistem kapsamında düzenlenecek e-belgelerde;  malın ve/veya işin nev’i genel ve soyut isimlerle (yiyecek, içecek, giyecek, gıda, meyve, temizlik malzemesi, ilaç gibi) tanımlanmaması ve satışı gerçekleştirilen mal veya hizmetin özel ve somut adıyla tanımlanması esas olmakla birlikte, 509 Sıra No.lu Vergi Usul Kanunu Genel Tebliği’nde 515 Sıra No.lu Vergi Usul Kanunu Genel Tebliği ile yapılan değişiklik uyarınca; vergiler dahil toplam satış tutarı 500 TL’ye kadar olan perakende mal ve hizmet satışlarına ait düzenlenen e-Arşiv Faturalarda “müşterinin adı, ticaret unvanı, adresi, vergi dairesi ve hesap numarası” bilgileri yerine, müşterinin adı bölümünde “NİHAİ TÜKETİCİ” açıklamasına yer verilerek düzenlenmesine imkanı Sistem kapsamından yararlanan mükellefler için de verilmiş ve bu şekilde düzenlenen e-Arşiv Faturaların perakende satış fişi veya ÖKC fişi olarak kabul edileceği belirtilmiştir. Mezkûr düzenlemede ayrıca bu kapsamda düzenlenecek e-Arşiv Faturaların düzenlenmesinde uyulacak usul ve esaslar ile e-Arşiv Faturanın şekli, formatı, içeriği ve uygulamaya yönelik diğer hususlarını ebelge.gib.gov.tr adresinde yayımlanacak kılavuzlarla Başkanlığın belirlemeye yetkili olduğu hüküm altına alınmıştır.  

Yapılan bu düzenlemeyle Başkanlığımıza verilen yetki çerçevesinde; Sistemden yararlanan mükelleflerce, Sistem kapsamında vergiler dahil toplam tutarı 500 TL ye kadar olan düzenlenecek e-Arşiv Faturalarda, alıcının (müşterinin) adı-soyadı, ünvanı, adresi, vergi dairesi ve vergi kimlik numarası veya TCKN bilgisine yer verilme zorunluluğu olmadan müşterinin adı bölümünde “Nihai Tüketici” açıklamasına yer verilmesi ve bu belgelerin mal ve hizmetlerin nev’i (cinsi) bilgisi alanında; mal ve hizmetlerin ait olduğu KDV oranlarına göre gruplandırarak genel ifadelere (Yiyecek, İçecek, Ekmek, Temizlik Malzemesi, Temel Gıda, Muhtelif Gıda, vb.)  yer verilmek suretiyle düzenlenmesi mümkün bulunmaktadır.  İşletici kuruluş tarafından sunulan sistemin bu gereksinimleri sağlaması gerekmektedir. İşletici kuruluşun sunacağı sisteme mükellef kendi ürün/mal/iş listesini ekleyebileceği gibi KDV departmanları ve genel mal/hizmet ifadelerini de ekleyebilmeli ya da harici satış uygulamaları üzerinden de bu bilgiler sisteme aktarılabilmelidir. Malın ve/veya hizmetin (işin) nev’inin doğru şekilde tanımlanması ve belge üretiminde kullanılması sorumluluğu satış uygulamasını kullanan mükellefe aittir.

Bu çerçevede uygulamayı kullanacak mükelleflerin vergi mükellefiyet durumlarına uygun şekilde Belge düzeninin sağlanmasına yönelik olarak Güvenli Mali Uygulamanın oluşturulması ve sunulması sorumluluğu işletici kuruluşlara aittir.

 

7. Ödeme Türleri

İşletici Kuruluşlar tarafından sunulan Sistemde, tüm mali ve finansal işlemlerin Güvenli Mali Uygulama üzerinden (veya Güvenli Mali Uygulama ile entegrasyonu İşletici Kuruluş sorumluluğunda gerçekleştirilmiş harici satış uygulama yazılımları üzerinden) başlaması ve Güvenli Mali Uygulama üzerinden / aracılığıyla sonlandırılması esastır. Mali işlemin sonlanması, satışa ait oluşacak e-Belgedeki bedelin hangi ödeme türü ile gerçekleştirileceğinin seçilmesi ile devam etmeli ve bu ödeme türüne göre işlemler sonlandırılarak e-Belge oluşturulmalıdır. 

Güvenli Mali Uygulamaların aşağıdaki ödeme türlerinin tamamı tanımlı olmalıdır. Ancak, söz konusu ödeme türlerinden, mükellefin ilgili finansal kuruluşlarla bir üye işyeri anlaşması olmaması nedeniyle kullanılması mümkün olmayanların aktif edilmemesi, üye işyeri anlaşması gerçekleştiğinde ise aktif edilmesi sorumluluğu işletici kuruluşa aittir.

Nakit: Para ile gerçekleştirilen ödemelerdir.

Banka / Kredi Kartı: Banka vb. kuruluşlara ait; ön ödemeli, banka veya kredi kartları ile gerçekleştirilen ödemelerdir. Fiziki, sanal veya dijital ortamdan oluşturulmuş kartlar (NFC/HCE/QR vb.) ile yapılan tahsilatlar bu gruptadır.  c) Diğer:

Senet/Çek/Açık Hesap/Kredili: Çek, senet teslimi veya açık hesap/kredili (vadeli) olarak gerçekleştirilen satışlarda kullanılan ödeme türüdür.

Havale/EFT: Banka hesapları arasında havale veya EFT işlemi ile gerçekleştirilen ödemelerdir.

Hediye Kartı: Hediye kartları ile gerçekleştirilen satışlarda kullanılan ödeme türüdür. İndirim çekleri de bu gruptandır.

Belediye Ulaşım Kartları, Yardım Kartları ve Çekleri: 5393 sayılı Belediye Kanununa uygun olarak; Belediyeler tarafından ihraç edilen ulaşım kartları veya ihtiyaç sahiplerine verilmiş olan yardım kartları ve çekleri ile gerçekleştirilen satışlarda kullanılan ödeme türüdür. 

Yemek Kartı ve Çekleri: Yemek Kartı ve çekleri ile gerçekleştirilen satışlar için kullanılacak ödeme türüdür. Yemek kartı ve çekleri ile yapılan ödemeler için mali değeri bulunmayan bilgi fişi düzenlenecektir.YENİ NESİL ÖDEME KAYDEDİCİ CİHAZLARDAN “BİLGİ FİŞLERİ” DÜZENLENMESİNE DAİR USUL VE ESASLARA İLİŞKİN TEKNİK KILAVUZ’un 9.2 bölümünde yer verilen açıklamalar ve ilgili bölümde belirtilen bilgi fişi belge örnekleri dikkate alınacaktır. Bu husus, bilgi fişinin düzenlenmesinde yeni nesil ödeme kaydedici cihazın kullanılması ve ÖKC ile özgülenen bilgilerin (Z No, EKÜ No, Fiş No, YN ÖKC Seri No) belge üzerinde yer verilmesi zorunluluğunu getirmemektedir. 

Finansal kuruluşlar tarafından sunulan/sunulabilecek diğer ödeme yöntemleri.  

İşletici Kuruluş, her bir ödeme/tahsilat işleminde düzenlenecek olan ilgili e-Belgenin hangi ödeme türü ile işlem gördüğünü Özel Entegratör Kuruluşa bildirmek ve mali verilerin doğruluğunu sağlamak zorundadır. Sistem, mali bir işlem ile eşleşmeyen hiçbir ödeme / tahsilatın yapılmasına müsaade etmemelidir.

 

8. Avans Ödeme ve Cari Hesap Tahsilatı İşlemleri

Ticari hayatın doğal akışı içerisinde yer alan mal ve hizmetlerin satışının gerçekleştirilmesinden önce ön ödeme (Avans, depozito, kaparo) Tahsilatı ve Cari Hesap Tahsilatı (Müşteriye önceden teslim edilmiş bir mal veya sunulmuş hizmet karşılığında ödemeleri alınmamış ve karşılığı 213 sayılı Vergi Usul Kanunu uyarınca düzenlenmiş resmi evraklar ile tevsik edilebilen alacakların ödeme / tahsilat işlemleri), Sistemi kapsamında Güvenli Mali Uygulama içeriğinde olmak üzere işletici kuruluşlar tarafından sunulabilir. 

Avans ve Cari Hesap Tahsilatlarına ilişkin, Sistem kapsamında düzenlenecek belgelerin format ve içeriği ile uygulama usulü hakkında YENİ NESİL ÖDEME KAYDEDİCİ CİHAZLARDAN “BİLGİ FİŞLERİ” DÜZENLENMESİNE DAİR USUL VE ESASLARA İLİŞKİN TEKNİK KILAVUZ’un 9.3 ve 9.6 bölümlerinde yer verilen açıklamalar ve bu bölümlerde yer verilen bilgi fişi belge örnekleri dikkate alınacaktır. Bu husus, bilgi fişinin düzenlenmesinde yeni nesil ödeme kaydedici cihazın kullanılması ve ÖKC ile özgülenen bilgilerin (Z No, EKÜ No, Fiş No, YN ÖKC Seri No) belge üzerinde yer verilmesi zorunluluğunu getirmemektedir.

Bu bilgi fişlerinin Güvenli Mali Uygulama üzerinden düzenlenmesi ve bu belgelerin de        e-Belge olarak düzenlenmek amacıyla Özel Entegratör Kuruluşa iletilmesi ve bunlar tarafından muhafaza edilmesi, Başkanlık tarafından talep edildiğinde Başkanlığa elektronik ortamda raporlanması gerekmektedir.

 

9. Fatura Tahsilatı İşlemleri

6493 sayılı Ödeme ve Menkul Kıymet Mutabakat Sistemleri, Ödeme Hizmetleri ve Elektronik Para Kuruluşları Hakkında Kanunun 12 nci maddesinin (1) numaralı fıkrasının (e) bendi uyarınca fatura ödemelerine aracılık edilmesine yönelik hizmetleri yerine getirme amacıyla faaliyet gösteren kuruluşlar ile bu kuruluşların resmi temsilcileri, fatura tahsilat işlemlerini bu kılavuzda belirtilen Sistem aracılığıyla da gerçekleştirebilir. 

Sistem kapsamında gerçekleştirilen Fatura Tahsilatı İşlemlerinde; 

Gerçekleştirilen fatura tahsilat işlemi sonucunda müşteriden ek bir ücret / komisyon alınmıyor ise, bu durumda YENİ NESİL ÖDEME KAYDEDİCİ CİHAZLARDAN “BİLGİ FİŞLERİ” DÜZENLENMESİNE DAİR USUL VE ESASLARA İLİŞKİN TEKNİK KILAVUZ’un 9.5. bölümünde yer alan açıklamalar dikkate alınacak ve söz konusu kılavuzun 7 numaralı ekinde yer verilen format ve içerikteki bilgi fişinin e-Belge olarak düzenlenmesi zorunludur. Bu husus, bilgi fişinin düzenlenmesinde yeni nesil ödeme kaydedici cihazın kullanılması ve ÖKC ile özgülenen bilgilerin (Z No, EKÜ No, Fiş No, YN ÖKC Seri No) belge üzerinde yer verilmesi zorunluluğunu getirmemektedir. 

Müşteriden ilave bir ücret / komisyon alınmadan yapılan fatura tahsilat işlemlerine ait olmak üzere, faturası tahsil edilen kurum veya kuruluşlardan daha sonra ücret, komisyon, ciro primi vb. adlar altında tahakkuk eden alacaklar için ise genel esaslar çerçevesinde KDV’li faturanın, faturası tahsil edilen kuruma kesilmesi gerektiği açıktır.

Gerçekleştirilen fatura tahsilat işlemi sonucunda müşteriden ek bir ücret / komisyon alınıyor ise, bu durumda alınan komisyon tutarında faturanın e-Belge olarak düzenlenmesi zorunludur. 

İlgili kuruluş ve temsilcilerinin, fatura tahsilat işlemlerinde işbu kılavuzda tanımlanan Sistemi tercih etmeyerek, YNÖKC kullanması ve tahsilatların banka / kredi kartı ile yapılması durumunda, tahsilatın yapıldığı pos cihazının ÖKC ya da YNÖKC ile entegre ve bağlantılı bir yapıda (satış işleminin ÖKC’den başlatılıp, tahsil edilecek tutarın EFT-POS cihazına ÖKC’den otomatik olarak gönderilmesi ve satış işleminin ÖKC’den sonlandırılması) ve ÖKC’den bütünleşik fişi YENİ NESİL ÖDEME KAYDEDİCİ CİHAZLARDAN “BİLGİ FİŞLERİ” DÜZENLENMESİNE DAİR USUL VE ESASLARA İLİŞKİN TEKNİK KILAVUZ’unda belirtilen şekilde düzenlemeleri zorunludur. 

 

10. İşletici Kuruluş İzin Başvurusu, Uyumluluk Testleri Denetimi ve İznin Verilmesi

507 Sıra No.lu Vergi Usul Kanunu Genel Tebliğinin Tanımlar bölümünde yer verilen “Finansal Kuruluş” ya da “ÖKC Üreticisi” şirketlerden dileyenler, Güvenli Mobil Ödeme ve Elektronik Belge Yönetim Sistemini işletmek üzere “İşletici Kuruluş” yetkisi almak için, Başkanlığa yazılı olarak başvuruda bulunurlar. 

İşletici Kuruluş izni almak isteyen kuruluşlar, Sisteme dair e-Belge düzenlenmesi konusunda işbirliği yaptığı özel entegratör ile imzaladığı protokolü de Başkanlığa başvuru ile birlikte iletir. 

Bu başvuruda, işbu kılavuzda tarif edilen Sistemi işletmek için gerekli olan yazılımlar ile teknik alt yapıyı hazırladığını gösteren bilgi ve belgeleri ve sistem mimarisini, alacağı denetim raporuna baz teşkil etmesi amacıyla sunar. Sistem mimarisi; network topolojisi, uçtan uca güvenlik altyapısı ile sertifika ve anahtar saklama yöntemini içerir. Başkanlık, gerek görmesi durumunda İşletici Kuruluştan ek ve açıklayıcı doküman ve bilgiler talep edebilir. 

İşletici Kuruluşlar, izin başvuruları ile birlikte Sistemi bu kılavuzda tariflenen şekilde kurarak işleteceklerini ve aynı zamanda bu kılavuz içerisindeki tüm sorumlulukları eksiksiz yerine getireceklerini gayrikabili rücu şekilde kabul, beyan ve taahhüt etmek zorundadırlar. 

Başvurusu değerlendirmeye alınan kuruluşlara, Sistemin işleyişi ve sistem kapsamında       e-Belgelerin düzenlenme, iptal/iade edilme, saklanma hususları ile çeşitli ödeme türlerinin uygulama esaslarını ve diğer gereklilikleri gösteren ve bu Kılavuz ekinde  yer alan “GMÖEBYS Test Adımları Tablosu” verilir. 

Başvuru yapan kuruluş, bu kılavuz içerisinde tariflenen şekilde bir dosya hazırlayarak, GMÖEBYS Test Adımları Tablosu’na uygun uyumluluk testleri için hazır olduğunu beyan eder. Uyumluluk testleri; TÜBİTAK Devlet Üniversitelerinden Teknik Üniversitelerin ilgili bölümlerince ya da BSDHY kapsamında yetkilendirilmiş veya izin verilmiş bağımsız denetim kuruluşlarının gerekli yetkinliğe haiz personeli tarafından, sorumlulukları kendilerine ait olmak üzere yapılması/yaptırılması gerekmektedir. Bununla birlikte kapsam ve içeriğini belirleyeceği testleri Başkanlık kendi bilgi işlem ekipleri ile de yapabilir. Uyumluluk testini gerçekleştirilen kuruluşlar, test sonuçlarını Başkanlığa bir Rapor ile bildirir. Bu birimler tarafından testlerin yapılması, gerek görülmesi halinde Başkanlık birimleri tarafından da ayrıca test yapmasına mani teşkil etmez. Uyumluluk testlerini başarıyla gerçekleştiren kuruluşların sistemlerinin çalışabilirliğini göstermiş oldukları kabul edilir. Ancak bu kabul hiçbir şekilde Uçtan Uca Güvenlik ve Vergi Güvenliği ile ilgili sorumluluklarında kısıtlama ya da Başkanlığa devri anlamına gelmez.

Başkanlık izin başvurularının değerlendirilmesi sürecinde ek bilgi ve belge talep edebilir, açıklama ve sistemin işleyişine ilişkin demo sunum isteyebilir, diğer kamu kurum ve kuruluşlarından uygunluk sorgulaması yapabilir. 

Başkanlık tarafından yapılan değerlendirme süreçlerini başarılı şekilde tamamlayan ve Bakanlık tarafından da izin verilen kuruluşlar, kendilerine izin yazısında bildirilen tarihten geçerli olmak üzere mükelleflere Sistem kapsamında İşletici Kuruluş olarak hizmet verebilirler. 

İşletici Kuruluş izni verilen kuruluş ile anlaşmalı olduğu Özel Entegratör Kuruluşuna ilişkin bilgiler ebelge.gib.gov.tr internet adresinde yayınlanır. İşletici kuruluş, izin aldıktan sonra, farklı bir özel entegratör ile de e-Belge entegrasyonu sağlamak istediği durumda, Başkanlığa yeniden izin için başvuru yapmasına gerek bulunmamakta olup entegrasyon yaptığı

Özel entegratör ile aralarında düzenlenen protokol örneğini Başkanlığa yazılı olarak sunmaları yeterlidir. Başkanlık gerek görmesi durumunda, işletici kuruluşun izin sonrası entegrasyon yaptığı Özel entegratör ile Sistemin uyumluluk testlerinin yeniden yapılmasını talep edebilir.

İşletici Kuruluşlar, izin aldıkları sistem mimarisine yönelik değişiklik yapmak istemeleri halinde, bu durum Başkanlık iznine bağlıdır. Başkanlık yazılı izni olmadan Sistem mimarisinde değişikliğe gidilemez. Bunun için ilk izin başvurusunda bulundukları kapsamda bir dosya hazırlayarak; 

Sistem Mimarisinde değişikliğe gitme ihtiyacının nedenlerini, İzin almak istedikleri yeni sistem mimarisi ile izin aldıkları sistem mimarisi arasındaki farkları, gösteren iki ek ile başvurularını yaparlar.  

Başkanlık sistem mimarisinde gerçekleştirilecek değişikliğe izin vermek için, yapılacak değişiklikler nedeniyle oluşan fark unsurların sistemin ana yapısında bir zafiyete yol açılmadığını uyumluluk testi raporu ile belgelendirilmesini talep eder. Söz konusu raporun uygun görüş içermesi durumunda sistem mimarisine ilişkin değişikliğe Başkanlık izin verir. Yeni sistem mimarisinin verilen izin tarihinden itibaren, sahaya uygulanması mümkündür.

Başkanlık belirli aralıklarla işletici kuruluşların test ve canlı networkleri üzerinde veya İşletici kuruluş bünyesinde test ve canlı ortamlarda Uyumluluk Testleri yaptırılmasını talep edebilir. Bu kapsamda Uyumluluk Testi Yapmaya Yetkili Kuruluşlar tarafından fonksiyonalite, performans ve güvenlik test araçları kullanılabilir ve oluşan raporlar Başkanlığa sunulur. Başkanlık bu raporların sonuçlarına göre işletici kuruluşların sistemlerinde kılavuza uygun düzenlemeler yapmalarını talep edebilir.

 

11. Sistemden Yararlanmak İsteyen Mükelleflerin Üyelik Başvurusu ve Sisteme Dahil Edilmesi 

507 Sıra No’lu Vergi Usul Kanunu Genel Tebliği 5 nci maddesi, 1 nci fıkrasında tanımlanan vergi mükelleflerinin tümü Sistemden faydalanabilir. Bunun için Başkanlık tarafından İşletici Kuruluş olarak yetkilendirilmiş şirketler ile üyelik anlaşmaları yapmaları ve Başkanlık tarafından sunulan İnteraktif Vergi Dairesi üzerinden 507 sıra no.lu VUK Genel Tebliği kapsamında e-Belge uygulamalarına dahil olacaklarını beyan etmeleri ve hizmet alacakları işletici kuruluşu seçmeleri gerekmektedir. 

Söz konusu başvuruyu müteakip hizmet alacakları işletici kuruluşun çalışmakta olduğu ve mükellefe e-Belge hizmet sunacak özel entegratör tarafından “e-Fatura Uygulaması Özel Entegrasyon Kılavuzunda” açıklanan şekilde mükellef hesabının açılması için HR.xml dosyası elektronik ortamda Başkanlığa iletilecek ve Başkanlıktan gelen onay mesajını müteakip Sistemden faydalanmaya başlayabilirler.

Başkanlık, üyelik başvurusu ve sisteme dahil edilme sürecinde elektronik imza, mali mühür dışında diğer doğrulama ve onaylama mekanizmalarını kullandırmaya ve bunu işletici kuruluşlara yazı ile bildirmeye yetkilidir. 

İşletici kuruluşlar, sisteme dahil ettiği veya sistemden çıkardığı (sözleşmesin feshi veya sona ermesi nedeniyle) mükelleflerin bilgilerini yine “e-Fatura Uygulaması Özel Entegrasyon Kılavuzunda” açıklanan şekilde mükellef hesabının kapatılması için HR.xml dosyası elektronik ortamda Başkanlığa aynı gün iletilmek zorundadır.

Üyelikten çıkış prosedürü ve süresi, üyelik başvuru prosedüründen ve süresinden uzun ve farklı olmamalı ve ayrıca işletici kuruluş ile uygulamadan yararlanan mükellef arasındaki ticari alacak ve borç ilişkisi, mükellefin sistemden çıkma talebinin yerine getirilmesine engel teşkil etmemelidir.

 

12. Sistem İle Birlikte ÖKC/YNÖKC Kullanımı

Sisteme dahil olan ve tüm mükelleflerin, faaliyetlerinde ödeme kaydedici cihaz kullanma mecburiyetleri bulunmamaktadır. Ancak sisteme dahil olan mükelleflerden hali hazırda ödeme kaydedici cihaz kullanmakta olanlar, söz konusu cihazlarını perakende satış fişi ile belgelendirilebilecek satışlarında kullanmaları mümkündür. 

Bununla birlikte söz konusu ödeme kaydedici cihazların Sistem kapsamında gerçekleştirilen ve e-Belge düzenlenen hallerde kullanılması durumunda, elektronik belgelere ilişkin olarak “Bilgi Fişi” (usul ve esasları Başkanlıkça www.ynokc.gib.gov.tr internet adresinde yayımlanan YENİ NESİL ÖDEME KAYDEDİCİ CİHAZLARDAN “BİLGİ FİŞLERİ” DÜZENLENMESİNE DAİR USUL VE ESASLARA İLİŞKİN TEKNİK KILAVUZ’da belirtilen) düzenlemeleri gerekmektedir.

Sisteme dahil olan mükellefler, sistem kapsamında verilmeyen banka vb. kuruluşlara ait EFT-POS cihazlarını,  ödeme kaydedici cihazlarla 483 Sıra No.lu Vergi Usul Kanunu Genel

Tebliğinde ve bu Tebliğe dayanılarak Başkanlık tarafından yayımlanan Teknik Kılavuzlar, Protokol dokümanları ve Başkanlık tarafından www.ynokc.gib.gov.tr internet adresinde yapılan duyurularla belirlenen kurallara uygun kullanılması şartıyla kullanmaya devam edebilirler.

 

13. Denetim

Başkanlık tarafından işletici kuruluş izni verilen firmalar, kurmuş oldukları ya da yararlandıkları dış hizmet sağlayıcıların sistemlerinin uçtan uca güvenli haberleşme ve bilgi sistemleri denetimini, izin tarihinden en geç 1 yıl içerisinde BSDHY kapsamında yetkilendirilmiş veya izin verilmiş bağımsız denetim kurumları veya Devlet Üniversitelerinden Teknik Üniversitelerin ilgili bölümlerince ya da TÜBİTAK tarafından denetlenmelerini tamamlamak ve ilgili raporların Başkanlığa iletimini sağlamak zorundadır. 

Bu süre içerisinde denetim raporları Başkanlığa ulaşmamış olan işletici kuruluşların izinleri önce askıya alınır ve bu durum ebelge.gib.gov.tr adresinden duyurulur. Bunun üzerine İşletici Kuruluşa denetim raporlarını teslim etmesi için 6 ay ek süre verilir. Bu süre zarfında da denetim raporlarını teslim etmeyen ya da edemeyen İşletici Kuruluşların izni iptal edilir. 

İşletici Kuruluşlar, Sistemi yönetmek ve işletmek amacıyla kurdukları altyapının (Dış Hizmet Sağlayıcıdan yararlanılması halinde bunların altyapılarının) Güvenli Haberleşme ve Bilgi Sistemleri denetimlerini, BSDHY kapsamında yetkilendirilmiş veya izin verilmiş bağımsız denetim kuruluşları veya Devlet Üniversitelerinden Teknik Üniversitelerin ilgili bölümlerince ya da TÜBİTAK tarafından her 3 yılda bir yaptırmak zorundadır. 

Bakanlık ya da Başkanlık gerek görmesi durumunda, İşletici Kuruluşu ve bu kılavuz kapsamında işletici kuruluş sorumluluğunda e-Belge ile ilgili hizmet sunacak Özel Entegratörlerin kurmuş olduğu altyapı sistemlerini dilediği anda ve dilediği şekilde denetleyebilir veya denetletebilir. 

İşletici Kuruluş ve Özel Entegratör kuruluşlar, sistem kapsamındaki altyapılarını geriye doğru 10 yıllık bir denetime elverişli halde kurmak ve tutmakla yükümlüdür. Bu sebeple İşletici Kuruluş ve Özel Entegratör kuruluşları tarafından sağlanacak olan sistem iz kayıtlarının doğruluğundan, bütünlüğünden ve değiştirilmezliğinden İşletici Kuruluş sorumludur.

 

14. Sorumluluk ve Ceza Uygulaması

Sistem uçtan uca bir bütündür. Bu bütünün güvenlik zincirini sağlamak da İşletici Kuruluşun sorumluluğu altındadır. Sistemin asli sorumlusu İşletici Kuruluş olsa da Bakanlık ve Başkanlık’a karşı tüm iş ortakları aldıkları izin kapsamındaki faaliyetlerden müteselsilen sorumludur.

e-Belgeleri, gerek bu kılavuzda gerek ilgili e-Belge Teknik kılavuzlarında açıklandığı şekilde üretmeyen İşletici Kuruluş hakkında Vergi Usul Kanununda yer alan cezai hükümler uygulanabileceği gibi yapılan yazılı uyarıya rağmen gerekli önlemleri almayan işletici kuruluşların Bakanlıkça verilen faaliyet izinleri belli bir süreyle durdurulabileceği gibi iptal de edilebilir.

İşletici Kuruluşlar, uçtan uca güvenliğin sağlanmasında kullandıkları yazılımsal metodlardan sorumludur. 

Güvenli Mali Uygulama, Ödeme Kabul Eden Araç ve e-Belge entegrasyonları İşletici Kuruluş adına üçüncü taraflarca da geliştirilebilir ve işletilebilir. Ancak bu durum İşletici Kuruluşun Sistemi için sahip olduğu münhasır ve asli sorumluluğu ortadan kaldırmadığı gibi, Sistemin ana omurgasını oluşturan bu üç yazılımın tamamının ya da bir kısmının üçüncü (dış hizmet sağlayıcı) taraflarca geliştirilmiş olması, ya da Sistemin işletilmekte olması diğer taraflarla sorumluluk paylaşımı anlamına gelmez. 

İşletici Kuruluşlar, Sistemin uçtan uca güvenliğinin sağlanması amacıyla aşağıda belirtilenlerle sınırlı olmamak üzere, sorumludurlar:

Her ödeme türü için, e-Belgenin düzenlenmesini sağlamaktan, 

Ödeme / Tahsilat işlemlerinin güvenliğinden, 

Satış işlemlerinin ve e-Belgenin vergi mevzuatındaki düzenlemelerine uyumluluğunun sağlanmasından, (asli olarak İşletici Kuruluşta olmakla birlikte Özel Entegratör Kuruluşların da müşterek ve müteselsil sorumluluğu bulunmaktadır.)

Güvenli Mali Uygulama, Ödeme Kabul Eden Araç ve Özel Entegratör Kuruluş ile entegrasyon yazılımlarının her birinin üzerinde ayrı ayrı ya da birbirleri olan entegrasyonlar arasında yapılan her tip ve türdeki manipülasyonları önlemekten, 

Tahsilat ile düzenlenen e-Belge arasındaki mutabakatsızlıkları kontrol ve önlemekten,   e-Belge düzenlemeye esas verilerin Özel Entegratör Kuruluşa, ilgili Genel Tebliğlerde ve Teknik Kılavuzlarında tariflenen belge düzenleme esas ve şartlarına riayet edilerek iletilmesini sağlamaktan, 

Mali verilerin kaynağının, doğruluğunun, değişmezliğinin ve bütünlüğünün kontrolünü sağlamaktan, 

Bozuk, hatalı ve atak içeren verilerin muhataplara iletilmesini önlemekten, 

Sisteme ilişkin verilerin güvenliği ve gizliliği zarar görmeyecek şekilde 10 yıl süre ile saklanmasını sağlamaktan, 

Denetime uygunluk verecek şekilde sistem loglarının tutulmasını sağlamaktan, 

Harici Uygulamalar ile Güvenli Mali Uygulama arasında yapılan entegrasyonların vergi kayıp ve kaçağına yol açılmayacak şekilde yapılmasını sağlamaktan, 

Yetkili Servislerin yaptığı iş ve işlemlerin bu kılavuz ve ilgili diğer mevzuatlarda belirlenen kurallara uygunluğunu sağlamaktan, 

sorumludur. 

İşletici Kuruluşlar işbirliği yaptığı özel entegratör kuruluşlar ile birlikte müşterek ve müteselsilen Sistem kapsamında düzenlenen e-Belgeleri, asgari 10 yıl süre ile gizlilik ve güvenliğini sağlayacak şekilde saklama ve talep edilmesi halinde Başkanlığa elektronik ortamda iletme yükümlülüğü bulunmaktadır. İşletici kuruluşların yukarıda sayılı sorumluluklarını yerine getirmemeleri durumunda; 213 sayılı Vergi Usul Kanununda yer alan cezai hükümler uygulanabileceği gibi yapılan yazılı uyarıya rağmen gerekli önlemleri ivedilikle almayan işletici kuruluşların Bakanlıkça verilen faaliyet izinleri belli bir süreyle durdurulabileceği gibi iptal de edilebilir. 

İşletici Kuruluşlar ve bunlarla e-Belge düzenlenmesi konusunda işbirliğinde bulunan özel entegratör kuruluşlar, merkezi sunucularını Türkiye Cumhuriyeti sınırları içerisinde kurmak ve barındırmak zorundadırlar. Sistem üzerinden geçen gerek mali gerekse finansal hiçbir verinin yedekleme amacıyla da olsa yurtdışına çıkarılmayacağını taahhüt ederler. 

Ayrıca, İşletici Kuruluşlar ve bunlarla e-Belge düzenlenmesi konusunda işbirliğinde bulunan özel entegratör kuruluşlar, kurmuş ve işletmiş oldukları Sistem üzerinden geçen işlemlere dair ticari, mali ve finansal verileri Başkanlık dışında, uygulamadan yararlanan mükelleflerin ve işleme taraf olanların yazılı izni olmadan hiçbir şekilde ve amaçla işleyemezler, üçüncü taraflara iletemezler, kullandıramazlar ve raporlayamazlar. Verilen hizmetler kapsamında elde edilen her tür ticari, mali ve finansal verilerin güvenliğinden ve gizliliğinden İşletici Kuruluşlar sorumludurlar. Sistem kapsamında düzenlenen e-Belgelerin, uygulamadan yararlanan mükellefler tarafından yazılı bir onayla finansal bir işleme (faktöring, kredi teminatı, alacak sigortası vb. e-Belgeye bağlı finansal/bankacılık işlemlerine) konu edilmesini sağlamak üzere ilgili finansal kuruluşlara belirtilen finansal işlemlerin gerçekleştirilmesi amacıyla iletilmesi mümkündür. 

Söz konusu sorumluluklara uymadığı tespit olunan İşletici Kuruluş veya özel entegratörlerin Bakanlıkça verilen faaliyet izinleri belli bir süreyle durdurulabileceği gibi tamamen iptal de edilebilir. Faaliyet izinleri iptal edilen işletici kuruluş veya özel entegratörlere ve bunların yöneticilerinin kanuni temsilciliğini yürüttüğü kuruluşlara, Güvenli Mobil Ödeme ve Elektronik Belge Yönetim Sistemi kapsamında tekrar faaliyet izni verilmez.  

İşletici Kuruluşlar, münhasıran Sistemden yararlanan mükellefin kendi bilgilerini kendisine katma değerli hizmetler sunmak maksadıyla ve yazılı bir sözleşme yapılmış ve katma değerli hizmetin kapsamı açıkça belirtilmiş olmak kaydıyla işleyebilir, raporlayabilir. Ancak bu durumda da Sistem kapsamındaki ticari, mali ve finansal verilerin üçüncü kişilerle herhangi bir şekilde paylaşılması ve bu amaçla işlenmesi mümkün değildir. 

 

15. Dış Hizmet Alımı 

İşletici Kuruluşlar, tebliğ konusu sistemlerin temini ve işletimi konusunda dış hizmet alımı yapabilirler. Ancak bu durum İşletici Kuruluş’un tebliğ kapsamındaki sorumluluklarını ortadan kaldırmaz.

 

16. Değişiklik Hakkı

Başkanlığın bu Teknik Kılavuz üzerinde her türlü değişiklik ve güncelleme hakkı bulunmakla birlikte, dijitalleşen süreçler, ödeme sistemlerindeki gelişmeler, güvenlik ihtiyaçlarındaki değişimler, ek gereksinim, fonksiyonalite vb. durumlarda teknik kılavuzda değişiklik yapmadan yazılı bildirim yapmak suretiyle İşletici Kuruluşlardan bu değişiklikleri yapmasını talep edebilecektir. 

EKLER: 

1- GMÖEBYS Test ve Doğrulama Adımları Tablosu

 

 


EK-1

          GELİR İDARESİ BAŞKANLIĞI

Güvenli Mobil Ödeme ve Elektronik Belge Yönetim Sistemi

           Test ve Doğrulama Adımları Dokümanı

 

Versiyon 1.1

(21.05.2020)

 

  1. GİRİŞ

Bu doküman, İşletici Kuruluşların geliştirdikleri sistemleri ön testlere tabi tutmaları ve yetkilendirilmiş test kuruluşları için rehber olması amacı ile düzenlenmiştir. İşletici Kuruluşların Sistemlerine ait doğrulama, fonksiyonel ve güvenlik testleri bu özet doküman temel alınarak yapılacaktır.

 

  1. TEST VE DOĞRULAMA TABLOSU

KODU

 TEST UNSURU

UYGULANACAK YÖNTEMLER

1

İzin Başvurusu Yapan Kuruluş Tebliğde belirtilen kuruluşlar kategorisinde midir? 

 Başvuru belgeleri kontrol edilecektir.

2

İşbirliği yapılacak Özel Entegratör Kuruluş ile İşletici Kuruluş arasında, Güvenli Mali Uygulama ile e-Belge entegrasyonu ve sorumluluğu konusunda protokol yapılmış mıdır? 

 Başvuru belgeleri kontrol edilecektir.

  

3

Sisteme dahil edilen kullanıcının, mükellefiyet durumu dikkate alınmakta mıdır? 

 Fonksiyonel testler esnasında; Mükellef/ Üye İşyeri  Yönetim modülleri incelenecektir.

4

Basit Usul mükelleflerinin düzenleyeceği

Fatura belgesinde       KDV   istisnası uygulanmakta mıdır?

 Fonksiyonel testler esnasında; e-Belge entegrasyonu  ve çıktıları incelenecektir.

5

Sistem kapsamında düzenlenen e-Belgeler

GİB şematron kontrollerinden geçmiş midir?

 Fonksiyonel testler esnasında; e-Belge entegrasyonu ve çıktıları incelenecektir.

6

Harici Satış Uygulama Yazılımı ile Güvenli Mali Uygulama Entegrasyonu sağlanmış mıdır?

 Fonksiyonel testler esnasında; Eğer entegrasyon  varsa; bilgi bütünlüğü, güvenliği ve doğruluğu iletişim protokolü incelenerek değerlendirilecektir.

7

Güvenli Mali Uygulama Yazılımında Mal ve

Hizmetlerin     Tanımlaması    (Mal    veya

Hizmetin Adı, Birim Ölçüsü, Barkodu/Standart Kodu, Birim Fiyatı, KDV Oranı, ÖTV Oranı) yapılmakta mıdır?

 Fonksiyonel testler esnasında; Sistem bünyesindeki  temel satış uygulaması incelenerek  değerlendirilecektir.

 

8

Belge üzerinde ödeme bilgisine de yer verilmiş midir?

Fonksiyonel testler esnasında; e-Belge ve müşteriye verilen/gönderilen belge ve çıktılar incelenerek değerlendirilecektir.

 

9

Belge üzerinde İçeriği GİB tarafından belirlenen Karekoda yer verilmiş midir?

Fonksiyonel testler esnasında; e-Belge entegrasyonu ve çıktıları incelenecektir.

10

KDV hesaplaması doğru şekilde yapılmakta mıdır?

 Fonksiyonel testler esnasında; farklı oranlarda KDV barındıran işlemler yapılarak değerlendirilecektir.

11

Fatura altı ıskonto tutarları farklı KDV oranlarına göre dağıtımı yapılmakta mıdır?

 Fonksiyonel testler esnasında; farklı oranlarda KDV barındıran işlemler yapılarak değerlendirilecektir.

12

Satır ıskontoları doğru uygulanmakta mıdır?

Fonksiyonel testler esnasında; farklı oranlarda KDV barındıran işlemler yapılarak değerlendirilecektir.

13

Belge üzerinde(alt kısmında) İşletici Kuruluş Güvenli Mali Uygulama Yazılım Sürüm bilgisine yer verilmiş midir?

Fonksiyonel testler esnasında; e-Belge ve müşteriye verilen/gönderilen belge ve çıktılar incelenerek değerlendirilecektir.

14

Ödeme/Tahsilat işlemi ile birlikte belge içerik bilgileri özel entegratör sistemlerine anlık olarak aktarılmakta mıdır? 

Fonksiyonel testler esnasında; e-Belge entegrasyonu ve çıktıları incelenecektir.

15

Ödeme/Tahsilat işlemi ile birlikte e-Belge özel entegratör sistemlerinde anlık olarak oluşturulmakta mıdır? 

Fonksiyonel testler esnasında; e-Belge entegrasyonu ve çıktıları incelenecektir.

16

Özel Entegratör sistemi ile çevrim içi olunmadığında Güvenli Mali Uygulama satış işlemini kesmekte midir?

Fonksiyonel testler esnasında; e-Belge entegrasyonu ve çıktıları incelenecektir.

17

Güvenli Mali Uygulamanın Çevrimdışı çalışıyorsa; fonksiyonel gereksinimler karşılanmış mıdır? Gerekli güvenlik önlemleri alınmış mıdır? 

Güvenlik testleri esnasında; Çevrimdışı sistemler için güvenlik testleri ayrıca değerlendirilecektir. Başvuru dokümanlarında İşletici Kuruluş tarafından iletilen Çevrimdışı mimari ve güvenlik altyapısı incelenecektir. Altyapının doğruluğu, verinin korunduğu ve Çevrimiçi olunduğunda güvenli bir şekilde merkeze iletildiği kontrol edilecektir. İşletici kuruluş sistemi bu akışları gösteren örnek işlemler yapmak ve Test kuruluşuna bu akışların doğru çalıştığını sunmalıdır.

 

Fonksiyonel testler esnasında; çevrimdışı yapılan işlemlerin sistem çevrim içi olduğunda veri kaybına neden olmadığı ve doğru bir şekilde çevrimiçi iken olduğu gibi akışların aynen uygulandığı kontrol edilecektir.

 

18

Sistem kapsamında düzenlenecek e-Belgenin müşteriye iletim usulü belge üzerinde belirtilmekte midir?

 Fonksiyonel testler esnasında; e-Belge entegrasyonu

ve çıktıları incelenecektir.

19

Sistem kapsamında düzenlenecek e-Belgenin müşteriye elektronik ortamda iletimi seçeneği arasında SMS var mıdır?

 Fonksiyonel testler esnasında; e-Belge entegrasyonu ve çıktıları incelenecektir. SMS var ise test edilecek ve SMS ile doğru bir şekilde belge aktarımı yapıldığı kontrol edilecektir.

20

Sistem kapsamında düzenlenecek e-Belgenin müşteriye elektronik ortamda iletimi seçeneği arasında e-Mail(e-Posta) var mıdır?

 Fonksiyonel testler esnasında; e-Belge entegrasyonu

ve çıktıları incelenecektir. E-Posta var ise test edilecek ve E-Posta ile doğru bir şekilde belge aktarımı yapıldığı kontrol edilecektir.

21

İşletici Kuruluş Güvenli Mali Uygulama ile

Özel Entegratör Sisteminin aylık olarak % 99,75 kullanılabilirlik oranı ile hizmet sunacağını taahhüt etmiş midir? 

Başvuru belgeleri kontrol edilecektir.

22

e-Belge üzerinde ödeme türü bilgisine yer verilmiş midir?

Fonksiyonel testler esnasında; e-Belge ve müşteriye verilen/gönderilen belge ve çıktılar incelenerek değerlendirilecektir.

23

e-Belge üzerinde banka/kredi kartı ile yapılan tahsilatlara ilişkin slip temel bilgilerine de yer verilmiş midir?

Fonksiyonel testler esnasında; e-Belge ve müşteriye verilen/gönderilen belge ve çıktılar incelenerek değerlendirilecektir.

24

e-Belge üzerinde KDV oranlarına göre Toplam Satış Tutarı ve Toplam KDV Tutarı bilgisine ayrıca yer verilmiş midir?

Fonksiyonel testler esnasında; e-Belge ve müşteriye verilen/gönderilen belge ve çıktılar incelenerek değerlendirilecektir.

25

İşletici kuruluş, sisteminde yer alan, ödeme kabul eden noktalardaki yazılım ve donanım matrisini sunmuş mudur? Bu matrise ait her bir varyasyonun mali uygulama yazılımının güvenliğini sağlamış mıdır? Mali uygulama yazılımı güvenlik altyapısına ilişkin gerekli dokümanları ve akış diyagramlarını sunmuş mudur?

Başvuru belgeleri kontrol edilecektir. Test Kuruluşu her bir matris için ayrı ayrı sistem fonksiyonel ve güvenlik testlerini tekrar edecektir.

26

İşletici Kuruluş hangi Ödeme/Tahsilat Türlerini desteklemektedir?

Başvuru belgeleri kontrol edilecektir.

27

Üye işyeri anlaşması gerektiren

ödeme/tahsilat türlerinde bu ödeme türünün aktif / pasif hale getirilmesi işletici kuruluş sorumluluğunda gerçekleştirilmekte midir? 

Fonksiyonel testler esnasında; İşletici Kuruluşun desteklediği ödeme türleri için İşletici Kuruluş Sistemlerinden, aktif ve pasif yapılarak kontroller yapılmalıdır. Yalnızca aktif olan ödeme türleri ile işlem yapılabildiği değerlendirilmelidir.       

 

   28

Güvenli Mali Uygulama Günlük Satış Raporunu üretebilmekte midir?

Bu raporları GİB ile GİB'in belirlediği yöntemlerle paylaşabilmekte midir?

Fonksiyonel testler esnasında; Fonksiyonel test süreçleri dokümanında yer aldığı şekli ile, İşletici Kuruluş arayüzleri, veritabanı ve merkezi sistemleri kontrol edilmelidir.

29

Güvenli Mali Uygulama Aylık Satış Raporunu üretebilmekte midir?

Bu raporları GİB ile GİB'in belirlediği yöntemlerle paylaşabilmekte midir?

Fonksiyonel testler esnasında; Fonksiyonel test süreçleri dokümanında yer aldığı şekli ile, İşletici Kuruluş arayüzleri, veritabanı ve merkezi sistemleri kontrol edilmelidir.

30

Güvenli Mali Uygulama İki Tarih Aralığı Satış Raporunu üretebilmekte midir?

Bu raporları GİB ile GİB'in belirlediği yöntemlerle paylaşabilmekte midir?

Fonksiyonel testler esnasında; Fonksiyonel test süreçleri dokümanında yer aldığı şekli ile, İşletici Kuruluş arayüzleri, veritabanı ve merkezi sistemleri kontrol edilmelidir.

31

Güvenli Mali Uygulama Düzenlenen Belgeler Raporunu üretebilmekte midir?

Bu raporları GİB ile GİB'in belirlediği yöntemlerle paylaşabilmekte midir?

Fonksiyonel testler esnasında; Fonksiyonel test süreçleri dokümanında yer aldığı şekli ile, İşletici Kuruluş arayüzleri, veritabanı ve merkezi sistemleri kontrol edilmelidir.

32

Güvenli Mali Uygulama Düzenlenen Bilgi Fişleri Raporunu dönemsel olarak

(Günlük/Aylık/İki Tarih Aralığı şeklinde) üretebilmekte midir?

Bu raporları GİB ile GİB'in belirlediği yöntemlerle paylaşabilmekte midir?

Fonksiyonel testler esnasında; Fonksiyonel test süreçleri dokümanında yer aldığı şekli ile, İşletici Kuruluş arayüzleri, veritabanı ve merkezi sistemleri kontrol edilmelidir.

33

İşletici Kuruluş, Uygulamaya dahil edilen mükellef ile kurulan yazılım arasındaki kimliklendirmeyi sağlamakta mıdır?

Fonksiyonel ve güvenlik testleri esnasında; Test süreçleri dokümanlarında yer aldığı şekli ile, gerekli kimlik doğrulama ve oturum açma yöntemlerinin uygulandığı kontrol edilmelidir.

34

Güvenli Mali Uygulamayı kullanacak mükellefin,  oturum açma ve kimlik doğrulaması için gerekli tedbirler alınmış mıdır? 

Fonksiyonel ve güvenlik testleri esnasında; Test süreçleri dokümanlarında yer aldığı şekli ile, gerekli kimlik doğrulama ve oturum açma yöntemlerinin uygulandığı kontrol edilmelidir.

35

Yarım kalan-sonlanmayan- veya iptal edilen

(Müşterinin vazgeçmesi, tahsilatın yapılamaması, işlemin iptali)  satış işlemlerine ait bilgiler de güvenli şekilde saklanmakta mıdır?

Fonksiyonel ve güvenlik testleri esnasında; ilgili akış olasılıkları uygulanmalı ve bu olasılıklara ait sonuçlar test raporuna yansıtılmalıdır.

 

36

Satış işleminin Ödeme/Tahsilat aşaması gerçekleştirildikten sonra kapatılması sağlanmakta mıdır? 

Fonksiyonel testler esnasında; satış uygulaması üzerinden işlem testleri yapıp gerekli kontroller yapılmalıdır.

37

Güvenli Mali Uygulama aracılığı ile oluşan satış bilgilerinin özel entegratör kuruluşa iletiminde güvenli iletişim yöntemi uygulanmakta mıdır?

Kullanılan güvenli iletişim yöntemine ilişkin gerekli dokümanları ve akış diyagramlarını sunmuş mudur?

Başvuru belgeleri kontrol edilecektir. e-Belge entegrasyonu incelenmelidir. Kullanılan iletişim yöntemi ve güvenlik seviyesi test raporunda yer almalıdır.

38

e-Belge bilgilerinin özel entegratör aracılığı ile müşteriye iletiminde güvenlikli iletim yöntemi uygulanmakta mıdır? 

e-Belge entegrasyonu incelenmelidir. Kullanılan iletişim yöntemi ve güvenlik seviyesi test raporunda yer almalıdır.

39

e-Belge bilgilerinin özel entegratör aracılığı ile satıcıya iletiminde güvenlikli iletim yöntemi uygulanmakta mıdır? 

e-Belge entegrasyonu incelenmelidir. Kullanılan iletişim yöntemi ve güvenlik seviyesi test raporunda yer almalıdır.

40

e-Belge bilgilerinin GİB tarafından sorgulanması ve doğrulanmasına ilişkin web servis kurulmuş mudur?

Fonksiyonel testler esnasında; İşletici Kuruluşun bu servisleri hazırlayıp hazırlamadığı kontrol edilecektir.

Servislerden örnek çağrımlar yapılarak sonuçları test raporuna yansıtılacaktır.

41

e-Belge örneklerinin GİB  sistemlerine aktarımına ilişkin web servis-transfer sistemi kurulmuş mudur?

Fonksiyonel testler esnasında; İşletici Kuruluşun bu servisleri hazırlayıp hazırlamadığı kontrol edilecektir. Servislerden örnek çağrımlar yapılarak sonuçları test raporuna yansıtılacaktır.

42

İşletici kuruluş sistem kapsamında gerçekleştirilen satış, ödeme/tahsilat, eBelge süreçlerinin, kılavuzun "Olay Kayıt Özelliği" başlığında belirtilen şekilde log kayıtlarının tutulmasına yönelik alt yapı kurmuş mudur?

Fonksiyonel testler esnasında; İşletici Kuruluşun merkezi sistemi ve uç nokta yazılımları kontrol edilecek, Olay Kayıt Özelliği test edilecektir. Geçmiş 10 yıl verisi için merkezi sistemde gerekli mimarinin kurgulanmış olduğu başvuru dokümanları ve merkezi sistem mimarisi incelenerek raporlanacaktır.

43

Avans tahsilat işleminde düzenlenen Bilgi Fişi'nde ilgili kılavuzda belirtilen gerekli bilgileri barındırmakta mıdır?

Fonksiyonel testler esnasında; İşletici Kuruluş destekliyorsa Bilgi Fişi ve çıktıları incelenecektir.

44

Cari Hesap Tahsilat işleminde düzenlenen Bilgi Fişi'nde ilgili kılavuzda belirtilen gerekli bilgileri barındırmakta mıdır?

Fonksiyonel testler esnasında; İşletici Kuruluş destekliyorsa Bilgi Fişi ve çıktıları incelenecektir.

45

Yemek Kartı ile Yapılan Tahsilat işleminde düzenlenen Bilgi Fişi'nde ilgili kılavuzda belirtilen gerekli bilgileri barındırmakta mıdır?

Fonksiyonel testler esnasında; İşletici Kuruluş destekliyorsa Bilgi Fişi ve çıktıları incelenecektir.

 

46

Fatura Tahsilatı işleminde düzenlenen Bilgi Fişi'nde ilgili kılavuzda belirtilen gerekli bilgileri barındırmakta mıdır?

Fonksiyonel testler esnasında; İşletici Kuruluş destekliyorsa Bilgi Fişi ve çıktıları incelenecektir.

47

Sistemin Otopark uygulamalarında kullanılması durumunda, araç giriş işlemleri

Otopark Giriş Bilgi Fişi ile belgelendirilmekte midir? 

Fonksiyonel testler esnasında; İşletici Kuruluş destekliyorsa Bilgi Fişi ve çıktıları incelenecektir.

48

Sistemin Otopark uygulamalarında kullanılması durumunda, araç çıkış işlemleri e-Belge (e-Fatura ya da e-Arşiv Fatura) belgelendirilmekte midir? 

Fonksiyonel testler esnasında; İşletici Kuruluş destekliyorsa e-Belge entegrasyonu ve çıktıları incelenecektir.

49

Vergiler dahil belli tutarı (500 TL) aşan eArşiv Faturalarda müşterinin Adı-Soyadı bilgisi için kontrol uygulanmakta mıdır? 

Fonksiyonel testler esnasında; e-Belge entegrasyonu ve çıktıları incelenecektir.

50

Sistemden yararlanmak isteyen mükellefin sisteme kayıt bilgilerinin GİB'e elektronik ortamda bildirimi için alt yapı tesis edilmiş midir?

İşletici kuruluşlar, sisteme dahil ettiği veya sistemden çıkardığı (sözleşmesin feshi veya sona ermesi nedeniyle) mükelleflerin bilgilerini yine “e-Fatura Uygulaması Özel Entegrasyon Kılavuzunda” açıklanan şekilde mükellef hesabının kapatılması için HR.xml dosyası elektronik ortamda Başkanlığa aynı gün iletilmek zorundadır. 

 

GİB'e ilgili bağlantılar sağlandığında iletilebileceğinin gösterilmesi yeterlidir.

51

İşlemler; satış, ödeme, e-Belge oluşturma süreçleri bütüncül olarak yönetilmekte midir?

Satış İşlemleri (Satışın başarılı olabilmesi için her üç işlemin de başarılı olduğu) İptal İşlemleri (İptal işleminin her üç işlem için de ortak yapıldığı; satış iptal, ödeme iptal, e-Belge iptal.)

İade İşlemleri (İade işleminin her üç işlem için de ortak yapıldığı; satış iade, ödeme iade, e-Belge iptal.)

Fonksiyonel testler esnasında; Tüm işlem türleri test edilecek ve sonuçları değerlendirilecektir. Uç noktadan yapılan işlemler merkezi sistemde İşletici Kuruluş arayüzleri üzerinde kontrol edilecek ve her üç işlemin de eşleştiği ve bu şekilde raporlanabildiği görülecektir.

 

52

Veri bütünlüğü uç noktadan merkezi sisteme, oradan da 3rd servislere kadar, uçtan uca ve güvenli bir şekilde sağlanmış mıdır? (Uç noktadaki verinin, (örneğin tutar verisi) merkezi sistemde ve verinin aktığı her yerde aynı değerde olması kontrolü sağlanmalıdır.)

Veri aktarımında; karşı taraf doğrulama, şifreleme, hash ve uç nokta doğrulama gibi yöntemler hangilerinin kullanıldığı tespit edilecek ve bu bilgilere ayrıntılı bir şekilde raporda yer verilecektir.

 

53

TCKN, e-posta, telefon numarası, adres, kart numarası gibi hassas veriler saklandığı noktalarda anahtar kullanılarak şifreli bir şekilde güvenli ortamlarda saklanmış mıdır?

İşletici Kuruluş Merkezi sistemi veritabanı ve dosya sunucuları üzerinde hassas verilerin tutulma yöntemleri incelenecektir. Verilerin saklandıkları yerde şifreli olduğu görülmelidir. Bu verilerin açık halde hiç bir ortamda saklanmadığı kontrol edilecektir. Bu bilgilere ayrıntılı bir şekilde raporda yer verilecektir.

54

TCKN, e-posta, telefon numarası, adres, kart numarası gibi hassas verilerin yetki bazlı olarak erişilebildiği, erişen sistem kullanıcının iz takibinin yapılabildiği bir altyapı kurgulanmış mıdır?

Hassas verilere erişim iz takibi ile erişim yapılabilmelidir. Kullanıcı arayüzü üzerinden yapılan erişimler test edilmeli, iz takibinin yapılabildiği görülmelidir. İz kayıtlarının da ayrıca korunduğu gözlemlenmelidir.

55

TCKN, e-posta, telefon numarası, adres, kart numarası gibi hassas verilerin raporlara veya yetki bazlı olmayan erişimlere açık değer olarak değil, maskeli olarak veya özet/hash değerleri ile yansıtılması sağlanmış mıdır?

Hassas verilere yetki bazlı olmayan, raporlama vb. amaçlı erişimler isteniyorsa; verinin saklandığı yerlerde yalnızca maskeli ve özet hali ile görülebildiği gözlemlenmelidir.

56

Sisteme ait Sertifika Yönetimi ile ilgili; gerekli dokümanlar ve akış diyagramları sunulmuş mudur?

Başvuru belgeleri kontrol edilecektir.

57

Sertifikasyon sürecinde kullanılmak üzere, sistem işleticisine ait private anahtarı güvenli olarak oluşturulabilmekte midir?

Kılavuzda yer alan HSM cihazları kullanılmalıdır.

 Anahtarlar doğrudan cihazlar üzerinde rasgele

üretilmelidir. Anahtarın cihazdan yetkisiz bir şekilde çıkarılamayacak özellikte tanımlandığı kontrol edilmelidir.

58

GİB'in belirlediği sertifika otoritesine gönderilmek üzere sertifika talebi yapılabilmekte midir?

Kılavuzda yer alan sertifika talep dosyası üretimi gösterilmelidir. Talep dosyasının formatı ve doğruluğu kontrol edilmelidir.

59

GİB'in belirlediği sertifika otoritesinden gelen sertifika sisteme yüklenebiliyor mu?

Kılavuzda yer alan sertifikanın sisteme

tanımlanabildiği gösterilmelidir. Sisteme tanımlanan sertifikanın formatı ve doğruluğu kontrol edilmelidir.

 

60

Sistem ve güvenli mali uygulama, sertifika geçerlilik süresi kontrolü yapıyor mu?

Sistem saati ileri alınarak sertifika geçerlilik kontrolü yapılıp yapılmadığı gözlemlenmelidir.

61

Sistemin kurulu olduğu merkezde anahtar yönetimi ve şifreleme işlemleri için HSM cihazları kullanılmakta mıdır?

Kullanılan HSM cihazlarının Ortak

Kriterler EAL4+ sertifikası var mıdır?

Hassas verilerin şifrelenmesi, sertifika yönetimi, işlem imzalama gibi İşletici kuruluş sistemleri tarafından yapılan kriptografik işlemlerde HSM cihazlarının kullanıldığı gösterilmelidir. 

 

Sistem testleri esnasında işlemler yapılarak; HSM

Cihazına giden/gelen işlem logları incelenmelidir.

 

Satış İşlemleri, Mükellef tanımlama işlemleri, Sertifika talebi işlemleri vb. yapılan işlem ve sonuçlarına raporda yer verilmelidir.

62

Sisteme ait uç nokta güvenliği ile ilgili; gerekli dokümanlar ve akış diyagramları sunulmuş mudur?

Başvuru belgeleri kontrol edilecektir.

63

Sistemim bir bütün olarak; uç noktada çalışan (web tabanlı olsun veya olmasın) her bir uygulama için, uygulamanın çalıştığı ortama ait fingerprint verilerini kullanılarak, mali uygulamanın uç noktada güvenli bir şekilde çalışmasını ve uç nokta doğrulamasını sağlayabiliyor mu?

Sistemde uç noktada kullanılan fingerprint verileri ve bunların kullanım yöntemleri incelenmelidir.

Fingerprint veri ile bir anahtar kullanılarak verilerin korunma yöntemi yapılıp yapılmadığı kontrol edilmelidir. Kaynak kodlarda gömülü olarak anahtar tutulmadığı kontrol edilmelidir. Raporda kullanılan yöntemlere ve bu bilgilere açık bir şekilde yer verilmelidir.

64

Uç nokta doğrulamasında OTP, Push

Notification vb. harici güvenlik önlemleri var mı?

Servis altyapısı incelenmelidir.  Mimari incelenmelidir.

İşlem testleri yapılarak kontrol edilmelidir.

65

Uç nokta ile merkezi sistemin iletişiminde en az TLS 1.2 kullanılıyor mu?

 Merkezi sistemde SSL sonlandırma ortamında ilgili tanımlamaların yapıldığı kontrol edilmelidir. TLS 1.1 ve altına izin verilmediği tanımlarda görülmelidir.

66

Uç nokta ile merkezi sistemin iletişiminde TLS 1.2 içerisinde akan verinin şifrelenmesi için işleme özel türetilmiş AES 256 bir anahtar kullanılıyor mu?

Örnek bir işlemde TLS içerisinde akan verinin şifreli olduğu ve hangi yöntem kullanıldığına ilişkin detaylara yer verilmelidir.

67

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalar bir veri tutuyorsa, bu verilerin saklanmasında anahtar kullanılıyor mu?

Anahtar kullanılıp kullanılmadığı kontrol edilmelidir. Kullanılıyorsa kod analizinde anahtarın saklanma yöntemi kontrol edilmeli ve güvenlik derecesi raporlanmalıdır.

 

68

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda; kullanıcı adı, şifre, anahtar, kişisel veriler, mali veriler vb.

hassas bilgiler saklanıyorsa veya işleniyorsa bu veriler güvenli bir şekilde saklanıyor/korunuyor mu?

Hassas bilgi saklanıyorsa(ssl pinning sertifikası, user, pass, url, IP, TCKN, mali bilgiler, olay kayıtları..), kod analizinde verilerin saklanma yöntemi kontrol edilmeli ve güvenlik derecesi raporlanmalıdır. Veri saklanması esnasında anahtar kullanımı ve fingerprint kullanımına ilişkin detaylara raporda yer verilmelidir.

69

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, Root Detection yapılıyor mu? (Uygulamasının rootlanmış cihazlarda çalışmasını engelleyebilmelidir.)

Uygulama web tabanlı değilse, Rootlanmış bir cihazda veya test tool u ile uygulamanın uç noktada çalışmadığı kontrol edilmelidir.

 

Web tabanlı ise yapılabilecek kontrollerin yapılıp yapılmadığı raporlanmalıdır.

70

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, Device Identification yapılıyor mu? 

Hangi cihaz verilerinin nasıl kullanıldığına raporda detaylı bir şekilde yer verilmedilir. Cihaz verilerin merkezi sisteme aktarılması ve doğrulanması yöntemleri incelenmelidir. 

Uygulamasının kurulduğu cihazı tanımlayabilecek veriler kullanıldığı incelenmelidir.

Kod analizi esnasında bu kısma yer verilmelidir.

71

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, Geolocation yapılıyor mu? 

 Geolocation yapılıyorsa farklı bir lokasyonda çalışıp çalışmadığı test edilmeli ve sonuçları raporlanmalıdır. Uç nokta uygulaması başarılı kurulmuş bir uygulama gibi davranıp farklı lokasyondan işlem yapmasına müsaade etmemelidir.

72

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, Device Binding yapılıyor mu?

 Uygulaması ile kurulduğu cihazı birbirine bağlayan eşsiz bir imza üretmeli ve yapılan bir işlemin ilgili cihaza kurulu uygulamadan gerçekleştirildiğini garanti etmelidir

73

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, Whitebox Cryptography Storage/Secure Storage kullanılıyor mu?

Bu yöntem ile uygulama; üzerinde saklanması gereken hassas verileri güvenli şifreleme algoritmaları ile şifreli ve sadece uygulamanın güvenli bir şekilde okuyabileceği ve başka bir şekilde ulaşılamayan bir alt yapı ile saklar.

Merkezi sisteme bağlantı için kullanılan API anahtarı, API Kullanıcı kodu, API şifresi, Merkezi sistem adresi(URL, IP, Port ) vb. bilgiler uç noktada güvenli bir şekilde saklanmalıdır. 

 

Çevrim dışı çalışan cihazlarda SAM kart, secure element vb. donanımsal bir kripto ortamı yoksa yazılımsal kripto kullanımı kontrol edilmeli ve raporlanmalıdır. Uygulama, uygulamaya ait özel anahtarı güvenlik sunucusu ile ilişkilendirecek, hiçbir şekilde açık olarak cihaz üzerinde depolamayacaktır.

 

 

   74

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda,  Secure Channel kuruluyor mu? 

SSL içerisinde akan veri için ikinci bir şifreleme olarak;

Uygulamanın sunucu ile olan iletişimini gizlilik ve bütünlük açısından gerekli asimetrik ve simetrik şifreleme algoritmaları ile koruyacağı güvenli bir kanal üzerinden sağlanıyor mu?

75

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, Anti-Debugging yapılıyor mu? 

Uygulamanın bir debugger ile analiz edilmesinin engellenmiş olduğu kontrol edilmelidir.

76

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, Detect Emulator yapılıyor mu? 

Uygulamanın bir emulator üzerinde çalışmasının engellendiği kontrol edilmelidir.

77

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, Detect-Hooking yapılıyor mu? 

Uygulamaya ait fonksiyonlarının harici bir fonksiyonla çalışma zamanında değiştirilmesini engellediği kontrol edilmelidir.

78

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, Detect Repackaging yapılıyor mu? 

Uygulamanın kodlarının çözülüp tekrar paketlenmesini tespit edip çalışmasını engellediği tespit edilmelidir. (özet vb. yöntemler ile)

79

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, Secure RunTime Memory yapılıyor mu?

Uygulamanın çalışma zamanında kullandığı hafıza alanından hassas verilerin alınmasını engelleyecek şifreleme, karıştırma ve diğer sisteme bağlı tedbirleri içerdiği kontrol edilmelidir. Bu madde için kod analizi de yapılıp raporda yer verilmelidir.

80

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, Runtime CRC Check yapılıyor mu?

Uygulama, uygulama çalışma zamanında yüklenen uygulama kodunun değişmesini kontrol edip çalışmasını durduracak ve bu durumu uzak sunucuya raporlayacaktır. Bu madde için kod analizi de yapılıp raporda yer verilmelidir.  

 

    81

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, OTP yapılıyor mu?

Uygulama ihtiyaç duyduğu işlemlerde OTP doğrulaması yapabilmelidir. Bu işlemler ilklendirme, ilk defa login, hassas veri işlemleri, büyük ölçülü işlemler vb. olabilir. SMS, Soft veya e-Mail ile OTP doğrulaması yapılabilir.

82

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, Push Notification yapılıyor mu? 

Sistem destekliyorsa, uygulama ihtiyaç duyduğu işlemlerde Push Notification doğrulaması yapabilmelidir. Örneğin login adımında Push Notification kullanılması gibi.

83

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, Applicationbinding yapılıyor mu? 

Uygulama içerisindeki kritik fonksiyonların dışarıdan izinsiz bir şekilde tetiklenmemesi, Fonksiyonların kendi uygulamasının dışında bir uygulama ile çalışmaması testleri yapılmalıdır. Raporda bu kısma yer verilmelidir.

84

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, Code Obfuscation and Diversification / Code Lifting yapılıyor mu?

Uygulama kodları tersine mühendislik ve statik kod analizleri ile açığa çıkmamalıdır. Bunun için kullanılan tool ve yöntemler incelenmelidir.

85

Uç noktada çalışan (web tabanlı olsun veya olmasın) uygulamalarda, SSL-pining yapılıyor mu?

 Uygulamasının sunucu ile olan iletişiminde kendi özel sertifikalarını kullanacak ve bunların güvenliğini ve bütünlüğünü garanti edecektir. Uygulama, kendi güvenli ve şifreli sertifika deposunu kullanacak, işletim sistemine ait sertifika deposunu

kullanmayacak ve tanımlı kök sertifika otoritelerine güvenmeyecektir.

 

Bu kısım için test raporunda detaylı bilgi verilecektir.

86

GMU da, Transaction Data Signing yapılıyor mu? 

 Uygulama, işlemlerin takibi için dijital olarak her işlemi imzalayacak ve bu imzayı sunucuda saklayacaktır. 

 

İmzalı işlemler testler esnasında kontrol edilecektir.

87

Sisteme ait dışarıya açılan tüm servisler için sızma testleri yapılmış mıdır?

Sızma testi Test Kuruluşu tarafından da yapılabilir veya Sızma Testi raporları kontrol edilebilir.

88

Sisteme ait işlem esnasında kullanılan tüm servisler için yük testleri yapılmış mıdır?

Yük testi Test Kuruluşu tarafından da yapılabilir veya Yük Testi raporları kontrol edilebilir.

89

Sisteme ait servisler için fonksiyonalite testleri yapılmış mıdır?

Fonksiyonel test süreçleri dokümanında yer alan testler yapılmalıdır.

90

Sisteme ait servisler için selftest modülü var mıdır?

Self test modülleri ile testlerin yapılabildiği görülmelidir ve sonuçları incelenmelidir. Test raporunda self test sonuçlarına yer verilmelidir.

91

Sistem işleticisinin, test ortamı var mı?

Testler esnasında görülmelidir. Ortam gereksinimleri başvuru dokümanı ve Kılavuz bütüncül olarak incelenerek belirlenmelidir. Ortama ilişkin bilgiler raporlanmalıdır.

91

Sistem işleticisinin, canlı ortamı yedekli mi?

Başvuru belgeleri kontrol edilecektir.

93

Sistem işleticisinin, FKM ortamı var mı?

Başvuru belgeleri kontrol edilecektir.

94

Sistem işleticisi, GİB tarafından saklaması gereken verileri güvenli bir şekilde ve yedekli olarak saklayabilecek bir altyapı ve yazılım mimarisi kurgulamış mı?

Başvuru belgeleri kontrol edilecektir.

95

Sistem işleticisi, sakladığı verilere ilişkin hash değerlerini, zaman, tutar ve id alanlarını içerecek şekilde ve değişmezliğini temin edecek güvenlik seviyesinde, anahtar kullanarak saklıyor mu?

Sistemin merkez mimarisi ve veritabanı incelenecek  kılavuzda geçen verilerin fonksiyonel ve güvenlik kriterlerine uygun şekilde saklandığı kontrol edilecektir.

96

Sistem işleticisi, GİB' in talep ettiği verileri sisteminden GİB'e ulaşana kadar güvenli bir şekilde iletilmesini sağlıyor mu?

GİB' e sunulan servislerin güvenliği ve kullanılan yöntemler incelenecektir.

97

Sistem işleticisi, GİB' in belirlediği otoritelere test ve doğrulama aşamalarında sunduğu verileri, kişisel verilerin güvenliğini bozmayacak şekilde ve güvenli bir ortamda sunuyor mu?

Denetçi ve otorite kuruluşlarına açılan verilerin, kişisel verilerin güvenliğini bozmayacak şekilde incelemeye sunulduğu gösterilmelidir.

98

Sistem işleticisi, 3rd entegrasyonlarında kendi sağladığı hizmetler için veri güvenliğini uçtan uca sağlıyor mu?

3rd entegrasyon servislerinin güvenliği ve kullanılan yöntemler incelenecektir.

 


 

GELİR İDARESİ BAŞKANLIĞI

Güvenli Mobil Ödeme ve Elektronik Belge Yönetim Sistemi 

İşletici Kuruluş Sistemi Fonksiyonel Test Süreçleri

Dokümanı

 

 

Versiyon 1.0

(21.05.2020)

1) GİRİŞ

Bu doküman, İşletici Kuruluşlar ile Başkanlık tarafından Sistemi test etmek üzere yetkilendirilmiş test kuruluşları için düzenlenmiştir. İşletici Kuruluşların Sistemlerine ait fonksiyon testleri bu doküman temel alınarak yapılmalı ve raporlanmalıdır. 

Test Kuruluşu, raporunu oluştururken bu doküman yanında Güvenli Mobil Ödeme ve Elektronik Belge Yönetim Sistemi Başvuru, İzin, Onay ve Denetim Süreçleri Kılavuzundan (“Kılavuz”) da yararlanmalı ve ürettiği sonuçların Kılavuz ile uyumlu olduğunu dikkate almalıdır. 

Test Kuruluşu yapmış olduğu testler sonucunda ilgili konulardaki uyumluluğun sağlandığını teyit edeceğinden, kendisinin uygun göreceği ya da test esnasında ortaya çıkan ve detaylandırılması gereken konularda ek testler yapabilir. Test Kuruluşu, Kılavuz ve bu doküman gereksinimleri ile bütünlük içinde değerlendirmesi sonucunda düzenlemiş olduğu raporun eksiklik, belirsizlik ve tutarsızlık içermeyen doğru bilgilerle oluşturulduğunu taahhüt eder.

İşletici Kuruluş, test süre ve süreçlerinin uzamasından kaçınmak amacıyla, Test Kuruluşu ile gerekli iş birliğini yapmalı, Test Kuruluşu tarafından talep edilen bilgi ve belgeleri zamanında ve eksiksiz şekilde sağlamalıdır. Test Kuruluşunun yapacağı kod analizi testleri için; İşletici Kuruluş bu analize katılarak kodlarını açabileceği gibi dilerse kodlarını Test Kuruluşuna teslim ederek kod analizinin Test Kuruluşu tarafından yapılmasını sağlayabilir.

 

2) AMAÇ

Güvenli Mobil Ödeme ve Elektronik Belge Yönetim sistemini sunan kuruluşların, sistem kapsamında hizmet verecekleri mükelleflerin ticari hayatında bir kesintiye sebebiyet vermeyecek ve vergide kayıp kaçağına yol açmayacak şekilde yazılımlarını geliştirmeleri gerekmektedir. Bu doküman ile “Kılavuz” ile uyumlu, sistemi sunmak için gerekli olan minimum fonksiyonların sorunsuz bir şekilde çalıştığı ve mükellefi, sistemi kullandığı durumda müşterisi ve Gelir İdaresi Başkanlığı karşısında ticari ve mali olarak zor durumda bırakmayacak bir sistem için fonksiyonel testlerin içerikleri aktarılmaktadır. İşletici Kuruluşun vergi kayıp kaçağına yol açmayacak şekilde bir sistem sunması asli sorumluluğu olmakla birlikte, bu testler ile sadece İşletici Kuruluşun sunduğu sistemin temel işlevlerinin test edilmesi amaçlanmaktadır. Uyumluluk testlerinin sonuçlarından bağımsız olarak, İşletici Kuruluşu işlemlerin bütünlüğü ve güvenliği konusundaki asli sorumluluğu devam etmektedir.

 

3) TEST RAPORU ve İÇERİĞİ

Test Kuruluşunun yapacağı testler sonucunda düzenleyeceği rapor, fonksiyonel gerekliliklere uygunluğu göstermelidir. Test uzmanı uygun testleri belirlemeli ve test gerekliliklerinin ve yöntemlerinin test gerekliliklerine dayanarak neden geçerli olduğunu belgelemelidir. Her test gereksinimi için raporda belirtilen değerlendirme sonuçları, anlaşılması ve doğrulanması için yeterli kanıtla desteklenmelidir. 

Test raporunda fonksiyonel test sonuçları maddeler halinde yer almalıdır. Ancak test sonucuna ilişkin bir hüküm yer almamalıdır. Varsa kritiklik seviyelerine göre bulgular ve bulgulara sebep olan açıklamalar ile birlikte yer almalıdır.

Yine test raporunda bulgulara ilişkin çözüm önerileri ve yönlendirmelere ilişkin açıklamalar da yer alabilir. 

Test Kuruluşu tarafından düzenlenen ve Başkanlığa iletilen raporun sonucunda Başkanlık aşağıdaki üç duruma karar verebilir:

  • İşletici Kuruluş fonksiyonel testlerinin başarılı bulunup, test onayının verilmesi.
  • İşletici Kuruluş fonksiyonel testlerinin kısmen başarılı bulunup, geçici onay verilmesi ve 3 ay içerisinde tekrar test sürecine girilmesini talep etmesi.
  • İşletici Kuruluş fonksiyonel testlerinin başarısız bulunup, tekrar test sürecine girilmesini talep etmesi.

4) TEST GEREKSİNİMLERİ VE ADIMLARI

Bu bölümün amacı, Sistemin Kılavuzda tanımlandığı şekilde çalıştığını güvence altına almak için bir takım ilke ve gereksinimleri uygun şekilde test edilmesini sağlamaktır. Bu bölümde açıklanan fonksiyonel gereksinimlere dair testler, işlemlerin bütünlüğü ve güvenliğini ön planda tutarak, Sistemin fonksiyonel olarak doğru çalıştığını ve mükellefin sistemi kullanırken mali ve ticari bir sorun ile karşılaşmadığını sınar. Test Kuruluşu, bu bölümde ana hatları verilen test gereksinimlerini baz alarak kendi yöntem ve araçları ile testlerini yapar. Test Kuruluşunun görevi yaptığı sınamalardan elde ettiği sonuçları objektif bir şekilde sonuç raporuna yansıtmasıdır.

Fonksiyonel testler, güvenli mali uygulamanın sistemin merkezinde olduğu ve bütün süreci yönettiği, satış uygulaması, ödeme uygulaması ve e-belge süreçlerinin fonksiyonel olarak sorunsuz çalıştığı bir ortamın testlerinden oluşmaktadır.

Başkanlık, gerekli gördüğü durumlarda, yeni fonksiyonel gereksinimleri test kuruluşuna bildirebilir. Bu durumda, test kuruluşu bu yeni fonksiyonlar için gerekli test ortamını oluşturmak durumundadır.  

İşletici Kuruluşun Sisteminin aşağıda sıralanan tüm bu bölümlerdeki testleri başarı ile tamamlaması beklenmektedir. Bu testler, işletici kuruluşun başvuru formunda belirttiği özellikler kapsamında yapılır.

  • Genel İşlem Akışı
  • E-belge Üzerinde olması gereken bilgiler
  • Vergi Hesaplama
  • Ödeme Türleri
  • Bilgi Fişleri
  • Raporlar
  • Olay Kayıtları
  • İşletici Kuruluş Veri Tabanı İle Yapılan İşlemler
  • Güvenli Mali Sertifika
  • Yazılım Güvenliği
  • Erişim Kontrolü
  • Kimlik Doğrulama
  • Oturum Açma ve Oturum Kimliği Doğrulama
  • Mükellef Kayıt İşlemleri

A. GENEL İŞLEM AKIŞI

1. İşletici Kuruluş Sistemi Fonksiyonları

  • Test Kuruluşu, Sistemin çalışma şekli ile ilgili İşletici Kuruluşun sunduğu akış diyagramlarını ve “Kılavuz” ile uygunluğunu kontrol eder.
  • Sistemin bütüncül olarak; GMU, Satış Uygulaması ve e-Belge işlemlerini doğru ve güvenli bir şekilde sağladığını kontrol eder.

2. Güvenli Mali Uygulama (GMU) Fonksiyonları

  • Test Kuruluşu, sistemin yöneticisi konumundaki bileşeni olan Güvenli Mali Uygulamanın çalışma şekli ile ilgili İşletici Kuruluşun sunduğu akış diyagramlarını ve “Kılavuz” ile uygunluğunu kontrol eder.
  • Test Kuruluşu, Sistemin Güvenli Mali Uygulama olmadan mali ve finansal işlemleri yapamadığını test eder.
  • Test Kuruluşu, satış, ödeme ve e-Belge oluşturma süreçlerinin bütüncül olarak GMU tarafından yönetildiğini test eder.
  • Test Kuruluşu, satış iptal, ödeme iptal ve e-belge iptal süreçlerinin bütüncül olarak GMU tarafından ve vergi kayıp kaçağına yol açmayacak şekilde yönetildiğini test eder.
  • Test Kuruluşu, GMU’nun negatif işleme izin vermediğini test eder.
  • Test Kuruluşu, GMU’nun vergisel bölümlemeler dâhil işlemlerini doğru bir şekilde yaptığını test eder.
  • Test Kuruluşu, GMU tarafından mükellefiyet seçiminin yapılabildiğini ve belgelerin bu mükellefiyet durumuna göre düzenlendiğini test eder.
  • Test Kuruluşu, GMU’da mal ve hizmetlerin tanımlanabildiğini (Mal veya Hizmetin Adı, Birim Ölçüsü, Barkodu/Standart Kodu, Birim Fiyatı, KDV Oranı, ÖTV Oranı) veya GMU’nun bu tanımlamaları dâhili veya harici satış uygulamasından işlem sırasında alarak işlem yapabildiğini test eder.

3. Dahili/Harici Satış Uygulaması Entegrasyonu

  • Test Kuruluşu, dahili satış uygulamasının veya entegre edilmiş harici satış uygulamasının kendi başına işlemi sonlandırmadığını, GMU’dan bağımsız olarak işlem yapamadığını test eder.
  • Test Kuruluşu, başlayan bir mali işlemin iptal edilmesi durumunda Kılavuza uygun şekilde kayıt altına alınabildiğini test eder.
  • Test Kuruluşu, Harici Satış Uygulaması Kullanılması durumunda, harici satış uygulaması ile GMU arasındaki iletişim nasıl sağlandığı, “Kılavuz” da belirtildiği şekilde bu bağlantının güvenliğini test eder.

4. Ödeme Uygulaması Entegrasyonu

  • Test Kuruluşu, Ödeme Uygulamasının GMU’dan bağımsız ödeme veya iptal/iade alamadığını, ödeme işlemini sadece GMU’dan gelen tutar ile yapabildiğini test eder.

5. E-Belge Entegrasyonu

  • Test Kuruluşu, Ödeme/Tahsilat işlemi ardından belge içerik bilgilerinin GMU tarafından özel entegratör sistemlerine anlık olarak aktarıldığını test eder.
  • Test Kuruluşu, Çevrimiçi sistemlerde belge içeriklerinin özel entegratöre anlık olarak aktarılması ardından e-Belgenin özel entegratör sistemlerinde anlık olarak oluşturulduğunu test eder.
  • Test Kuruluşu, Çevrimiçi sistemlerde GMU’nun Özel Entegratör ile bağlantısını sürekli kontrol ettiğini, özel entegratör ile bağlantı olmadığı durumda satış işlemine izin vermediğini test eder.
  • Test Kuruluşu, Çevrimiçi sistemlerde GMU’nun cihazın çevrim içi olmadığı durumda, sistemin çalışmasını engellediğini test eder.
  • Test Kuruluşu, Çevrimdışı sistemlerde GMU’nun güvenli bir şekilde çalıştığını ve gerekli fonksiyonaliteyi sağladığını başvuru dokümanlarına göre test eder.
  • Test Kuruluşu, düzenlenen e-belgenin müşteriye iletiminde “Kılavuz” ve 507 Sıra No.lu VUK Genel Tebliği içerisinde belirtilen yöntemler ile müşteriye iletilebildiğini test eder.
  • Test Kuruluşu, ödeme işlemi tamamlandıktan sonra, e-belgenin Özel Entegratöre gönderilemediği durumunda, e-belgeyi Özel Entegratör bağlantısı kurulduğu anda iletebildiğini test eder.
  • Test Kuruluşu, vergiler dahil belli tutarı (500 TL) aşan e-arşiv fatura düzenlemesinde mutlaka müşterinin Adı-Soyadı Bilgisinin girilmesinin zorunlu olduğunu test eder.
  • Test Kuruluşu, oluşturulan e-belgelerin GİB şematron kontrolünden geçirildiğini test eder.

 

B. E-BELGE ÜZERİNDE BULUNMASI GEREKEN BİLGİLER

E-belge üzerinde aşağıdaki bilgilerin bulunması gerekmektedir. Test kuruluşu sistemin çıktısı olan e-belge üzerinde bu bilgilerin bulunduğunu test eder.

  • Satışı gerçekleştirilen mal veya hizmetin özel ve somut adı veya Kılavuzda geçen şekli
  • Ödeme türü (Parçalı ödeme durumunda farklı ödeme türleri)
  • GMU Yazılım Sürüm Bilgisi
  • İşletici Kuruluş ismi
  • Ödemenin bir finansal kuruluş üzerinden yapıldığı durumda slip temel bilgileri
  • e-Belge uygulamalarına ilişkin olarak ilgili mevzuatlarında (Kanun, Genel Tebliğ ve
  • Teknik Kılavuzlarda) belirtilen şekil şartlara uygun mali veriler
  • Basit Usul mükelleflerinin düzenleyeceği Fatura belgesinde KDV istisnasının uygulanması

 

C. VERGİ HESAPLAMA

  1. Test Kuruluşu, GMU’nun mali işlemlere ilişkin vergisel hesaplamaları vergi kayıp kaçağına yol açmayarak doğru bir şekilde yaptığını test eder.
  2. Test Kuruluşu, GMU’nun farklı mali işlemlere ait farklı e-Belge tipleri için doğru vergileri ve vergi oranlarını kullanabildiğini test eder.
  3. Test Kuruluşu, GMU’nun farklı vergi tip ve oranlarını ayrı ayrı ve toplam olarak doğru şekilde hesaplayabildiğini test eder.
  4. Test Kuruluşu, GMU’nun belge toplamına ait yüzdesel ve tutar bazında indirim ve artırım işlemlerinde farklı vergisel oranlara göre dağıtımı doğru bir şekilde yaptığını test eder.
  5. Test Kuruluşu, GMU’nun satıra ait yüzdesel ve tutar bazında indirim ve artırım işlemlerinde farklı vergisel oranlara göre dağıtımı doğru bir şekilde yaptığını test eder.
  6. Test Kuruluşu, GMU’nun ara toplama ait yüzdesel ve tutar bazında indirim ve artırım işlemlerinde farklı vergisel oranlara göre dağıtımı doğru bir şekilde yaptığını test eder.
  7. Test Kuruluşu, KDV tevkifatının vergi kayıp kaçağına yol açmayacak şekilde ve doğru oranlarla hesaplanabildiğini test eder.
  8. Test Kuruluşu, vergisel işlemlerde yuvarlama hesaplamalarının vergi kayıp kaçağına yol açmayacak şekilde yapıldığını test eder.

 

D. ÖDEME TÜRLERİ

1. Test Kuruluşu tarafından aşağıdaki ödeme tiplerinin tamamının GMU tarafından tanımlanabildiği test edilmelidir.

 1.1 Aşağıdaki ödeme tipleri zorunlu olarak sistemde tanımlı olmalıdır. İşletici Kuruluş altyapısı hangilerini destekliyorsa bunlar test edilmelidir.

  • Nakit
  • Senet
  • Çek
  • Açık Hesap
  • Kredili
  • Havale/EFT

 1.2. Aşağıdaki ödeme tipleri zorunlu olarak sistemde tanımlı olması gerektiği yanında (İşletici Kuruluş altyapısı hangilerini destekliyorsa bunlar test edilmelidir), üye işyeri anlaşması olması veya olmaması durumuna göre işletici kuruluş tarafından aktif veya pasif hale getirilebilmelidir.

  • Banka/Kredi Kartı
  • Yemek Kartı ve Çekleri
  • Belediye Ulaşım Kartları, Yardım Kartları ve Çekleri
  • Hediye Kartı

2. Test kuruluşu, her bir ödeme türü için, sistem kapsamında mali bir belge ile eşleşmeyen hiçbir ödeme/tahsilat işleminin yapılamadığını test etmelidir.

 

E. BİLGİ FİŞLERİ

  1. Test Kuruluşu, Sistemin, vergiden muaf esnaflara kullandırılması durumunda, GMU’nun gerçekleştirilen satış işlemi için vergiden muaf esnafın, belge düzenleme zorunluluğu bulunmadığından, satış işlemine ait bilgilerin (Satışı gerçekleştiren vergiden muaf esnafın bilgileri, satışa konu mal veya hizmetin bilgileri, tutarları) yer alacağı ve mali değeri bulunmayan, bilgi amaçlı “Bilgi Fişi” düzenlenmesini yapabildiğini test eder.
  2. Test Kuruluşu, Sistem destekliyorsa; “Kılavuz” da tanımlanan şekilde Ön Tahsilat (Avans) Bilgi Fişinin GMU tarafından üretilebildiğini test eder.
  3. Test Kuruluşu, Sistem destekliyorsa; “Kılavuz” da tanımlanan şekilde Cari Hesap Tahsilat Bilgi Fişinin GMU tarafından üretilebildiğini test eder.
  4. Test Kuruluşu, Sistem destekliyorsa; Yemek Kartı ile yapılan tahsilat işlemlerinde,
  5. “Kılavuz” da tanımlanan şekilde Yemek Kartı Bilgi Fişinin GMU tarafından üretilebildiğini test eder.
  6. Test Kuruluşu, “Kılavuz” da tanımlandığı şekilde Fatura Tahsilat Bilgi Fişinin GMU tarafından üretilebildiğini test eder.
  7. Test Kuruluşu, Sistem destekliyorsa; sistemin Otopark uygulamalarında kullanılması durumunda, araç giriş işlemleri için GMU’nun Otopark Giriş Bilgi Fişi üretebildiğini test eder.
  8. Test Kuruluşu, Sistem destekliyorsa; sistemin Otopark uygulamalarında kullanılması durumunda, araç çıkış işlemleri için GMU’nun e-belge üretebildiğini test eder.
  9. Test Kuruluşu, Sistem destekliyorsa; üretilen bilgi fişlerinin Özel entegratör veya İşletici Kuruluş sistemlerinde saklandığını test eder.

 

F. RAPORLAR

  1. Test Kuruluşu, GMU’nun Günlük Satış Raporunu doğru bir şekilde üretebildiğini ve bu raporu GİB ile GİB'in belirlediği yöntemlerle paylaşabildiğini test eder.
  2. Test Kuruluşu, GMU’nun Aylık Satış Raporunu doğru bir şekilde üretebildiğini ve bu raporu GİB ile GİB'in belirlediği yöntemlerle paylaşabildiğini test eder.
  3. Test Kuruluşu, GMU’nun İki Tarih Aralığı Satış Raporunu doğru bir şekilde üretebildiğini ve bu raporu GİB ile GİB'in belirlediği yöntemlerle paylaşabildiğini test eder.
  4. Test Kuruluşu, GMU’nun Düzenlenen Belgeler Raporunu doğru bir şekilde üretebildiğini ve bu raporu GİB ile GİB'in belirlediği yöntemlerle paylaşabildiğini test eder.
  5. Test Kuruluşu, GMU’nun Düzenlenen Bilgi Fişleri Raporunu doğru bir şekilde üretebildiğini ve bu raporu GİB ile GİB'in belirlediği yöntemlerle paylaşabildiğini test eder.
  6. Test Kuruluşu, GMU’nun İptal Edilen İşlemler Raporunu doğru bir şekilde üretebildiğini ve bu raporu GİB ile GİB'in belirlediği yöntemlerle paylaşabildiğini test eder.

 

G. OLAY KAYITLARI

1. Test Kuruluşu, İşletici Kuruluşun aşağıda belirtilen log kayıtlarını oluşturabildiğini ve sistemlerinde 10 yıl süre ile tutabilecek altyapıyı oluşturduğunu test eder.

  • İlgili mali işleme ait Güvenli Mali Uygulama sürüm numarası 
  • İlgili mali işlem sonunda üretilen e-belge tipi, tarih ve numarası 
  • İlgili mali işlemin Özel Entegratör Kuruluşa iletim zamanı 
  • İlgili mali işlem için Özel Entegratörden dönen cevap zamanı 
  • Harici uygulamalar ile entegrasyon mevcut ise bağlantının yapıldığı ve kesildiği / koptuğu zaman bilgileri 
  • Mükellefin kullandığı Güvenli Mali Uygulamanın güncelleme bilgileri 
  • Mükellefin kullandığı, Ödeme Kabul Aracının güncelleme bilgileri 

 

2. Test Kuruluşu, İşletici Kuruluşun olay kayıtlarına dair kayıtların bütünlüğünün ve zaman bilgisinin güvence altına alındığını test eder.

3. Test Kuruluşu, olay kayıtlarının değiştirilemezliğine yönelik kurulan mekanizmaları ayrıntılı olarak raporlar ve bunların uygunluğunu test eder.

4. Test Kuruluşu, olay kayıtlarının cihaz ve kullanıcı bazlı tutulabildiğini test eder.

5. Test Kuruluşu, olay kayıtları ile hata bildirim özelliğinin gerçekleşebildiğini test eder.

 

H. İŞLETİCİ KURULUŞ VERİ TABANI İLE YAPILAN İŞLEMLER

  1. Test Kuruluşu, e-belgelerin GİB tarafından sorgulanması ve doğrulanmasına ilişkin İşletici Kuruluş veya çalıştığı Özel Entegratörün gerekli web servisi kurmuş olduğunu ve gerekli şartları sağladığını test eder.
  2. Test Kuruluşu, İşletici Kuruluşun e-belgelerin saklanacağı veri tabanı yapısını (model, erişim, ürün grubu, alt grup, indeksleme vb. gibi) ayrıntılı bir şekilde raporlar ve uygunluğunu test eder.
  3. Test Kuruluşu, veri tabanının GİB’in özel tanımlamalarına / sorgularına cevap verebilecek şekilde tasarlandığını test eder.
  4. Test Kuruluşu, veri tabanında saklanan mali verilerin bütünlüğünü, değişmezliğini ve silinmezliğini kontrol edecek mekanizmaları ve bunlara yönelik oluşabilecek aksi durumlarda alınan tedbir ve eylem planlarını ayrıntılı olarak raporlar ve bunların uygunluğunu test eder.
  5. Test kuruluşu, e-belge örneklerinin GİB sistemlerine aktarımına ilişkin web servistransfer sistemin İşletici Kuruluş veya çalıştığı özel entegratör tarafından kurulmuş olduğunu ve gerekli şartları sağladığını test eder.

 

İ. GÜVENLİ MALİ SERTİFİKA

  1. Test Kuruluşu, Güvenli Mali Sertifika yüklü olmadığı durumda, GMU’nun işlem yapmadığını test eder.
  2. Test Kuruluşu, Güvenli Mali Sertifikanın kullanım süresinin dolması durumunda, GMU’nun işlem yapmadığını test eder.

 

J. YAZILIM GÜVENLİĞİ

  1. Test Kuruluşu, Sistem üzerinde çalışan uygulamaların arşivlenmesine dair prosedürleri ayrıntılı bir şekilde raporlar ve uygunluğunu test eder.
  2. Test Kuruluşu, yazılım sürüm takibi yapılmasına yönelik prosedürleri ayrıntılı bir şekilde raporlar ve uygunluğunu test eder.
  3. Test Kuruluşu, yazılım sürümleri için özet bilgi değeri oluşturulması ve bu değerlerin saklanmasına yönelik prosedürleri ayrıntılı bir şekilde raporlar ve uygunluğunu test eder.
  4. Test Kuruluşu, geçmiş sürümlerin tamamı da dahil olmak üzere, tüm yazılım sürümlerinin güvenli bir şekilde saklanma prosedürlerini ayrıntılı bir şekilde raporlar ve uygunluğunu test eder.

 

K. ERİŞİM KONTROLÜ 

  1. Test Kuruluşu, Sisteme yönelik servis müdahalesine dair prosedürlerini ayrıntılı bir şekilde raporlar ve uygunluğunu test eder.
  2. Test Kuruluşu, Sisteme yönelik servis müdahalesinde tüm iş ve işlemlerin iz kaydının tutulduğunu test eder.
  3. Test Kuruluşu, Sisteme yönelik servis müdahalesinin prosedürlere (olay kayıtları, yetkili servis vb. gibi) uygun bir şekilde yapılabildiğini test eder.
  4. Test Kuruluşu, Sistemin üzerinde çalışacağı cihazın kendi özel işletim sistemine ait otomatik bir saat ayarı yok ise, her açılışta NTP ile saatlerinin doğruluğunun kontrol edildiğini test eder.

 

L. KİMLİK DOĞRULAMA

  1. Test Kuruluşu, lisans ve mükellef eşleşmesi yapılan cihazların marka, model ve seri numarası kaydının doğru bir şekilde yapılabildiğini test eder.
  2. Test Kuruluşu, GMU ve bağlı uygulamalarının kayıtlı olmadığı bir cihaz üzerinde çalışmaması için alınan önemleri ayrıntılı bir şekilde raporlar ve uygunluğunu test eder.

 

M. OTURUM AÇMA VE OTURUM AÇMA KİMLİĞİ DOĞRULAMA

  1. Test Kuruluşu, Sertifikasız cihazlar üzerinde çalışacak olan GMU’nun ilgili mükellefini kullanımına sunulduğunun doğrulanması amacıyla; mobil imza, tek kullanımlık şifre (OTP) ya da İşletici Kuruluşun belirlediği güvenli doğrulama metodunu kullandığını test eder. (tek kullanımlık şifre ve OTP gibi doğrulamalar ilk giriş için zorunludur. Daha sonraki doğrulamalar belirlenen bir Pin ile yapılabilir.)
  2. Test Kuruluşu, Satış işlemlerinin sisteme güvenli bir kullanıcı doğrulama ile giriş yapıldıktan sonra yapılabildiğini ve işlem bilgilerinin bu kullanıcı ile eşleştirildiğini test eder.
  3. Test Kuruluşu, İşletici Kuruluşun, sadece Web tarayıcısı üzerinden erişilebilen bir Sistem sunması durumunda, bir oturum açıldıktan sonra işlem yapılmama süresi 180 saniyeyi geçtiği durumda oturumun otomatik olarak kapatıldığını test eder.

 

N. MÜKELLEF KAYIT İŞLEMLERİ

  1. Test Kuruluşu, mükellefin sisteme kayıt edilmesi ve sistemden çıkarılması aşamaları için “Kılavuz” da belirtilen sistemi kurduğunu ve doğru bir şekilde çalıştırdığını test eder.

 


 

GELİR İDARESİ BAŞKANLIĞI

Güvenli Mobil Ödeme ve Elektronik Belge Yönetim Sistemi

İşletici Kuruluş Sistemi Güvenlik Test Süreçleri

Dokümanı  

 

 Versiyon 1.0

(21.05.2020)

1) GİRİŞ

Bu doküman, İşletici Kuruluşlar ile Başkanlık tarafından Sistemi test etmek üzere yetkilendirilmiş test kuruluşları için düzenlenmiştir. İşletici Kuruluşların Sistemlerine ait güvenlik testleri bu doküman temel alınarak yapılmalı ve raporlanmalıdır. 

Test Kuruluşu raporunu oluştururken bu doküman yanında Güvenli Mobil Ödeme ve Elektronik Belge Yönetim Sistemi Başvuru, İzin, Onay ve Denetim Süreçleri Kılavuzundan (“Kılavuz”) da yararlanmalı ve ürettiği sonuçların Kılavuz ile uyumlu olduğunu dikkate almalıdır. 

Test Kuruluşu, raporuna temel oluşturacak testlerini yaparken en az Test Gereksinimleri ve Adımları başlığında tanımlanan test adımlarını uygulamalı ancak sadece bunlara bağlı kalmak zorunda olmadığından testini bunlarla sınırlamamalıdır. Test Kuruluşu yapmış olduğu testler sonucunda ilgili konulardaki uyumluluğun sağlandığını teyit edeceğinden, kendisinin uygun göreceği ya da test esnasında ortaya çıkan ve detaylandırılması gereken konularda ek testler yapması beklenmektedir. Test Kuruluşu, Kılavuz ve bu doküman gereksinimleri ile bütünlük içinde değerlendirmesi sonucunda düzenlemiş olduğu raporun eksiklik, belirsizlik ve tutarsızlık içermeyen doğru bilgilerle oluşturulduğunu taahhüt eder.

Test Kuruluşu tarafından düzenlenecek raporlar, sunulan Sistemin istenilen güvenlik gereksinimlerine uygun olduğuna dair kanıtları sunmalıdır. Bu nedenle, Test Kuruluşunun kapsamlı bir teknik ve kalite güvence incelemesi yapması gerekir.

İşletici Kuruluş, test süre ve süreçlerinin uzamasından kaçınmak amacıyla, Test Kuruluşu ile gerekli işbirliğini yapmalı, Test Kuruluşu tarafından talep edilen bilgi ve belgeleri zamanında ve eksiksiz şekilde sağlamalıdır. Test Kuruluşunun yapacağı kod analizi testleri için; İşletici Kuruluş bu analize katılarak kodlarını açabileceği gibi dilerse kodlarını Test Kuruluşuna teslim ederek kod analizinin Test Kuruluşu tarafından yapılmasını sağlayabilir.

 

2) AMAÇ

Sistem üzerinde gerçekleşen tüm mali ve finansal işlemlerin güvenli bir şekilde yapılması ve hassas verilerin güvenli bir şekilde saklanabilmesi gerekmektedir. Bu doküman ile tüm bunlara yönelik testlerin yapılarak Sistemin bu doküman ve Kılavuza uygunluğunun bir sınamadan geçirilmesi amaçlanmaktadır.

Bu dokümanda hem uç cihazlar için hem de Merkezi Bilgi Sistemi için gerekli temel güvenlik gereksinimlerinin test edilmesi hedeflenmektedir. 

İşletici Kuruluşlar, bu doküman ve Kılavuz içerisinde tanımlanan güvenlik gereksinimlerine aynen uymak koşuluyla, Başkanlık tarafından yetkilendirilmiş Test Kuruluşuna Güvenlik Gereksinimi Testlerini yaptırmak ve onaylatmak zorundadır.

Uç noktada kullanılan cihazların güvenlik gereksinimi açısından cihaz üreticisi tarafından sağlanan güvenlik önlemleri, sertifikaları ve/veya çözümleri de İşletici Kuruluş tarafından Test Kuruluşuna sunulabilir. Test Kuruluşu test ve değerlendirmelerini bu yönde yapmalıdır. 

Açıkça ifade edilmelidir ki; Uç noktada cihaz, ödeme uygulaması veya farklı bir uygulama ile ilgili bir sertifika veya güvenlik testi yapılmış olması(PCI PTS, CPoC, vb..); Kılavuz kapsamında geliştirilmiş olan GMU’nun, ödeme uygugulamalarını, satış uygulamalarını ve eBelge entegrasyonlarını güvenli bir şekilde yaptığı anlamına gelmemektedir. Bu sebeple GMU için uygulanacak güvenlik testleri aynen geçerli olacaktır. Şöyle ki; diğer sertifikasyonlar, kullanılan Secure Element, SAM kart, WBC vb. kripto altyapılarının GMU için de kullanılması, sistem güvenliği için büyük oranda katkı sağlayacak ve testlerde temel alıncaktır. 

 

3) TEST RAPORU ve İÇERİĞİ

Test Kuruluşunun yapacağı testler sonucunda düzenleyeceği rapor, güvenlik gerekliliklerine uygunluğu göstermelidir. Tüm test gereklilikleri için Test Kuruluşu, herhangi bir sonucun nasıl elde edildiğini göstererek sonuçları doğrulamak için doğrudan testler ve teorik iddialar hakkında yeterli bilgi sunmalıdır. Test uzmanı uygun testleri belirlemeli ve test gerekliliklerinin ve yöntemlerinin test gerekliliklerine dayanarak neden geçerli olduğunu belgelemelidir. Her test gereksinimi için raporda belirtilen değerlendirme sonuçları, anlaşılması ve doğrulanması için yeterli kanıtla desteklenmelidir. Bu kanıtlar, bunlarla sınırlı olmamak üzere, aşağıdakileri içermelidir:

  • İşletici Kuruluş tarafından sağlanan bilgiler ve test gereksinimlerine dair referanslar,
  • Test edilen bileşenin, güvenlik gereksinimlerine uygun olduğuna dair kanıtların açıklamaları,
  • Uygulanan koruma yöntemleri, yazılım mimarisi ve işletim sistemi dâhil ancak bunlarla sınırlı olmamak üzere ilgili sistem özelliklerinin doğru tanımları,
  • Beyaz kutu (White-box) yaklaşımları kullanılması durumunda, bu yaklaşımların neler olduğu ve bunların nedenleri dâhil olmak üzere test faaliyetlerinin kapsamı ve odağı ve saldırı hipotezlerinin ayrıntılı açıklamaları,
  • Kaynak kod analizi ve sonuçları,
  • Sızma testi yapmak için alınan kararların detayları, kullanılan yöntemler ve sızma testi sonuçları,
  • Uygulamalı test yerine teorik analize dayalı her türlü sonuca ilişkin açıklamalar,  
  • İstisnai durumlarda geçerli olmak üzere, doğrudan test faaliyetlerinden elde edilmeyen, ancak İşletici Kuruluş tarafından sunulan kanıt veya taahhütlere güvenmenin gerekçesi ya da gerekçeleri. 

Test raporunun, değerlendirmeyi açıklayan ekran görüntüleri ve / veya diğer grafikler, resimler de dâhil edilerek zenginleştirilmesi talep edilmektedir. Ekran görüntüsü, grafik ve resimlerin yeterli kalitede olması gerekmektedir.

Test Kuruluşu üstlenmiş olduğu görevin bilinci ile yapacağı testler ve düzenleyeceği rapordan Başkanlığa karşı sorumludur. 

Test raporunda güvenlik test sonuçları maddeler halinde yer almalıdır. Ancak test sonucuna ilişkin bir hüküm yer almamalıdır. Varsa kritiklik seviyelerine göre bulgular ve bulgulara sebep olan açıklamalar yer almalıdır.

Yine test raporunda bulgulara ilişkin çözüm önerileri ve yönlendirmelere ilişikin açıklamalar da yer alabilir. 

Test Kuruluşu tarafından düzenlenen ve Başkanlığa iletilen raporun sonucunda Başkanlık aşağıdaki üç duruma karar verebilir:

  • İşletici Kuruluş güvenlik testlerinin başarılı bulunup, test onayının verilmesi.
  • İşletici Kuruluş güvenlik testlerinin kısmen başarılı bulunup, geçici onay verilmesi ve 3 ay içerisinde tekrar test sürecine girilmesini talep etmesi.
  • İşletici Kuruluş güvenlik testlerinin başarısız bulunup, tekrar test sürecine girilmesini talep etmesi.

 

4) GEREKLİ EN DÜŞÜK TEST GEREKSİNİMLERİ VE ADIMLARI

Sistem uç nokta ve arka uçta yer alan yazılımlardan, bunların birbirleriyle ve diğer Sistem bileşenleriyle uyumlu şekilde çalışmasından ve bu çalışma esnasında işlenen ve üretilen verilen güvenli bir şekilde saklanmasını sağlayan birimlerden oluşmaktadır. Her İşletici Kuruluş, Sistemin güvenliğini, verilerin doğruluğunu, bütünlüğünü ve değiştirilemezliğini taahhüt ettiğinden, kendisine ait Sistem topolojisi içerisinde kendi mimarisini oluşturur. 

Bu bölümün amacı, Sistemin Kılavuzda tanımlandığı şekilde çalıştığını güvence altına almak için bir takım ilke ve gereksinimleri uygun şekilde test edilmesini sağlamaktır. Bu bölümde açıklanan güvenlik gereksinimlerine dair testler, işlemlerin bütünlüğü ve güvenliğini ön planda tutarak, Sistemde işlenen hassas mali ve finansal verilerin gizliliğini ve bütünlüğünü korumak için bir güvenlik çerçevesi sağlandığını sınar. Test Kuruluşu, bu bölümde ana hatları verilen test gereksinimlerini baz alarak kendi yöntem ve araçları ile testlerini yaparlar. Test Kuruluşunun görevi yaptığı sınamalardan elde ettiği sonucu objektif bir şekilde sonuç raporuna yansıtmasıdır.

Güvenlik gereksinimleri, Kılavuzun yayınlandığı tarih itibariyle bilinen saldırı senaryoları ile güvenlik açıklarına yönelik olarak düzenlenmiştir. Başkanlık, yeni tehdit ve/veya güvenlik açıklarının ortaya çıkması ile veya uygun gördüğü durumlarda, burada tanımlanan güvenlik testi gereksinimlerini gözden geçirmeye, değiştirmeye, ek testler talep etmeye karar verebilir.  

Güvenlik testi gereksinimleri birden fazla bölümde toplanmaktadır. İşletici Kuruluşun Sisteminin aşağıda sıralanan tüm bu bölümlerdeki testleri başarı ile tamamlaması beklenmektedir. 

  • Temel Güvenlik Gereksinimleri
  • Güvenli İletişim
  • Anahtar ve Sertifika Yönetimi
  • Veri güvenliği

A. TEMEL GÜVENLİK GEREKSİNİMLERİ

1. Operasyonel Yönetim

  • Test Kuruluşu, İşletici Kuruluşun ilgili kılavuzları hazırladığını ve bu kılavuzların test edilen Sistem ile uyumlu ve kullanıcılar için de yeterli olduğunu test etmelidir. 1.2. Test Kuruluşu, uç nokta güvenliğine yönelik hazırlanan gerekli doküman ve diyagramların Kılavuz ve bu doküman kapsamında geçerli ve yeterli olduğunu test etmelidir. 
  • Test Kuruluşu, Güvenli Mali Uygulama yaşam döngüsü içerisinde; geliştirme ortam güvenliği, kaynak kod güvenliği, versiyon yönetimi, değişiklik yönetimi, erişim kontrolü için gerekli prosedürlerin tanımlandığını test etmelidir.
  • Test Kuruluşu, Sistem ile ilgili olası uygulama hataları ve güvenlik açıklarının İşletici Kuruluşa bildirilebileceği bir ara yüz (portal, e-posta adresi, vb.) sunulduğunu test etmelidir.
  • Bu ara yüzden yapılan bildirimlerin İşletici Kuruluşa iletildiği test edilir. 
  • Bu iletimden sonra da ilgili kişi ve birimlere dağıtımlarının yapıldığı bir yöntem tanımlı olmalıdır.
  • Test Kuruluşu, İşletici Kuruluşun risk değerlendirme, yazılım ve son kullanıcı kullanım kılavuzu güncelleme politikası, iç test gibi operasyonel süreçlerini belgelendirdiğini ve bunların uygunluğunu test etmelidir. 

 

2. Uygulama Bütünlüğü

  • Test Kuruluşu, Güvenli Mali Uygulamanın uç noktaya güvenli bir şekilde kurulabildiğini test etmelidir.
  • Test Kuruluşu, GMU’nun bileşenlerinin GMU kontrolünde güvenilir bir uygulama mağazasından yüklenip yüklenmediğini test eder. Güvenli olmayan bir mağazadan indirilen uygulamanın çalıştırılmamasının sağlandığı test etmelidir.
  • Test Kuruluşu, GMU’nun aşağıdaki güvenlik kontrollerini doğru bir şekilde yaparak merkezi sistemine iletebildiğini test etmelidir:
    • Cihaz “rooted” olarak tabir edilen yöntemle manipüle edilmekte midir?
    • Cihaz “jailbreak” olarak tabir edilen yöntemle manipüle edilmekte midir?
    • Cihaz üzerinde bir hata ayıklayıcı (debugger) yüklü ve/veya çalışmakta mıdır?
    • Uygulama kurcalaması yapılmış mıdır?
  • Test Kuruluşu, GMU’nun çalışma zamanı bütünlüğü kontrolleri (run-time integrity checks) yaptığını ve işlevsel bir değişiklik tespit etmesi halinde kontrollerin sonuçlarını Merkezi Sistemine ilettiğini test etmelidir.
  • Test Kuruluşu, GMU’nun uygulama dosyalarını tersine mühendislikten koruduğunu test etmelidir.
  • Test Kuruluşu, GMU’nun hassas ve referans olarak kullanılan verileri yetkisiz değişiklikleri önlemek için uygulama içerisinde güvenli bir şekilde sakladığını test etmelidir.

3. İşlem Sırasında Hassas Verilerin Korunması

  • Test Kuruluşu, GMU’nun mali ve finansal işlemler sırasında Kişisel Veri, Tutar,
  • Mali Veri, TCKN vb. gibi hassas verilerin alınma anı ile ilgili güvenlik önlemlerini sağladığını test etmelidir.
  • Test Kuruluşu, GMU’nun hassas veriler kullanımı sonrasında güvenli bir şekilde sildiğini ve işlem sırasındaki izinler dışında uygulama belleğinde tutmadığını test etmelidir.
  • Test Kuruluşu, GMU’nun hassas verileri Sistemin bir paydaşı olan ilgili taraflar dışında üçüncü partilerin sistemleri ya da yazılımları ile paylaşmadığını test etmelidir.
  • GMU’nun, hassas verileri Sistem paydaşları ilgili veri – paydaş ilişkisi çerçevesinde paylaşım yapıldığı, paydaşlara kendilerini ilgilendirmeyen verilerin iletilmediğini test etmelidir. 
  • Test Kuruluşu, GMU’nun hassas verileri kaynak koduna gömmediğini test etmelidir. 3.5. Test Kuruluşu, GMU’nun diğer uygulama ve kullanıcıların erişimini engellemek amacıyla çalışma zamanı veri koruması (run-time data protection) yaptığını test etmelidir.
  • Test Kuruluşu, kullanıcı arayüzü koruması (UI Protection) yapıldığını test etmelidir. GMU tarafından oluşturulan kullanıcı arayüzüne, hassas bilgilere GMU dışındaki yetkisiz kişi, işlem ve uygulamaların erişilemeyeceği şekilde yalıtım sağlandığını ve verilerin güvence altına alındığını test etmelidir.
  • Test Kuruluşu, GMU’nun web tabanlı bir arayüze sahip olması durumunda, HTML üzerinden yapılan tüm yetkisiz ve harici URL isteklerini durdurulduğunu ve bu isteklerin işletim sistemine veya internete iletilmesinin engellendiğini test etmelidir.
  • Test Kuruluşu, GMU’nun web tabanlı bir arayüze sahip olması durumunda, kendisine ait olmayan herhangi bir Java Script kodunun başka bir kişi/uygulama/işlem tarafından enjeksiyonunun ve yürütülmesinin önlendiğini test etmelidir.

 

4. Uç Nokta Güvenliği

  • Test Kuruluşu, GMU’nun desteklediği platform ya da platformların (Android, iOS, Linux vb. gibi) neler olduğunu teyit etmeli ve bunu raporlamalıdır.
  • Test Kuruluşu, Sisteme bağlı olarak uç noktada çalışan her bir uygulamanın çalıştığı ortama ait parmak izi (fingerprint) verilerini kullanarak, GMU’nun ve bağlı bileşenlerinin uç noktada güvenli bir şekilde çalışmasını ve uç nokta doğrulamasını sağlayabildiğini test etmelidir.
  • Test Kuruluşu, uç noktadaki cihaz üzerinde bir veri tutulması durumunda bu verinin saklanmasında anahtar kullanıldığını test etmelidir.
  • Test Kuruluşu GMU’nun ve bağlı bileşenlerinin kullanıcı adı, şifre, anahtar, kişisel veriler, mali veriler vb. hassas bilgiler saklanıyorsa veya işleniyorsa bu verilerin güvenli bir şekilde saklanabildiğini ve korunabildiğini test etmelidir.
  • Test Kuruluşu GMU ve bağlı bileşenleri için Root Detection yapıldığını ve GMU’nun rootlanmış cihazlarda çalışmadığını test etmelidir.
  • Test Kuruluşu GMU ve bağlı bileşenleri için, kurulduğu cihazı tanımlayabilecek veriler sağlandığını (Device Identification) test etmelidir.
  • Test Kuruluşu GMU ve bağlı bileşenleri için,  başarılı kurulmuş bir uygulama gibi davranıp farklı lokasyondan işlem yapmasına müsaade etmemesini sağlayacak (Geolocation) bir mekanizmaya sahip olduğunu ve bunu başarılı bir şekilde uygulayabildiğini test etmelidir.
  • Test Kuruluşu GMU ve bağlı bileşenleri için, uygulama ile kurulduğu cihazı birbirine bağlayan eşsiz bir imza üreten ve yapılan bir işlemin ilgili cihaza kurulu uygulamadan gerçekleştirildiğini garanti eden bir mekanizma (Device Binding) olduğunu ve bunu başarılı bir şekilde uygulayabildiğini test etmelidir.
  • Test Kuruluşu GMU ve bağlı bileşenleri için, yazılımsal veya donanımsal kriptografik depolama / güvenli depolama yapıldığını test etmelidir.
  • Uygulamalar üzerinde saklanması gereken hassas verilerin güvenli şifreleme algoritmaları ile şifreli ve sadece uygulamanın güvenli bir şekilde okunabileceği ve başka hiç şekilde ulaşılamayan bir alt yapı ile saklandığı test etmelidir.
  • Test Kuruluşu GMU ve bağlı bileşenlerinin, herhangi bir debugger ile analiz edilmesini engelleyecek bir mekanizmaya (Anti-Debugging) sahip olduğunu ve bunu başarılı bir şekilde uygulayabildiğini test etmelidir. 
  • Test Kuruluşu GMU ve bağlı bileşenlerinin, emulatör üzerinde çalışmasını engelleyecek bir mekanizmaya (Detect Emulator) sahip olduğunu ve bunu başarılı bir şekilde uygulayabildiğini test etmelidir.
  • Test Kuruluşu GMU ve bağlı bileşenlerine ait fonksiyonlarının harici bir fonksiyonla çalışma zamanında değiştirilmesini engelleyecek bir mekanizmaya (Detect Hooking) sahip olduğunu ve bunu başarılı bir şekilde uygulayabildiğini test etmelidir.
  • Test Kuruluşu GMU ve bağlı bileşenlerinin, uygulama kodlarının çözülüp yeniden paketlenmesini tespit ederek çalışmasını engelleyecek bir mekanizmaya (Detect Repacking) sahip olduğunu ve bunu başarılı bir şekilde uygulayabildiğini test etmelidir.
  • Test Kuruluşu GMU ve bağlı bileşenlerinin, uygulamanın çalışma zamanında kullandığı hafıza alanından hassas verilerin alınmasını engelleyecek şifreleme, karıştırma ve diğer sisteme bağlı tedbirleri içeren bir mekanizmaya (Secure Runtime Memory) sahip olduğunu ve bunu başarılı bir şekilde uygulayabildiğini test etmelidir.
  • Test Kuruluşu GMU ve bağlı bileşenlerinin, uygulama çalışma zamanında yüklenen uygulama kodunun değişmesini kontrol edip çalışmasını durduracak ve bu durumu Merkezi Bilgi Sistemine bildirecek bir mekanizmaya (Runtime CRC Check) sahip olduğunu ve bunu başarılı bir şekilde uygulayabildiğini test etmelidir.
  • Test Kuruluşu GMU ve bağlı bileşenlerinin, uygulamanın ihtiyaç duyduğu işlemlerde OTP doğrulama yapabildiğini test etmelidir.
  • Test Kuruluşu GMU ve bağlı bileşenlerinin, uygulamanın ihtiyaç duyduğu işlemlerde, cihazın izin vermesi durumunda Push Notification doğrulaması yapabildiğini test etmelidir.
  • Test Kuruluşu GMU ve bağlı bileşenlerinin, uygulama içerisindeki fonksiyonların dışarıdan izinsiz bir şekilde tetiklenmemesini, fonksiyonların kendi uygulamasının dışında bir uygulama ile çalışmamasına yönelik bir mekanizmaya (Application Binding) sahip olduğunu ve bunu başarılı bir şekilde uygulayabildiğini test etmelidir. 4.19. Test Kuruluşu GMU ve bağlı bileşenlerinin, uygulama kodları tersine mühendislik ve statik kod analizleri ile açığa çıkmamasını sağlamak amacıyla önlemlere (Code Obfuscation and Diversification / Code Lifting) sahip olduğunu ve bunu başarılı bir şekilde uygulayabildiğini test etmelidir.
  • Test Kuruluşu GMU’nun, işlemlerin takibi için dijital olarak her işlemi imzalayacağı ve bu imzayı Merkezi Bilgi Sisteminde saklayacağı bir mekanizmaya (Transaction Data Signing) sahip olduğunu ve bunu başarılı bir şekilde uygulayabildiğini test etmelidir.

 

B. GÜVENLİ İLETİŞİM

  1. Test Kuruluşu, Sistem üzerindeki kritik noktalar arasındaki (GMU, Merkezi Sistem, Özel Entegratör Kuruluş ve (varsa) Üye İşyeri Yapan Kuruluş) ve İşletici Kuruluş tarafından sunuluyor ise GMU’nun Harici Donanım ve/veya Harici Uygulamalar arasındaki iletişimin şifreleme yapılarak kurulduğunu ve iletişimlerin bu sayede korunduğunu test etmelidir. 
  2. Test Kuruluşu, kurulan güvenli iletişim kanallarının yapısını ayrıntılı olarak raporlamalı ve uygunluğunu test etmelidir.
  3. Test Kuruluşu, hassas verilerin ele geçirilmesini engellemek amacıyla birbirleri ile işlem yapan arabirimler arasındaki trafiğin izlenmesini önlemek amacıyla kullanılan yöntemleri ayrıntılı olarak raporlamalı ve uygunluğunu test etmelidir.
  4. Test Kuruluşu, güvenli iletişim kanallarında kimlik doğrulama yöntemi içerdiğini teyit ederek, uygulamasını ayrıntılı olarak raporlamalı ve uygunluğunu test etmelidir.
  5. Test Kuruluşu, her bir güvenli iletişim kanalı için Ortadaki Adam (Man in the Middle) ve Tekrarlayan Saldırısı (Replay Attacks) engellenme yöntemini ayrıntılı olarak raporlamalı ve uygunluğunu test etmelidir.
  6. Test Kuruluşu, Sistemin farklı bileşenleri arasında güvenli iletişim kanalı oluşturmak amacıyla kullanılan anahtarların sadece ilgili bileşene ait olduğunu teyit etmeli ve GMU ile diğer bileşenler arasındaki güvenli iletişimin nasıl oluşturulduğunu ayrıntılı olarak raporlamalı ve uygunluğunu test etmelidir.
  7. Test Kuruluşu, TLS vb. gibi standart iletişim protokollerinin kullanıldığı yerlerde Sürüm Düşürme Saldırısı (Downgrade Attack / Rollback Attack) yönteminin mümkün olamayacak şekilde engellenmesine yönelik alınan tedbirleri ayrıntılı olarak raporlamalı ve uygunluğunu test etmelidir.
  8. Test Kuruluşu, kullanılan standart iletişim protokollerinin ve versiyonlarının genel olarak bilinen bir güvenlik açığına yol açmadığını denetlemeli ve bunu raporlamalıdır.

 

C. ANAHTAR ve SERTİFİKA YÖNETİMİ

İşletici Kuruluşun sunmuş olduğu Sistemde işlemlerin güvenli bir şekilde yapılması, işlem verilerinin korunması, gizliliği ve bütünlüğünün sağlanması kritik önemde bir role sahiptir. Bu amaçlarla kullanılan anahtarlar ve sertifikaların yönetimi, Sistemin güvenliği üzerinde önem arz edecektir. 

1. Sertifika Yöntemi

  • Test Kuruluşu İşletici Kuruluşun Kılavuza uygun şekilde; 
    • Tübitak KamuSM için uygun formatta sertifika talep dosyası üretme,
    • Tübitak KamuSM tarafından üretilen sertifikayı güvenli bir şekilde alarak saklama ve gerekmesi durumunda imha edilme,
    • Güvenli bir şekilde sakladığı İşletici Kuruluş Güvenli Mali Sertifikasından, yapılan her bir işlemin imzalanmasını ve kullanılan yöntemlerini ayrıntılı bir şekilde raporlamalı ve uygunluğunu test etmelidir.
  • Test Kuruluşu yapılan her bir işlem için imza yöntemi ile Güvenli Mali Sertifika, mükellef VKN, cihaz marka – model ve seri numarası eşleşmesini güvenli bir şekilde kayıt alabildiğini ve saklayabildiğini test etmelidir.
  • Test Kuruluşu, Güvenli Mali Uygulamanın her bir işlemi kendisinden beklendiği şekilde imzalayabildiğini test etmelidir.
  • Test Kuruluşu, GMU tarafından imzalanarak Merkezi Sistemde saklanan işlemlere ait imzaların doğrulanabildiğini test etmelidir.
  • Test Kuruluşu, yapılan her bir işleme ait imzanın, işleme ait kılavuzda yer alan bilgileri içerdiğini test etmelidir.

2. Anahtar Yönetimi

  • Test Kuruluşu, Sistem içerisinde sadece onaylı ve doğruluğu kanıtlanmış ve Başkanlık tarafından tanınan algoritmalar kullanıldığını test etmelidir.
  • Test Kuruluşu, İşletici Kuruluş tarafından kullanılan tüm anahtarlar için anahtar amaç ve bütünlüğün sağlanma yöntemlerini ayrıntılı bir şekilde raporlamalı ve uygunluğunu test etmelidir.
  • Test Kuruluşu, GMU tarafından kullanılan rastgele sayıların üretilmesinde kullanılan onaylı rastgele sayı üretme (RNG) algoritmaları veya kütüphanelerini ayrıntılı olarak raporlamalı ve uygunluğunu test etmelidir. 
  • Test Kuruluşu, whitebox kriptoloji tekniği kullanılması durumunda bu amaçla kullanılan anahtarlar hariç olmak üzere, diğer tüm gizli şifreleme anahtarlarının ve özel şifreleme anahtarlarının benzersiz olduğunu test etmelidir.
  • Test Kuruluşu, Sistemde kullanılan her bir anahtara ait yükleme yöntemi ve prosedürünü ayrıntılı olarak raporlamalı ve uygunluğunu test etmelidir.
  • Test Kuruluşu, tüm simetrik ve asimetrik kök/ana anahtarların güvenli bir şekilde saklanma yöntemlerini ayrıntılı bir şekilde raporlamalı ve uygunluğunu test etmelidir.
  • Test Kuruluşu, Sistemde kullanılan asimetrik anahtarların her biri için anahtarın iptal edilme yöntemini ayrıntılı bir şekilde raporlamalı ve uygunluğunu test etmelidir.
  • Test Kuruluşu, tüm anahtar yönetim işlemleri için yetkisiz değişikliklere veya silinmelere karşı bütünlük koruması içerek şekilde denetim amaçlı iz kayıtları oluşturma yöntemlerini ayrıntılı bir şekilde raporlamalı ve uygunluğunu test etmelidir.

 

D. VERİ GÜVENLİĞİ

Sistem mali ve finansal hassas veriler içermesi ve bu verilerin sızmasının bilgi gizliliğini ihlal etmesi yanında verilerin açığa çıkmasının ulusal güvenlik problemi yaratabilme potansiyelinden dolayı veri güvenliğinin sağlanması kritik derecede önemlidir.

  1. Test Kuruluşu, veri bütünlüğünün uç noktadan merkezi sisteme kadar uçtan uca ve güvenli bir şekilde sağlanma yöntemlerini ayrıntılı bir şekilde raporlamalı ve uygunluğunu test etmelidir.
  2. Test Kuruluş, TCKN, e-posta, telefon numarası, adres, kart numarası gibi her tür hassas verinin anahtar kullanılarak şifreli bir şekilde güvenli ortamlarda saklanma yöntemlerini ayrıntılı bir şekilde raporlar ve uygunluğunu test eder.
  3. Test Kuruluşu, her tür hassas veriye yetki bazlı erişimin sağlanma ve bu erişimlerinin iz kayıtlarının saklanma yöntemlerini ayrıntılı bir şekilde raporlamalı ve uygunluğunu test etmelidir.
  4. Test Kuruluşu, her bir tür hassas verinin açık metin olarak değil, maskeli ve özet değerleri gösterildiğini test etmelidir.
  5. Test Kuruluşu, hassas verilerin korunması ve yönetilmesine dair İşletici Kuruluş ve/veya Dış Hizmet Sağlayıcısı tarafından sağlanan belgelendirilmiş politikaları ayrıntılı bir şekilde raporlamalı ve uygunluğunu kontrol etmelidir.
  6. Test Kuruluşu, hassas verilerin saklandığı ortamın güvenliğinin sağlanması, izlemesi ve bunların sürdürülebilir olması için alınan önlemleri ayrıntılı bir şekilde raporlamalı ve uygunluğunu kontrol etmelidir.
  7. Test Kuruluşu, hassas verilerin işlenmesinden, yönetiminden sorumlu şirket içi personel değişikliklerinde, Sisteme yeni donanım ve/veya ağ bağlantıları eklenmesi gibi durumlarda hassas verilerin korunması ve güvenliğinin sağlanması amacıyla alınan tedbir ve uygulanan yöntemleri ayrıntılı bir şekilde raporlamalı ve uygunluğunu kontrol etmelidir.
  8. Test Kuruluşu, sistem mimarisi ve güvenlik kontrol noktalarını destekleyen ağ ve veri akış diyagramlarını ayrıntılı bir şekilde raporlamalı ve uygunluğunu test etmelidir.
  9. Test Kuruluşu, açık metin şeklindeki verilerin yetkilendirilmemiş / izin verilmemiş bir kanal ya da yöntem üzerinden Merkezi Sistemden dışarı çıkartılmasını anlayacak, ayrı verecek ve bunu engelleyecek mekanizmaları ayrıntılı bir şekilde raporlamalı ve yeterliliğini test etmelidir.
  10. Test Kuruluşu İşletici Kuruluş tarafından her 6 ayda bir sızma testleri yapılması için alınan tedbirleri ayrıntılı bir şekilde raporlamalı ve uygunluğunu kontrol etmelidir.
  11. Test Kuruluşu, Merkezi Sistemde saklanan verilere için dosya bütünlüğü izleme mekanizmalarına ait yöntemleri ayrıntılı bir şekilde raporlamalı ve yeterliliğini test etmelidir.
  12. Test Kuruluşu, Merkezi Sistem üzerinde kötü amaçlı yazılımların çalışmasını tespit etmek, önlemek ve kaldırmak için alınan tedbirleri ayrıntılı bir şekilde raporlamalı ve yeterliliğini test etmelidir.
  13. Test Kuruluşu, Merkezi Sistemin güvenlik açıklarını derecelendirme ve oluşması durumunda tespit etmeye dayalı yöntemlerini ayrıntılı bir şekilde raporlamalı ve yeterliliğini test etmelidir.

 


 

GELİR İDARESİ BAŞKANLIĞI

GMÖEBYS EKS Web Servis Kılavuzu

(Güvenli Mobil Ödeme Elektronik Kayıt Servisi)

 

 

Ağustos 2025

ANKARA

GELİR İDARESİ BAŞKANLIĞI

Uygulama ve Veri Yönetimi Daire Başkanlığı (III)

 

İÇİNDEKİLER

 

1. GENEL AÇIKLAMA___________________________________________________________________ 3

2. SİSTEMDE BULUNAN WEB SERVİSLER__________________________________________________ 4

2.1 Servisler ve Metotları________________________________________________________________ 4

3. SERVİSLERİN TEKNİK BİLGİLERİ_______________________________________________________ 4

3.1 Cihaz Ekleme (RegisterDevice)_________________________________________________________ 4

3.2 Arşiv Cihaz Ekleme (RegisterDevice /Archive )____________________________________________ 5

3.3 Cihaz Silme________________________________________________________________________ 7

3.4 Adres Güncelleme___________________________________________________________________ 8

3.5 Entegratör Ekleme___________________________________________________________________ 8

3.6 Entegratör Silme___________________________________________________________________ 10

3.7 Harici Uygulama / Harici Satış Uygulaması_______________________________________________ 12

3.8 Banka Uygulaması_________________________________________________________________ 14

3.9 Cihaz Sorgulama___________________________________________________________________ 16

4. ORTAK YAPILAR TEKNİK BİLGİLER____________________________________________________ 22

4.1 Sonuç___________________________________________________________________________ 22

4.2 Entegratör Bilgileri_________________________________________________________________ 22

4.3 Eski Entegratör Bilgileri______________________________________________________________ 23

4.4 Harici Uygulama Bilgileri____________________________________________________________ 23

4.5 Banka Uygulama Bilgileri____________________________________________________________ 23

4.6 Durum Kodları ve Açıklamaları_______________________________________________________ 24

5. ÖRNEK REQUEST VE RESPONSE ÖRNEKLERİ____________________________________________ 28

5.1 Cihaz ekleme_____________________________________________________________________ 28

5.2 Arşiv Cihaz ekleme_________________________________________________________________ 31

5.3 Cihaz Silme_______________________________________________________________________ 33

5.4 Adres Güncelleme__________________________________________________________________ 33

5.5 Entegratör Ekleme__________________________________________________________________ 34

5.6 Entegratör Silme___________________________________________________________________ 35

5.7 Harici Uygulama /Harici Satış Uygulaması_______________________________________________ 35

5.8 Banka Uygulaması_________________________________________________________________ 38

5.9 Cihaz Sorgulama___________________________________________________________________ 39

 

VERSİYON DEĞİŞİKLİĞİ

 

 

              Versiyon Değişikliği

Versiyon

Yayım Tarihi

Eklenen/Silinen

/Değişen Bölüm

Açıklama

1.1

22.10.2024

--

Kılavuzun ilk yayım tarihidir.

 

 

 

1.2

 

 

 27.02.2025

 

 

                  Sayfa 

5,7,8,9,11,14,15

 Arşiv Cihaz Ekleme Servisi, Entegratör Güncelleme Servisi ve Veri Sorgulama Servisleri eklenmiştir.

 

 

 

1.3

 

 

 11.04.2025

 

 

 

 

 

Sayfa

4,5,7,8,9,11,12,14,16,

18,20,21,22,23

Entegratör Ekleme, Entegratör Silme Servisleri eklenmiştir. 

Cihaz Ekleme, Arşiv Cihaz Ekleme, Entegratör Ekleme,  Entegratör Silme Servislerine Entegratör Bilgileri kısmı eklenmiştir. 

Veri Sorgulama kısmına Entegratör

Bilgileri kısmına ek olarak Eski Entegratör Bilgileri kısmı eklenmiştir.

Hata Durum Kodları alanına yeni hata kodları eklenmiştir. 

 

1.4

  25.07.2025

 

 

 

Sayfa

10,11,12,13,14,16,25,

26,27,28,29,30,31,32

Harici Uygulama /Harici Satış

Uygulama ve Banka Uygulama

Servisleri eklenmiştir. 

Hata Durum Kodları alanına yeni hata durum kodları eklenmiştir. 

Cihaz Sorgulama servislerine yeni eklenen servis bilgileri eklenerek ilgili servis tekrar güncellenmiştir. 

 

 

GMÖEBYS EKS ENTEGRASYON SİSTEMİ

  1. GENEL AÇIKLAMA

Güvenli Mobil Ödeme ve Elektronik Belge Yönetim Sistemi Elektronik Kayıt Sistemi uygulaması dış sistemlerle (İşletici Kuruluşlar) Web Servisleri üzerinden haberleşme servisidir. 

Servisin 9 farklı metodu ile Cihaz Ekleme, Cihaz Silme, Arşiv Cihaz Ekleme, Adres Güncelleme, Entegratör Ekleme, Entegratör Silme, Veri Sorgulama, Harici Uygulama /Harici Satış

Uygulaması (Aktif – Kapalı)  ve Banka Uygulaması (Aktif – Kapalı) işlemleri gerçekleştirilmektedir.

Aşağıda tüm metotların girdileri ve çıktıları ile ilgili açıklamalar bulunmaktadır.

Servis Response Json formatındadır.

Servis swagger adresi aşağıdaki gibidir:

TEST: https://gmoebystest.gib.gov.tr/gmoebys-eks

Servis altında bulunan tüm metotların kullanımı için kimlik doğrulaması yapılmaktadır. Kimlik doğrulaması Servise ilk erişmeye çalıştığınızda istenmekte olup kimlik bilgileri işletici kuruluşların yetkilileri ile paylaşılacaktır.

Metotların sonuç parametresi işlem başarılı ise durum true, hatalı ise durum false şeklinde

dönecektir.

 

  1. SİSTEMDE BULUNAN WEB SERVİSLER
    1. Servisler ve Metotları  

Cihaz Ekleme (RegisterDevice) https://gmoebystest.gib.gov.tr/api/v1/gmoebys/registerdevice

Arşiv Cihaz Ekleme (RegisterDevice/Arcive ) https://gmoebystest.gib.gov.tr/api/v1/gmoebys/registerdevice/archive

Cihaz Silme (CloseDevice) https://gmoebystest.gib.gov.tr/api/v1/gmoebys/closedevice

Adres Güncelleme (UpdateAddress) https://gmoebystest.gib.gov.tr/api/v1/gmoebys/updateaddress

Entegratör Silme ( Delete Entegratör)  https://gmoebystest.gib.gov.tr/api/v1/gmoebys/entegrator/delete

Entegratör Ekleme (Adding Entegratör) https://gmoebystest.gib.gov.tr/api/v1/gmoebys/entegrator/add

Veri Sorgulama (QueryDevice) https://gmoebystest.gib.gov.tr/api/v1/gmoebys/query/device?deviceId

Banka Aktif (Bank/Active) https://gmoebystest.gib.gov.tr/api/v1/gmoebys/application/bank/active

Banka Kapalı (Bank/Closed) https://gmoebystest.gib.gov.tr/api/v1/gmoebys/application/bank/closed

Harici Uygulama (Satış) Aktif (External/Active)

https://gmoebystest.gib.gov.tr/api/v1/gmoebys/application/external/active

Harici Uygulama (Satış) Kapalı (External/Closed)

https://gmoebystest.gib.gov.tr/api/v1/gmoebys/application/external/closed

 

  1. SERVİSLERİN TEKNİK BİLGİLERİ
    1. Cihaz Ekleme (RegisterDevice)

GMÖEBYS kapsamında mükelleflerin (kullanıcıların) kullanıma sunulan ödeme kabul edilen araçların yüklenebileceği kullanılabileceği sertifikalı ya da sertifikasız fiziki donanımları eklemek için kullanılan servistir.

Güvenli Mali Uygulama kapsamında mükelleflerin kullanımına sunulan ödeme kabul edilen araçları eklemek için kullanılan servistir. Örneğin; Sertifika bilgisi alanı 0 ise ImeiNo, 1 ise CihazNo alanı dolu olmak zorundadır.

Not: Cihaz Seri No ve Imei No alanlarına veri girişi seçimli olmakla birlikte bu iki alandan birinin dolu olması zorunludur.

 

 

Metot: Cihaz Ekleme (RegisterDevice)

 

Cihaz Ekleme (RegisterDevice)Girdi

Bilgi

 

Tipi

Zorunluluk

Aciklama

 

 

 mukellef_vkn_tckn

 

 

 

String

 

 

Zorunlu

İşletici Kuruluşun Ekleyeceği

Mükellefin Kimlik Numarası 10 ya da 11 Hane Olmalıdır.

 

 mukellef_unvan

 

 

String

 

Zorunlu

İşletici Kuruluşun Ekleyeceği

Mükellefin Ünvanı

 

mukellef_adres

 

 

String

 

Zorunlu

İşletici Kuruluşun Ekleyeceği Mükellefin Adres Bilgisi

 

il_kodu

 

 

 String

 

Zorunlu

İşletici Kuruluşun Ekleyeceği Mükellefin İl Kodu

 

ilce_adi

 

 

 String

 

Zorunlu

İşletici Kuruluşun Ekleyeceği Mükellefin İlçe Adı

 

 

sertifika_bilgisi

 

 

 

 Numerik

 

 

Zorunlu

Cihaz Sertifikalı İse 1,

Sertifikasız (Cep Tel, Tablet Vs.) ise 0 Girilir.

cihaz_markasi

 

String

Zorunlu

  Cihazın Markası

cihaz_modeli

 

String

Zorunlu

Cihazın Modeli

islem_tarihi

 

Date

Zorunlu

Cihazın Teslim Edildiği Tarih

cihaz_seri_no

 

String

Seçimli

Cihazın Seri Numarası

cihaz_imei_no

 

String

Seçimli

Cihazın Imeı Numarası

 

 

 

entegrator_vkn_tckn

 

 

 

 

String

 

 

 

Zorunlu

 

 Mükellefin Bağlı Olduğu Özel Entegratörün Kimlik Numarası 10 ya da 11 Hane Olmalıdır.

 

entegrator_tıp

 

 

String

 

Zorunlu

 Mükellef e-Fatura mükellefi ise tip =1

 Mükellef e-Arşiv mükellefi ise tip = 2

 

 

    1. Arşiv Cihaz Ekleme (RegisterDevice /Archive )  

GMÖEBYS kapsamında mükelleflerin (kullanıcıların) kullanıma sunulan ödeme kabul edilen araçların yüklenebileceği kullanılabileceği sertifikalı ya da sertifikasız fiziki donanımları eklemek için kullanılan servistir.

2021-02-15 ile 2025-01-20 tarihleri arasında mükellefler tarafından kullanılan cihazlar bu servis üzerinden bildirilecektir. Bu tarih aralığında bildirilen cihazların tamamı kapalı konumda olmak zorundadır. Bu cihazların bildirimi yapılırken tarih sırasına önem gösterilmesi ve sırayla bildirilmesi gerekmektedir.

Güvenli Mali Uygulama kapsamında mükelleflerin kullanımına sunulup akabinde kullanımdan çıkarılan ödeme kabul edilen araçları eklemek için kullanılan servistir. Örneğin; Sertifika bilgisi alanı 0 ise ImeiNo, 1 ise CihazNo alanı dolu olmak zorundadır.

Not: Cihaz Seri No ve Imei No alanlarına veri girişi seçimli olmakla birlikte bu iki alandan birinin dolu olması zorunludur.

 

Cihaz Ekleme (RegisterDevice)Cikti

 

 

Bilgi

Tipi

Zorunluluk

Aciklama

 

 

durum

 

 

Boolean

 

 

Zorunlu

True ya da False Dönmektedir. True

Döndüğünde İşlem Başarılı, False Döndüğünde ise Hatalıdır.

sonuc

 

Zorunlu

Bakınız: Sonuç

 

 

Metot: Arşiv Cihaz Ekleme(RegisterDevice/ Archive)

 

Arşiv Cihaz Ekleme (RegisterDevice)Girdi

Bilgi

 

Tipi

Zorunluluk

Aciklama

 

 

mukellef_vkn_tckn

 

 

 

String

 

 

Zorunlu

İşletici Kuruluşun Ekleyeceği

Mükellefin Kimlik Numarası 10 ya da 11 Hane Olmalıdır.

 

mukellef_unvan

 

 

String

 

Zorunlu

İşletici Kuruluşun Ekleyeceği

Mükellefin Ünvanı

 

mukellef_adres

 

 

String

 

Zorunlu

İşletici Kuruluşun Ekleyeceği Mükellefin Adres Bilgisi

 

il_kodu

 

 

 String

 

Zorunlu

İşletici Kuruluşun Ekleyeceği Mükellefin İl Kodu

 

ilce_adi

 

 

 String

 

Zorunlu

İşletici Kuruluşun Ekleyeceği Mükellefin İlçe Adı

 

 

sertifika_bilgisi

 

 

 

Numerik

 

 

Zorunlu

Cihaz Sertifikalı ise 1,

Sertifikasız (Cep Tel, Tablet Vs.) ise 0 Girilir.

cihaz_markasi

 

 

String

Zorunlu

Cihazın Markası

cihaz_modeli

 

String

Zorunlu

Cihazın Modeli

islem_tarihi

 

Date

Zorunlu

Cihazın Teslim Edildiği Tarih

 

    1. Cihaz Silme

GMÖEBYS kapsamında mükelleflerin (kullanıcıların) kullanımına sunulan ödeme kabul edilen araçların (sertifikalı ya da sertifikasız fiziki donanımların) değiştirilmesi ya da geri alınması durumunda kullanılan metottur.

Not: Cihaz Seri No ve Imei No alanlarına veri girişi seçimli olmakla birlikte bu iki alandan birinin dolu olması zorunludur.

cihaz_seri_no

 

String

Seçimli

Cihazın Seri Numarası

cihaz_imei_no

 

String

Seçimli

Cihazın Imeı Numarası

kapanma_tarihi

 

Date

Zorunlu

 Cihazın Kapanma Tarihi

 

 

 entegrator_vkn_tckn

 

 

 

 String

 

 

Zorunlu

 Mükellefin Bağlı Olduğu Özel  Entegratörün Kimlik Numarası 10   ya da 11 Hane Olmalıdır.

 

 entegrator_tıp

 

 

 String

 

 Zorunlu 

 Mükellef e-Fatura mükellefi ise tip =1

 Mükellef e-Arşiv mükellefi ise tip = 2

 

Arşiv Cihaz Ekleme (RegisterDevice)Cikti

Bilgi

 

Tipi

Zorunluluk

Aciklama

 

 

durum

 

 

 

Boolean

 

 

Zorunlu

True ya da False Dönmektedir. True

Döndüğünde İşlem Başarılı, False Döndüğünde ise Hatalıdır.

sonuc

 

 

Zorunlu

Bakınız: Sonuç

 

 

Metot: Cihaz Silme (CloseDevice)

 

Cihaz Silme (CloseDevice)Girdi

Bilgi

Tipi

Zorunluluk

Aciklama

cihaz_seri_no

String

Seçimli

Silinecek Cihaz Numarası Yazılır.

cihaz_imei_no

Stiring

Seçimli

Silinecek IMEI Numarası Yazılır.

 

islem_tarihi

 

Date

 

Zorunlu

 

 Cihazın Kapatıldığı Tarih Bilgisi Girilir.

 

Cihaz Silme (CloseDevice)Cikti

Bilgi

Tipi

Zorunluluk

Aciklama

 

 

durum

 

 

Boolean

 

 

Zorunlu

True ya da False Dönmektedir. True Döndüğünde İşlem Başarılı, False Döndüğünde ise Hatalıdır.

sonuc

 

Zorunlu

Bakınız: Sonuç

 

    1. Adres Güncelleme

GMÖEBYS kapsamında mükelleflerin (kullanıcıların) kullanımına sunulan fiziki donanımların bulunduğu adres değiştiğinde adresi güncellemek için kullanılan metottur.

Not: Cihaz Seri No ve Imei No alanlarına veri girişi seçimli olmakla birlikte bu iki alandan birinin dolu olması zorunludur.

 

M

etot: Adres Güncelleme (UpdateAddress)

Adres

 Güncelleme (UpdateAddress)Request:

POST

Bilgi

Tipi

Zorunluluk

Aciklama

 

mukellef_adres

 

String

 

Zorunlu

Mükellefe Verilen Cihazın Güncel Adres Bilgisi Yazılır.

 

 cihaz_seri_no

 

String

 

 Seçimli

Güncellenecek Cihaz Numarası Yazılır.

 

 cihaz_imei_no

 

String

 

 Seçimli

Güncellenecek IMEI Numarası

Yazılır.

 

il_kodu

 

String

 

Zorunlu

Mükellefe Verilen Cihazın Güncel İl Kodu

 

ilce_adi

 

String

 

Zorunlu

Mükellefe Verilen Cihazın Güncel İlçe Kodu

 

Adres Güncelleme Cikti

Bilgi

Tipi

Zorunluluk

Aciklama

 

 

durum

 

 

Boolean

 

 

Zorunlu

True ya da False Dönmektedir. True Döndüğünde İşlem Başarılı, False  Döndüğünde ise Hatalıdır.

sonuc

String

Zorunlu

Bakınız: Sonuç

 

    1. Entegratör Ekleme 

GMÖEBYS kapsamında mükelleflerin entegre olduğu özel entegratör firmasını eklemek için işletici kuruluşların kullandığı metottur. 

Not: Cihaz Seri No ve Imei No alanlarına veri girişi seçimli olmakla birlikte bu iki alandan birinin dolu olması zorunludur.

Sadece aktif olan cihazlar için entegratör ekleme işlemi yapılabilir.

Entegratör ekleme işlemi mevcutta aktif olarak cihazı kullanan mükellefin yeni bir entegratör ile çalışmaya başlaması durumunda kullanılacaktır.  

Firma, MukellefVknTckn ve seri_no ya da imei No bilgilerine göre gerekli kontroller yapıldıktan sonra yeni entegratör bilgisini ekleyebilir. 

 

 

Metot: Entegratör Ekleme (Addingentegrator)

 

Entegratör Ekleme (Addingentegrator)Request:POST

Bilgi

 

Tipi

Zorunluluk

Aciklama

 

 

mukellef_vkn_tckn

 

 

 

String

 

 

Zorunlu

İşletici Kuruluşun Ekleyeceği Mükellefin Kimlik Numarası 10 ya da 11 Hane Olmalıdır.

 

cihaz_seri_no

 

 

String

 

Zorunlu

Güncellenecek Cihaz Numarası Yazılır.

 

cihaz_imei_no

 

 

String

 

Seçimli

Güncellenecek IMEI Numarası

Yazılır.

 

 

 entegrator_vkn_tckn

 

 

 

 String

 

 

Zorunlu

Mükellefin Bağlı Olduğu Özel

Entegratörün Kimlik Numarası 10 ya da 11 Hane Olmalıdır.

 

 

 

 entegrator_tıp

 

 

 

 

 String

 

 

 

 Zorunlu 

 

Mükellef e-Fatura mükellefi ise tip =1

Mükellef e-Arşiv mükellefi ise tip = 2

 

Entegratör Ekleme Cikti

Bilgi

 

Tipi

Zorunluluk

Aciklama

 

 

durum

 

 

 

Boolean

 

 

Zorunlu

True ya da False Dönmektedir. True

Döndüğünde İşlem Başarılı, False Döndüğünde ise Hatalıdır.

sonuc

 

String

Zorunlu

Bakınız: Sonuç

               

 

  

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

    1. Entegratör Silme

GMÖEBYS kapsamında mükelleflerin entegre olduğu özel entegratör firmasını silmek için işletici kuruluşların kullandığı metottur.

Not: Cihaz Seri No ve Imei No alanlarına veri girişi seçimli olmakla birlikte bu iki alandan birinin dolu olması zorunludur.

Sadece aktif olan cihazlar için entegratör silme işlemi yapılabilir.

Entegratör silme işlemi mevcutta aktif olarak cihazı kullanan mükellefin entegratörü ile artık çalışmaması durumunda kullanılacaktır.  

Firma, MukellefVknTckn ve seri_no ya da imeiNo bilgilerine göre gerekli kontroller yapıldıktan sonra yeni entegratör bilgisini silebilir. 

Ayrıca mükellefin 1 tane e-Fatura 1 tane Arşiv mükellefi varsa ve entegratörü silmeden önce yeni anlaştığı entagratör bilgisini sisteme eklemesi gerekmektedir. Eklememesi durumunda mükellef hata alacaktır.  

..

 

Metot: Entegratör Silme (Deleteentegrator)

 

 

Entegratör Silme

(Deleteentegrator)Request:DELETE

Bilgi

 

Tipi

Zorunluluk

Aciklama

 

 

 mukellef_vkn_tckn

 

 

 

String

 

 

Zorunlu

İşletici Kuruluşun Ekleyeceği Mükellefin Kimlik Numarası 10 ya da 11 Hane Olmalıdır.

 

 cihaz_seri_no

 

 

String

 

Zorunlu

Güncellenecek Cihaz Numarası Yazılır.

 

 cihaz_imei_no

 

 

String

 

Seçimli

Güncellenecek IMEI Numarası

Yazılır.

 

 

 entegrator_vkn_tckn

 

 

 

 String

 

 

Zorunlu

Mükellefin Bağlı Olduğu Özel Entegratörün Kimlik Numarası 10 ya da 11 Hane Olmalıdır.

 

 

 

 entegrator_tıp

 

 

 

 

 String

 

 

 

 Zorunlu 

 

Mükellef e-Fatura mükellefi ise tip =1

Mükellef e-Arşiv mükellefi ise tip = 2

 

 

 

 İşlem_tarihi

 

 

 

 

 String

 

 

 

 Zorunlu 

 

 

Mükellefin İşlem Tarihi

 

Entegratör Silme Cikti

Bilgi

 

Tipi

Zorunluluk

Aciklama

 

 

durum

 

 

 

Boolean

 

 

Zorunlu

True ya da False Dönmektedir. True

Döndüğünde İşlem Başarılı, False Döndüğünde ise Hatalıdır.

sonuc

 

String

Zorunlu

Bakınız: Sonuç

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

7.Harici Uygulama/Harici Satış Uygulaması

 GMÖEBYS kapsamında işletici kuruluşların kullandıkları harici uygulama ve harici satış uygulamalarına ait bilgileri gönderdikleri ve bu uygulamaları eklemek ya da çıkarma işlemi için kullanılan metottur. Bu metot seçimlidir.

Uygulama tipi; 

  1. Harici Uygulama,
  2. Harici Satış Uygulaması 

Tip 1 ve Tip 2 için ayrı ayrı gönderim yapılabilir.

Uygulamaya ait Durum ve Tip Bilgileri;

HK=Harici Uygulama Kapalı

SK=Harici Satış Uygulama Kapalı

HA=Harici Uygulama Aktif

SA=Harici Satış Uygulama Aktif 

İmei No ya da seri No seçimli diğer alanlar zorunludur.

Harici Uygulama (Harici Satış Uygulaması) Açık;

Tip 1 olarak gönderim yapıldığında Harici Uygulama olarak, Tip 2 olarak gönderildiğinde Harici Satış Uygulaması olarak sisteme kayıt yapılacaktır.

Harici Uygulama (Harici Satış Uygulaması) Kapalı;

Tip 1 olarak gönderim yapıldığında Harici Uygulama Kapatma, Tip 2 olarak gönderim yapıldığında Harici Satış Uygulaması Kapatma kaydı yapılacaktır.

...

             

Metot: Harici Uygulama/ Harici Satış Uygulaması

 

Harici Uygulama / Harici Satış Uygulaması  / Açık / Girdi

Bilgi 

Tipi 

Zorunluluk 

Aciklama 

 cihaz_imei_no

String 

Seçimli

 Cihazın Imeı Numarası 

 cihaz_seri_no

String 

Seçimli 

 Cihazın Seri Numarası

 firma_unvan

 String

Zorunlu 

İşletici Kuruluşun Harici Uygulama / Harici Satış uygulaması için Bağlı Olduğu Firma Ünvan Bilgisi 

firma_vkn

 String

Zorunlu 

 İşletici Kuruluşun Harici Uygulama / Harici Satış uygulaması için Bağlı Olduğu Firma VKN Bilgisi

 aktivasyon_tarihi

String 

Zorunlu 

İşletici Kuruluşun Harici Uygulama

/Harici Satış Uygulamasını

Kullanmaya Başladığı Tarih

 tip

 String

Zorunlu 

İşletici Kuruluşun Seçebileceği

Uygulama Tip Bilgisi

1-> Harici Uygulama 

2-> Harici Satış Uygulaması

 

Harici Uygulama / Harici Satış Uygulaması / Kapalı /  Girdi 

Bilgi 

Tipi 

Zorunluluk 

Aciklama 

 cihaz_imei_no

String 

Seçimli

Cihazın Imeı Numarası 

 cihaz_seri_no

String 

Seçimli 

Cihazın Seri Numarası

 kapanma_tarihi

String 

Zorunlu 

İşletici Kuruluşun Harici Uygulama

/Harici Satış Uygulamasını

Kullanmaya Başladığı Tarih 

 tip

 String

Zorunlu 

İşletici Kuruluşun Seçebileceği

Uygulama Tip Bilgisi

1-> Harici Uygulama 

2-> Harici Satış Uygulaması

 

    1. Banka Uygulaması

 GMÖEBYS kapsamında işletici kuruluşların kullandıkları banka uygulamasına ait bilgileri gönderdikleri ve  bu uygulamaları ekleme ya da çıkarma işlemi için kullanılan metottur. Bu metot zorunludur. 

Uygulamaya ait Durum Bilgisi;

BA= Banka Uygulama Aktif

BK= Banka Uygulama Kapalı  

Banka uygulama durumu kapalıya çekilmeden cihaz durumu kapalıya çekilemez.

İmei No ya da seri No seçimli. Diğerleri zorunludur. 

 

 

Harici Uygulama / Harici Satış Uygulaması Cikti 

Bilgi

Tipi

Zorunluluk

Aciklama

durum

Boolean

Zorunlu

True ya da False Dönmektedir. True Döndüğünde İşlem Başarılı, False Döndüğünde ise Hatalıdır.

Sonuc 

 

Zorunlu 

Bakınız: Harici Uygulama /Harici

Satış Uygulama Bilgileri 

Bakınız: Harici Uygulama /Harici

Satış Uygulama Bilgileri

 

             

Metot: Banka Uygulaması Aktif

 

 Banka Uygulaması / Aktif /  Girdi 

Bilgi 

Tipi 

Zorunluluk 

Aciklama 

 cihaz_imei_no

String 

Seçimli

Cihazın Imeı Numarası 

 cihaz_seri_no

String 

Seçimli 

Cihazın Seri Numarası

 banka_unvan

String 

Zorunlu 

İşletici Kuruluşun Kullandığı Banka Uygulamasının Ünvan Bilgisi

 aktivasyon_tarihi

 String

Zorunlu 

İşletici Kuruluşun Kullandığı Banka Uygulamasını Aktif Etme Tarih Bilgisi

             

Metot: Banka Uygulaması Kapalı

 

Banka Uygulaması / Kapalı /  Girdi 

Bilgi 

Tipi 

Zorunluluk 

Aciklama 

 cihaz_imei_no

String

Seçimli

Cihazın Imei Numarası 

 cihaz_seri_no

String

Seçimli

Cihazın Seri Numarası

 kapanma_tarihi

String 

Zorunlu 

İşletici Kuruluşun Kullandığı Banka Uygulamasının Kapatıldığı Tarih 

 

 

    1. Cihaz Sorgulama    

    GMÖEBYS kapsamında işletici kuruluşların ekledikleri verileri sorgulayabilmek için kullanılan metottur. 

Sorgulama servisinde harici uygulama için dönen durum tipleri için;

HA=Harici Uygulama Aktif

SA=Harici Satış Uygulama Aktif

HK=Harici Uygulama Kapalı

SK=Harici Satış Uygulama Kapalı

Sorgulama servisinde banka uygulama dönen durum tipleri için;

BA= Banka Uygulama Aktif

BK= Banka Uygulama Kapalı 

Burada yer alan durum bilgisi girilen cihaza ait durumu bildirmektedir.

 

 

Banka Uygulaması Cikti 

 

Bilgi

Tipi

Zorunluluk

Aciklama

durum

Boolean

Zorunlu

True ya da False Dönmektedir. True Döndüğünde İşlem Başarılı, False Döndüğünde ise Hatalıdır.

Sonuc 

 

Zorunlu 

Bakınız: Banka Uygulaması Bilgileri 

 

 

             

Metot: Veri Sorgulama (QueryDevice)

 

Veri Sorgulama (QueryDevice)Girdi 

Bilgi 

Tipi 

Zorunluluk 

Aciklama 

 adres

String 

Zorunlu 

İşletici Kuruluşun Ekleyeceği Mükellefin Adres Bilgisi

il_kodu

String

Zorunlu 

İşletici Kuruluşun Ekleyeceği Mükellefin İl Kodu

ilce_adi

String

Zorunlu 

 İşletici Kuruluşun Ekleyeceği              Mükellefin İlçe Adı

Sertifika_turu

String

Zorunlu 

 Cihaz Sertifikalı ise 1 ,  

 Sertifikasız (Cep Tel, Tablet Vs.)   ise 0 Girilir.

cihaz_markasi

String

Zorunlu

 Cihazın Markası

cihaz_modeli

String

Zorunlu

 Cihazın Modeli

 son_guncelleme_tarihi

String

Zorunlu 

 İlgili Cihazın Son Güncellenme Tarihi

cihaz_seri_no

String

Seçimli

 Cihazın Seri Numarası 

cihaz_imei_no

String

Seçimli

 Cihazın Imeı Numarası

durum

String

Seçimli

 Eklenen Cihazın Durum Bilgisi

mukellef_vkn_tckn

String 

Zorunlu 

 İşletici Kuruluşun Ekleyeceği    Mükellefin Kimlik Numarası 10   ya da 11 Hane Olmalıdır.

mukellef_unvan 

String 

Zorunlu 

İşletici Kuruluşun Ekleyeceği Mükellefin Unvanı

kapanma_tarihi

Date

Zorunlu

 Cihazın Kapandığı Tarih

aktif_tarihi

Date

Zorunlu

 Cihazın Aktif Olduğu Tarih

 

 

 entegrator bilgileri 

 

 

 String

 

 

Zorunlu

 

 

 4.2 Yer Alan Bilgileri İçermektedir. 

 

 

 entegrator_vkn_tckn

 

 

 String

 

 

Zorunlu

 Mükellefin Bağlı Olduğu Özel  Entegratörün Kimlik Numarası 10   ya da 11 Hane Olmalıdır.

 

 

 

 entegrator_tıp

 

 

 

 String

 

 

 

 Zorunlu 

 

Mükellef e-Fatura mükellefi ise tip =1

Mükellef e-Arşiv mükellefi ise tip = 2

 

 

 

 eski_entagratör_bilgileri

 

 

 

 String

 

 

 

 Zorunlu 

 

 

4.3 te Alan Bilgileri İçermektedir. 

 

 

 entegrator_vkn_tckn

 

 

 String

 

 

Zorunlu

Mükellefin Bağlı Olduğu Özel Entegratörün Kimlik Numarası 10 ya da 11 Hane Olmalıdır.

 

 

 

 entegrator_tip

 

 

 

 String

 

 

 

 Zorunlu 

 

Mükellef e-Fatura mükellefi ise tip =1

Mükellef e-Arşiv mükellefi ise tip = 2

 

 

 

 eklenme_tarihi

 

 

 

 String

 

 

 

 Zorunlu 

 

 

Mükellefin Sisteme Eklendiği Tarih 

 

 

 

 kapanma_tarihi

 

 

 

 String

 

 

 

 Zorunlu 

 

Mükellefin Mükellefiyetinin

Kapandığı Tarih 

 

 

 banka bilgileri (aktif)

 

 

 String

 

 

 Zorunlu 

 

Mükellefe Ait Banka Aktif Bilgileri 

 

 

 durum

 

 

 String

 

 

 Zorunlu 

Banka Aktif

Banka Kapalı Durum Bilgisi

 

 

 

 banka_unvan

 

 

 

 String

 

 

 

 Zorunlu 

İşletici Kuruluşun Kullandığı Banka Uygulamasının Ünvan Bilgisi

 

 

 

 

 

 aktivasyon_tarihi

 

 

 

 String

 

 

 

 Zorunlu 

İşletici Kuruluşun Kullandığı Banka Uygulamasını Aktif Etme Tarih Bilgisi

 

 

 

 banka uygulama kapalı bilgileri 

 

 

 

 String

 

 

 

 Zorunlu 

 

 

Mükellefe ait Banka Kapalı Bilgileri

 

 

 

 durum

 

 

 

 String

 

 

 

 Zorunlu 

 

Banka Aktif

Banka Kapalı Durum Bilgisi

 

 

 

 banka_unvan

 

 

 

 String

 

 

 

 Zorunlu 

İşletici Kuruluşun Kullandığı Banka Uygulamasının Ünvan Bilgisi

 

 

 

 aktivasyon_tarihi

 

 

 

 String

 

 

 

 Zorunlu 

İşletici Kuruluşun Kullandığı Banka Uygulamasını Aktif Etme Tarih Bilgisi

 

 

 

 Kapanma tarihi

 

 

 

 String

 

 

 

 Zorunlu 

 

İşletici Kuruluşun Kullandığı Banka Uygulamasının Kapatıldığı Tarih

 

 

 Harici uygulama bilgileri (aktif)

String 

Seçimli

Mükellefe ait Harici Uygulama Bilgileri 

 

 

 

 durum

 

 

 

 String

 

 

 

 Zorunlu 

Harici Uygulama ya da Harici Satış

Uygulaması Durum Bilgisi 

HA=Harici Uygulama Aktif

SA=Harici Satış Uygulama Aktif

 cihaz_imei_no

String 

Seçimli

 Cihazın Imeı Numarası 

 cihaz_seri_no

String 

Seçimli 

 Cihazın Seri Numarası

 firma_unvan

 String

Zorunlu 

İşletici Kuruluşun Harici Uygulama /

Harici Satış uygulaması için Bağlı Olduğu Firma Unvan Bilgisi 

firma_vkn

 String

Zorunlu 

 İşletici Kuruluşun Harici Uygulama /

Harici Satış uygulaması için Bağlı Olduğu Firma VKN Bilgisi

 aktivasyon_tarihi

String 

Zorunlu 

İşletici Kuruluşun Harici Uygulama

/Harici Satış Uygulamasını

Kullanmaya Başladığı Tarih 

 Harici Uygulama/Harici Satış Uygulaması Kapalı Bilgileri

String 

Seçimli

Mükellefe ait Harici Uygulama/Harici Satış Uygulama Bilgileri 

 durum

 

 

 

 String

 

 

 

 Zorunlu 

Harici Uygulama ya da Harici Satış

Uygulaması Durum Bilgisi  HK=Harici Uygulama Kapalı

SK=Harici Satış Uygulama Kapalı

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 cihaz_imei_no

String 

Seçimli

Cihazın Imeı Numarası 

 cihaz_seri_no

String 

Seçimli 

Cihazın Seri Numarası

 kapanma_tarihi

String 

Zorunlu 

İşletici Kuruluşun Harici Uygulama

/Harici Satış Uygulamasını

Kullanmaya Başladığı Tarih 

 tip

 String

Zorunlu 

İşletici Kuruluşun Seçebileceği Uygulama Tip Bilgisi

 

 1-> Harici Uygulama 

 2-> Harici Satış Uygulaması

 

Veri Sorgulama (RegisterDevice)Cikti 

Bilgi

Tipi

Zorunluluk

Aciklama

durum

Boolean

Zorunlu

True ya da False Dönmektedir. True Döndüğünde İşlem Başarılı, False Döndüğünde ise Hatalıdır.

Sonuc 

 

Zorunlu 

Bakınız: Entegratör Bilgileri

Bakınız: Eski Entegratör Bilgileri 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

                  4. ORTAK YAPILAR TEKNİK BİLGİLER

1.Sonuç

 

Sonuc

 

Bilgi

Tipi

Zorunluluk

Aciklama

 

cihaz_id

 

String

 

Zorunlu

IMEI No Veya Cihaz No Bilgisi Dönülecektir.

 

kod

 

String

 

Zorunlu

Requestin Durum Kodu Dönülecektir.

Bakınız: Durum Kodları

 

 

mesaj

 

 

String

 

 

Zorunlu

Durum Kodunun Açıklaması Dönülecektir.

Bakınız: Durum Kodları

 

  1.  

2. Entegratör Bilgileri 

 

Sonuc

 

Bilgi

Tipi

Zorunluluk

Aciklama

 

 

 entegratör_vkn_tckn 

 

 

 String

 

 

Zorunlu

Mükellefin Bağlı Olduğu Özel Entegratörün Kimlik Numarası 10 ya da 11 Hane Olmalıdır.

 

   tip 

 

 

 

String

 

 

 

Zorunlu

 

Mükellef e-Fatura mükellefi ise tip =1

Mükellef e-Arşiv mükellefi ise tip = 2

 

 

 

mesaj

 

 

 

String

 

 

 

Zorunlu

 

Mükellefin Entegratör Vkn/ Tckn Bilgisi ve Entegratör Tip Bilgisi Dönülecektir.

  1.  

3. Eski Entegratör Bilgileri

 

Sonuc

 

Bilgi

Tipi

Zorunluluk

Aciklama

 

 

 entegratör_vkn_tckn 

 

 

String

 

 

Zorunlu

Mükellefin Bağlı Olduğu Özel Entegratörün Kimlik Numarası 10 ya da 11 Hane Olmalıdır.

 

   tip 

 

 

 

String

 

 

 

Zorunlu

 

Mükellef e-Fatura mükellefi ise tip =1

Mükellef e-Arşiv mükellefi ise tip = 2

 

 eklenme tarihi 

 

String

 

Zorunlu

 

Mükellefin Sisteme Eklendiği Tarih 

 

 kapanma tarihi

 

String

 

Zorunlu

Mükellefin Mükellefiyetinin Kapandığı Tarih 

 

 

 

 

 mesaj

 

 

 

 

String

 

 

 

 

Zorunlu

 

Mükellefin Entegratör Vkn/ Tckn Bilgisi ve Entagratör Tip Bilgisi Eklenme Tarihi ve Kapanma Tarihi Bilgileri Dönülecektir.

  1.  

4.Harici Uygulama Bilgileri

 

Sonuc

 

Bilgi

Tipi

Zorunluluk

Aciklama

 

 

 durum

 

 

String

 

 

Zorunlu

True ya da False Dönmektedir. True Döndüğünde İşlem Başarılı, False Döndüğünde ise Hatalıdır.

 

 kod

 

String

 

Zorunlu

Requestin Durum Kodu Dönülecektir.

Bakınız: Durum Kodları

 

 

mesaj

 

 

String

 

 

Zorunlu

Durum Kodunun Açıklaması Dönülecektir.

Bakınız: Durum Kodları

  1.  

5.Banka Uygulama Bilgileri

 

Sonuc

 

Bilgi

Tipi

Zorunluluk

Aciklama

 

 

 durum

 

 

String

 

 

Zorunlu

True ya da False Dönmektedir. True Döndüğünde İşlem Başarılı, False Döndüğünde ise Hatalıdır.

 

kod

 

String

 

 Zorunlu

Requestin Durum Kodu Dönülecektir.

Bakınız: Durum Kodları

 

 

mesaj

 

 

String

 

 

Zorunlu

Durum Kodunun Açıklaması Dönülecektir.

Bakınız: Durum Kodları

 

 

  1.  

6.Durum Kodları ve Açıklamaları

 

Bu alanda Web Servis üzerinden yapılan işlemlerde dönülen Durum Kodu ve Açıklamaları mevcuttur.

 *****

 

 

ArchiveDateError

1019

"Arşiv Için Gönderilen Tarih Hatalıdır."

EntegratorFault

1020

"Gönderilen Entagratör Bilgisi

Ile Mükellefin Çalıştığı

Entagratör Bilgisi

Uyuşmamaktadır."

ArchiveIssueDateError

1021

"Gönderilen Durum Tarihi Kapanma Tarihinden Önce Olamaz."

ArchiveAlreadyAdded

1022

"Daha Önce Eklenen Cihaz Aynı Tarihler Ve Aynı Mükellef

Bilgisi Ile Tekrar Eklenemez."

DateEmpty

1023

"Durum Tarihi Ve Kapanma

Tarihi Boş Olamaz"

MukellefError

1024

"Gönderilen Mükellef Vkn İlgili Cihaza Kayıtlı Değildir"

IssueDateNull

1025

"Cihazın Durum Tarihi Null Olamaz"

AlreadySavedEnt

1026

"Cihaz Gönderilen Entegratöre

Kayıtlıdır."

OrganizationNotAuth

1027

"İşletici Kuruluşun Gönderilen Cihazı Görüntüleme Yetkisi Yoktur."

AfterDate

1028

"Durum Tarihi Bugünün Tarihinden İleri Bir Tarih Olamaz. "

EntegratorError

1029

"Entegrator Tip Gönderimi Hatalıdır."

EntegratorDublicate

1030

"Aynı Entegratör Vkn/Tckn Ve Tip Bilgisi Gönderilemez."

EntegratorNotFound

1031

"Entegratör Bilgisi Hatalıdır."

OneEntegratorError

             

1032

"Sistemde Kayıtlı En Az Bir E-

Fatura/Earsiv Entegratörü Olmalıdır."

DeleteFaultEar

 

1033

"Sistemde Yalnızca Bir Adet EArsiv Entegratörü Kayıtlıdır.

Yeni Entegratör Eklemeden Silme Işlemi Yapılamaz."

DeleteFaulteFat

1034

"Sistemde Yalnızca Bir Adet EFatura Entegratörü Kayıtlıdır.

Yeni Entegratör Eklemeden Silme Işlemi Yapılamaz."

SeriNoError

1035

Sertifika Bilgisi 1 gönderilen cihazların seri no bilgisi gönderilmelidir.

AlreadyBankActive

1036

Banka Aktif Cihaz Tekrar Banka Aktif Olamaz

DeviceNotBankActive

1037

Banka Aktif Olmayan Cihaz

Banka Kapalı Olamaz

AlreadyApplicationActive

1038

Harici Uygulama Aktif Olan Cihaz Tekrar Aktif Olamaz

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  1. ÖRNEK REQUEST VE RESPONSE ÖRNEKLERİ
    1. Cihaz ekleme

Dikkat edilmesi gereken noktalar;

 Mevcuttaki requestlere entegratör bilgi kısmı eklendi. Entegratör bilgi kısmı entegratör vkn/ tckn alanından ve entegratör tip alanını kapsamaktadır. Entegratör tip bilgisi 1 veya 2 şeklinde gönderilebilir;

AlreadyApplicationSalesActive

1039

Harici Satış Uygulama Aktif

Olan Cihaz Tekrar Aktif Olamaz

 

 

 

 

 

  • Mükellef e-Fatura mükellefi ise tip =1
  • Mükellef e-Arşiv mükellefi ise tip = 2 şeklindedir. 
  • Entegratör bilgi için bir veya birden fazla bilgi gönderilebilir. 
  • 1 den fazla Entegratör bilgisi gönderildiğinde, gönderilen veriler için aynı tipte aynı entegratör vkn/tckn bilgisi gönderilemez. 
  • Bir adet vkn/tckn gönderilmesi durumunda bu gönderilen entegratörün tip bilgisi 1 olmalıdır. Eğer tip 2 olursa entegratör bilgisi hatalıdır mesajı dönülecektir.
  • Eğer bir adet entegratör vkn/tckn bilgisi gönderilirse hem e-Arşiv hem de e-Fatura entegratörü olarak kullanılacaktır.
  • Aynı tip ve farklı vkn/tckn bilgisi gönderilebilir. Bu gönderilen vkn/tckn ler hem e-Arşiv hem de eFatura entegratörü olarak kabul edilecektir. 

 

 

 

Cihaz Ekleme Örnek Request ve Response Örnekleri

REQUEST:POST

{

  "mukellef_vkn_tckn": "************",

  "mukellef_unvan": "GIB",

  "mukellef_adres": "Merasim  Caddesi ",

  "il_kodu": "051",

  "ilce_adi": "Merkez",

  "sertifika_bilgisi": 1,

  "cihaz_markasi": "MARKA",

  "cihaz_modeli": "MODEL",

  "islem_tarihi": "2025-03-02",

  "cihaz_seri_no": "GIB1234567890",

  "cihaz_imei_no": "",

  "entegrator_bilgi": [

    {

      "entegrator_vkn_tckn": "6090122074",

      "entegrator_tip": 1

    },

    {

      "entegrator_vkn_tckn": "7230421913",

      "entegrator_tip": 2

    }

  ]

}

RESPONSE (Başarılı ise)

{

"durum": true,

"sonuc": [

{

"cihaz_id": "GIB777777",

"kod": "1000",

"mesaj": "İşlem başarılı bir şekilde tamamlanmıştır" }

]

}

RESPONSE (Hatalı ise)

{

  "durum": false,

  "sonuc": [

    {

      "cihaz_id": "GIB777777",

      "kod": "1011",

      "mesaj": "Cihaz daha önce kaydedilmiş"

   }

  ]

}

 

 

 

 

Cihaz Ekleme Örnek Request ve Response Örnekleri

REQUEST:POST

{

  "mukellef_vkn_tckn": "************",

  "mukellef_unvan": "GIB",

  "mukellef_adres": "Merasim Caddesi ",

  "il_kodu": "051",

  "ilce_adi": "Merkez",

  "sertifika_bilgisi": 1,

  "cihaz_markasi": "MARKA",

  "cihaz_modeli": "MODEL",

  "islem_tarihi": "2025-03-02",

  "cihaz_seri_no": "GIB1234567890",

  "cihaz_imei_no": "",

   {

       "entegrator_bilgi": [

 

    {

      "entegrator_vkn_tckn": "6090122074",

      "entegrator_tip": 3

    }

  ]

}

 

RESPONSE (Hatalı)

{

  "durum": false,

  "sonuc": [

    {

      "cihaz_id": "",

      "kod": "1002",

      "mesaj": "Entegrator Tip hatalı. Efatura Entegratörleri için '1', Earşiv Entegratörleri için '2' bilgisi gönderilebilir."

    }

  ]

}

 

 

Cihaz Ekleme Örnek Request ve Response Örnekleri

REQUEST:POST

{

  "mukellef_vkn_tckn": "************",

  "mukellef_unvan": "GIB",

  "mukellef_adres": "Merasim  Caddesi ",

  "il_kodu": "051",

  "ilce_adi": "Merkez",

  "sertifika_bilgisi": 1,

  "cihaz_markasi": "MARKA",

  "cihaz_modeli": "MODEL",

  "islem_tarihi": "2025-03-02",

  "cihaz_seri_no": "GIB1234567890",

  "cihaz_imei_no": "",

 {

  

  "entegrator_bilgi": [

    {

      "entegrator_vkn_tckn": "6090122074",

      "entegrator_tip": 1

    },

    {

      "entegrator_vkn_tckn": "6090122074",

      "entegrator_tip": 1

    }

  ]

}

 

 

RESPONSE (Hatalı)

{

  "durum": false,

  "sonuc": [

    {

      "cihaz_id": GIB7777",

      "kod": "1030",

      "mesaj": "Aynı Entegratör vkn/tckn ve tip Bilgisi Gönderilemez."

    }

  ]

}

 

 

 

 

 

  1.  

2.Arşiv Cihaz ekleme

 

 

Arşiv Cihaz Ekleme Örnek Request ve Response Örnekleri

REQUEST:POST

{

  "mukellef_vkn_tckn": "*************",

  "mukellef_unvan": "GIB",

  "mukellef_adres": "Merasim Caddesi",

  "il_kodu": "006",   "ilce_adi": "Altındağ",

  "sertifika_bilgisi": 1,

  "cihaz_markasi": "MARKA",

  "cihaz_modeli": "MODEL",

  "islem_tarihi": "2022-04-11",

  "cihaz_seri_no": "**********",

  "cihaz_imei_no": "",

  "entegrator_bilgi": [

    {

      "entegrator_vkn_tckn": "**********",

      "entegrator_tip": 1

    }

  ],

  "kapanma_tarihi": "2023-04-11" }

RESPONSE (Başarılı ise)

{

"durum": true,

"sonuc": [

{

"cihaz_id": "GIB777777",

"kod": "1000",

"mesaj": "İşlem başarılı bir şekilde tamamlanmıştır" }

]

}

 

 

RESPONSE (Hatalı ise)

{

"durum": false,

"sonuc": [

{

"cihaz_id": "GIB777777",

"kod": "1011",

"mesaj": "Cihaz daha önce kaydedilmiş" }

] }

 

Dikkat edilmesi gereken noktalar;

  • Tarih olarak islem_tarihi -> kapanma tarihi kuralları;
  • 2021-02-15 ile 2025-01-20 tarihleri arasında işlem gören cihazlar bu servis üzerinden bildirilecektir. Bu tarih aralığında bildirilen cihazlar için tamamı kapalı konumda olacaktır.
  • Bu cihazları bildirirken tarih sırasına önem göstererek sırayla bildirilmesi gerekmektedir.
  • islem_tarihi -> cihazın mükellefe verildiği tarih, kapanma_tarihi -> cihazın mükelleften alındığı tarih

 

  1.  

3. Cihaz Silme

Cihaz Silme Örnek Request ve Response Örnekleri

REQUEST:POST

{

"cihaz_seri_no": " GIB1234567890",

"cihaz_imei_no": "",

"islem_tarihi ": "2024-10-04" }

 

RESPONSE (Başarılı ise)

{

"durum": true,

"sonuc": [

{

"cihaz_id": "GIB777777", 

"kod": "1000",

"mesaj": "İşlem başarılı bir şekilde tamamlanmıştır" }

]

}

 

 

RESPONSE (Hatalı ise)

{

"durum": false,

"sonuc": [

{

"cihaz_id": "GIB777777", 

"kod": "1011",

"mesaj": "Cihaz daha önce kaydedilmiş" }

] }

 

  1.  

4. Adres Güncelleme

 

Adres Güncelleme Örnek Request ve Response Örnekleri

REQUEST:POST

{

"mükellef_adres": "Yeni Ziraat Mahallesi Etlik Cad. No: 16 06110 Dışkapı", 

"cihaz_seri_no": "",

"cihaz_imei_no": "GIB1234567890",

"il_kodu": "006",

"ilce_adi": "Altındağ" }

RESPONSE (Başarılı ise)

{

"durum": true,

"sonuc": [

{

"cihaz_id": "GIB777777",

 

"kod": "1000",

"mesaj": "İşlem başarılı bir şekilde tamamlanmıştır" }

] }

RESPONSE (Hatalı ise)

{

"durum": false,

"sonuc": [

{

"cihaz_id": "GIB777777",

"kod": "1011",

"mesaj": "Cihaz daha önce kaydedilmiş" }

] }

 

 

  1.  

5. Entegratör Ekleme

 

Entegratör Ekleme Örnek Request ve Response Örnekleri

REQUEST:POST

{

 "entegrator_vkn_tckn": "**********",

  "mukellef_vkn_tckn": "***********",

  "cihaz_imei_no": "",

  "cihaz_seri_no": "GIB777777",

  "entegrator_tip": 2,

  "islem_tarihi": "2025-04-02"

}'

RESPONSE (Başarılı ise)

{

"durum": true,

"sonuc": [

{

"cihaz_id": " GIB777777",

 "kod": "1000",

"mesaj": "İşlem başarılı bir şekilde tamamlanmıştır" }

] }

RESPONSE (Hatalı ise)

{

"durum": false,

"sonuc": [

{

"cihaz_id": " GIB777777", "kod": "1020",

"mesaj": "Gönderilen Entagrator bilgisi ile mükellefin çalıştığı entagratör bilgisi uyuşmamaktadır." }

] }

 

 

6. Entegratör Silme

 

Entegratör Silme Örnek Request ve Response Örnekleri

REQUEST:POST

{

 

      "entegrator_vkn_tckn": "**********",

  "mukellef_vkn_tckn": "**********",

  "cihaz_imei_no": "",

  "cihaz_seri_no": "GIB7777",

  "entegrator_tip": 2,

  "islem_tarihi": "2025-04-02" }

 

 

  1.  

7.Harici Uygulama /Harici Satış Uygulaması

İmei No ya da seri No seçimli. Diğerleri zorunlu, tip bilgisi yalnızca 1 veya 2 olarak gelebilir. 1-> Harici Uygulama  2-> Harici Satış Uygulaması 

Tip 1 ve Tip 2 için ayrı ayrı gönderim yapılabilir. 

Tip 1 olarak gönderim yapıldığında Harici Uygulama kapatma, Tip 2 olarak gönderim yapıldığında Harici Satış Uygulaması Kapanma kaydı yapılacaktır.

 

Harici Uygulama/ Harici Satış Uygulaması Aktif Örnek Request ve Response Örnekleri

REQUEST:POST

 

{

  "imeiNo": "",

  "seriNo": "GIB12346789",

  "firma_unvan": "TEST",

  "firma_vkn": "1234567890",

  "aktivasyon_tarihi": "2025-07-10",

  "tip": 1

}

 

RESPONSE (Başarılı ise)

{

"durum": true,

"sonuc": [

{

"kod": "1000",

"mesaj": "İşlem başarılı bir şekilde tamamlanmıştır" }

] }

RESPONSE (Hatalı ise)

{

"durum": false,

"sonuc": [

{

 

"kod": "1038",

"mesaj": Harici Uygulama Aktif Olan Cihaz Tekrar Aktif Olamaz

] }

Harici Uygulama/ Harici Satış Uygulaması Kapalı Örnek Request ve Response Örnekleri

REQUEST:POST

{

  "seri_no": "GIB123456789",

  "imei_no": "",

  "kapanma_tarihi": "2025-07-11",

  "tip": 1

}

RESPONSE (Başarılı ise)

{

"durum": true,

"sonuc": [

{

     "kod": "",

  "mesaj": "Uygulama durumu başarıyla kaydedildi.",

  ] }

RESPONSE (Başarısız ise)

{

  "durum": false,

"sonuc": [

{

  "hataKodu": "1039",

  "mesaj": "Harici Satış Uygulama Aktif Olan Cihaz Tekrar Aktif Olamaz." }

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  1. 8. Banka Uygulaması

   İmei No ya da seri No seçimli. Diğerleri zorunludur. 

Banka Uygulaması Aktif / Örnek Request ve Response Örnekleri

REQUEST:POST

 {

  "imeiNo": "",

  "seriNo": "GIB123456789",   "banka_unvan": "A Bankası",

  "aktivasyon_tarihi": "2025-07-10" }

RESPONSE (Başarılı ise)

{

"durum": true,

"sonuc": [

{

"cihaz_id": " GIB777777",

"kod": "1000",

"mesaj": "İşlem başarılı bir şekilde tamamlanmıştır" }

] }

RESPONSE (Hatalı ise)

{

"durum": false,

"sonuc": [

{

"cihaz_id": " GIB777777", "kod": "", "mesaj": 

}

] }

Banka Uygulaması Kapalı  / Örnek Request ve Response Örnekleri

 

{

  "seri_no": "GIB12346789",

  "imei_no": "",

  "kapanma_tarihi": "2025-07-10"

}

  

RESPONSE (Başarılı ise)

{

  "durum": true,

 "sonuc": [

{

 

  "kod": "",

  "mesaj": "Cihaz durumu başarıyla kaydedildi.",

  

}

RESPONSE (Hatalı ise)

{

  "durum": false,

"sonuc": [

{

  "hataKodu": "1036",

  "mesaj": "Banka Aktif Cihaz Tekrar Banka Aktif Olamaz." }

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

9. Cihaz Sorgulama

1.

Cihaz Sorgulama Örnek Request ve Response Örnekleri

REQUEST:GET

{

  "durum": true,

  "sonuc": [

    {

      "cihaz_id": "GIB11111111",

      "kod": "1000",

      "mesaj": "İşlem başarılı bir şekilde tamamlanmıştır",       "cihaz_listesi": [

        {

          "adres": "Ankara TÜRKİYE",

          "il_kodu": "006",

          "ilce_adi": "MERKEZ",

          "sertifika_türü": "1",

          "marka": "TEST",

          "model": "TEST",

          "son_guncelleme_tarihi": "2025-07-18T14:04:27.928+00:00",

          "seri_no": "GIB11111111",

          "imei_no": "",

          "durum": "AKTIF",

          "mukellef_unvan": "Test Firması 3",

          "mukellef_vkn_tckn": "1234567890",

          "aktif_tarihi": "2025-07-18",

          "entegrator_bilgileri": [

            {

              "entegrator_vkn_tckn": "1111111111",

              "tip": 2,

              "eklenme_tarihi": "2025-07-18"

            },

            {

              "entegrator_vkn_tckn": "1111111111",

              "tip": 1,

              "eklenme_tarihi": "2025-07-18"

            }

          ],

          "eski_entegrator_bilgileri": [],

          "banka_uygulama_bilgileri": [

            {

              "durum": "BA",

              "banka_unvan": "A Bankası",

              "aktivasyon_tarihi": "2025-07-24"

            }

          ],

          "banka_uygulama_kapali_bilgileri": [

            {

              "durum": "BK",               "banka_unvan": "A Bankası",

              "aktivasyon_tarihi": "2025-07-20",

              "kapanma_tarihi": "2025-07-24"

            }

          ],

          "harici_uygulama_bilgileri": [],

          "harici_uygulama_kapali_bilgileri": []

        }

      ]

    }

  ]

}

 

  

                                                                       RESPONSE(Başarılı ise)

{

  "durum": true,

  "sonuc": [

    {

      "cihaz_id": "GIB7777",

      "kod": "1000",

      "mesaj": "İşlem başarılı bir şekilde tamamlanmıştır",       "cihaz_listesi": [

 

}

                                                                      RESPONSE (Hatalı ise)

{

"durum": false,

"sonuc": [

{

"cihaz_id": " GIB777777", "kod": "1013",

"mesaj": "Cihaz Bulunamadı"

 

}

] }

 

 

2.

 

Cihaz Sorgulama Örnek Request ve Response Örnekleri

REQUEST:GET

{

  "durum": true,

  "sonuc": [

    {

      "cihaz_id": "GIB11111111",

      "kod": "1000",

      "mesaj": "İşlem başarılı bir şekilde tamamlanmıştır",       "cihaz_listesi": [

        {

          "adres": "Ankara TÜRKİYE",

          "il_kodu": "006",

          "ilce_adi": "MERKEZ",

          "sertifika_türü": "1",

          "marka": "TEST",

          "model": "TEST",

          "son_guncelleme_tarihi": "2025-07-18T14:04:27.928+00:00",

          "seri_no": "GIB11111111",

          "imei_no": "",

          "durum": "AKTIF",

          "mukellef_unvan": "Test Firması 3",

          "mukellef_vkn_tckn": "1234567890",

          "aktif_tarihi": "2025-07-18",

          "entegrator_bilgileri": [

            {

              "entegrator_vkn_tckn": "1111111111",

              "tip": 2,

              "eklenme_tarihi": "2025-07-18"

            },

            {

              "entegrator_vkn_tckn": "1111111111",

              "tip": 2,

              "eklenme_tarihi": "2025-07-18"

            }

          ],

          "eski_entegrator_bilgileri": [],

          "banka_uygulama_bilgileri": [

            {

              "durum": "BA",

              "banka_unvan": "A Bankası",

              "aktivasyon_tarihi": "2025-07-24"

            }

          ],

          "banka_uygulama_kapali_bilgileri": [

            {

              "durum": "BK",

              "banka_unvan": "A Bankası",

              "aktivasyon_tarihi": "2025-07-20",

              "kapanma_tarihi": "2025-07-24"

            }

          ],

          "harici_uygulama_bilgileri": [],

          "harici_uygulama_kapali_bilgileri": []

        }

      ]

    }

  ]

}

RESPONSE (Başarılı ise)

{

 

  "durum": true,

  "sonuc": [

    {

      "cihaz_id": "GIB7777",

      "kod": "1000",

      "mesaj": "İşlem başarılı bir şekilde tamamlanmıştır",       "cihaz_listesi": [

 

}

 

RESPONSE (Hatalı ise)

{

"durum": false,

"sonuc": [

{

"cihaz_id": " TEST123",  "kod": "1013",

"mesaj": "Cihaz Bulunamadı"

}

] }