2026-08-10 Yazar : ZCS
Bir POS terminalinde sadakat programının başarısız olmasının en büyük nedeni şudur: Donanım, dışarıdan yazılım girişine izin verecek şekilde tasarlanmamıştır. Perakendeciler bir sadakat platformu satın alır, sözleşmeyi imzalar, dağıtım için bütçe ayırır; ardından terminalin işletim sisteminin, SDK'sının veya ödeme sertifikasının entegrasyonu tamamen engellediğini keşfederler. Bu bir yazılım sorunu değil, donanım mimarisi sorunudur ve bir satıcı, sadakat programı işlevselliğine sahip bir POS sistemini, açık bir bilgi işlem cihazı yerine kapalı bir ödeme cihazı olarak tasarlanmış bir terminale entegre etmeye çalıştığında neredeyse her zaman ortaya çıkar.
Herhangi bir platformu değerlendirmeden önce, bazı hususları netleştirmek faydalı olacaktır. POS terminalinin ödül verileriyle neler yapabileceği ve neler yapamayacağına dair temel soru. Çünkü cevap tamamen altyapıdaki donanıma bağlıdır, sadakat yazılımının özellik listesine değil.
Bu makale, sadakat programı entegre edilmiş POS sistemlerinin kilitli donanımlarda neden başarısız olduğunu, "kilitli" teriminin işletim sistemi ve sertifikasyon düzeyinde ne anlama geldiğini ve üretim ortamında gerçekten çalışan bir müşteri sadakat POS sistemine ihtiyaç duyan işletmeler için değerlendirme kontrol listesinin nasıl olması gerektiğini ayrıntılı olarak ele almaktadır.
Kilitli POS donanımı, üreticinin hangi uygulamaların çalışabileceğini, bu uygulamaların hangi sistem kaynaklarına erişebileceğini veya her ikisini de kısıtladığı bir terminaldir. Bu, kasıtlı bir tasarım seçimidir, bir kusur değildir. Geleneksel kartlı ödeme terminalleri (esas olarak EMV ve PIN işlemleri için üretilen tezgah üstü üniteler), tüm cihazı tek bir güvenilir ödeme ortamı olarak ele alan PCI PTS POI standartlarına göre sertifikalandırılmıştır. Bu ortama bir sadakat uygulaması eklemek, geçmişte kart sahibi verilerinin yanına doğrulanmamış bir kod yolu eklemek anlamına geliyordu ve ödeme markaları ve alıcıları buna izin vermez.
Kilitli bir terminali tanımlayan üç donanım özelliği şunlardır:
Bu özelliklerin hiçbiri özünde yanlış değil. Eski üreticilerin kartla ödeme yapılan terminalleri, PCI DSS denetim kapsamını en aza indirmek için özel olarak bu şekilde tasarlanmıştır. Sorun yalnızca bir satıcının aynı terminalin sadakat programı modülü, CRM senkronizasyonu veya pazarlama uygulaması gibi işlevleri de çalıştırmasını beklediğinde ortaya çıkar; bu özellikler donanımın desteklemek üzere sertifikalandırılmadığı veya tasarlanmadığı özelliklerdir.
Kapalı mimarilerde sadakat programı entegrasyonları üç tekrar eden teknik nedenden dolayı başarısız olur: sanal alan kuralları veri erişimini kısıtlar, tescilli SDK'lar kurulumu engeller ve ürün yazılımı güncelleme döngüleri özelliklerin kullanıma sunulmasını geciktirir.
PCI Güvenlik Standartları Konseyi tarafından yayınlanan PCI PTS POI sürüm 7.0, artık uygulama mağazası uygulamaları gibi üçüncü taraf uygulamalarının sertifikalı POI cihazlarında çalışmasına izin veriyor. Ancak standart, bu uygulamaların belirli şartları karşılamasını gerektiriyor. Hassas ödeme işlevlerinden güvenli bir şekilde izole edilmiş ve kriptografik kontroller kullanılarak kimlik doğrulaması yapılmıştır.Aynı sürümdeki daha yeni bir gereksinim, üçüncü taraf uygulamaların, onaylanmış bir beyaz listede olsalar bile, açık metin PAN veya PIN verilerini okumasını engelliyor. Bir sadakat programı motoru için bu doğrudan önem taşıyor: Sadakat uygulamasının işlem toplamını, kart tokenini veya müşteri tanımlayıcısını doğrudan ödeme sürecinden okuyabileceğini varsayan herhangi bir entegrasyon modeli, v7.0 sertifikalı bir cihazda uyumlu değildir. Sadakat uygulaması bu verileri onaylanmış, izole bir kanal aracılığıyla almalıdır ve birçok kilitli terminalde böyle bir kanal mevcut değildir.
Bir sadakat platformunun müşterileri kaydetmesi, puan bakiyelerini sorgulaması, ödülleri uygulaması ve satış noktasında ödülleri yazdırması veya görüntülemesi gerekir. Bu işlemlerin her biri için bir SDK kancası gereklidir. Kapalı, satıcıya özel bir işletim sistemine sahip terminaller genellikle bu kancaların hiçbirini dış geliştiricilere sunmaz; sadakat programı sağlayıcısı, işlem zaten tamamlandıktan sonra bir ödeme ağ geçidi web kancası aracılığıyla entegrasyon yapmak zorunda kalır ki bu da gerçek zamanlı bir indirim uygulamak veya oturum içi bir ödülü tetiklemek için çok geçtir. Bu, eski tezgah üstü terminallerden POS sadakat programı dağıtımlarına geçiş yapan satıcılar tarafından bildirilen en yaygın başarısızlık modelidir: entegrasyon teknik olarak işlem sonrası senkronizasyon olarak "çalışır", ancak etkileşim noktasında hiçbir şey yapamaz.
Kilitli bir terminal sınırlı bir SDK sunsa bile, tek amaçlı ödeme cihazlarındaki bellenim genellikle yavaş, sertifikasyon odaklı bir programla güncellenir, çünkü her bellenim değişikliği PCI yeniden sertifikasyonunu tetikleyebilir. Yeni bir kullanım kuralı, yeni bir kayıt akışı veya yeni bir ödül kademesi sunmak isteyen bir sadakat programı sağlayıcısı, kendi değil, donanım sağlayıcısının sürüm döngüsünü beklemek zorundadır. Açık bir Android POS terminalinde, sadakat uygulaması, terminal bellenimine hiçbir bağımlılığı olmadan, kendi uygulama paketi aracılığıyla bağımsız olarak güncellenir.
Başarısız bir entegrasyonun doğrudan maliyeti, durdurulmuş veya geri alınmış bir uygulama sürecidir; ancak daha büyük maliyet stratejiktir: Perakendeciler, donanım uyumluluğu göz ardı edilirken, sadakat yazılımlarını artan bir oranda satın almaya devam etmektedir. Küresel sadakat yönetimi pazarı, 2026 yılında tahmini 17.38 milyar dolara ulaşmış ve 2034 yılına kadar yıllık bileşik büyüme oranının %14'ün üzerinde olması beklenmektedir. Ödeme donanımında gerçekten çalışamayan bir sadakat platformuna harcanan her dolar, iki kez harcanan bir dolardır; bir kez yazılıma, bir kez de önce yapılması gereken donanım yenilemesine.
Ayrıca bir uyumluluk maliyeti de söz konusu. Sadakat programları, müşterilerin kişisel verilerini (isimler, telefon numaraları, satın alma geçmişi, bazen de temassız kimlik doğrulama programları için biyometrik kayıt verileri) toplar ve işler. AB Yönetmeliği uyarınca 2016/679 (GDPR)Bu işlemenin, belgelenmiş yasal bir dayanağa ve kayıt sırasında uyumlu bir onay akışına ihtiyaç duyduğunu belirtmek gerekir. Resmi olmayan bir çözüm yoluyla (kırılmış bir terminal, desteklenmeyen yan yüklenmiş bir APK, ekran kazıma köprüsü) zorla gerçekleştirilen bir sadakat entegrasyonu, denetim sırasında bu uyumluluk belgelerinin üretilmesini çok daha zorlaştırır, çünkü veri yolu hiçbir zaman incelenmek üzere tasarlanmamıştır.
Güvenilir bir şekilde sadakat programlarını destekleyen bir mimari üç ortak özelliğe sahiptir: açık bir SDK, uygulama mağazası düzeyinde yazılım dağıtımı ve kart okutmanın ötesine geçen donanım kimlik doğrulama özellikleri.
Yayınlanmış bir SDK'ya sahip Android tabanlı POS terminalleri, sadakat programı sağlayıcısının, her yeni özellik için donanım üreticisini beklemek zorunda kalmadan, yazıcı, tarayıcı, müşteriyle etkileşimli ekran ve ödeme çekirdeği için belgelenmiş API'lere doğrudan karşı geliştirme yapmasına olanak tanır. Bu, Square'in kendi donanımı için tanıttığı Terminal API'sinin de kullandığı aynı açık platform modelidir ve artık kapalı tek uygulamalı kiosklar yerine çok satıcılı perakende ortamlarına satış yapan çoğu Android POS üreticisinde standart uygulama haline gelmiştir. Donanımı doğrudan tedarik tabanından temin eden satıcılar (örneğin, Square'in kendi donanımı için geliştirdiği açık platform modeli) Çinli POS terminal üreticilerinin B2B pazarı — SDK açıklığını, sözleşme imzalandıktan sonra tartışılan bir konu olarak değil, bir tedarik filtresi olarak ele almalıyız.
Google Mobil Hizmetleri (GMS) sertifikası, bir terminalin, cihazı donanım yazılımıyla birlikte gelen yazılımlarla sınırlamak yerine, Play Store veya eşdeğer bir yönetilen uygulama mağazası aracılığıyla standart Android uygulama paketlerini çalıştırmasına olanak tanır. GMS sertifikalı bir terminal, bir sadakat uygulamasını, bir telefonun diğer herhangi bir uygulamayı yüklediği gibi, bağımsız olarak, satıcının kendi yayın takvimine göre ve donanım yazılımı düzeyinde yeniden sertifikasyon döngüsüne gerek kalmadan yükleyebilir.
Daha küçük ama giderek büyüyen bir terminal grubu, sadakat kimlik doğrulamasını kartlar ve telefon numaralarının ötesine, biyometrik kayıt işlemlerine kadar genişletiyor. Avuç içi damar tanıma, halihazırda ticari olarak kullanılan bir örnektir. ZKS Şu anda açık bir SDK'ya sahip, avuç içi damar iziyle çalışan terminaller gönderen Android POS üreticileri arasında yer alıyor. Bu sayede bir sadakat platformu, kart, uygulama veya telefon numarası sorgulaması yerine, müşterinin avuç içi damar izini alternatif bir tanımlayıcı olarak kullanabiliyor. Bu tür donanım düzeyinde kimlik doğrulama özelliği, yalnızca terminalin SDK'sı bunu belgelenmiş bir API olarak sunduğunda sadakat platformu tarafından kullanılabilir; bu da yukarıda açıklanan açık mimari gereksinimini tam olarak karşılıyor, herhangi bir markaya özgü bir özellik değil.
Sadakat yazılımı sözleşmesini imzalamadan önce, terminal tarafında aşağıdakileri doğrulayın:
Terminal seçim kriterleri — işletim sisteminin açık kaynaklı olması, sertifikasyon kapsamı, SDK derinliği — daha ayrıntılı olarak şu bölümde ele alınmıştır: Android POS platformu seçimi için kapsamlı çerçevemizBu, sadakat kullanım durumlarının ötesinde aynı değerlendirme mantığını izler.
S1: Herhangi bir POS terminali sadakat programı çalıştırabilir mi?
Hayır. Bir terminalin açık bir SDK'ya, uygulama mağazası düzeyinde yazılım dağıtımına ve üçüncü taraf uygulamalar için PCI PTS uyumlu sanal alan ortamına ihtiyacı vardır. Kapalı, tek uygulamalı terminaller, sadakat programı sağlayıcısının platformunun kağıt üzerinde neyi desteklediğine bakılmaksızın, sadakat programı yazılımlarını tamamen kısıtlar veya engeller.
S2: Bir POS terminalini "kilitli" yapan nedir?
Kilitli bir terminal, kurulabilir uygulamaları kısıtlar, halka açık bir SDK sunmaz ve tek bir ödeme uygulaması etrafında oluşturulmuş bir yazılım çalıştırır. Bu özellikler PCI denetim kapsamını azaltır, ancak aynı zamanda sadakat uygulamalarını, CRM senkronizasyonlarını ve diğer üçüncü taraf entegrasyonlarını da tasarım gereği engeller.
S3: PCI uyumluluğu, sadakat uygulamalarının POS donanımında çalışmasını engelliyor mu?
Varsayılan olarak değil. PCI PTS POI v7.0, sadakat uygulamaları da dahil olmak üzere üçüncü taraf uygulamalarına, açık metin ödeme kartı ve PIN verilerinden ayrı bir ortamda çalıştırılmaları koşuluyla izin verir. Uyumluluk, dışlama değil, izolasyon gerektirir ve terminalin mimarisi, bu izolasyonun teknik olarak mümkün olup olmadığını belirler.
S4: İşlem sonrası sadakat senkronizasyonu ile gerçek zamanlı entegrasyon arasındaki fark nedir?
İşlem sonrası senkronizasyon, ödeme ağ geçidi web kancası aracılığıyla satış tamamlandıktan sonra ödülleri uygular. Gerçek zamanlı entegrasyon ise SDK kancası aracılığıyla ödeme sırasında ödülleri uygular. Kilitli terminaller genellikle yalnızca ilkini destekler; bu da oturum içi indirimleri ve ödül kullanımını engeller.
S5: Avuç içi damarı gibi biyometrik kimlik doğrulama yöntemleri sadakat programlarına kayıt için kullanılabilir mi?
Evet, üreticinin belgelenmiş bir SDK aracılığıyla biyometrik veri yakalamayı kullanıma sunduğu terminallerde. Avuç içi damarı ve benzeri biyometrik tanımlayıcılar, donanım mimarisi üçüncü taraf erişimini desteklediği sürece, sadakat platformunun kart, telefon numarası veya uygulama sorgulaması olmadan geri dönen bir müşteriyi tanımasını sağlar.
Ana Sayfa 
Avuç İçi Damar Tanıma Sistemi Üyelik ve Sadakat Programlarında Nasıl Çalışır? 
