Yemek Kartı Entegrasyonu: Tek Panelde Tahsilat

Türkiye pazarında yaygın olarak Multinet, Pluxee (eski Sodexo), Edenred Ticket Restaurant, Metropol ve Setcard entegre edilir; kuruluşların mobil uygulama ve karekod ödemeleri de aynı akışa bağlanabilir. Hangilerini kabul edebileceğiniz imzaladığınız üye işyeri sözleşmelerine, sektör kodunuza ve cihaz altyapınıza bağlıdır. Yazılım tarafında her kuruluş ayrı bir tahsilat tipi olarak tanımlanır.

Her kuruluşla ayrı başvuru yapılır. Genelde vergi levhası, imza sirküleri, işletme ruhsatı, banka hesap bilgisi ve işletme fotoğrafları istenir. Başvuru onaylandıktan sonra komisyon oranı ve ödeme vadesi görüşülür, kuruluş size Merchant/terminal bilgilerini tanımlar. Bu bilgiler yazılıma girilip test işlemleri yapıldıktan sonra tahsilat alınmaya başlanır. Sözleşme işletmenin adına yapılır; yazılım firması bu sürecin tarafı değildir.

Komisyon kuruluşla yaptığınız anlaşmaya özeldir ve entegrasyondan bağımsızdır. Oranı belirleyen üç şey vardır: aylık yemek kartı cironuz, seçtiğiniz ödeme vadesi ve sektör/lokasyon. Kısa vade isteyen işletmeler genelde daha yüksek oran öder. Hacminiz büyüdükçe yeniden pazarlık edebilirsiniz; entegrasyonun ürettiği kuruluş bazlı hacim raporu bu görüşmede elinizdeki en somut veridir.

Vade kuruluşa ve sözleşmenize göre değişir; sektörde haftalık, on beş günlük ve aylık ödeme seçenekleri konuşulur. Entegre yapıda her satışta beklenen tutar birikir, komisyon düşülür ve hesabınıza geçen havale bu alacakla eşleştirilir. Böylece hangi kuruluştan hangi hafta ne kadar gireceğini önceden görür, nakit akışınızı buna göre planlarsınız.

EFT-POS özellikli yeni nesil ÖKC'ler birden fazla kuruluşu tek cihazda toplayabilir; bu, kasadaki cihaz kalabalığını ve kablo karmaşasını ciddi biçimde azaltır. Ancak her kuruluşun ilgili cihaz üreticisi/banka tarafında yüklü olması gerekir. Bazı kuruluşlar hâlâ kendi terminalini veya sanal entegrasyonunu tercih ettirebilir; bu yüzden cihaz kararı sözleşmelerden önce değil, sonra netleşir.

Çoğu durumda evet. Belirleyici olan, mevcut yazılımın ödeme tipi ekleyebilen bir API veya cihaz entegrasyon katmanına sahip olmasıdır; banka POS entegrasyonu zaten kuruluysa yemek kartı çoğunlukla aynı katmana eklenir. Kapalı bir sistemde tahsilat cihazdan alınıp gün sonunda toplu aktarılabilir, ancak satır bazlı mutabakat kaybolur. İnceleme yaparken bakılan ilk şey, yazılımın satış kaydına ödeme tipi ve işlem numarası yazıp yazamadığıdır.

Karma ödeme devreye girer: hesabın bir kısmı yemek kartından geçilir, kalan tutar nakit veya banka kartıyla kapatılır. Yazılım iki ayrı tahsilat satırı üretir, tek fiş çıkar ve stok yalnızca bir kez düşer. Bakiye sorgulamayı satış öncesine almak, kasiyerin daha ilk denemede doğru tutarı girmesini sağlar ve iptal-tekrar deneme trafiğini azaltır.

Yemek kartları yemek ve gıda harcaması için tanımlıdır; kuruluşlar sektör kodu ve ürün kısıtı üzerinden bunu denetler. Market ve büfe gibi karma reyonu olan işletmelerde doğru yaklaşım, yemek kartıyla ödenebilir ürünleri yazılımda ayrı bir kural setiyle işaretlemektir. Böylece kasiyer yanlış sepeti yemek kartına yönlendiremez, sonradan iptal ve mutabakat farkı oluşmaz.

Satış anında kuruluş bazında beklenen tutar birikir, komisyon ve vade kuralı uygulanır, banka hesabına geçen havale bu beklentiyle eşleştirilir. Eşleşmeyen kalemler — iptal edilip iade edilmemiş işlem, yanlış terminalden geçen satış, kuruluşun düzeltme kaydı — ayrı bir açık liste olarak kalır. Elle yapıldığında ayda yarım gün süren ekstre karşılaştırması, günlük birkaç dakikalık bir kontrole iner.

Perakende satışta tahsilat ÖKC/yeni nesil yazarkasa üzerinden mali fişe işlenir. Muhasebede kritik nokta, yemek kartını nakit veya banka kartıyla aynı hesaba atmamaktır: her kuruluş ayrı alacak hesabı olur, komisyon gider olarak ayrışır, gelen havale alacağı kapatır. Bu kırılım Logo, Mikro, Netsis veya Paraşüt aktarımıyla otomatikleştiğinde ay sonu kapanışı sadeleşir.

Yemek kartı işlemleri kuruluşun sunucusundan çevrimiçi onay gerektirdiği için bağlantı yoksa tahsilat alınamaz. Bu nedenle kasada yedek bağlantı (GSM hattı olan cihaz veya ikinci internet) bulundurmak pratik bir önlemdir. Yazılım tarafında ise adisyon çevrimdışı çalışmaya devam edip bağlantı gelince tahsilatı tamamlayabilecek şekilde kurgulanır; sipariş ve stok verisi kaybolmaz.

İade, satışın geçtiği kuruluşun kanalı üzerinden ve çoğunlukla orijinal işleme referansla yapılır; gün sonu kapandıktan sonra iptal yerine iade işlemi gerekir. Yazılım tarafında iade kaydı stok ve ciro düzeltmesini tetikler, mutabakattaki beklenen tutarı düşürür. En sık görülen hata, iadeyi nakit vererek kapatmaktır; bu, kuruluş ekstresiyle kasa arasında kalıcı fark bırakır.

Kuruluşun uzaktan ödeme veya sanal POS desteği varsa evet. Masadaki QR menüden verilen siparişte müşteri kendi telefonundan yemek kartı uygulamasıyla ödeyebilir; bu akış karekod ve dijital cüzdan tahsilat altyapısına bağlanır. Paket serviste ödeme linki veya kapıda EFT-POS kullanılır. Her kanal ayrı sözleşme kalemi olabildiği için hangi kanalı kullanacağınıza entegrasyon başlamadan karar vermek gerekir.

Hayır, bu iki akış birbirine karıştırılmamalı. Pazaryeri siparişinde tahsilatı platform yapar ve size hakediş öder; bu, kendi kasanızdan geçen yemek kartı tahsilatı değildir. Muhasebede pazaryeri hakedişi ayrı bir alacak hesabında izlenir. Aynı gün içinde her iki kanaldan satış yapan işletmelerde ciroyu doğru okumanın tek yolu bu ayrımı yazılım seviyesinde kurmaktır.

Süreyi belirleyen, teknik iş değil kuruluşların üye işyeri onay süreçleridir; yazılım tarafı hazırken sözleşmeler beklenebilir. Maliyette hazır bulut POS abonelikleri yıllık yaklaşık 25.000–35.000 TL bandında ilan ediliyor. Özel geliştirilen entegrasyonda bütçe; kabul edilecek kuruluş sayısı, mutabakat otomasyonunun derinliği, muhasebe aktarımı ve şube sayısıyla değişir. Kapsam netleşmeden verilen tek fiyat gerçekçi olmaz.

Edge Bilişim olarak işe sahada bir vardiya izleyip mevcut ödeme akışını çıkarmakla başlıyoruz; ardından kuruluş-kanal matrisini (masa, paket, QR) birlikte karara bağlıyor, test ortamında satış-iade-karma ödeme turlarını kasiyerle deniyoruz. Canlıya geçişi yoğun olmayan bir gün öğleden sonra yapıp ilk gün sonu kapanışını birlikte alıyor, teslimatta kaynak kodu Git deposuyla devrediyoruz. Detaylı kapsam için özel yazılım geliştirme tarafındaki çalışma modelimize ve Avize ERP saha yönetim sistemi projemize bakabilirsiniz.