Ödeme Sağlayıcısı Passkey'leri: 3. Taraf SDK Nasıl Oluşturulur

Passkey'ler, geleneksel çok faktörlü kimlik doğrulamaya (MFA) kıyasla güvenliği ve kolaylığı önemli ölçüde artırarak çevrimiçi işlemleri güvence altına almak ve yetkilendirmek için en etkili yöntem olarak ortaya çıkıyor. Yakın zamanda PayPal, passkey'leri birincil bağımsız MFA çözümü olarak benimsedi ve dünya çapındaki ödeme sağlayıcıları için net bir trend belirledi.

Ancak passkey'ler, başlangıçta birinci taraf bağlamları düşünülerek tasarlandı. Yani, kullanıcılar kimlik bilgilerine sahip olan web sitesinde veya uygulamada doğrudan kimlik doğruladığında en iyi şekilde çalışırlar. Buna karşılık, ödeme sağlayıcıları genellikle hizmetlerinin (ödeme formları veya SDK'lar gibi) tüccarların web sitelerine ve uygulamalarına gömülü olduğu üçüncü taraf bağlamlarında faaliyet gösterir. Passkey tasarımı ile ödeme sağlayıcılarının operasyonel modelleri arasındaki bu temel uyumsuzluk, sorunsuz entegrasyon için kritik sınırlamalar sunar. Bu zorlukları ele almak için iki kritik soruyu araştırmalıyız:

1. Ödeme sağlayıcıları için üçüncü taraf bağlamlarında passkey kullanmanın mevcut sınırlamaları nelerdir? 2. Ödeme sağlayıcıları, üçüncü taraf passkey entegrasyonlarını başarıyla uygulamak için bu sınırlamaların üstesinden nasıl gelebilir?

Bu soruları inceleyerek, passkey'leri üçüncü taraf bağlamlarına uyarlamaya yönelik devam eden endüstri çabalarının - özellikle Güvenli Ödeme Onayı (SPC) gibi web standartları aracılığıyla - Apple tarafından dolaylı olarak dayatılan stratejik engellerle tıkandığını ortaya çıkaracağız. Özellikle, Apple'ın Safari'de kaynaklar arası passkey oluşturmaya yönelik sınırlı desteği ve Güvenli Ödeme Onayı Standardı'ndan eksik destek, üçüncü taraf ödeme sağlayıcıları tarafından passkey tabanlı kimlik doğrulamanın sorunsuz bir şekilde benimsenmesini zorlaştıran önemli bir engel teşkil etmektedir. Bu engelleri anlamak ve aşmak, sorunsuz ve güvenli ödeme deneyimleri sunmayı amaçlayan her sağlayıcı için esastır.

Passkey'ler, ödeme yığınının her katmanına kimlik avına dayanıklı, biyometrik tabanlı giriş imkanı sunar. Aşağıda, ödeme değer zincirindeki her oyuncunun passkey kimlik doğrulamasını entegre etmekten nasıl fayda sağlayabileceğinin bir dökümü bulunmaktadır.

Etki: Daha hızlı ödeme, daha yüksek dönüşüm, daha az sepet terk etme. Fırsat: SDK'lar veya yönlendirme akışları aracılığıyla passkey sunan tüccarlar, Apple Pay düzeyinde bir kullanıcı deneyimini taklit edebilir ve şifrelere veya OTP'lere olan bağımlılığı azaltabilir - bu da daha yüksek güven ve satışlara yol açar.

Etki: Cihazlar arasında sorunsuz, şifresiz kimlik doğrulama. Fırsat: Passkey'ler, OTP'lerden veya SMS kodlarından daha iyi bir kullanıcı deneyimi sunar ve kimlik avı riskini ortadan kaldırır. Geniş çapta benimsenmesi, passkey'leri kart sahibi doğrulaması için yeni varsayılan haline getirebilir.

Etki: Daha güçlü dolandırıcılık önleme. Fırsat: Kartı veren kuruluşlar, 3DS akışlarında passkey tabanlı yükseltilmiş kimlik doğrulama sunarak OTP maliyetlerini düşürebilir ve kullanıcı memnuniyetini artırabilir.

Etki: Daha yüksek işlem kabulü ve daha az başarısız kimlik doğrulama. Fırsat: PSP'ler aracılığıyla passkey'leri desteklemek, tüccar sonuçlarını iyileştirebilir ve ödeme veya yinelenen faturalandırma akışları sırasındaki sürtünmeyi azaltabilir.

Etki: Azaltılmış dolandırıcılık, daha iyi tüccar kullanıcı deneyimi ve geliştirilmiş uyumluluk. Fırsat: Passkey akışlarını gömerek veya yönlendirerek, PSP'ler tarayıcılar ve yerel uygulamalar arasında uyumluluğu korurken yeni nesil kimlik doğrulama sağlayabilir.

Etki: Daha az reddedilen ödeme ile kolaylaştırılmış işlem onayları. Fırsat: Ödeme işleme şirketleri, riski azaltmak ve uyumlu akışlar için biyometrik SCA alternatiflerini desteklemek amacıyla passkey doğrulamasını API'lerine entegre edebilir.

Etki: Güvenli kimlik bilgisi depolama ve sorunsuz yeniden kimlik doğrulama. Fırsat: Apple Pay ve Google Pay gibi cüzdan sağlayıcıları zaten passkey benzeri akışlar kullanıyor.

Devamında, büyük ödeme ve kredi kartı sağlayıcılarına kısa bir göz atıyor ve passkey'leri uygulayıp uygulamadıklarını ve nasıl uyguladıklarını analiz ediyoruz:

Mastercard, EMV 3DS akışlarına gömülü şifresiz bir kimlik doğrulama deneyimi sunan Ödeme Passkey Hizmeti'ni resmi olarak başlattı. Kullanıcılar, Mastercard'in kimlik doğrulama alan adına (ör. verify.mastercard.com) bağlı passkey'ler oluşturup kullanabilir, bu da katılımcı tüccarlar arasında güvenli, biyometrik girişi mümkün kılar. Bu lansman, ödeme endüstrisinde kimlik avına dayanıklı, PSD2 uyumlu kimlik doğrulamaya yönelik büyük bir adımı temsil ediyor. Daha fazlasını okuyun: Mastercard Passkey'leri

Visa, passkey'leri “Click to Pay” akışına entegre ederek Visa Ödeme Passkey Hizmeti'ni tanıttı. Kullanıcıların şifreler veya OTP'ler yerine biyometri kullanarak sorunsuz bir şekilde kimlik doğrulamasına olanak tanıyarak, Visa çevrimiçi ödeme deneyimini gelişmiş güvenlik ve kullanıcı kolaylığı ile modernize etmeyi hedefliyor. Daha fazlasını okuyun: VISA Passkey'leri

American Express henüz halka açık bir passkey teklifi sunmadı. Ancak, FIDO Alliance'ın yönetim kurulu düzeyinde bir üyesi olarak, American Express'in yakın gelecekte daha geniş endüstri trendleriyle uyumlu olarak passkey tabanlı bir kimlik doğrulama çözümü sunması muhtemeldir.

PayPal, passkey'leri benimseyen ilk ödeme sağlayıcılarından biriydi. Lansmanları, kişisel ve ticari hesaplar için cihazlar arasında sorunsuz biyometrik girişi destekliyor. Passkey, PayPal'in alan adına bağlıdır ve zaten birçok bölgede mevcuttur. Ancak, uygulamalarının özellikle çoklu cihaz akışları ve platform tespiti konularında iyileştirme alanı bulunmaktadır. Daha fazlasını okuyun: PayPal Passkey'leri

Klarna henüz resmi olarak passkey desteğini sunmadı. Gözlemlerimize göre, Klarna uygulamalarında ve ödeme SDK'larında büyük ölçüde gömülü WebView'lere dayanıyor. Safari ve iOS, iframe'lerde / WebView'lerde passkey oluşturmayı kısıtladığından, bu Klarna'nın şimdiye kadar passkey'leri kullanıma sunmamasının bir nedeni olabilir.

Square, geliştirici panosu ve yönetim konsolu için passkey girişi sunarak dahili araçlara güvenli, şifresiz erişim sağladı. Ancak, son kullanıcılar veya tüccarlar için ödeme akışlarında veya API'lerde passkey desteğiyle ilgili herhangi bir duyuru yapılmadı.

Stripe, panosu için passkey girişi sunarak geliştiricilerin biyometri kullanarak kimlik doğrulamasına olanak tanıdı. Stripe Checkout veya Elements için passkey'ler henüz mevcut değil. Stripe'ın yönlendirme tabanlı akışları güçlü bir şekilde savunması göz önüne alındığında, passkey'lerin - eğer ödemelerde uygulanırsa - aynı yönlendirme mimarisini takip etmesi muhtemeldir.

Şu an itibarıyla, BILL kimlik doğrulama için passkey'lerle ilgili herhangi bir kamuoyu duyurusu veya ürün güncellemesi yapmadı.

Remitly, hizmetlerinde passkey kimlik doğrulamasını uygulama konusunda herhangi bir plan veya kamuya açık bilgi açıklamadı.

Payoneer'in passkey tabanlı giriş veya işlem akışlarını benimsediğini veya test ettiğini gösteren herhangi bir kamuya açık rapor veya ürün dokümantasyonu bulunmamaktadır.

Adyen, kimlik doğrulama veya ödeme akışlarına henüz passkey'leri dahil etmedi. Herhangi bir kamuoyu açıklaması veya geliştirici dokümantasyonunda passkey desteğinden bahsedilmiyor.

Worldpay, şu an itibarıyla passkey'ler için herhangi bir destek duyurmadı. Kimlik doğrulama yığınları hala şifreler, OTP'ler ve 3DS tabanlı akışlar gibi geleneksel yöntemlere dayanmaktadır.

Checkout.com, halka açık olarak passkey desteğini sunmadı. Passkey benimsenmesiyle ilgili herhangi bir geliştirici güncellemesi, blog yazısı veya resmi duyuru bulunmamaktadır.

AliPay, resmi olarak passkey'leri başlatmadı. Çin ödeme ekosistemlerindeki biyometrik kimlik doğrulama eğiliminin artması göz önüne alındığında, gelecekte bir lansman gerçekleşebilir, ancak mevcut hiçbir dokümantasyon bunu doğrulamamaktadır.

Mollie, kimlik doğrulama veya ödeme sistemlerinde passkey'lerin benimsenmesiyle ilgili herhangi bir kamuoyu açıklaması veya ürün güncellemesi yapmadı.

Amazon, ana platformunda kullanıcı girişleri için passkey desteğini kullanıma sundu. Bu teknolojiyi Amazon Pay'e genişletmek doğal bir sonraki adım olacaktır, özellikle de birçok kullanıcının Amazon'da kayıtlı bir passkey'i olduğu için bu, ödeme sırasında kullanıcı katılımını önemli ölçüde basitleştirecektir.

Bir PayPal şirketi olan Braintree, henüz resmi olarak passkey kimlik doğrulamasını benimsemedi. Mevcut dokümantasyonları, kullanıcı girişi veya tüccar API'leri bağlamında passkey'lerden bahsetmiyor.

Stripe'ın tek tıkla ödeme çözümü olan Link, passkey'leri kullanıma sundu ve bu, Stripe'ın tüketici ödemelerindeki passkey stratejisinin temelini oluşturabilir. Ancak Stripe, Link için passkey desteğini veya lansman için belirli planları resmi olarak duyurmadı.

Afterpay, passkey desteğiyle ilgili herhangi bir açıklama veya özellik yayınlamadı. Klarna gibi, ödeme entegrasyonları da büyük ölçüde uygulama tabanlıdır, bu da gömülü WebView kısıtlamaları nedeniyle passkey benimsenmesi için teknik engeller oluşturabilir.

Üçüncü taraf ödeme sağlayıcıları tarafından passkey'lerin benimsenmesi, öncelikle Apple'ın Safari'deki kısıtlayıcı politikalarından kaynaklanan stratejik engellerle karşı karşıyadır. İki kritik standardizasyon girişimi sürekli olarak engellenmiştir:

• Güvenli Ödeme Onayı (SPC)
• iframe'lerde Üçüncü Taraf Passkey Oluşturma

Güvenli Ödeme Onayı (SPC), endüstrinin - özellikle Google tarafından yönlendirilen - passkey'lerin güvenli ödeme yetkilendirmeleri için özel olarak tasarlanmış, sorunsuz, kaynaklar arası kullanımını sağlamaya yönelik en önemli çabasını temsil eder. SPC, ödeme sağlayıcılarının güvenlik veya kullanıcı deneyiminden ödün vermeden birden fazla tüccar sitesinde kullanıcıları nasıl doğrulayacağını standartlaştırır. Ancak Apple, muhtemelen Apple Pay'in kendi ekosistemi içinde tercih edilen, en sürtünmesiz ödeme çözümü olarak kalmasını sağlamak için stratejik bir hamle olarak Safari içinde SPC desteğini sürekli olarak geri çekti. Apple'ın SPC'yi benimsemeyi reddetmesi, yalnızca passkey'lerin üçüncü taraf bağlamlarında yaygın olarak dağıtılmasını sınırlamakla kalmaz, aynı zamanda standartlaştırılmış ödeme kimlik doğrulamasının daha geniş endüstri tarafından benimsenmesini de etkili bir şekilde geciktirir.

Detaylar hakkında daha fazla bilgi edinmek isterseniz SPC hakkındaki bu blog yazısını okuyun.

Bir diğer kritik engel, Apple'ın kaynaklar arası iframe'ler içinde passkey oluşturmayı kasıtlı olarak kısıtlamasıdır. Safari, üçüncü taraf bir iframe içinde kimlik doğrulama için mevcut passkey'lerin kullanılmasına (navigator.credentials.get()) izin verirken, bu tür bağlamlarda passkey kaydını (navigator.credentials.create()) açıkça engeller.

Bu sınırlama, tüccar ödeme akışı sırasında sorunsuz bir şekilde yeni passkey'ler oluşturmaya bağımlı olan ödeme sağlayıcılarını ciddi şekilde kısıtlar. Sonuç olarak, sağlayıcılar ya yönlendirme tabanlı yaklaşımlara zorlanır ya da daha önce doğrudan kendi alan adlarında oluşturulmuş mevcut passkey'lere güvenmek zorunda kalır. Apple'ın bu kararı, tüccar entegrasyonlarının pratikliğini ve akıcılığını doğrudan etkileyerek tüketiciler ve sağlayıcılar için önemli bir sürtünme noktası oluşturur.

Bu yaklaşımda, tüccar ödeme formunuzu ödeme sağlayıcı alan adınızdan sunulan bir <iframe> içine dahil eder - örneğin, https://pay.provider.com. Kullanıcı tüccarın alan adında kalır (ör. https://www.mystore.com), gömülü iframe içinde ödeme kullanıcı arayüzünüzü görür ve pay.provider.com Güvenen Taraf ID'sine bağlı bir passkey ile kimlik doğrular.

Önemli Noktalar:

• Kaynaklar Arası: iframe farklı bir alan adında olduğu için, iframe içinde passkey işlemlerine izin vermek üzere publickey-credentials-get ve publickey-credentials-create için izin politikalarını yapılandırmanız gerekir.

• Oluşturma Sınırlaması: Bazı tarayıcılar (özellikle eski sürümler ve Safari) hala kaynaklar arası iframe'lerde passkey oluşturmaya izin vermemektedir. Kimlik doğrulama (navigator.credentials.get()) daha yaygın olarak desteklenir, ancak kayıt (navigator.credentials.create()) belirli ortamlarda, özellikle Safari'de başarısız olabilir.

• Kullanıcı Etkinleştirmesi: Passkey akışları genellikle “geçici etkinleştirme” (ör. kullanıcıdan doğrudan bir düğme tıklaması) gerektirir. iframe arayüzünüzün passkey seremonisini kullanıcı tarafından başlatılan bir olay içinde tetiklediğinden emin olun.

• Güvenlik ve Kullanıcı Deneyimi: iframe yaklaşımı sorunsuz, satır içi bir ödeme deneyimi sağlar, ancak bir kullanıcının tarayıcısı üçüncü taraf çerezlerini veya yerel depolamayı engeller veya kısıtlarsa, passkey akışını bozabilir.

Yönlendirme tabanlı bir akışla, kullanıcıyı tüccarın alan adından ödeme alan adınıza gönderir veya https://pay.provider.com/checkout gibi bir adrese işaret eden yeni bir sekme/pencere açarsınız. Passkey'ler daha sonra doğrudan alan adınızda birinci taraf bağlamında oluşturulur veya kullanılır.

Önemli Noktalar:

• Birinci Taraf Basitliği: Tüm passkey iş akışı (oluşturma, kimlik doğrulama) ödeme sağlayıcısının alan adında gerçekleşir, bu nedenle kaynaklar arası kısıtlamalar yoktur. Tüm büyük tarayıcılar birinci taraf bağlamlarında passkey oluşturmayı ve giriş yapmayı destekler.

• Yönlendirme Kullanıcı Deneyimi: Kullanıcı, kimlik doğrulamayı tamamlamak için tüccar sayfasından ayrılır (veya bir pop-up görür). Bu daha az sorunsuz olabilir, ancak passkey mimarisini basitleştirir ve kaynaklar arası karmaşıklıkları azaltır.

• Uyumsuz Tarayıcılar için Yedekleme: Passkey'ler mevcut değilse (ör. eski tarayıcılar), ödeme alan adınızda alternatif giriş yöntemleri sağlayarak zarif bir şekilde düşüş yapabilirsiniz, ekstra kaynaklar arası izin yönetimine gerek kalmadan.

Yerel mobil uygulamalara passkey entegrasyonu, web tabanlı senaryolara kıyasla benzersiz zorluklar sunar. Tüccarlar için yerel uygulamalar (hem iOS hem de Android üzerinde) genellikle sorunsuz bir kullanıcı deneyimi sağlamak için gömülü WebView'ler kullanarak ödeme akışlarını uygulama içine yerleştirir. Ancak, bu gömülü bağlamlarda üçüncü taraf passkey kimlik doğrulamasını uygulamak, katı tarayıcı-kaynak politikaları ve platforma özgü sınırlamalar nedeniyle sorunlu olabilir.

Passkey'ler doğası gereği belirli bir alan adına (“Güvenen Taraf ID”) bağlıdır. Bu, kimlik bilgilerinin ilgisiz web siteleri veya uygulamalar arasında kötüye kullanılamamasını sağlayan temel bir güvenlik ilkesidir. Bir ödeme sağlayıcısı kendi alan adı altında - örneğin, pay.provider.com - passkey'ler oluşturduğunda, bu passkey'ler hem iOS hem de Android üzerinde kesinlikle o alan adıyla sınırlıdır. Sonuç olarak, bir tüccarın yerel uygulaması (doğal olarak tüccarın kendi uygulama tanımlayıcısı ve alan adı altında çalışan) sağlayıcının passkey'lerini “birinci taraf” bir kimlik bilgisi olarak doğrudan çağıramaz. Bunu yapmak, işletim sistemlerinin ve WebAuthn spesifikasyonlarının kimlik avı ve kimlik bilgisi hırsızlığını önlemek için açıkça yasakladığı özel anahtarların kaynaklar arası paylaşımını gerektirir.

Cihazın bakış açısından, tüccarın yerel uygulaması ödeme sağlayıcısının alan adından farklı bir “kaynaktır”. Ayrı bir kaynağa kayıtlı kimlik bilgilerine karşı yerel olarak kimlik doğrulamaya çalışmak, passkey'lerin temel kaynak-bağlı güvenlik modelini bozar. Bu, bir tüccar bağlamında üçüncü taraf passkey kullanımının neden bir sistem tarayıcısına veya sistem tabanlı bir WebView'e (iOS'ta ASWebAuthenticationSession veya Android'de Chrome Custom Tabs gibi) bağlı olduğunun tam nedenidir. Bu özel akışlar, sağlayıcının orijinal alan adı bağlamını korur - passkey'lerin güvenli bir şekilde kaynak-bağlı kalmasını sağlar - aynı zamanda kullanıcıların bir tüccarın uygulaması içinde ödeme sağlayıcısıyla kimlik doğrulamasına olanak tanır. Aşağıdaki bölümlerde bunun nasıl çalıştığını keşfedeceğiz.

Gömülü WebView'ler (ör. iOS'ta WKWebView veya Android'in WebView'i), uygulamaların web içeriğini doğrudan yerel arayüzlerine gömmelerine olanak tanıdığı, sıkı entegrasyon ve kullanıcı deneyimi tutarlılığı sunduğu için yaygın olarak tercih edilir. Ancak, bu gömülü ortamlar, kaynak ve güvenlik politikaları nedeniyle üçüncü taraf passkey'leri işlerken önemli ölçüde kısıtlanmıştır:

• Kaynak Uyuşmazlığı: Passkey'ler, güvenli kimlik bilgisi işleme için kesinlikle alan adı kaynaklarına dayanır. Gömülü bir WebView, görüntülediği içeriğin (genellikle tüccarın) alan adı altında çalışır, bu da üçüncü taraf bir ödeme sağlayıcısının alan adına açıkça bağlı passkey'ler oluşturmayı veya doğrulamayı zorlaştırır veya imkansız hale getirir.

• Platform Güvenlik Kısıtlamaları: Hem Apple (iOS) hem de Google (Android), özellikle güvenli kimlik bilgileriyle uğraşırken gömülü WebView'lerin kimlik doğrulama yeteneklerini giderek daha fazla kısıtlamıştır. Bu kısıtlamalar, kullanıcı gizliliğini ve güvenliğini korumak için tasarlanmıştır, ancak üçüncü taraf passkey uygulamasını belirgin şekilde daha karmaşık hale getirir.

Genel olarak, gömülü WebView'ler bir kullanıcı deneyimi perspektifinden tüccarlar için çekici olsa da, sağlam üçüncü taraf passkey kimlik doğrulama akışlarını uygulamak için önemli pratik sınırlamalar getirirler.

Gömülü WebView'lerle ilişkili sınırlamalar göz önüne alındığında, ödeme sağlayıcıları genellikle yerel mobil uygulamalarda üçüncü taraf passkey'leri güvenilir bir şekilde uygulamak için iki alternatif stratejiden birini benimser:

iOS (ASWebAuthenticationSession):

Apple, ana uygulamanın bağlamı dışında güvenli, tarayıcı benzeri bir ortam olarak ASWebAuthenticationSession sağlar. Varsayılan Safari tarayıcısıyla çerez depolamasını paylaşır ve kimlik bilgileri ödeme sağlayıcısının kaynak alan adıyla uyumlu olduğu için üçüncü taraf passkey'leri güvenilir bir şekilde destekler.

Aşağıdaki örnek, BOSS yerel uygulaması içindeki “PayPal ile Öde” işlevselliğini göstermektedir. Safari çerezleriyle durumunu paylaşan bir ASWebAuthenticationSession sistem webview'inin nasıl açıldığını ve passkey diyaloğunun hemen başlamasına nasıl izin verdiğini gösterir.

Android (Chrome Custom Tabs):

Benzer şekilde, Android'in Custom Tabs'ı, tutarlı passkey oluşturma ve kimlik doğrulamasına olanak tanıyan tarayıcıya yakın bir ortam sunar. ASWebAuthenticationSession gibi, Custom Tabs da tüccarın uygulama bağlamından ayrı çalışarak alan adı ve kimlik bilgisi bütünlüğünü sağlar.

Android'deki BOSS yerel uygulamasından aynı örneği burada görebilirsiniz:

Başka bir yaklaşım, kullanıcıları yerel uygulamadan mobil cihazın varsayılan web tarayıcısına (iOS'ta Safari, Android'de Chrome) yönlendirmeyi içerir. Bu, ödeme akışının - ve dolayısıyla passkey yönetiminin - tamamen ödeme sağlayıcısının alan adıyla ilişkili güvenilir, birinci taraf bir bağlamda gerçekleşmesini sağlar. Kullanıcılar daha sonra başarılı kimlik doğrulama veya ödeme tamamlandıktan sonra tüccar uygulamasına geri döner. Bu seçenek, uygulamadan ayrılmak zorunda kaldıkları için müşteriler için çok elverişsizdir.

Her iki çözüm de kullanıcıları geçici olarak tüccarın yerel uygulama ortamından çıkarmayı gerektirir. Gömülü çözümlere kıyasla biraz daha az sorunsuz olsa da, bu yaklaşımlar üçüncü taraf passkey işlemlerinin uyumluluğunu, güvenliğini ve güvenilirliğini önemli ölçüde artırır.

Sonuç olarak, yerel SDK'lar geliştiren ödeme sağlayıcıları, kullanıcı deneyimi hususlarını pratik teknik kısıtlamalarla dikkatlice dengelemelidir. Tüccarların tamamen gömülü deneyimlere yönelik tercihlerine rağmen, sistem WebView'lerinden veya harici tarayıcı yönlendirmesinden yararlanmak, yerel uygulamalar içinde güvenli, güvenilir üçüncü taraf passkey kimlik doğrulaması sağlamak için en iyi uygulama olmaya devam etmektedir.

Üçüncü taraf passkey'leri ödeme SDK'larına entegre etmek için gömülü (iframe) bir yaklaşım ile yönlendirme tabanlı bir yaklaşım arasında seçim yapmak, kullanıcı deneyimi, tarayıcı uyumluluğu, teknik karmaşıklık ve tüccar tercihleri arasındaki ödünleşimleri değerlendirmeyi içerir.

Her iki çözümün de belirgin avantajları ve dezavantajları vardır ve ödeme sağlayıcıları bunları hedef pazarlarına, istenen kullanıcı deneyimine ve teknik altyapılarına göre dikkatlice değerlendirmelidir.

Gömülü (iframe) yaklaşımı, tüccarlar için son derece çekici, sorunsuz, tüccar markalı bir kullanıcı deneyimi sunar, ancak özellikle Safari'nin kaynaklar arası passkey oluşturmaya izin vermemesi nedeniyle sınırlı tarayıcı uyumluluğu tarafından engellenir. Bu sınırlama, tüccarları ve sağlayıcıları genellikle işlevsellikten ödün veren veya passkey kaydı için eksik desteğe yol açan karmaşık, geçici çözümlere zorlar.

Tersine, yönlendirme yaklaşımı, birinci taraf alan adı bağlamında çalışarak tarayıcılar ve yerel mobil platformlar arasında kapsamlı uyumluluk sunar. Entegrasyonu önemli ölçüde basitleştirir, güvenilirliği artırır ve tam passkey oluşturma ve kimlik doğrulama desteği sağlar. Ana dezavantajı, kullanıcıları tüccarın web sitesinden veya uygulamasından uzağa yönlendirmenin yarattığı potansiyel sürtünmedir, ancak bu dikkatli bir kullanıcı deneyimi tasarımı, açıkça iletilen beklentiler veya Corbado gibi güvenilir platformlarla entegrasyonlarla azaltılabilir.

Bu hususlar göz önüne alındığında, genellikle hibrit bir yaklaşım idealdir. Bu, ödeme sağlayıcılarının kullanıcının tarayıcısı desteklediğinde gömülü iframe modelinden yararlanmasına ve aksi takdirde zarif bir şekilde bir yönlendirme yaklaşımına geri dönmesine olanak tanır. Bu birleşik strateji, çeşitli ortamlarda uyumluluğu, tüccar çekiciliğini ve müşteri memnuniyetini en üst düzeye çıkarır.

Üçüncü taraf bir passkey ödeme SDK'sı uygulamak, kullanıcı deneyimi, tarayıcı uyumluluğu, yerel uygulama kısıtlamaları, analitik ve güvenliği dengelemeyi içerir - özellikle Apple'a özgü engeller (ör. kaynaklar arası passkey oluşturmayı engelleme, eksik SPC desteği) göz önüne alındığında. Aşağıda, passkey'leri web veya yerel ödeme akışlarına entegre ederken mümkün olan en iyi sonucu sağlamak için temel öneriler bulunmaktadır.

Değişen tarayıcı desteği ve tutarsız Apple davranışları nedeniyle, hem gömülü (iframe tabanlı) bir yaklaşımı hem de bir yönlendirme yaklaşımını desteklemek kritik öneme sahiptir:

• Iframe ile Ödeme (Gömülü)

  • Kaynaklar arası passkey işlemlerine izin veren modern tarayıcılar için (öncelikle kimlik doğrulama için) sorunsuz, sayfa içi bir deneyim sağlar.

  • publickey-credentials-get/publickey-credentials-create için doğru Permissions-Policy ayarlanmalıdır.

  • Safari ve bazı eski tarayıcıların iframe'lerde kaynaklar arası passkey oluşturmayı engellediğini unutmayın.

• Yönlendirme Akışı

  • Birinci taraf bağlamında hem passkey kaydını hem de girişini güvenilir bir şekilde destekler.

  • Ekstra yönlendirme veya pop-up nedeniyle biraz daha fazla sürtünme, ancak tarayıcılar arası uyumluluk için evrensel olarak daha güvenlidir.

  • Şu anda iframe'lerde üçüncü taraf passkey oluşturmaya izin vermeyen Safari için ideal bir yedekleme.

Her iki yaklaşımı da sunarak, dinamik olarak hangisinin kullanılacağına karar verebilir veya tüccarların karar vermesine izin vererek tüm kullanıcı ortamları için uyumluluğu en üst düzeye çıkarabilirsiniz.

Azaltılmış User-Agent ayrıntı düzeyi ve platformlar arasında tutarsız Client Hints desteği nedeniyle tarayıcı yeteneklerini doğru bir şekilde algılamak zor olmaya devam etmektedir.

Tarayıcılar kullanıcı gizliliğini korumak için User-Agent dizelerindeki ayrıntıyı azalttıkça geleneksel ayrıştırma giderek daha güvenilmez hale gelmektedir. Windows 10 ile Windows 11 arasındaki fark, hassas macOS sürümleri veya CPU mimarileri gibi temel ayrıntıları ayırt etmek artık yalnızca User-Agent kullanarak zor veya imkansızdır.

Client Hints gizliliğe saygılı bir şekilde yüksek entropili veriler sağlarken, yalnızca Chromium tabanlı tarayıcılar bunları tam olarak destekler. Safari ve Firefox, Client Hint desteği sunmaz, bu da Apple cihazlarında hassas özellik tespitini ciddi şekilde kısıtlar.

Gömülü WebView'ler genellikle ayrıntılı cihaz bilgilerine erişimi kısıtlar ve nadiren Client Hints destekler. Bu sınırlama, passkey yetenek tespitini özellikle yerel uygulama bağlamlarında zorlaştırır.

Bu kısıtlamalar göz önüne alındığında, özellikle üçüncü taraf ödeme SDK'larında kaynaklar arası passkey desteğini güvenilir bir şekilde tespit etmek, dinamik Client Hint sorgularının (mevcut olduğunda), yedek User-Agent sezgisellerinin ve Safari ve Firefox gibi tarayıcılar için muhafazakar varsayılan davranışların dikkatli bir kombinasyonunu gerektirir.

Yerel tüccar uygulamaları genellikle web içeriğini WKWebView (iOS) veya Android WebView'e gömer, ki bunlar passkey'ler için çok kısıtlayıcıdır. Yaygın stratejiler şunları içerir:

• Sistem Tarayıcı Oturumları: Passkey oluşturma/girişini güvenli bir “birinci taraf” tarayıcı bağlamına kaydırmak için ASWebAuthenticationSession (iOS) veya Custom Tabs (Android) kullanın.

• Varsayılan Tarayıcıya Yönlendirme: Passkey işlemleri için alan adı bütünlüğünü sağlamak için daha az sorunsuz ama son derece güvenilir bir yaklaşım.

Bir ödeme sağlayıcısı olarak, güçlü güvenlik ve düzenleyici uyumluluk (PCI, PSD2 SCA, vb.) anahtardır:

• Başlıklar ve İçerik Güvenliği: Kaynaklar arası akışlar için katı Permissions-Policy başlıkları ve sağlam CSP kuralları uygulayın.

• Günlük Kaydı ve İzleme: Dolandırıcılığı önleme ve uyumluluk denetimleri için passkey oluşturma ve kullanım olaylarını kapsamlı bir şekilde günlüğe kaydedin.

• Minimum PII Depolama: Kullanıcıları karma tanımlayıcılar kullanarak passkey'lerle eşleştirin, GDPR veya benzeri veri koruma yasaları kapsamındaki maruziyeti azaltın.

• Denetim İzleri: Anormallikleri tespit etmek ve uyumluluk denetimlerini karşılamak için her passkey oluşturma ve kimlik doğrulama olayını günlüğe kaydedin.

Passkey'ler hala gelişiyor, bu yüzden sürekli kontrollere ihtiyacınız olacak:

• Tarayıcılar Arası ve İşletim Sistemleri Arası Test: Safari, Chrome, Edge, Firefox ve büyük mobil işletim sistemi sürümlerinde testleri otomatikleştirin.

• Sık Güncellemeler: W3C WebAuthn özelliklerindeki, FIDO Alliance yönergelerindeki veya SPC tekliflerindeki değişiklikleri takip edin.

• Kullanıcı Geri Bildirimi ve Hata Oranları: Özellikle Apple tabanlı kullanıcılar için sorunları hızla düzeltmek amacıyla passkey hatalarını (oluşturma veya giriş) günlüğe kaydedin.

Sağlam bir KPI çerçevesi, üçüncü taraf passkey entegrasyonunuzun güvenliği ve kullanıcı deneyimini gerçekten iyileştirip iyileştirmediğini izlemenize yardımcı olur. Bu makale SDK'ları uygulamakla ilgili olsa da, passkey benimsenmesinin bu kullanım durumunda da anahtar olduğunu akılda tutmak önemlidir. Passkey'lerin oluşturma oranı ve kullanım oranı dikkatli bir analiz ve optimizasyon gerektirir.

• Tanım: İstendiğinde (ör. ödeme veya hesap kurulumunda) başarılı bir şekilde bir passkey oluşturan kullanıcıların yüzdesi.

• Neden Önemli: Yüksek bir oluşturma oranı, passkey'ler için katılım/teşvik akışınızın ilgi çekici ve sürtünmesiz olduğu anlamına gelir.

• Hedef: %50-80'lik bir oranı hedeflemelisiniz.

• Tanım: Oluşturma seremonisine başlayan kullanıcılar arasında (“Passkey Oluştur”a tıklayan), kaç tanesi iptal etmeden veya hata almadan tamamlıyor?

• Neden Önemli: Kaynaklar arası veya yönlendirme akışınızın ne kadar iyi çalıştığını gösterir.

• Hedef: İdeal olarak, bir kullanıcı kabul ettikten sonra ~%95–100'lük bir sayıya sahip olursunuz.

• Tanım: Yedek yöntemlere kıyasla passkey'ler aracılığıyla yapılan toplam ödeme yetkilendirmelerinin (veya girişlerin) yüzdesi.

• Neden Önemli: Kullanıcılar eski yöntemlere geri dönerse oluşturma anlamsızdır.

• Hedef: %50–80'lik bir oran, güçlü passkey benimsenmesini işaret eder.

• Tanım: Hata veya yedekleme olmadan başarılı olan passkey giriş denemelerinin yüzdesi.

• Neden Önemli: Gerçek dünya kullanılabilirliğinizin bir yansıması.

• Hedef: Genellikle passkey'leri “sürtünmesiz” olarak kabul etmek için %90–95'i aşmalısınız.

• Tanım: Kullanıcılar seremoni ortasında passkey'lerde ne sıklıkla başarısız olur ve bir şifreye veya OTP'ye geçer?

• Neden Önemli: Yüksek yedek kullanımı, teknik veya kullanıcı deneyimi engellerinin passkey'lerin eski yöntemlerin yerini almasını engellediğini gösterir.

• Hedef: İdeal olarak, yedek kullanımı %1-5'ten azdır.

Ödeme sağlayıcıları için, passkey'lerin dolandırıcılığı azaltıp azaltmadığını, ödemeyi hızlandırıp hızlandırmadığını veya sepet terkini düşürüp düşürmediğini ölçün. Bütünsel bir görünüm için passkey kullanım verilerini ödeme dönüşümü veya 3-D Secure başarı metrikleriyle birleştirin.

Bu KPI'ları izlemek, hangi ortamların veya kullanıcı yolculuklarının iyileştirilmesi gerektiğini belirlemenize yardımcı olur - ör. Safari iOS, kaynaklar arası engellemeler nedeniyle daha yüksek bir terk oranına sahipse, bu kullanıcıları sistematik olarak bir yönlendirme akışına yönlendirebilirsiniz.

Üçüncü taraf bir passkey SDK'sı oluşturmanın en kritik zorluklarından biri, kullanıcıların passkey'lerini gerçekten kaydettiği sorunsuz ve tutarlı bir oluşturma akışı düzenlemektir. Bu, bir bankanın portalında, ödeme sağlayıcısının kendi hesap ayarlarında veya doğrudan bir tüccarın ödeme sayfasında gerçekleşse de, temel passkey kayıt adımları çok benzerdir. Sonuç olarak, passkey oluşturma yaklaşımı, akışı bir iframe'e gömüp gömmediğinize veya kullanıcıyı birinci taraf bir sayfaya yönlendirip yönlendirmediğinize göre temelden değişmez; en önemli olan, açık, kullanıcı dostu ekranlar sağlamak, kaynaklar arası kısıtlamaları yönetmek ve kullanıcıların passkey'leri ne kadar etkili bir şekilde benimsediğini gösteren temel metrikleri izlemektir. Aşağıda, en iyi uygulama passkey oluşturma akışının temel yönleri ve Corbado'nun bunları nasıl desteklediği bulunmaktadır:

Bir kullanıcının bir passkey oluşturması için nerede istenirse istensin - bir bankanın çevrimiçi bankacılık ortamı, ödeme sağlayıcısının kendi web sitesi/uygulaması veya bir tüccarın ödemesi olsun - Corbado, kullanıcı istemleri, başarı onayları ve hata işleme için önceden oluşturulmuş, özelleştirilebilir bileşenler sağlar.

Bu bileşenler, her bankanın veya tüccarın gerekirse kendi benzersiz tasarım öğelerini korumasına olanak tanıyan beyaz etiketli markalamaya izin verirken tutarlı bir görünüm ve his sağlar.

VicRoads tasarımında markalanmış passkey oluşturma ekranı için aşağıdaki UI bileşenini görün:

Corbado, tüm oluşturma uç noktalarından verileri toplar ve birleştirir:

• Passkey'lerin başlangıçta sunulduğu banka web siteleri veya uygulamaları.

• Ödeme sağlayıcısının kişisel hesap ayarları (kullanıcıların kimlik bilgilerini yönetebileceği yer).

• İsteğe bağlı olarak “anında” passkey oluşturmaya izin veren tüccar ödeme sayfaları.

Bu birleşik yaklaşım, passkey oluşturma oranını, oluşturma başarı oranını, kullanıcı bırakma noktalarını ve herhangi bir teknik hatayı ölçmeyi kolaylaştırır - passkey kaydını hangi kanal başlatırsa başlatsın.

Corbado, ekran talimatlarını, düğme metnini ve istemlerin zamanlamasını ince ayar yapmak için A/B testi özellikleri sunar. Kelimelerdeki ince değişiklikler (ör. “Şimdi bir passkey oluşturun - artık şifre yok!” vs. “Bir sonraki ödemenizi bir passkey ile güvence altına alın!”) genellikle kullanıcı kabulünde önemli farklılıklar yaratır.

A/B testinin sonuçlarına dayanarak, aşağıdaki KPI'lar optimize edilebilir:

• Oluşturma Oranı: İstendiğinde, başarılı bir şekilde bir passkey kuran kullanıcıların yüzdesi.

• Oluşturma Başarı Oranı: Seremoniyi iptal etmeden veya hata almadan bitiren kullanıcıların payı.

• Yedek Kullanımı: Kullanıcıların eski giriş yöntemleri lehine passkey oluşturmayı atlama oranı.

• Dönüşüm Etkisi: Tüccarlar için, ödemede passkey oluşturmanın sepet terkini azaltıp azaltmadığını ölçün.

Kullanıcılar aşağıdaki bağlamlarda passkey oluşturabilir:

• Banka Bağlamı: Bir kullanıcı bankasına giriş yaptıktan sonra tetiklenen, bankacılık ortamının güvenini ve aşinalığını kullanan oluşturma akışları.

• Ödeme Sağlayıcısı Hesap Ayarları: Kullanıcılar, passkey'leri doğrudan ödeme sağlayıcısının alan adının “Profilim” veya “Güvenlik” ayarlarında kurar.

• Tüccar Ödemesi: Son ödeme adımında, özellikle kullanıcı daha önce bir passkey oluşturmadıysa, istemde bulunun. Bu, gömülü (iframe) veya yönlendirme yoluyla olabilir.

Her senaryoda, temel passkey seremonisi aynı adımları izler - kullanıcı onayı, biyometrik/PIN istemi ve kimlik bilgisi kaydı. Corbado'nun SDK'sı, kaynaklar arası kısıtlamaların (gömülüyse) veya birinci taraf alan adı bağlamının (yönlendirilirse) arka planda sorunsuz bir şekilde ele alınmasını sağlar.

Corbado, her yeni passkey'i uygun kullanıcı tanımlayıcısına - bu “bankaÖneki_kullanıcıId” veya ödeme sağlayıcısının sistemindeki dahili bir kullanıcı referansı olabilir - ekler, böylece sonraki tüm kullanım doğru kullanıcı hesabına kadar izlenebilir.

Bu meta veri, gelişmiş analitik için de çok önemlidir: örneğin, RBC'nin passkey oluşturma kampanyalarının TD'ninkilere kıyasla nasıl performans gösterdiğini veya oluşturma oranlarının tüccar ödemeleri ile doğrudan “hesap ayarları” akışları arasında nasıl farklılaştığını görmek.

Aynı Corbado SDK mantığı, kaynaklar arası passkey oluşturmaya izin verilip verilmediğine (modern Chrome veya Edge'de) veya Safari için zarif bir şekilde bir yönlendirmeye geçilmesi gerekip gerekmediğine uyum sağlayabilir.

Dahili hata raporlaması, herhangi bir kullanıcı alt kümesinin sürekli olarak passkey oluşturmada başarısız olup olmadığını (ör. eski iOS sürümleri, kurumsal Windows cihazları) belirlemeye yardımcı olur, böylece ürün ekibi talimatları veya yedek stratejileri iyileştirebilir.

Ekibimiz, kurumsal müşterilerle kapsamlı passkey oluşturma deneyleri yürüterek hangi ifadelerin, düğme yerleşimlerinin ve zamanlamanın en iyi benimseme oranlarını sağladığını öğrendi.

Bu en iyi uygulamaları her oluşturma ekranına dahil ederken, markalaşma ve uyumluluk ihtiyaçları için tam özelleştirmeye hala izin veriyoruz.

Genel olarak, passkey oluşturma, yüksek benimsemeyi sağlamak için en önemli aşama olarak duruyor: en zarif passkey giriş akışı bile, kullanıcılar ilk başta kimlik bilgilerini hiç kaydetmezse bir anlam ifade etmeyecektir. Corbado, tüm olası kanallarda - banka, ödeme sağlayıcısı alan adı veya tüccar ödemesi - tek tip, izlenebilir oluşturma ekranları sunarak ve bunları KPI analitiği ve A/B testi ile donatarak, ödeme sağlayıcılarının Apple Pay gibi yerel çözümlerin kullanıcı deneyimini yansıtan, gerçekten ölçeklenebilir passkey benimsemesini sağlamasına yardımcı olur.

Bir kullanıcı bir passkey oluşturduktan sonra, bir sonraki adım, Apple Pay'in sunduğu Apple Pay ödeme akışı gibi hızlı, sürtünmesiz ödemeler için o passkey'i gerçekten kullanmalarını sağlamaktır.

Corbado'da, bir kullanıcının ortamının muhtemelen geçerli bir passkey içerdiğini otomatik olarak algılayan ve gerçek bir tek dokunuşla ödeme deneyimi sağlayan bir “Passkey Intelligence” mekanizması geliştirdik. Aşağıda bunu mümkün kılan temel unsurlar bulunmaktadır.

Geri dönen bir kullanıcı tanındığında, Corbado'nun ön ucu, yedek kimlik bilgileri girişini zorlamak yerine özel bir düğme (ör. “Passkey ile Öde”) görüntüler.

Bu düğmeye bir kez dokunmak, WebAuthn get() akışını (veya yerel passkey istemini) tetikler ve kullanıcının biyometri/PIN aracılığıyla anında kimlik doğrulamasına olanak tanır - ek adımlar veya form girişleri gerekmez.

Corbado'nun SDK'sı, mevcut cihaz + tarayıcının bu kullanıcı için muhtemelen geçerli bir passkey'e sahip olup olmadığını tahmin etmek için sinyaller (ör. yerel depolama çerezleri, önceki başarılı passkey kullanımı, ortam tespitleri) toplar.

Çerezler silinmiş veya mevcut değilse, Corbado bir passkey akışını otomatik olarak başlatmanın güvenli olup olmadığına karar vermek için ek sezgisellere (ör. kullanıcının bilinen mevcut ortamı, tüccar tarafından sağlanan kullanıcı ipuçları) geri döner.

Bir passkey'in mevcut olduğunu gösteren yetersiz kanıt varsa, kullanıcı arayüzü zarif bir şekilde yedek akışlar sunar veya kullanıcıdan bir passkey'e sahip olduklarını onaylamasını ister.

Corbado, tam e-postalar veya isimler gibi kişisel olarak tanımlanabilir bilgileri (PII) saklamaz.

Bunun yerine, tüccar karma veya maskelenmiş bir tanımlayıcı (ör. bir e-posta karması veya dahili kullanıcı ID) geçirebilir. Corbado bunu potansiyel passkey kayıtlarını aramak için kullanır, ardından bir passkey kimlik doğrulaması başlatıp başlatmayacağına veya daha genel bir yaklaşıma geri dönüp dönmeyeceğine karar verir. Ödeme sağlayıcısı tarafından destekleniyorsa, dahili kullanıcı ID'sini aramak için tüccar tarafından sağlanan bilgileri arayabiliriz.

Bu, kullanıcı gizliliğini sağlarken hala yüksek doğrulukta ortam eşleştirmesine olanak tanır.

Kullanıcının passkey'inin var olabileceği ancak tespit edilemediği senaryolarda (ör. çerezler silinmiş, yeni cihaz), Corbado'nun Passkey Intelligence'ı bir passkey istemini otomatik olarak başlatmanın mantıklı olup olmadığını dikkatlice analiz eder.

Bunun yerine, kullanıcı alternatif yedek akışlar veya “başka bir cihazdan passkey tara” seçeneği görürken, kullanıcının manuel olarak bir tane olduğunu onaylayabilmesi durumunda passkey kullanımına hızlı bir geri dönüş yolu korunur.

Corbado tek dokunuşla bir passkey istemini başlatmayı veya atlamayı her seçtiğinde, bu karar günlüğe kaydedilir. Zamanla, hangi tarayıcıların veya cihaz türlerinin en yüksek passkey kapsamını sağladığını ve hangilerinin sık sık yedeğe döndüğünü tam olarak görebilirsiniz.

Bu analitik geri bildirim döngüsü, düşük performans gösteren ortamları (ör. belirli iOS veya Android sürümleri) veya passkey kullanımının düşük kaldığı kullanıcı segmentlerini belirlemenize olanak tanır - böylece katılım veya eğitim stratejilerini iyileştirebilirsiniz.

Kullanıcının bir bankanın passkey oluşturma kampanyasından mı yoksa doğrudan bir tüccarın ödemesinden mi geldiğine bakılmaksızın, tek dokunuşla mantığı tutarlı kalır.

Corbado, bir passkey bulunursa (alan adı çerezlerine, yerel depolama belirteçlerine veya passkey intelligence sinyallerine dayanarak), kullanıcının hemen en sürtünmesiz giriş/ödeme akışıyla karşılanmasını sağlar.

Özet

Kısacası, tek dokunuşla passkey kullanımı, ilk etapta passkey oluşturmanın nihai karşılığıdır. Passkey Intelligence'ı - ortam tespiti, minimum PII kullanımı ve yedek mantığının bir karışımı - kullanarak Corbado, kullanıcıların yalnızca gerçekten başarılı olma olasılığı yüksek olduğunda passkey kimlik doğrulamasıyla karşılaşmasını sağlar. Bu, başarısız denemeleri önemli ölçüde azaltır, kullanıcı hayal kırıklığını önler ve alışkanlık oluşturan passkey kullanımını teşvik eder, bu da Apple Pay veya diğer yerel ödeme deneyimlerinin rahatlığına rakip olan tek dokunuşla bir ödeme akışıyla sonuçlanır.

Passkey'leri etkinleştirmenin ötesinde, farklı cihazlar, tarayıcılar ve kullanıcı yolculukları arasında ne kadar etkili bir şekilde benimsendiklerini ve kullanıldıklarını anlamak çok önemlidir. Ödeme sağlayıcıları, passkey'lerin sürtünmeyi gerçekten azaltıp azaltmadığı, dolandırıcılığı kesip kesmediği ve dönüşümü iyileştirip iyileştirmediği konusunda somut verilere ihtiyaç duyar. Passkey Satın Al vs. Kendin Yap Kılavuzu en iyi uygulamalarından yararlanarak Corbado, passkey performansını gerçek zamanlı olarak izlemenize, segmentlere ayırmanıza ve optimize etmenize olanak tanıyan zengin bir analitik katmanı sunar.

Aşağıda temel öne çıkanlar bulunmaktadır.

Corbado, tüm passkey olaylarını bir huni içinde düzenler: bir kullanıcının bir passkey oluşturması istendiği andan, başarılı kayda, sonraki girişlere/ödemelere (passkey kullanımı) kadar.

Bu huni görselleştirmesi, kullanıcıların nerede bıraktığını görmenizi sağlar - ör. kaç tanesinin oluşturmaya hiç başlamadığını, kaç tanesinin seremoni ortasında terk ettiğini veya kaç tanesinin girişte yedek yöntemlere geri döndüğünü.

Kurumsal şirketlerin passkey'leri uygulamasına yardımcı olma konusundaki kapsamlı deneyimimize dayanarak, doğrudan yatırım getirisi ve kullanıcı memnuniyetini etkileyen metriklere odaklanıyoruz:

• Passkey Kabul Oranı: Bir oluşturma istemi gören kullanıcıların kaçı passkey kaydını gerçekten tamamlıyor?

• Passkey Oluşturma Başarı Oranı: Seremoniyi başlatanlardan (“Passkey Oluştur”a tıklayanlar), yüzde kaçı hata veya terk etmeden tamamlıyor?

• Passkey Kullanım Oranı: Geri dönen kullanıcılar, günlük kimlik doğrulama veya ödeme için şifreler veya OTP yerine ne sıklıkla passkey'leri seçiyor?

• Passkey Giriş Başarı Oranı: Yedekleme veya kullanıcı hayal kırıklığı olmadan başarılı olan passkey denemelerinin yüzdesi.

• Yedek Kullanımı: Kaç kullanıcı bir passkey akışı başlatır ancak eski yöntemlere geri döner? Bu, potansiyel kullanıcı deneyimi veya teknik engelleri işaret eder.

Corbado, her olayı işletim sistemi (Windows, macOS, iOS, Android) ve tarayıcı (Chrome, Safari, Edge, Firefox, vb.) ile otomatik olarak etiketler.

Bu segmentasyonla, örneğin iOS Safari'nin daha yüksek bir passkey terk oranına sahip olup olmadığını veya Windows Chrome'un daha iyi passkey benimsemesi sağlayıp sağlamadığını görebilirsiniz.

Bu veriler ayrıca yedek stratejilerinizi ince ayar yapmanıza yardımcı olur - özellikle Apple'ın kaynaklar arası kısıtlamaları kullanıcı tabanınızı beklenenden daha fazla etkiliyorsa.

Passkey hunisinin her aşaması için pano görünümleri sağlıyoruz: oluşturma istemleri, başarılı kayıtlar, kullanıcı girişleri, yedek kullanımı.

Gerçek zamanlı grafikler, ürün yöneticilerinin trendleri hızla fark etmesini sağlar (ör. yeni bir işletim sistemi güncellemesi passkey akışlarını bozarsa).

Otomatik uyarılar, passkey başarı oranları önemli ölçüde düşerse ekibinizi bilgilendirebilir - böylece yeni bir tarayıcı hatasını veya yapılandırma sorununu derhal araştırabilirsiniz.

Her passkey akışı (oluşturmadan girişe kadar) zaman damgalı adım adım olaylarla günlüğe kaydedilir ve derin adli analize olanak tanır.

Bir kullanıcının nerede zorlandığını veya hangi hata kodunun döndürüldüğünü tam olarak görmek için kullanıcı karması, oturum ID'si veya cihaz imzası ile hızlıca arama yapabilirsiniz.

Bu, büyük ölçekli lansmanlar için kritiktir, burada anekdot niteliğindeki destek biletlerine güvenemezsiniz, ancak kullanıcı sorunlarını çözmek için kesin verilere ihtiyacınız vardır.

Corbado'nun analitik platformu, passkey hunisine entegre edilmiş A/B testini destekler: ödeme akışında farklı CTA metinlerini, oluşturma istemlerini, yedek mesajlarını veya “Passkey Oluştur” düğmelerinin yerleşimini test edin.

“Passkey Kabul Oranı” veya “Yedek Oranı” gibi metrikler her varyant için yan yana ölçülebilir.

Bu yaklaşım, akışları zamanla iyileştiren önde gelen passkey benimseyenlerinin başarısını yansıtarak sürekli iyileştirme sağlar.

Corbado'nun panoları kullanıma hazır bir görsel arayüz sağlarken, anahtar veri noktalarını (ör. passkey oluşturma başarısı, girişler) BI veya SIEM araçlarınıza dışa aktarabilir veya webhook ile gönderebilirsiniz.

Bu, ödeme sağlayıcılarının passkey KPI'larını daha geniş analitik paketlerine dahil etmelerine olanak tanır - passkey'lerden elde edilen yatırım getirisini diğer güvenlik, pazarlama veya operasyonel metriklerle birlikte izleyerek.

Özet

Passkey yolculuğunun her adımını - işletim sistemi/tarayıcı kombinasyonları, oluşturma akışları ve giriş senaryoları arasında - ölçerek ve görselleştirerek Corbado, passkey teklifinizi sürekli olarak iyileştirmek için gereken bilgileri size verir. Bu analitikler sadece passkey'lerin etkinleştirildiğini doğrulamakla kalmaz; kullanıcıların bunları gerçekten ölçekte benimseyip benimsemediğini kanıtlar, sürtünme noktalarını belirler ve kullanım oranlarını passkey'lerin güvenli, sürtünmesiz ödemeler için şifrelerin yerini gerçekten aldığı noktaya kadar artırmanıza yardımcı olur.

Ödeme sağlayıcıları için, kullanıcı başına yalnızca bir passkey oluşturmak, gerçekten sorunsuz bir kimlik doğrulama deneyimi sunmak için genellikle yeterli değildir. Gerçekte, kullanıcılar sık sık cihaz değiştirir - işteki dizüstü bilgisayarlardan kişisel akıllı telefonlara, tabletlere ve hatta paylaşılan aile bilgisayarlarına kadar. Her cihazın aynı hesap için geçerli bir passkey'e sahip olmasını sağlamak, sürtünmeyi azaltmak ve şifrelere geri dönmeyi önlemek için kritik öneme sahiptir. Apple Pay bunu, iCloud'a bağlı tüm cihazlarda iCloud Hesabından yararlanarak başarır.

Aşağıda, Corbado'nun kullanıcı yaşam döngüsü boyunca çoklu cihaz kapsamını korumaya nasıl yardımcı olduğu anlatılmaktadır.

• Birincil Passkey Oluşturma Ekranları: Corbado başlangıçta her kullanıcının en az bir passkey - “birincil” passkey - kaydetmesine odaklanır, ödeme akışınızla ilk karşılaştıkları yerde (ör. ödemede, bir bankanın çevrimiçi portalında veya hesap ayarlarınızda).

• İkincil Passkey Oluşturma Ekranları: Bir kullanıcı ilk passkey'ini başarıyla kaydettikten sonra, diğer cihazlardaki sonraki girişler otomatik olarak kısa bir “Bu cihazı ekle” akışını tetikleyebilir. Bu, kullanıcının şifre girmeden veya yedek yöntemlere geçmeden ilgili tüm cihazlarda hızla sürtünmesiz passkey erişimi kazanmasını sağlar.

Bir kullanıcının bir cihazda passkey'i olsa bile, ikinci bir cihazda yerel passkey olmadan görünebilir (yeni işletim sistemi kurulumları, çerez silinmeleri veya o cihazda hiç passkey oluşturmamış olmaları nedeniyle).

Corbado'nun yaklaşımı genellikle hibrit bir adım kullanır: kullanıcı telefonundaki mevcut bir passkey veya bir yedek yöntemle giriş yapabilir, ardından mevcut cihazda bir passkey oluşturarak boşluğu anında “iyileştirebilir”.

Bu kendi kendini onarma süreci, kapsamın yüksek kalmasına yardımcı olur ve gelecekte tekrarlanan yedek kullanımını ortadan kaldırır.

Cihazlar arası sinyaller ve Corbado'nun “Passkey Intelligence”ı aracılığıyla, sistem mevcut bir passkey'e sahip bir kullanıcının kayıtsız bir cihaza geçtiğini tespit edebilir.

Kullanıcı deneyimi stratejiniz maksimum kapsamı hedefliyorsa, Corbado otomatik olarak şunu sorabilir: “Bir dahaki sefere yedeklemek zorunda kalmamak için bu cihaza bir passkey eklemek ister misiniz?”

Kullanıcılar tek seferlik bir cihazdaysa bunu atlayabilir, ancak genellikle açıklandığında passkey tabanlı biyometrik girişin rahatlığını takdir ederler.

Corbado'nun SDK'sı, “ilk passkey oluşturma” (yani, kullanıcının bir kimlik bilgisini ilk kez kaydetmesi) ve “ikincil cihaz” oluşturma için ayrı ekran akışları sağlar.

Mesajlaşma farklı olabilir: ör. “Bu yeni cihazı bir passkey ile güvence altına alın” vs. “İlk passkey'inizi kurun.”

Bu, ilk kayıt ile ek cihazlara kapsamı genişletme arasındaki farkı anlayan son kullanıcılar için netlik sağlar.

Bazen passkey oluşturma seremoni ortasında başarısız olabilir veya kullanıcının işletim sistemi güncel olmayabilir. Bu senaryolarda, Corbado kısmi denemeyi kaydeder ve zarif bir şekilde olası çözümleri önerir (yönlendirme, manuel yedekleme veya cihazlar arası QR akışı).

Kullanıcı bir sonraki giriş denemesinde o cihazda bir passkey eklemeyi her zaman yeniden deneyebilir veya başka bir cihazdan mevcut bir passkey'e güvenebilir.

Corbado'nun analitiği, yalnızca başlangıçta kaç kullanıcının bir passkey oluşturduğunu değil, aynı zamanda kaç tanesinin passkey'leri birden fazla cihaza genişlettiğini de gösterir.

Cihaz kapsam oranlarını (ör. 1 cihaz vs. 2 veya daha fazla) izleyebilir ve bunun azaltılmış yedek kullanımı veya iyileştirilmiş ödeme başarısı ile nasıl ilişkili olduğunu görebilirsiniz.

Bu, ekibinizin çoklu cihaz passkey penetrasyonunu artırmak için kullanıcı eğitimi, uygulama istemleri veya banka tabanlı kayıt akışlarına öncelik vermesine yardımcı olur.

Özet: Çoklu Cihaz Kapsamı Neden Önemlidir?

Tüm kullanıcı cihazlarında tutarlı bir kapsam olmadan, kullanıcıların “passkey olmayan” bir cihazda olduklarında yedek kimlik doğrulama önlemlerine geri dönmeye zorlanma riskiyle karşı karşıya kalırsınız. Bu, sürtünmesiz deneyimi bozar ve operasyonel maliyetleri yüksek tutar (ör. SMS ücretleri, destek ek yükü). Corbado, ikincil passkey oluşturma ekranları, hibrit yedek iyileştirme ve ortama dayalı istemler sunarak, her kullanıcının sonunda kullandıkları tüm cihazlarda passkey'leri sürdürebilmesini sağlar - bu da genel olarak daha yüksek benimseme sağlar ve bu sinir bozucu yedek anlarını en aza indirir.

Üçüncü taraf bir passkey SDK'sı oluştururken en büyük yanılgılardan biri, en zor kısmın WebAuthn çağrılarını (navigator.credentials.create() veya navigator.credentials.get() gibi) uygulamak olduğudur.

Gerçekte, bu “kolay” kısımdır - temel seremoniyi tetiklemek için bir veya iki API çağrısı. Gerçek karmaşıklık ve başarının gerçek belirleyicisi, büyük ölçekli benimsemeyi sağlamak ve bu API çağrıları etrafında tam bir ekosistem oluşturmaktır.

Passkey Satın Al vs. Kendin Yap Kılavuzu tarafından da desteklenen aşağıdaki temel noktalar, minimal, yalnızca seremoniye odaklı uygulamaların neden genellikle gerçek dünya sonuçları vermediğini vurgulamaktadır.

• Seremoni Uygulaması: Bir passkey oluşturmak veya doğrulamak genellikle navigator.credentials.create() veya navigator.credentials.get() çağırmak için sadece birkaç satır JavaScript içerir.

• Gerçek Karmaşıklık: Passkey akışının birçok tarayıcıda çalışmasını sağlamak, hataları zarif bir şekilde ele almak ve eski sistemler için yedekleme sunmak. Ayrıca sağlam oturum yönetimi, hata günlüğü, analitik, cihaz kapsam stratejileri ve daha fazlasına ihtiyacınız olacak.

• Öngörülemeyen Tuzaklar: Passkey'lerin bir “teknik demosunun” ötesine geçtiğinizde, kaynaklar arası engellemeler, gömülü WebView kısıtlamaları ve çoklu cihaz senkronizasyon karmaşıklıkları gibi uç durumları keşfedersiniz. Bunlar, saf şirket içi yapıları raydan çıkaran bilinmeyen bilinmeyenlerdir.

• Seremoni vs. Benimseme: Mükemmel bir WebAuthn seremoniniz olsa bile, düşük kullanıcı benimsemesi (ör. <%5 passkey kullanım oranı) minimum güvenlik veya kullanıcı deneyimi faydası sağlayacaktır.

• Bütünsel Yaklaşım: Başarılı bir passkey lansmanı, ilgi çekici kullanıcı istemlerinden ve A/B test edilmiş metinlerden çoklu cihaz kapsam akışlarına, yedekleme yönetimine ve sürekli analitiğe kadar her şeyi gerektirir - temel seremoni çağrılarının çok ötesinde.

• Satın Al vs. Kendin Yap Kılavuzundan Alınan Bilgiler: Kılavuz, sadece passkey'leri etkinleştirmenin değil, passkey benimsemesini sağlamanın nihayetinde yatırım getirisini belirlediğini vurgular. Kullanıcılar kaydolmaz ve aktif olarak passkey kullanmazsa, proje etkili bir şekilde “MFA 2.0”da dönüşüm oranı iyileşmesi olmadan durmuş demektir.

• Eksik Yedekleme ve Hata İşleme: Gelişmiş yedekleme mantığının veya gerçek zamanlı hata ayıklamanın olmaması, kullanıcı kilitlenmelerine ve daha yüksek destek maliyetlerine yol açabilir.

• Parçalanmış Çoklu Cihaz Kapsamı: Ek cihazları senkronize etme veya passkey boşluklarını “iyileştirme” planı olmadan, kullanıcılar platform değiştirdiklerinde şifrelere geri dönerler.

• Sınırlı Analitik ve A/B Testi: Passkey oluşturma hunileri veya ortam kullanımı hakkında veri eksikliği, benimsemeyi sistematik olarak iyileştiremeyeceğiniz veya yeni tarayıcı tuhaflıklarını hızla gideremeyeceğiniz anlamına gelir.

• Önceden Oluşturulmuş UI ve En İyi Uygulamalar: Sadece seremoni uç noktalarını ortaya çıkarmak yerine, uygun bir çözüm (Corbado gibi) beyaz etiketli ekranlar, yedekleme akışları, hata işleme ve cihazlar arası kapsamı bir araya getirir.

• Uyarlanabilir Zeka ve Günlük Kaydı: Muhtemel passkey varlığını otomatik olarak algılama, kullanıcıları eksik passkey'leri oluşturmaya veya düzeltmeye yönlendirme ve ayrıntılı olay günlüklerini yakalama.

• Benimseme Odaklı “Bilinmeyen Bilinmeyenler”: E-posta tabanlı yedekleme veya kurumsal cihazların nasıl ele alınacağı gibi birçok ayrıntı, kullanıcılar gerçek dağıtımlarda onlarla karşılaşmaya başlayana kadar belirgin değildir.

• Benimseme Stratejisine Daha Derin Bir Bakış: Passkey Satın Al vs. Kendin Yap Kılavuzu, maliyet, pazara çıkış süresi ve sağlam bir passkey çözümünün gizli karmaşıklıklarını nasıl dengeleyeceğinizi vurgular.

• Gerçek Dünya Karşılaştırmaları: Büyük bankaların ve e-ticaret sağlayıcılarının büyük ölçekli lansmanlarının, “basit” seremoni mantığını kodladıktan sonra ortaya çıkan bilinmeyen bilinmeyenlerin üstesinden nasıl geldiğini öğrenin.

• Sürdürülebilir Başarı: Kanıtlanmış benimseme kalıplarına sahip yerleşik bir platforma yatırım yapmak, tekerleği yeniden icat etmekle ve yol boyunca maliyetli sürprizler keşfetmekle uğraşmamanızı sağlar.

Özetle

Sadece WebAuthn seremonisini bağlamak, anlamlı bir passkey benimsemesi elde etmek için yeterli değildir. Gerçek başarı, yedeklemeler, analitik, çoklu cihaz genişletmeleri ve A/B test edilmiş kullanıcı yolculukları gibi uçtan uca akışları düzenlemeye bağlıdır. “Sadece seremoni”nin ötesindeki incelikli karmaşıklıkları ele alarak, passkey projenizi teknik bir meraktan gerçekten sürtünmesiz, yaygın olarak kullanılan ve maliyet tasarrufu sağlayan bir kimlik doğrulama çözümüne dönüştürebilirsiniz.

Kaynaklar arası akışlar, kullanıcı benimsemesi ve passkey yaşam döngüsü yönetimi etrafındaki karmaşıklıklara ek olarak, barındırma ve dağıtım hususları herhangi bir büyük ölçekli passkey çözümü için kritiktir. Ödeme sağlayıcıları genellikle bölgeler arasında önemli ölçüde değişebilen katı uyumluluk, veri yerleşimi talepleri ve dayanıklılık gereksinimleriyle uğraşır. Aşağıda, Corbado'nun (veya benzer şekilde sağlam çözümlerin) bu endişeleri nasıl ele aldığı anlatılmaktadır:

Veri egemenliği veya düzenleyici çerçevelere (ör. Avrupa'da GDPR, Kanada'da PIPEDA veya Amerika Birleşik Devletleri'nde NIST/HIPAA) uymak için, bazı sağlayıcılar verileri belirli coğrafi sınırlar içinde tutmalıdır.

Bölgeden bağımsız bir mimari, passkey hizmetinin istenen herhangi bir AWS bölgesinde dağıtılabilmesini sağlar ve performanstan veya ölçeklenebilirlikten ödün vermeden yerel uyumluluk yetkilerini karşılar.

Bu esneklik, kullanıcı tabanınız her biri farklı veri işleme kuralları uygulayan birden fazla ülkeyi kapsıyorsa özellikle önemlidir.

Kritik ödeme kimlik doğrulama akışları için kesinti bir seçenek değildir. Corbado, anahtar bileşenleri birden fazla kullanılabilirlik alanına dağıtan çoklu AZ dağıtımlarını kullanır.

Bu kurulum, bir AZ bir kesinti veya bağlantı sorunu yaşarsa, diğer bölgelerdeki passkey altyapınızın çevrimiçi kalmasını sağlamaya yardımcı olur - böylece kullanıcılar kimlik doğrulamaya devam edebilir.

Sonuç, finansal hizmetler ve e-ticaret siteleri için katı SLA'ları karşılayan daha dayanıklı bir sistemdir, burada kısa bir kesinti bile önemli gelir etkisine yol açabilir.

Bazı ödeme sağlayıcıları, daha sıkı veri yalıtımı, özel uyumluluk kontrolleri veya yamalar ve güncellemeler üzerinde daha derin kontrol için özel bir küme tercih eder.

Esnek bir çözüm her iki ucu da destekleyebilir:

• SaaS / Çok Kiracılı: Hızlı uygulanır, daha düşük maliyetli, birçok orta ölçekli dağıtım için çok uygundur.

• Özel Bulut Örneği: Seçtiğiniz bölgede ayrı bir hesap ve veritabanı örneği, ek yalıtım veya uyumluluk ihtiyacı olanlar için.

Passkey'ler ani iş yüklerini yönetmelidir: büyük trafik artışları (ör. tatil alışverişi zirveleri veya etkinlik bileti satışları) sabit kapasiteli sistemleri bunaltabilir.

Modern bir passkey arka ucu, kullanım modellerine göre hesaplama örnekleri ekleyerek veya kaldırarak gerçek zamanlı olarak yatay olarak ölçeklenir. Bu otomatik ölçeklendirme, manuel müdahale olmadan tutarlı performans sağlar.

PCI-DSS, PSD2 SCA veya ISO 27001 gibi endüstri standartları genellikle ödeme sağlayıcıları için geçerlidir. Sağlam bir passkey sağlayıcısı genellikle bilinen uyumluluk çerçeveleriyle kutudan çıktığı gibi entegre olur:

• Beklemede ve Aktarımda Şifreleme: Depolanan kimlik bilgileri için güçlü TLS ve sunucu tarafı veya istemci tarafı şifreleme ile verileri güvence altına alın.

• Günlük Kaydı ve Denetim İzleri: Düzenleyiciler veya olay incelemeleri için uygun, her passkey işlemi için ayrıntılı günlükler.

• Düzenli Güvenlik Yaması: Özellikle akışkan bir çoklu AZ ortamında ilgili olan güvenlik açıklarını uzak tutmak için otomatik işletim sistemi ve konteyner yaması.

Gerçek dayanıklılık tek bir bölgenin ötesine uzanır. Bazı sağlayıcılar, büyük ölçekli felaketler sırasında iş sürekliliğini sürdürmek için bölgeler arası çoğaltmayı zorunlu kılar.

Coğrafi yedeklilik, passkey verilerini farklı bir bölgede veya kıtada çoğaltabilir ve tüm bir bölgenin kesintisinin kimlik doğrulama akışlarını durdurmamasını sağlar.

Özet: Multi-AZ ve Bölgeden Bağımsız

Kolayca ölçeklenen, coğrafi olarak uyum sağlayan ve hem yerel kesintilere hem de büyük ölçekli felaketlere direnen bir passkey çözümü seçmek, modern ödeme sağlayıcıları için - özellikle birden fazla ülkede veya katı uyumluluk altında faaliyet gösterenler için - esastır. Corbado (veya karşılaştırılabilir çözümler), çoklu AZ dağıtımlarını ve bölgeden bağımsız yapılandırmaları destekleyerek, ödeme passkey hizmetlerinin kullanıcılarınız veya verileriniz nerede olursa olsun hem kullanılabilir hem de uyumlu kalmasını sağlar.

Passkey'ler gerçekten de güvenli, kullanıcı dostu kimlik doğrulamanın yeni neslini temsil ediyor. Yine de, ödeme sağlayıcıları geleneksel WebAuthn tasarımının doğrudan ele almadığı benzersiz zorluklarla karşı karşıyadır. Bu sınırlamalar en çok şunlarda belirgindir:

1. Safari'nin kaynaklar arası passkey oluşturmaya (özellikle iframe'lerde) izin vermeyi reddetmesi, ya yönlendirme tabanlı bir yaklaşımı ya da daha önce oluşturulmuş passkey'lere güvenmeyi zorunlu kılması.

2. Apple'ın Güvenli Ödeme Onayı (SPC) desteğinin olmaması, tarayıcılar ve platformlar arasında sürtünmesiz, standartlaştırılmış bir ödeme akışını engellemesi.

Yine de, passkey'ler Apple Pay benzeri bir ödeme deneyimi sunmak isteyen ödeme sağlayıcıları için hala esastır: kolaylaştırılmış, güvenli ve son kullanıcılar için keyifli derecede basit. Aşağıda bu zorlukların nasıl aşılabileceği ve Corbado'nun nasıl yardımcı olduğu anlatılmaktadır.

1. Ödeme sağlayıcıları için üçüncü taraf bağlamlarında passkey kullanmanın mevcut sınırlamaları nelerdir?

• Kaynaklar Arası Kısıtlamalar: Safari (ve bazı eski tarayıcılar) bir iframe aracılığıyla gömüldüğünde navigator.credentials.create()'i engeller. Bu, bu tarayıcılarda tüccara gömülü bir akışta sorunsuz bir şekilde yeni passkey'ler oluşturamayacağınız anlamına gelir.

• Eksik SPC Desteği: Apple'ın SPC'yi benimsemeyi reddetmesi, kaynaklar arası ödeme onaylarını standartlaştırma yeteneğini sınırlar ve sağlayıcıları Safari ile Chrome/Edge için ayrı yaklaşımlar sürdürmeye zorlar.

• WebView ve Yerel Uygulama Kısıtlamaları: Gömülü WebView'ler genellikle passkey akışlarını bozar ve alan adı kaynak hizalamasını yönetmek için sistem tarayıcı oturumları veya diğer özel yaklaşımlar gerektirir.

• Parçalanmış Cihaz Kapsamı: Kullanıcı bir cihazda veya tarayıcıda bir passkey oluştursa bile, diğerlerinde kapsama sahip olmayabilir, bu da yedek kullanımına neden olur.

2. Ödeme sağlayıcıları, üçüncü taraf passkey entegrasyonlarını başarıyla uygulamak için bu sınırlamaların üstesinden nasıl gelebilir?

• Hibrit (Iframe + Yönlendirme) Stratejisinden Yararlanın:

  • Kaynaklar arası passkey'leri tam olarak destekleyen tarayıcılar için iframe, sorunsuz bir gömülü kullanıcı arayüzü sunar.

  • Safari veya uyumsuz kurulumlar için bir yedek olarak yönlendirme, sağlam passkey oluşturmanın her zaman mümkün olmasını sağlar.

• Yerel Uygulamalarda Sistem WebView veya Tarayıcı Yönlendirmesi:

  • Tüccar uygulamalarına iframe gömmek yerine, alan adı sürekliliğini korumak için ASWebAuthenticationSession (iOS) veya Chrome Custom Tabs'a (Android) geçin.

  • Benimseme Odaklı Araç Seti: Kullanım oranını yüksek tutmak için ilgi çekici passkey oluşturma istemleri, çoklu cihaz kapsam akışları ve yedek “iyileştirme” adımları sağlayın.

  • Gelişmiş Analitik ve A/B Testi:

    • Akışlarınızı iyileştirmek için passkey başarı/yedek oranlarını, ortam kapsamını ve kullanıcı geri bildirimlerini sürekli olarak ölçün.

    • Başarının muhtemel olduğu durumlarda passkey'leri otomatik olarak sunmak için passkey zekasını kullanın.

Bu kılavuz boyunca, sadece navigator.credentials.create()'i bağlamanın yeterli olmadığını vurguladık. Gerçek başarı, yüksek passkey benimsemesine, tutarlı kullanıcı deneyimine ve dayanıklı çoklu cihaz kapsamına bağlıdır. İşte Corbado'nun öne çıktığı yer burasıdır:

• Iframe ve Yönlendirme için Birleşik Destek: Corbado'nun SDK'sı, gömülü bir passkey akışının mümkün olup olmadığını (ör. Chrome veya Edge'de) veya bir yönlendirmenin gerekli olup olmadığını (ör. Safari) otomatik olarak algılar. Bu, tüccarların birden fazla kod yolu sürdürmesini gerektirmeden uyumluluğu en üst düzeye çıkarır.

  • Tek Dokunuşla Ödeme Deneyimi: Passkey Intelligence ile Corbado, bir kullanıcının ortamının muhtemelen geçerli bir passkey'e sahip olup olmadığını anında algılar - sürtünmesiz bir “passkey ile öde” akışını tetikler. Bu yaklaşım, Apple Pay'in tek dokunuşla ödemesine paraleldir ve nadiren kullanılan bir MFA adımı olarak kalmak yerine günlük passkey kullanımını artırır.

  • Sağlam Çoklu Cihaz Kapsamı: Corbado, ilk passkey oluşturma ile ikincil passkey genişletmeleri için özel akışlar sağlar, böylece her kullanıcı yedekleme veya cihazlar arası QR ile giriş yaptıktan sonra yeni cihazlar için hızla kapsam ekleyebilir.

  • Tam Yığın Benimseme Odağı: Entegre analitik, A/B testi ve hata işleme yoluyla Corbado, sağlayıcıların sürtünme noktalarını belirlemesine ve passkey kabulünü sistematik olarak optimize etmesine yardımcı olur. Bu, bankaların ilk passkey istemlerinden tüccarların ödeme deneyimlerine kadar uzanır.

  • Esnek, Uyumlu Barındırma: Corbado'nun çoklu AZ, bölgeden bağımsız dağıtımları, katı ödeme endüstrisi uyumluluğu (PCI DSS, PSD2 SCA, vb.) ile uyumludur ve dünya çapında çalışma süresi ve veri yerleşimi kurallarına bağlılığı sağlar.

Apple'ın kısıtlayıcı politikaları kaçınılmaz sürtünme yaratsa da, ödeme sağlayıcıları yine de üçüncü taraf passkey'leri başarıyla uygulayabilir:

1. Gömülü yaklaşımı (iframe) yönlendirme yedeği ile birleştirerek.

2. Yerel uygulamalar için özel sistem webview'lerini veya harici tarayıcı akışlarını benimseyerek.

3. Sağlam benimseme stratejilerine odaklanarak: çoklu cihaz kapsamı, yedek “iyileştirme”, gelişmiş analitik ve A/B testi.

Corbado tüm bu unsurları bir araya getirerek, passkey kaydını, tek dokunuşla kullanımı, analitik odaklı optimizasyonu ve küresel ölçekte barındırmayı kapsayan kurumsal bir passkey platformu sunar. Sonuç: kendi ödeme hizmetiniz için Apple Pay gibi gerçekten sürtünmesiz bir deneyim, hem artırılmış güvenlik hem de üstün bir kullanıcı yolculuğu sunar.