Dijital Passler ve Erişim Kartları İçin Mobil Uygulama Nasıl İnşa Edilir

Kullanım Durumunu ve Başarı Metriklerini Netleştirin

QR vs. NFC—ya da Apple Wallet vs. uygulama içi pass seçmeden önce, projenizde “dijital pass”in ne anlama geldiğini kesinleştirin. Tek bir uygulama çalışan erişim rozeti, üye kimliği, etkinlik bileti veya zaman sınırlı ziyaretçi pass verebilir ve her birinin kimlik kontrolleri, iptal süreçleri ve kimliğin ne sıklıkla değiştiği konusunda farklı gereksinimleri vardır.

Pass tipini (ve gerçek dünya iş akışını) tanımlayın

Onay veren kişi ve kapıdaki “başarı”nın ne olduğu dahil olmak üzere uçtan uca ne olduğunu yazın.

Örneğin:

• Erişim rozeti: kişiye bağlı; hızlı açma gerekir; işten ayrılma durumunda anında iptal.
• Üyelik pass'i: katılım ve yenileme kolaylığı, sıkı erişim kontrolünden daha öncelikli olabilir.
• Biletler: yüksek hacimli tarama, çoğaltmayı önleme, kısa geçerlilik süresi.
• Ziyaretçi pass: bir çalışan tarafından sponsorlanır; otomatik olarak süresi dolar; belirli alanlarla sınırlı olabilir.

Birincil kullanıcıları belirleyin (sadece “son kullanıcılar” değil)

Sisteme dokunan kişileri ve hedeflerini listeleyin:

• Çalışanlar/müşteriler/ziyaretçiler: basit kurulum, güvenilir giriş, düşük sürtünme.
• Yöneticiler/güvenlik personeli: verme, iptal etme, denetleme, istisnaları yönetme (kayıp telefon, reddedilen giriş).
• Resepsiyon/etkinlik personeli: yoğun dönemlerde hızlı doğrulama ve sorun giderme.

Ölçebileceğiniz başarı metriklerini seçin

Hem kullanıcı deneyimine hem operasyonlara bağlanan metrikleri seçin:

• Aktivasyon oranı: davet edilen kullanıcıların pass'i başarıyla ekleyip etkinleştirme yüzdesi.
• Kapı açma başarı oranı: ilk denemede başarılı olan açılma/tarama sayıları.
• Verme süresi: talep/onaydan kimliğin kullanılabilir olmasına kadar geçen süre.
• Destek talepleri: hacim, başlıca nedenler ve çözüm süresi.

Erken karar verin: çevrimdışı eriş (ve sınırları)

Kapılar veya tarayıcılar ağ bağlantısı olmadan çalışmak zorundaysa, çevrimdışı erişin ne kadar süreyle geçerli kalacağını (dakikalar, saatler, günler) ve bir pass iptal edildiğinde çevrimdışıyken ne olacağını tanımlayın. Bu seçim, kimlik tasarımını, okuyucu yapılandırmasını ve ilerideki güvenlik modelinizi etkiler.

Pass Nasıl Sunulacak: QR, NFC ve Yedekler

Dijital pass'iniz, tarandığı veya dokunulduğu anda işe yarar. Ekranları inşa etmeden önce okuyucunun neyi kabul edeceğine ve kullanıcıların kalabalık, zayıf bağlantı, soğuk hava veya eldiven gibi gerçek koşullar altında neyi güvenle sunabileceğine karar verin.

Yaygın sunum seçenekleri (ve hangi durumlara uygun oldukları)

QR kodları evrenseldir ve ucuzdur: herhangi bir kamera tabanlı tarayıcı—veya görsel doğrulama için bir telefon kamerası—işe yarar. Kişi başına daha yavaştır ve statik kodlara dayandığınızda kopyalanmaya daha açıktır.

NFC (dokunma) fiziksel rozete benzer bir his verir. Hızlı ve tanıdık, ancak uyumlu kapı okuyucularına ve cihaz desteğine bağımlıdır. Ayrıca platform sınırlamaları vardır (örneğin kartı taklit edip edemeyeceğiniz veya Wallet tabanlı kimlik kullanmanız gerekip gerekmediği).

Bluetooth (eller serbest) erişilebilirlik ve hızı artırabilir, ancak menzil ve parazit gibi ayarlamalar gerektirir ve "neden açılmadı?" anları yaratabilir.

Tek seferlik linkler / uygulama içi kodlar (dönen kodlar, imzalı tokenlar) güçlü yedeklerdir ve klonlama riskini azaltabilir. Bunlar uygulama mantığı gerektirir ve tasarıma bağlı olarak periyodik ağ erişimi isteyebilir.

Teknolojiyi kısıtlarınıza eşleyin

Her yöntemi şu kriterlere göre eşleyin: mevcut okuyucu donanımı, hacim (kişi/dakika), çevrimdışı ihtiyaçlar, bütçe ve destek yükü. Örnek: yüksek trafikli turnikeler genellikle NFC hızını gerektirir; geçici etkinlik girişleri QR ile idare edebilir.

Birincil yöntem ve kasıtlı yedek seçin

Pratik bir desen: birincil NFC + QR yedek. NFC hızı sağlar; QR daha eski telefonlar, bozuk NFC veya NFC olmayan siteler için yedek olur.

"Kötü gün" senaryolarını planlayın

Aşağıdaki durumlarda tam olarak ne olacağını belgeleyin:

• Telefon kilitli: pass kilit ekranından (Wallet) sunulabilir mi, yoksa kullanıcıların uygulamayı mı açması gerekir?
• Ağ yok: kimlik çevrimdışı doğrulanabilir mi (imzalı token, önbelleğe alınmış yetki) ve ne kadar süre için?
• Düşük pil / ölü telefon: geçici basılı QR sunuyor musunuz, yerinde aşırı yükleme seçeneği veya yedek fiziksel kart var mı?

Bu kararlar okuyucu entegrasyonunu, güvenlik duruşunu ve daha sonra kullanıcı destek oyun planını şekillendirir.

Karar: Uygulama İçi Passler mi, Apple/Google Wallet mı

Kimliğin “nerede yaşadığı” erken bir karardır çünkü okuyucu entegrasyonunu, kullanıcı deneyimini ve güvenlik kısıtlarını etkiler.

Seçenek A: Uygulama içi passler (uygulamanız içinde)

Uygulama içi pass uygulamanız tarafından oluşturulur ve yönetilir. Bu, UI, kimlik doğrulama, analiz ve özel iş akışları üzerinde maksimum kontrol verir.

Artıları: tam marka uyumu ve özel ekranlar, esnek auth (biyometri, step-up istemleri), zengin bağlam (site haritaları, talimatlar) ve birden fazla kimlik türü için daha kolay destek.

Eksileri: kullanıcıların uygulamayı açması gerekir (veya sizin oluşturduğunuz widget/quick action), OS seviyesinde kilit ekran erişimi sınırlıdır ve çevrimdışı davranış tamamen sizin sorumluluğunuzdadır.

Seçenek B: Apple Wallet / Google Wallet passleri

Wallet passleri (ör. iOS'ta PKPass) hızlı sunum için tasarlanmıştır ve tanıdıktır.

Artıları: yüksek güven, keşfedilebilirlik, kilit ekranı/hızlı erişim, presentation için güçlü OS desteği ve hızlı “kodu göster” davranışı.

Eksileri: daha sıkı platform kısıtları (desteklenen barkod/NFC formatları, sınırlı özel UI), güncellemeler Wallet kurallarına tabi, ve Apple/Google için sertifika, issuer yapılandırması ve bazen onay/review gerekebilir. Derin telemetri de zorlaşır.

Pratik karar kuralı

Hız, tanıdıklık ve “her zaman erişilebilir” sunum önemliyse Wallet kullanın (ziyaretçiler, etkinlikler, basit kapı/barkod iş akışları). Daha güçlü kimlik kontrolleri, zengin iş akışları veya karmaşık kimlik mantığı gerektiğinde uygulama içi tercih edin (çok site çalışan erişimi, onaylar, rol tabanlı erişim).

Birden çok pass türü, şablon ve markalama

Birden fazla kuruluş hizmet ediyorsanız, kuruluş başına şablonlar planlayın: logolar, renkler, talimatlar ve farklı veri alanları. Bazı ekipler her ikisini de sunar: hızlı giriş için Wallet pass ve yönetim/destek için uygulama içi kimlik.

Desteklemeniz gereken pass yaşam döngüsü

Konteyner ne olursa olsun tetikleyebileceğiniz yaşam döngüsü işlemlerini tanımlayın:

• Issue (ilk kayıt)
• Update (isim, erişim seviyesi, bitiş, görsel değişiklikler)
• Suspend (geçici bekletme)
• Revoke (kalıcı kaldırma)
• Re-issue (yeni cihaz, kayıp telefon, şüpheli ihlal)

Bu işlemleri uygulama içi ve Wallet arasında tutarlı tutun ki operasyon ekipleri manuel çözümler olmadan erişimi yönetebilsin.

Veri Modelini ve Pass Yaşam Döngüsünü Tasarlayın

Temiz bir veri modeli sisteminizi öngörülebilir kılar: bir pass vermek, bir okuyucuda doğrulamak, iptal etmek ve olayları incelemek hepsi basit sorgularla yapılabilmeli—tahmin değil.

Modellemeniz gereken temel varlıklar

Küçük bir “birinci sınıf” nesne setiyle başlayın ve gerekmedikçe büyütmeyin:

• Kullanıcı: erişim kazanması gereken kişi.
• Kuruluş / Site: sistemi kimin sahip olduğu (ve erişimin hangi alana uygulandığı).
• Pass: kullanıcıya gösterilen “kart”.
• Credential: okuyucuya sunulan token (NFC credential, QR yükü vb.). Bir pass zaman içinde birden çok credential'a sahip olabilir.
• Cihaz: kimliği tutan veya gösteren telefon örneği.
• Okuyucu / Kapı: fiziksel uç nokta (okuyucu kimliği, kapı kimliği, konum).
• Erişim politikası: kullanıcı/grupları kapılara ve programlara bağlayan kurallar.

Bu ayrım, bir kullanıcı telefon değiştirince kullanıcının passinin kavramsal olarak aynı kalmasına, ancak credentiallerin döndürülmesine ve cihazların değişmesine yardımcı olur.

Pass durumları ve yaşam döngüsü

Açık durumlar tanımlayın ve yalnızca kasıtlı geçişlere izin verin:

• pending (davetli/kayıt oluyor)
• active (kullanılabilir)
• suspended (geçici bloklanmış)
• expired (zamanla sona erdi)
• revoked (kalıcı olarak geçersiz)

Örnek geçişler: pending → active doğrulamadan sonra; active → suspended politika ihlali için; active → revoked işten ayrılma durumunda; suspended → active admin geri yüklemesi ile.

Tanımlayıcılar ve okuyuculara eşleme

İki seviyede benzersiz kimlikler planlayın:

• Yaşam döngüsü ve destek için sabit bir pass_id (iç)
• Okuyucuların doğrulayabileceği bir veya daha fazla credential_id / token_id değeri

Okuyucular tokenları erişim kurallarına nasıl eşleyecek: doğrudan arama (token → kullanıcı → politika) mı yoksa token → politika grubu (uçta daha hızlı) mı? Kimlikleri tahmin edilemez yapın (rastgele, ardışık değil).

Denetim kayıtları: ne kaydedilmeli ve nerede

Denetim kayıtlarını ekleyici (append-only) ve “geçerli durum” tablolarından ayrı tutun. En azından şunları kaydedin:

• issue (kim verdi, kime, cihaz, zaman)
• scan (okuyucu, sonuç, sebep kodu)
• deny (politika uyuşmazlığı, süresi dolmuş, iptal edilmiş, çevrimdışı hata)
• revoke/suspend/reactivate (aktör, gerekçe, zaman)

Bu olaylar sorun giderme, uyumluluk ve kötüye kullanım tespiti için sizin tek gerçek kaynağınız olur.

Kullanıcı Kaydı ve Pass Verme Akışını İnşa Edin

Dijital pass projesi “ilk 5 dakika” deneyiminde başarılı olur veya başarısız olur: gerçek bir kişinin nasıl hızla kayıt olup kimlik alacağı ve bir sonraki adımı anlayacağı önemlidir.

Kayıt yolları (1–2 birincil seçin)

Çoğu ekip güvenlik ve dağıtım boyutuna göre bu adımların karışımını destekler:

• Davet linki: bir admin (veya İK sistemi) zaman sınırlı bir link oluşturur. Kullanıcı bunu telefonunda açar ve doğrudan doğru akışa gelir.
• E-posta/SMS doğrulama: kimlik kaydıyla ilişkili telefon numarası veya e-posta teyidi için tek kullanımlık kod gönderin.
• SSO: çalışanlar için SAML/OIDC ile pass yalnızca kurumsal oturum açma sonrası verilir.
• Admin onayı: yüksek güvenlikli siteler için isteği bir inceleme kuyruğuna koyun (sebep kodları, zaman damgaları ve denetim iziyle).

Pratik bir desen: davet linki → e-posta/SMS doğrulama → (isteğe bağlı) SSO → pass verme.

Pass'in nasıl eklendiği (ve kullanıcıları nasıl yönlendireceğiniz)

Vermeyi kullanıcıların "kendileri bulmak zorunda kalmaması" için tasarlayın:

• Uygulama içi pass: kimlik uygulamanız içinde yaşar; güncellemeler ve UI kontrolü sizdedir. Özel kimlik doğrulama, çevrimdışı kurallar veya özel okuyucu davranışları gerektiğinde iyidir.
• Wallet ekleme: doğrulamadan sonra bir “Add to Apple Wallet” / “Add to Google Wallet” düğmesi sağlayın. Davetten wallet-ekranını açan deep linkleri de destekleyin.
• QR davet yedeği: yerinde, resepsiyon kioskunun kayıt linkini açan bir QR göstermesine izin verin (kullanıcı e-postayı bulamadığında kullanışlıdır).

Metinleri son derece açık tutun: pass'in ne için olduğu, nerede görüneceği (uygulama vs. wallet) ve kapıda ne yapılacağı.

Cihaz değişiklikleri ve yeniden verme kuralları

Bunu erken planlayın ki destek talepleri oluşmasın:

• Yeni telefon: kimliği yeniden doğrulayan ve pass'i yeniden veren self-servis yeniden kayıt akışı sağlayın.
• Birden çok cihaz: izin verip vermeyeceğinize karar verin. İzin veriliyorsa sayıyı sınırlayın ve ayarlarda aktif cihazları gösterin.
• Kayıp cihaz: anında uzaktan iptal sağlayın, ardından yeniden doğrulama sonrası yeniden verme izni verin.

Gerçek dünya hataları için kullanıcı mesajları

Arkadaşça, spesifik mesajlar yazın:

• Erişim reddedildi (ve sonraki adım: “Güvenlik ile iletişime geç” vs. “Yeniden dene/yenile”)
• Pass süresi doldu (bitiş tarihini ve yenileme adımını dahil edin)
• Bağlantı sorunları (çevrimdışında nelerin çalıştığını ve çevrimiçi olunca nasıl kurtarılacağını açıklayın)

İyi verme yalnızca “pass oluşturmak” değil—tahmin edilebilir kurtarma yolları olan anlaşılır bir yolculuktur.

Kullanıcı ve Yöneticiler için Kimlik Doğrulama ve Yetkilendirme

Dijital passler, arkasındaki kimlik ve izinler kadar güvenilirdir. Kimlik doğrulamayı (sen kimsin) ve yetkilendirmeyi (ne yapabilirsin) birinci sınıf ürün özellikleri olarak ele alın, sadece altyapı olarak değil.

Kimlik doğrulama yaklaşımını seçme

Hedef kitle ve risk seviyesine uygun giriş yöntemini seçin:

• E-posta + tek seferlik şifre (OTP): tüketiciler için kolay, daha az parola sıfırlama.
• Şifrasız “magic link”: düşük sürtünmeli kayıt için iyi, ancak güvenilir e-posta teslimatı gerekir.
• SSO / kurumsal kimlik (SAML/OIDC): çalışanlar, yükleniciler ve kampüsler için en iyisi; erişimi mevcut İK/BT politikalarına bağlar.

Birden çok kiracı (tenant) destekliyorsanız, bir kullanıcının birden fazla tenant'a ait olup olamayacağını ve bağlamlar arasında nasıl geçiş yapacağını erken belirleyin.

Yetkilendirme: roller, kapsamlar ve denetlenebilirlik

Rolleri basit dilde tanımlayın (ör. Pass Holder, Front Desk, Security Admin, Auditor) ve bunları izinlere eşleyin:

• Kim verebilir, yeniden verebilir, iptal edebilir veya askıya alabilir passleri
• Kim erişim kayıtlarını görüntüleyip rapor dışa aktarabilir
• Kim tesis kurallarını değiştirebilir (kapı grupları, programlar)

Yetkilendirme kontrollerini sunucuda tutun (sadece UI'da değil) ve her hassas eylemi kim, ne, ne zaman, nerede (IP/cihaz) ile birlikte bir gerekçe alanı ile kaydedin.

Oturumlar, cihaz güvencesi ve kullanıcı kolaylığı

Kısa ömürlü erişim tokenları ve yenileme tokenları kullanın; pass gösterimi için güvenli yeniden girişte biyometri (Face ID/Touch ID) destekleyin.

Daha yüksek güvenlikli dağıtımlar için cihaz bağlama ekleyin, böylece bir credential yalnızca kaydedilmiş cihaz(lar)da geçerli olur. Bu ayrıca kopyalanan tokenların başka yerde kullanılmasını zorlaştırır.

Yöneticiler için hataları ve suistimali azaltan önlemler

Yönetici araçları ek korumalar gerektirir:

• Ayrıcalıklı passler veya toplu issuance için onay iş akışları
• Issuance/reissue uç noktalarında oran sınırlamaları
• Olağandışı desenler için alerter (aynı e-posta alanına çok sayıda pass verilmesi, iş saatleri dışındaki ani artışlar gibi)

Bu politikaları dahili bir çalıştırma kılavuzunda belgeleyin ve admin UI'den bağlantı verin (örneğin, /docs/admin-security) ki operasyon tutarlı kalsın.

Güvenlik Modeli: Klonlamayı, Ekran Görüntüsünü ve Replay'i Önleme

Dijital pass güvenliği “QR kodunu gizlemek”ten çok okuyucunun neye güveneceğini belirlemektir. Doğru model, bağlantıya, okuyucu yeteneklerine ve iptal hızına bağlıdır.

Okuyucu neyi doğrular?

Genellikle üç desen vardır:

• İmzalı yük (çevrimdışı doğrulama): QR/NFC sisteminizce imzalanmış bir yük taşır. Okuyucular imzayı yerel olarak doğrular, böylece kapılar çevrimdışı çalışır. Bu hızlıdır, fakat iptal okuyucu güncellemeleri kadar hızlıdır.
• Sunucu kontrolü (çevrimiçi doğrulama): okuyucu taranan tokenı backend'inize gönderir ve gerçek zamanlı onay/red alır. İptal anında geçerlidir, fakat ağ çalışırlığına bağımlıdır.
• Hibrit: okuyucular önce bir imzayı doğrular (bariz sahtecilikleri engellemek için), sonra bağlantı varsa yüksek riskli alanlarda sunucuyu çağırır.

QR kodları: ekran görüntüsü ve replay riskini azaltma

Statik QR kodları paylaşılmaya ve ekran görüntüsüne açıktır. Dönen veya zaman sınırlı kodlar tercih edin:

• Kısa ömürlü token kullanın (ör. 15–60 saniye).
• İmkan varsa cihaz/oturuma bağlayın (iletlenmiş bir ekran görüntüsü başka yerde doğrulanmasın).
• Anti-replay verileri (zaman damgası + nonce) dahil edin ve backend, “tek seferlik giriş” için zaten kullanılmış tokenları reddetsin.

Çevrimdışı QR doğrulaması desteklenmesi gerekiyorsa, QR zaman kutulu ve imzalı olsun; gerçek zamanlı iptalin yalnızca okuyucular senkronize edildikçe mümkün olduğunu kabul edin.

NFC credential'ları: anahtarları cihazda koruma

NFC için sırların nerede tutulacağına ve nasıl kullanılacağına plan yapın:

• Credential anahtarlarını donanım destekli güvenli depolamada saklayın (mevcutsa Secure Enclave/Keystore).
• NFC üzerinden uzun ömürlü tanımlayıcılar göndermekten kaçının; okuyucu destekliyorsa challenge-response veya türetilmiş oturum anahtarları kullanın.
• Root'lu/jailbreakli cihazların olacağını varsayın; uygulama gizleme yerine donanım destekli anahtarlar ve sunucu tarafı risk kurallarına güvenin.

İptal hızı: operasyonel gereksinimi tanımlayın

Bir pass'in iptal edildikten sonra ne kadar çabuk çalışmayı durdurması gerektiğini (saniye, dakika, saat) baştan kararlaştırın. Bu gereksinim mimariyi yönlendirir:

• Saniyeler: genellikle çevrimiçi kontroller veya sürekli bağlantılı okuyucular gerekir.
• Dakikalar: sık okuyucu senkronları + kısa ömürlü tokenlar işe yarayabilir.
• Saatler: düşük riskli alanlar için periyodik güncellemeler kabul edilebilir.

Bunu güvenlik ve operasyonel SLO olarak yazın çünkü okuyucu yapılandırmasını, backend erişilebilirliğini ve olay müdahalesini etkiler.

Kapı Okuyucuları ve Erişim Kontrol Sistemleriyle Entegrasyon

Dijital passlerin gerçek dünya ile buluştuğu yer burasıdır: turnikeler, kapı kontrolörleri, asansör okuyucuları ve resepsiyon tarayıcıları. Buradaki entegrasyon seçimleri güvenilirliği, hızı ve ağ kesildiğinde ne olacağını etkiler.

Okuyucu doğrulama yolunu seçin

Yaygın entegrasyon yolları:

• Okuyucu → API'niz (cloud validation): okuyucu (veya kontrolörü) her tap/scan için doğrulama uç noktanızı çağırır. Esnektir ama ağ kalitesine bağımlıdır ve dikkatli oran sınırlama gerektirir.
• Okuyucu → mevcut erişim kontrol sistemi (ACS): uygulamanız, ACS'nin anladığı bir credential verir ve ACS izin/verme kararını alır. Kapıda daha az özel mantık olur ama kodlanabilecek veri sınırlı olabilir.
• Okuyucu → yerel gateway (edge validation): okuyucular yerel bir servise konuşur, credential'lar yerelde doğrulanır ve backend ile senkronize edilir. Dayanıklılığı artırır ve gecikmeyi öngörülebilir kılar.

Yanıt süresi ve çevrimdışı davranış hedeflerini belirleyin

Erken hedefler belirleyin (örn. “açma kararı 300–500 ms içinde”). Ayrıca her site için “çevrimdışı”nın ne anlama geldiğini belgeleyin:

• Ağ düşerse, belirli kapılar için fail closed (hepsini reddet) mi yoksa fail open mi uygulanır?
• Gateway/controller üzerinde önbelleğe alınmış izin listeleri kısa süreli sürelere sahip olarak desteklenebilir mi?
• Olayları nasıl kaydedeceksiniz ve daha sonra çoğaltmadan nasıl senkronize edeceksiniz?

Entegrasyon noktalarını belgeleyin (dağınıklığı atlamayın)

Hizalayacağınız sistemleri ve verileri yazılı hale getirin:

• Rozet provizyonu: bir kişi kaydını kim ve ne zaman oluşturur (İK sistemi, ziyaretçi sistemi, admin portalı)?
• Erişim grupları ve programlar: rollerin kapılara, katlara, zaman pencerelerine ve tatil kurallarına eşlenmesi.
• Kapı ve okuyucu envanteri: kanonik kapı kimlikleri, konumlar, okuyucu türleri (NFC, QR) ve kontrolör donanım/firmware kısıtları.

İç dokümanlarınızda basit bir “gerçeğin kaynağı” diyagramı haftalar kazandırır.

İzleme ve teşhis planlayın

Okuyucuları üretim altyapısı gibi ele alın. Şunları izleyin:

• Okuyucu sağlığı: son görülme zaman damgası, firmware sürümü, pil/güç durumu (varsa).
• Hata oranları ve gecikme: p95 doğrulama süresi, zaman aşımı ve yeniden denemeler.
• Reddedilme nedenleri: süresi dolmuş pass, iptal edilmiş credential, program dışında, bilinmeyen kapı, şüpheli replay.

Bunları bir operasyon panosunda görünür kılın ve kritik sorunları on-call'a yönlendirin. “Neden reddedildim?” akışı hızlı destek yükünü azaltır.

Backend Mimarisi: API'ler, İmzalama ve Ölçeklenebilirlik

Dijital pass sistemi backend'ine dayanır: credential verir, geçerliliği kontrol eder ve kapıda olanları hızlı ve güvenilir şekilde kaydeder.

Temel API'ler (basit ve versiyonlu tutun)

Küçük bir uç nokta setiyle başlayın ve geliştirin:

• POST /v1/passes/issue — bir kullanıcı için pass oluşturur, aktivasyon linki veya pass yükü döndürür
• POST /v1/passes/refresh — tanımlayıcıları döndürür / yetkileri günceller, en son pass verisini döndürür
• POST /v1/passes/validate — okuyucuda sunulan QR/NFC tokenını doğrular (çevrimiçi okuyucular)
• POST /v1/passes/revoke — bir pass'i hemen geçersiz kılar (kayıp telefon, erişim sonlandırma)
• POST /v1/events — giriş denemelerini ve sonuçları (kabul/red/hata) kaydeder

Bazı doğrulamalar cihazda veya okuyucuda olsa bile denetim, uzak iptal ve “kırma cam” işlemleri için sunucu tarafı doğrulama API'si tutun.

İmzalama ve anahtar yönetimi (güvenli rotasyon)

Apple Wallet (PKPass) veya diğer imzalı yükleri destekliyorsanız, imzalama anahtarlarını üretim gizli olarak ele alın:

• Özel anahtarları yönetilen KMS/HSM içinde saklayın; asla uygulama sunucularında veya CI loglarında tutmayın.
• Anahtarları planlı olarak ve olay sonrası döndürün; eski pass'lerin geçiş sırasında çalışmaya devam etmesi için birden fazla açık ortak anahtar desteği sağlayın.
• Her imzalama işlemini denetleyin (kim/ne için/ne zaman/hangi anahtar sürümüyle).

Pratik bir desen, dar bir arayüze sahip, uygulamanın geri kalanından izole edilmiş bir “imzalama servisi”dir (ör. “pass yükünü imzala”).

Zirve giriş zamanlarında ölçek için tasarım

Giriş dalgaları öngörülebilirdir (09:00, etkinlik başlangıcı). Patlayan okumalar için plan yapın:

Revocation listeleri ve yetki aramalarında önbellekleme kullanın, issuance için idempotent anahtarlarla yeniden denemeler ekleyin ve analitik/bildirim gibi kritik olmayan işleri sıraya koyun ki doğrulama hızlı kalsın. Okuyucular çevrimiçi olduğunda doğrulama gecikmesini düşük tutmak için konuşkan bağımlılıklardan kaçının.

Gizlilik kontrolleri ve log saklama

Tutulan kişisel veriyi en aza indirin: pass kayıtlarında isimler/e-postalar yerine dahili kullanıcı kimliklerini tercih edin. Tutma süresini önceden tanımlayın (örn. giriş kayıtlarını 30–90 gün sakla, gerekiyorsa daha uzun) ve operasyonel logları güvenlik/denetim loglarından ayrı, daha sıkı erişim kontrolleriyle tutun.

Hızlı inşa etme (mimariye kilitlenmeden)

Hızlı yineleme yapıyorsanız—admin portalı, issuance API'leri ve ilk mobil deneyim—gibi araçlar pilotu prototipleyip dağıtmanıza yardımcı olabilir. Koder.ai gibi araçlar, chat üzerinden uçtan uca bir pass sistemi prototipi oluştururken mühendislik sınıfı yığını korumanıza yardımcı olur (web için React, backend için Go + PostgreSQL, mobil için Flutter). Pilotu dağıtıp barındırmak, özel alan adları ve geri alma ile anlık görüntüler dahil hızla ilerlemek için özellikle faydalıdır; kaynak kodu daha sonra dışa aktarabilirsiniz.

Mobil Uygulama UX'i: Kurulum, Gösterim ve Erişilebilirlik

Dijital pass, kapıdaki ekranda çalışan ya da çalışmayan şeydir. İlk kurulum, “şimdi pass'imi göster” ve “bir sorun var—beni hızlıca kurtar” anlarına odaklanın.

Uygulama yaklaşımını seçin

• Native (iOS/Android): NFC deneyimleri, Wallet entegrasyonu ve sistem davranışları için en iyi.
• Çapraz platform (Flutter/React Native): paylaşılan UI ve hızlı yineleme için iyi, ancak NFC, arka plan davranışları ve Wallet geçişlerini erken doğrulayın.
• Web tabanlı yardımcı: sadece QR programları ve hızlı pilotlar için işe yarar, ancak kamera izinleri ve bağlantıya daha çok bağımlı olursunuz.

Apple Wallet / Google Wallet destekliyorsanız, provision sonrası uygulamanın gerekli olup olmadığını netleştirin. Birçok kullanıcı “wallet’e ekle ve unut”u tercih eder.

Kapıda işe yarayan pass gösterimi

“Pass’i göster” ekranını boarding pass gibi tasarlayın: anında, parlak ve okunması kolay.

• QR render: yüksek kontrastlı kod, geniş marginler (quiet zones), gerekirse yön kilidi ve “parlaklığı maksimize et” istemi.
• NFC tap UI: basit “Okuyucuya yaklaştır” durumu, konumlandırma için animasyonlu ipuçları ve net bir başarı onayı.
• Wallet deep linkleri: “Cebe Aç” / “Google Wallet'da Aç” gibi tek dokunuşlu eylemler sağlayın (kullanıcıları uygulamalarında arama yapmaya zorlamayın).

Pass'i menülerin arkasına saklamayın. Kalıcı bir ana ekran kartı veya tek bir ana düğme kapı gecikmelerini azaltır.

Erişilebilirlik ve açıklık

Büyük Metin, Dynamic Type, ekran okuyucu etiketleri (“Erişim pass QR kodu”) ve yüksek kontrast temaları destekleyin. Hata durumlarını UX'in parçası sayın: kamera engellendi, NFC kapalı, pass süresi doldu veya okuyucu yanıt vermiyor. Her biri düzeltme adımı içermeli (“Ayarlar'da Kamerayı Etkinleştir”) ve bir yedek eylem sunmalı.

Kenar durumları için tasarım

Saat dilimleri ve cihaz saat sapması zaman tabanlı passlerin “yanlış” görünmesine neden olabilir; bu yüzden zamanları mekanın saat dilimiyle gösterin ve küçük bir “Son senkron: X dakika önce” göstergesi ekleyin.

Ayrıca planlayın: uçak modu, lobide zayıf bağlantı, izinlerin iptali (kamera/NFC), düşük pil erişilebilirlik modları. Küçük bir “Sorun Giderme” bağlantısı /help/mobile-pass destek sıralarını azaltabilir.

Test Stratejisi: Cihazlar, Okuyucular, Çevrimdışı ve Kötüye Kullanım Vakaları

Mobil erişim kartı uygulaması testi "açıyor mu"dan çok "her zaman, baskı altında açıyor mu" ile ilgilidir. Testi ürün gereksinimi olarak ele alın.

Pratik bir test matrisi oluşturun

Kullanıcıların gerçekte taşıdıklarını ve kapılarınızın gerçekten kullandıklarını yansıtan bir matrisle başlayın:

• Cihazlar: eski ve yeni iPhone/Android karışımı, farklı ekran boyutları ve düşük kaliteli kameralar
• OS sürümleri: en güncel ve önceki ana iOS/Android sürümlerini dahil edin
• Yetenekler: NFC varlığı (ve yerleşimi), kamera otomatik odak hızı, parlaklık ve pil tasarruf modları
• Okuyucu modelleri: desteklediğiniz her kapı okuyucu firmware/sürümü, turnikeler ve elde tutulan tarayıcılar

Hem uygulama içi credential'ları hem de wallet akışlarını (Apple Wallet pass / Google Wallet pass) dahil edin; çünkü PKPass davranışı ve sistem UI zamanlaması uygulamanızdan farklı olabilir.

Gerçek dünya giriş koşullarını prova edin

Laboratuvar mükemmel taramalar gerçek giriş sıralarıyla eşleşmez. 20–50 kişinin ardışık olarak pass sunduğu “koşu testleri” yapın:

• Kötü aydınlatma ve parlamalar (dış güneş, loş lobi)
• Spotty bağlantı (Wi‑Fi düşmeleri, zayıf LTE)
• Çevrimdışı mod (uçak modu + cihaz yeniden başlatma) ile önbelleğe alınmış credential ve UX rehberliğini doğrulama

Ortalama giriş süresini, hata oranını ve kurtarma süresini (kullanıcının sonraki adımı) ölçün.

Kötüye kullanım ve hata senaryolarını doğrulayın

Aktif olarak test edin:

• Replay denemeleri (geçerlilik penceresi içinde aynı QR'ı tekrar kullanma)
• Ekran görüntüsü kullanımı ve ekran kaydı kenar durumları
• İptal edilmiş pass denemeleri (sunucu tarafı iptal sonrası anlık reddetme)
• Tekrarlanan hatalar için oran limitleri ve kilitlenmeler

Üretim gibi sahneyi kurun

Test okuyucuları ve zirve trafiğini simüle eden sentetik trafik ile bir staging ortamı tutun. Issuance, güncellemeler ve iptallerin yük altında doğrulanmasını sağlayın ve logging'in “tap/scan → karar → kapı sonucu” zincirini uçtan uca izlemenize izin verdiğini doğrulayın.

Lansman, Yayılım ve Süregelen Operasyonlar

Başarılı bir lansman büyük sürümden çok her kapıda, her gün öngörülebilir girişle ilgilidir. Kontrollü bir yayılım, net destek yolları ve sürtünmenin nerede saklandığını gösteren metrikler planlayın.

Fiziksel kartlardan geçişte erişimi bozmadan ilerleyin

Çoğu kuruluş için kademeli bir yayılım en iyisidir:

• Pilot grup önce (güvenlik ekibi, tesisler, tek bir ofis/kat) okuyucuları, onboarding'i ve kenar durumları doğrulamak için
• Çift kimlikli dönem: çalışanlar fiziksel kart veya dijital pass kullanabilir. Hedef bir bitiş tarihi koyun, ancak yükleniciler veya özel cihazlar için istisnalar bırakın.
• Eğitim ve iletişim: kısa “nasıl girilir” talimatları, nerede dokunulur/taranır, telefon ölürse ne yapılır ve nasıl yardım istenir.

Gerçekten kullanacağınız destek çalışma kitapları

Help desk ve adminler için basit, tekrarlanabilir iş akışları oluşturun:

• Kayıp telefon: credential'i hemen iptal edin; kimlik doğrulama sonrası yeni cihaza yeniden verin.
• Erişim reddedildi: okuyucu loglarını, pass durumunu (active/expired), kullanıcı izinlerini ve programı kontrol edin; gerektiğinde geçici bir yedek sağlayın.
• Cihaz değişikliği/yükseltme: mümkünse self-serve yeniden kayıt, oran limitleri ve admin override ile.
• Yeniden verme: tanımlayıcıları ne zaman döndürüp ne zaman aynı pass'i yeniden etkinleştireceğinizi tanımlayın (dolandırıcılık önleme ve denetim için önemli).

Bu çalışma kılavuzlarını tek bir yerde tutun ve admin konsolu ile iç dokümanlardan bağlantı verin.

Enstrümantasyon ve operasyonel metrikler

Sadece kurulumları değil, gerçek giriş performansını gösteren analitik ekleyin:

• Aktivasyon hunisi: davet → yükleme → kayıt → ilk başarılı giriş
• Site/kapı/okuyucu modeline göre tarama/tap başarı oranı
• Giriş süresi (medyan ve p95)
• Okuyucu ve backend hataları (zaman aşımı, çevrimdışı, imza hataları)

Bu metrikleri okuyucu ayarlarını incelemek ve kullanıcı eğitimi önceliklendirmek için kullanın.

Yayılım kontrol listesi (yayımlayın ve tekrar kullanın)

• Okuyucular doğrulandı (NFC/QR) ve yedek test edildi
• Yönetici rolleri ve yükseltme irtibatları tanımlandı
• Destek senaryoları hazır (kayıp telefon, reddedilen erişim, yeniden verme)
• Analitik panosu canlı ve haftalık inceleme takvimi var
• Net kullanıcı iletişimi ve yardım talebi yolu mevcut (/contact)
• Ticari ve ölçekleme planı onaylandı (/pricing)