Dijital Kimlik Bilgileri ve Ödemeler: Apple ve Google Cüzdan Stratejisi

Dijital ödemeler sürekli değişiyor. Daha hızlı, daha güvenli ve daha kolay kullanılabilir olmalarını istiyoruz. Aynı zamanda, Doğrulanabilir Kimlik Bilgileri (VC'ler) ve mobil kimlik belgeleri (mdoc'lar) gibi dijital kimlik araçları da gelişiyor. Bu araçlar, insanların kim olduklarını göstermeleri için yeni yollar sunuyor. Peki, asıl soru şu: Bu yeni dijital kimlikler, dijital ödemeleri de çok daha iyi veya daha basit hale getirebilir mi?

Bu makale, dijital kimlik bilgilerinin (ISO mdoc'ları ve OpenID4VC kullanılarak gönderilen VC'ler dahil) ödemeler dünyasıyla nasıl bağlantı kurduğunu inceliyor. Ele alacağımız konular:

• Mevcut telefon cüzdanlarının (Apple Wallet, Google Wallet) kimlik bilgilerini ödeme kartlarına kıyasla nasıl işlediği.
• ISO 18013-5/7 mdoc'ları gibi mevcut dijital kimlik standartlarının neden doğrudan ödeme araçları olarak pek uygun olmadığı.
• OpenID4VC gibi protokollerin gelecekteki ödeme yöntemlerinde ne gibi bir rol oynayabileceği.
• Diğer (üçüncü taraf) cüzdan uygulamalarının ödeme özelliklerini nasıl ele alabileceği.
• Doğrulanabilir kimlik bilgilerini ödeme sistemlerinde kullanmaya çalışırken karşılaşılan temel sorunlar ve gelecekte neler olabileceği.

Bu metin, yalnızca ödemelere odaklanarak Dijital Kimlik Bilgileri ve Passkey'ler üzerine olan diğer tartışmamızı tamamlıyor.

Dijital kimlik bilgilerinin ödemelerde nasıl kullanılabileceğini görmek için öncelikle günümüzün ana mobil platformlarının ve yerleşik cüzdanlarının (Apple Wallet, Google Wallet) kimlik bilgilerini ödemelerin işlenme şeklinden nasıl ayrı tuttuğunu anlamamız gerekiyor.

Native platform cüzdanları, kullanıcılar için gelişmiş merkezler haline geldi, ancak genellikle kimlik bilgileri ile ödeme araçları arasında net bir ayrım yaparlar:

• Kimlik Bilgileri (ör. mDL'ler):
  • Apple Wallet: Öncelikle ISO/IEC 18013-5 uyumlu mobil sürücü belgelerini (mDL'ler) ve eyalet kimliklerini destekler. WWDC25 itibarıyla Apple, Safari 26'nın (iOS 26'da) çevrimiçi sunum için W3C Dijital Kimlik Bilgileri API'sini destekleyeceğini ve yalnızca org.iso.mdoc protokolüne odaklanacağını doğruladı. Bu, ödemeler için değil, kimlik özelliklerini (ör. ad, yaş, adres) doğrulamak içindir.
  • Google Wallet ve Android Credential Manager: Google Wallet da ISO 18013-5 tabanlı mDL'leri destekler. Altta yatan Android Credential Manager daha esnek bir çerçeve sunar. Dijital Kimlik Bilgileri API'sinin uygulanması protokolden bağımsız olsa da, Android taşıma mekanizması olarak OpenID4VP kullanan varsayılan bir uygulama sağlar.
• Ödeme Araçları (ör. Kredi/Banka Kartları):
  • Hem Apple Pay (Apple Wallet içinde) hem de Google Pay (Google Wallet içinde), yerleşik ve sıkı bir şekilde düzenlenmiş ödeme teknolojilerini kullanır. Bunlar öncelikle EMV (Europay, Mastercard, Visa) standartlarına dayanır ve tokenizasyon (işlemler için gerçek kart numaralarının yerini alan Cihaz PAN'ları veya DPAN'lar), ödeme token'larını saklamak için güvenli öğeler veya donanım destekli güvenlik ve işlem güvenliği için dinamik kriptogramlar içerir.
  • Bu ödeme sistemleri, mevcut ödeme ağları (Visa, Mastercard, Amex vb.) ve edinen bankalarla doğrudan etkileşime girer.

Önemli Çıkarım: Native platform cüzdanları şu anda kimlik bilgileri ve ödeme kartları için ayrı "yığınlar" veya teknolojilerle çalışmaktadır. Bir mdoc, bir kimlik özelliğini kanıtlamak için sunulur; token'laştırılmış bir kart ise bir ödeme yapmak için sunulur. Bu native ekosistemlerde bir mdoc'un bir ödeme aracı olarak doğrudan kullanımı yoktur.

ISO/IEC 18013-5 standardı, mDL'ler ve diğer mobil kimlikler (mdoc'lar) için veri yapısını tanımlar. Kimlik doğrulaması için mükemmel olsa da, tasarımı doğrudan bir ödeme aracı olarak kullanıma uygun değildir:

Bir mdoc'a teorik olarak bir PAN veya bir ödeme token'ı tutmak için özel veri alanları eklenebilse bile (ISO 18013-5 özel ad alanlarına izin verdiği için), mdoc standardının kendisi şunları tanımlamaz:

• Dinamik ödeme kriptogramlarının nasıl oluşturulacağı veya işleneceği.
• Bir ödeme ağıyla çevrimiçi yetkilendirmenin nasıl yapılacağı.
• Ödeme işlemlerine özgü gerekli güvenlik mekanizmaları (kimlik verisi bütünlüğünün ötesinde).

Bu nedenle, şu anda ISO 18013-5 mdoc'unu doğrudan bir ödeme aracı olarak kullanmanın bir yolu yoktur.

Bir mdoc bir ödeme aracı olmasa da, bir kullanıcının kimliğinin yüksek riskli bir eylem için açıkça doğrulanması gereken bir "step-up authentication" akışında rol oynayabilir. Bu, ödemeyi gerçekleştirmek için kullanılmasından farklıdır. Akış tipik olarak şöyle görünür:

1. Birincil Kimlik Doğrulama: Kullanıcı, genellikle bir passkey gibi düşük sürtünmeli bir yöntemle bir hizmete giriş yapar.
2. Step-Up Tetikleyicisi: Yüksek güvenceli bir eylem için (ör. büyük bir banka havalesi, kişisel bilgileri güncelleme), hizmet açık bir kimlik kontrolü gerektirir.
3. mdoc Sunumu: Hizmet, kullanıcının mdoc'unun (ör. sürücü belgesi) bir sunumunu talep eder. Kullanıcı, cüzdanından gerekli özellikleri sunar.
4. Doğrulama: Hizmet, mdoc verilerini güvenilir bir kaynağa veya daha önce kaydedilmiş bir kimliğe karşı kriptografik olarak doğrular.

Bu modelde mdoc, belirli, yüksek riskli bir an için güçlü, phishing dirençli bir kimlik kanıtı sağlar. Ancak, ardından gelen finansal işlem yine de yerleşik ödeme raylarını kullanır. mdoc, ödeme yöntemini değil, kişiyi doğrular.

mdoc'lar kendileri ödeme aracı olmasa da, Doğrulanabilir Kimlik Bilgileri için OpenID (OpenID4VC – sunum için OpenID4VP ve düzenleme için OpenID4VCI'yi kapsar) gibi protokoller daha esnek bir taşıma katmanı sunar.

OpenID4VC'nin Temel Özellikleri:

• Protokol, Yük Değil: OID4VC, VC'lerin nasıl talep edileceğini ve sunulacağını tanımlar, ancak VC yükünün formatı konusunda büyük ölçüde agnostiktir. mdoc'ları, W3C standart VC'lerini (ör. JWT veya SD-JWT formatında) veya diğer özel kimlik bilgisi türlerini taşıyabilir.
• Geniş Kullanım Alanı: Bu esneklik, Android gibi platformların (Credential Manager aracılığıyla) ortak bir mekanizma üzerinden çeşitli kimlik bilgisi türleri için talepleri desteklemesine olanak tanır.
• Ödeme VC'leri İçin Gelecek Uyumluluğu: Eğer ödeme endüstrisi doğrulanabilir bir "ödeme token'ı" veya "ödeme yetkilendirmesi" kimlik bilgisi formatını standartlaştırırsa, OID4VC teorik olarak böyle bir kimlik bilgisini bir kullanıcının cüzdanı ile bir satıcı/PSP arasında taşıyabilir.

Ancak, OID4VC Tek Başına Bir Ödeme Çözümü Değildir:

• OID4VC'nin rolü, bir kimlik bilgisinin değişimini kolaylaştırmaktır. Ödeme kimlik bilgisinin içeriğini, güvenlik özelliklerini veya ödeme işleme sistemleriyle nasıl etkileşime gireceğini tanımlamaz.
• OID4VC'nin ödemeler için faydalı olabilmesi için, öncelikle yaygın olarak benimsenen, güvenli ve standartlaştırılmış bir doğrulanabilir ödeme kimlik bilgisi formatının geliştirilmesi ve ödeme ekosistemi (ihraççılar, edinenler, ağlar) tarafından desteklenmesi gerekir. Bu şu anda mevcut değildir.

Native platform cüzdanlarının ötesinde, büyüyen bir üçüncü taraf cüzdan ekosistemi (ör. EUDI Cüzdanı, banka tarafından sağlanan cüzdanlar, özel endüstri cüzdanları) ortaya çıkmaktadır. Bu cüzdanlar, özellikle ödeme bağlamlarında, hızlı, düşük sürtünmeli kimlik doğrulama ile yüksek güvenceli özellik doğrulama arasındaki temel farkı yönetmelidir.

Ortaya çıkan genel kanı, passkey'lerin bir ödeme hizmetine yönelik temel kimlik doğrulama için ideal olduğu, çünkü phishing dirençli ve sorunsuz bir kullanıcı deneyimi için tasarlandıklarıdır. Kritik ödeme onay adımına bir dijital kimlik bilgisi sunumu eklemek, önemli ölçüde sürtünme yaratır ve muhtemelen dönüşüm oranlarına zarar verir. Bu nedenle, dijital kimlik bilgilerinin birincil rolü, işlemin kendisinden ziyade, ödeme yeteneklerini sağlayan tek seferlik, yüksek güvenceli katılım ve KYC aşamasındadır. Peki bu cüzdanlar, özellikle dijital kimlik özellikleriyle birlikte ödemelere nasıl yaklaşabilir?

Bir üçüncü taraf cüzdanın bir ödemeyi yetkilendirmesi için, satıcının uygulaması veya web sitesi tarafından çağrılmasının bir yolu olması gerekir. Bunun için her biri farklı platform entegrasyonu ve kullanıcı deneyimi seviyelerine sahip birkaç yerleşik etkileşim modeli vardır:

• Uygulamadan Uygulamaya Derin Bağlantı (App-to-App Deep Linking): Bu, satıcının uygulamasının (native veya web) kullanıcıyı özel bir URL şeması (ör. eudi-wallet://...) kullanarak üçüncü taraf cüzdan uygulamasına yönlendirdiği evrensel bir yöntemdir. İşlem detayları URL'de parametre olarak iletilir. Kullanıcı cüzdan uygulamasında ödemeyi onayladıktan sonra, başka bir derin bağlantı kullanarak satıcı uygulamasına geri yönlendirilir. Bu hem iOS hem de Android'de çalışır ancak uygulamalar arasında gözle görülür bir bağlam geçişi içerir.
• Native Cüzdan Seçimi: Native Cüzdan Seçimi ile bir uygulama, kayıtlı tüm ödeme işleyicilerini veya cüzdanları görüntüleyen genel bir sistem hizmetini çağırabilir. Kullanıcı daha sonra sistem tarafından sağlanan bir kullanıcı arayüzünden tercih ettiği cüzdanı seçebilir. Bu, basit derin bağlantıdan (Dijital Kimlik Bilgileri API'si) daha entegre bir his sunar.
• Basit QR Kod Tabanlı Ödemeler: Bu model, masaüstünden mobile akışlar için idealdir. Satıcının web sitesi, işlem ayrıntılarını veya bir URL'yi içeren bir QR kodu görüntüler. Kullanıcı bu kodu mobil cüzdan uygulamasıyla tarar ve uygulama telefonda onayı bağımsız olarak yönetir. Cüzdanın arka ucu daha sonra onayı satıcının sistemine geri iletir.
• Standartlaştırılmış Cihazlar Arası Akışlar (FIDO CTAP): QR kodu yönteminin bir evrimi olan bu yöntem, masaüstü tarayıcı (istemci) ile mobil cüzdan (bir doğrulayıcı olarak hareket eden) arasında doğrudan, güvenli ve şifreli bir kanal oluşturmak için FIDO'nun İstemciden Doğrulayıcıya Protokolü (CTAP) gibi protokolleri kullanır. Bu, tarayıcı ve telefonun doğrudan iletişim kurması nedeniyle basit QR kodlarından daha güvenlidir ve Google tarafından hem passkey'ler hem de dijital kimlik bilgileri için yoğun bir şekilde desteklenen bir modeldir.
• Doğrudan Arka Uç Entegrasyonu: Bazı kapalı döngü sistemlerde, üçüncü taraf cüzdan uygulaması, genellikle tescilli API'ler kullanarak ödemeleri işlemek için bir Ödeme Hizmeti Sağlayıcısı (PSP) veya bir finans kurumunun arka ucuyla doğrudan etkileşime girebilir.

Bu modeller, bir ödeme onayını başlatmak için "taşıma katmanını" sağlar ve bu katman içinde (EUDI Cüzdanı için ayrıntılı olarak açıklanan gibi) bir kriptografik akış gerçekleşebilir.

WWDC25'teki duyurularla birlikte, tarayıcıların dijital kimlik bilgilerini nasıl ele aldığına dair tablo çok daha netleşti ve kimlik doğrulama ile ödeme işleme arasındaki ayrımı pekiştirdi. Platformlar, üçüncü taraf cüzdanların W3C Dijital Kimlik Bilgileri API'si aracılığıyla kimlik doğrulaması için tarayıcılarla etkileşime girmesini sağlıyor, ancak yaklaşımlar farklılaşıyor:

• Apple'ın Duruşu (WWDC25'te Onaylandı): Apple, Safari 26'da (iOS 26 ile birlikte gönderilecek) Dijital Kimlik Bilgileri API'si desteğini resmi olarak duyurdu. "Web'de kimlik belgelerini doğrulayın" oturumlarında ayrıntılı olarak açıklandığı gibi, uygulama yalnızca org.iso.mdoc protokolünü desteklemektedir. Bu, web sitelerinin Apple Wallet'taki veya diğer kayıtlı üçüncü taraf belge sağlayıcı uygulamalarındaki mdoc'lardan doğrulanabilir bilgi talep etmesine olanak tanır, ancak daha genel amaçlı OpenID4VP protokolünü desteklemez. Dijital kimlik bilgilerine artan destek ve gelişmiş web entegrasyonları ile sistem performansını ve güvenliğini korumak daha da önemli hale geliyor - CleanMyMac gibi araçlar, bu teknolojiler geliştikçe Mac'inizin sorunsuz çalışmasını sağlamaya yardımcı olur.
• Google'ın Duruşu: Android'in Credential Manager'ı, üçüncü taraf cüzdanların kimlik bilgisi talepleri için işleyici olarak kaydolmasına olanak tanır. Chrome'daki Dijital Kimlik Bilgileri API'si uygulaması, birincil taşıma protokolü olarak OpenID4VP'yi kullanmaya odaklanmıştır. OpenID4VP bir mdoc'u yük olarak taşıyabilse de, protokolün kendisi Apple'ın doğrudan org.iso.mdoc yaklaşımından farklıdır.

Önemli bir nokta, bu tarayıcı entegrasyonlarının, sunulan mDoc veya VC'yi bir ödeme aracı olarak ele almak için değil, kimlik özellikleri için olmasıdır.

Bir kullanıcı cüzdanından bir mDL'yi tarayıcının Dijital Kimlik Bilgileri API'si aracılığıyla bir web sitesine sunarsa, bu web sitesi bilgiyi ödeme sırasında adres ön doldurma veya yaş doğrulaması için kullanabilir. Ancak, asıl ödeme adımı yine de bir ödeme yöntemiyle (ör. Apple Pay, Google Pay veya kart bilgilerini girme) ayrı bir etkileşim gerektirecektir. Tarayıcı API'sinin kendisi, bir kimlik bilgisini kullanarak bir finansal işlemi başlatmak veya işlemek için tasarlanmamıştır.

AB Dijital Kimlik (EUDI) Cüzdanı, bir üçüncü taraf cüzdanın işletim sistemlerinin ve API kullanılabilirliğinin karmaşık, gerçek dünya ortamında nasıl gezinmesi gerektiğine dair mükemmel bir vaka çalışması olarak hizmet vermektedir. Birçok işlevi arasında en belirgin kullanım alanlarından ikisi kimlik doğrulama ve ödeme onayıdır ve bu iki görevi yerine getirmek için teknik yollar, özellikle Android'in esnek çerçevesi ile Apple'ın daha katı uygulaması karşılaştırıldığında farklıdır.

aşağıdaki tablo, EUDI Cüzdanı'nın kimlik doğrulama veya ödeme yetkilendirmesi için nasıl çağrılabileceğini platformlar arasındaki farklı destekleri vurgulayarak ayırmaktadır.

Karşılaştırmadan Önemli Çıkarımlar:

• Dijital Kimlik Bilgileri API'si: Bu gelişmekte olan W3C standardı protokolden bağımsızdır ve her iki platformda da kimlik için iyi desteklenmektedir. Uygulaması için Android, çeşitli kimlik bilgisi formatlarını taşıyabilen esnek OpenID4VP protokolünü kullanan varsayılan bir akış sağlar. Apple'ın uygulaması ise tam tersine, kesinlikle org.iso.mdoc formatı içindir. Önemli bir nokta, tarayıcıların bu API'yi ödeme başlatmak için değil, kimlik kullanım durumları için kapsamasıdır.
• Native Cüzdan Seçici: Her iki işletim sistemi de bir cüzdan seçmek için native bir kullanıcı arayüzü sağlar, ancak farklı sınırlamalarla. Android hem kimlik hem de ödeme uygulamaları için bir seçici sunar. iOS, kayıtlı kimlik "Belge Sağlayıcı" uygulamaları için bir seçici sağlar ancak üçüncü taraf ödeme uygulamaları için bir tane sunmaz.
• Uygulamadan Uygulamaya Derin Bağlantı: Bu, her iki platformda hem kimlik hem de ödeme kullanım durumları için güvenilir bir şekilde çalışan evrensel bir iş atıdır. iOS'ta bir üçüncü taraf cüzdanını ödemeler için çağırmanın birincil yöntemi olmaya devam etmektedir.
• Standartlaştırılmış Cihazlar Arası: Bu FIDO CTAP tabanlı akış şu anda Google/Android ekosisteminin bir özelliğidir ve iOS'ta desteklenmemektedir.

(*) DC API Üzerinden Ödemeler Hakkında Not: Android'in OpenID4VP kullanımı, Dijital Kimlik Bilgileri API'si aracılığıyla bir ödeme akışını teknik olarak mümkün kılsa da, bu onun birincil tasarım odağı değildir. Diğer native yöntemlerin aksine, bu özel API aracılığıyla ödemeler için sorunsuz entegrasyonun görülmesi beklenmektedir ve tarayıcı satıcılarından açık destek gerektirecektir.

Bu karşılaştırma, kimlik doğrulamasının Dijital Kimlik Bilgileri API'si aracılığıyla giderek standartlaştırılırken, EUDI Cüzdanı gibi üçüncü taraf cüzdanlar için ödeme yetkilendirmesinin, özellikle iOS'ta, hala uygulamadan uygulamaya derin bağlantı gibi daha geleneksel native entegrasyon modellerine büyük ölçüde dayandığını açıkça ortaya koymaktadır.

Cüzdanı çağırmak için hangi ödeme entegrasyon modelinin kullanıldığına bakılmaksızın, EUDI Cüzdanı'nın ödeme onayının özü, EWC RFC008 belgesinde ayrıntılı olarak açıklanan standartlaştırılmış bir kriptografik akışa dayanır.

Aşağıda bu sürecin üst düzey bir anlatımı bulunmaktadır:

Bu, cüzdana gönderilen ve kullanıcının onaylaması için işlemi detaylandıran payment_data nesnesinin normatif olmayan bir örneğidir.

{
    "payee": "Merchant XYZ",
    "currency_amount": {
        "currency": "EUR",
        "value": "23.58"
    },
    "recurring_schedule": {
        "start_date": "2024-11-01",
        "expiry_date": "2025-10-31",
        "frequency": 30
    }
}

Kullanıcı onayladıktan sonra, cüzdan bir anahtar bağlama JWT'si oluşturur. İddiaları, kullanıcının belirli işlem verilerini onayladığını kanıtlar.

{
    "nonce": "n-0S6_WzA2Mj",
    "aud": "https://example.com/verifier",
    "iat": 1709838604,
    "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4",
    "transaction_data_hashes": ["fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do"]
}

Teknik standartlar gelişirken, ödeme sektörü de yerinde saymıyor. Kilit oyuncular, dijital kimlik bilgilerinin güvenliğini ödemelerin işlevselliğiyle nasıl birleştireceklerini aktif olarak araştırıyorlar.

Doğrulanabilir Kimlik Bilgilerinin (VC'ler) potansiyelini anlamanın güçlü bir yolu, onları başarılı ağ ödeme tokenizasyon sistemleriyle (Visa Token Service veya Mastercard MDES gibi) karşılaştırmaktır.

• Ödeme Tokenizasyonu, hassas Birincil Hesap Numarası'nı (PAN) güvenli bir token ve tek kullanımlık bir kriptogramla değiştirdi. Bu, işlemler sırasında temel varlık olan kart numarasını korur.
• Doğrulanabilir Kimlik Bilgileri, tokenizasyonun PAN'lar için yaptığını kişisel veriler için yapmayı hedefler. Kullanıcı, ham verileri (ad, doğum tarihi, adres) paylaşmak yerine, güvenilir bir ihraççıdan kriptografik olarak imzalanmış bir kimlik bilgisi sunar.

Özünde, bir VC'nin kişisel veriler için anlamı, bir ödeme token'ı ve kriptogramın kart verileri için anlamıyla aynıdır: riski azaltan ve gizliliği artıran güvenli, doğrulanabilir bir ikame.

Bu paralellik üzerine inşa edilen endüstri kuruluşları, "doğrulanabilir ödeme kimlik bilgisi" kavramı üzerinde çalışıyor. Bu, bir banka tarafından verilen, bir ödeme aracını (token'laştırılmış bir kart gibi) paketleyen ve işlemleri yetkilendirmek için kullanılabilen bir kimlik bilgisi olacaktır.

• Güvenli ödemeler için standartlar kurulu olan EMVCo, FIDO standartlarını EMV 3-D Secure protokolüne aktif olarak entegre etmektedir. Bu, önceki passkey kimlik doğrulamalarının sürtünmesiz onaylar için güçlü bir sinyal olarak kullanılmasına olanak tanırken, aynı zamanda Güvenli Ödeme Onayı (SPC) için geleneksel OTP zorluklarına modern, phishing dirençli bir alternatif olarak hizmet vermeye hazırlanıyor. Ayrıca, doğrulanabilir kimlik bilgilerinin gelecekte bu akışlara nasıl dahil edilebileceğine dair devam eden tartışmalar da var.
• Visa, bir FIDO doğrulayıcısını ödeme kimlik bilgilerine güvenli bir şekilde bağlayan Visa Payment Passkey Service hizmetini duyurdu. Bu hizmet, ödeme deneyimini kesintiye uğratmadan tek bir sürtünmesiz adımda kimliği doğrulamak ve ödemeleri yetkilendirmek için tasarlanmıştır.
• Mastercard, Token Kimlik Doğrulama Hizmeti'ni (TAS) kullanarak şifreleri ve OTP'leri passkey tabanlı biyometrik kimlik doğrulama ile değiştiren ve tokenizasyon hizmetleriyle (MDES) sıkı bir şekilde entegre olan Mastercard Payment Passkey Service ile paralel bir strateji izliyor.

Bu, net bir eğilimi gösteriyor: sektör, bir cüzdanın hem kimlik hem de ödeme yetkilendirmesinin kriptografik olarak doğrulanabilir bir kanıtını tek bir standartlaştırılmış akışta sunabildiği bir geleceğe doğru ilerliyor.

Bu inovasyonun büyük bir kısmı, özellikle Avrupa Birliği'nden gelen güçlü düzenleyici rüzgarlarla hızlanıyor.

AB'nin eIDAS 2.0 düzenlemesi sadece vatandaşlara dijital bir kimlik sağlamakla kalmıyor; EUDI Cüzdanı'nı açıkça çevrimiçi ödemeler için SCA gerçekleştirme yöntemi olarak öngörüyor. Bu, gelecekte AB'deki bankaların ve ödeme sağlayıcılarının, kullanıcıların çevrimiçi işlemleri onaylaması için EUDI Cüzdanı'nı kabul etmek zorunda kalabileceği ve tescilli bankacılık uygulamalarına veya SMS kodlarına standartlara dayalı bir alternatif sunacağı anlamına geliyor.

AB'deki dönüm noktası niteliğindeki bir antitröst anlaşması, Apple'ı iPhone'lardaki daha önce kapalı olan NFC arayüzünü açmaya zorladı. 5 Mart 2024'te yayınlanan iOS 17.4 itibarıyla Apple, gerekli API'leri uyguladı ve kullanıcıların varsayılan bir temassız ödeme uygulaması seçmesine izin vererek Avrupa Komisyonu'nun 25 Temmuz 2024 olan bağlayıcı son tarihini karşıladı. Bu artık gelecekteki bir olasılık değil; Avrupa Ekonomik Alanı'nda (EEA) mevcut bir gerçektir.

Bu değişim, üçüncü taraf cüzdan uygulamalarının artık iOS'ta kendi dokun-öde çözümlerini sunabileceği ve Apple Pay'in uzun süredir devam eden tekelini sona erdireceği anlamına geliyor. Geliştiricilere artık sunulan temel yetenekler şunları içeriyor:

• Varsayılan Cüzdan Seçimi: EEA'daki kullanıcılar, uygun bir üçüncü taraf uygulamasını varsayılan temassız ödeme uygulaması olarak ayarlayabilir ve bu uygulama yan düğmeye çift tıklayarak çağrılabilir.
• Tam Entegrasyon: Bu cüzdanlar, ödeme yetkilendirmesi için Face ID ve Touch ID dahil olmak üzere iPhone'un native güvenlik özelliklerini kullanabilir.
• Gerçek Dünya Benimsemesi: Norveç'te Vipps MobilePay ve Almanya'da PayPal dahil olmak üzere birçok büyük oyuncu çözümlerini zaten başlattı.

Bu açılımın sonuçları önemli ve şimdiden ortaya çıkıyor:

• Artan Rekabet: Bankalar ve fintech'ler artık Apple Pay ile kendi platformunda doğrudan rekabet edebilir, bu da ihraççı ücretlerini düşürmesi ve inovasyonu teşvik etmesi bekleniyor.
• Daha Geniş Kimlik Bilgisi Kullanımı: Aynı API'ler sadece ödemeler için değil, aynı zamanda kurumsal kartlar, toplu taşıma kartları ve otel anahtarları gibi daha fazlası için de Apple Wallet'ta olmaya gerek kalmadan kullanılabilir.
• Standartlaştırılmış Kimlik Bilgileri İçin Bir Yol: Bu, çok önemli bir emsal teşkil ediyor. NFC arayüzünü ödeme uygulamaları için açan aynı düzenleyici mantık, sonunda standartlaştırılmış, tarafsız "Doğrulanabilir Ödeme Kimlik Bilgileri" (EUDI Cüzdanı için pilot uygulaması yapılanlar gibi) için desteği zorunlu kılmak ve tescilli çözümlerin yanında çalışmalarına izin vermek için kullanılabilir.
• Küresel Emsal: Değişiklik şu anda EEA ile sınırlı olsa da, güçlü bir küresel emsal teşkil ediyor. ABD de dahil olmak üzere diğer bölgelerdeki düzenleyiciler yakından izliyor ve bu, dünya çapında benzer açılımları hızlandırabilir.

Ödeme ihraççıları (bankalar, şemalar, fintech'ler) için dijital kimlik bilgilerine geçişi yönetmek, pragmatik, aşamalı bir strateji gerektirir. Amaç, yarının ekosistemine hazırlanmak için bugün kontrol ettiğiniz varlıklar üzerine inşa etmektir. Bu oyun kitabı, acil, düşük pişmanlık getiren eylemlerden daha stratejik, uzun vadeli değerlendirmelere doğru ilerleyen bu stratejiyi özetlemektedir.

Gelecekteki herhangi bir cüzdan stratejisinin temeli, güvenli, yaygın olarak benimsenen bir native uygulamadır. Acil öncelik, uygulamanızın erişimini en üst düzeye çıkarmak ve hem giriş hem de ödemeler için kimlik doğrulamasını güçlendirmektir.

1. Native Uygulama Benimsemesini Teşvik Edin: Mobil uygulamanız gelecekteki cüzdanınızdır. Birincil amaç, onu müşterileriniz için vazgeçilmez bir araç haline getirmektir. Bu dağıtım ve etkileşim, gelecekteki herhangi bir kimlik bilgisi düzenlemesi veya cüzdan işlevselliği için kritik temeldir.

2. PayPal Modelini İzleyerek Ödemeler İçin Passkey'leri Kullanın: Passkey'leri sadece giriş için değil, ödeme yetkilendirmesi için de hemen dağıtın. Apple Pay gibi native platform çözümleriyle yakın bir denklik içinde bir deneyim hedefleyin. Güçlü Müşteri Kimlik Doğrulaması (SCA) gerektiren düzenleyici ortamlar için PayPal'ın pragmatik yaklaşımını benimseyin:

   • Passkey'leri birincil kimlik doğrulama faktörü olarak kullanın.
   • SCA'nın "sahiplik" faktörünü karşılamak için bunları güvenilir cihaz sinyalleriyle (ör. uygulamanız veya güvenli çerezler aracılığıyla yönetilen "hatırlanan cihazlar") birleştirin.
   • Bu kombinasyon, evrensel VC desteğini beklemeden hem son derece güvenli hem de uyumlu, sorunsuz, düşük sürtünmeli bir ödeme onayı deneyimi sunmanıza olanak tanır.

Güvenli, passkey korumalı bir uygulama temeliniz olduğunda, net bir değer sundukları yerlerde yeni kimlik bilgisi teknolojilerini seçici olarak entegre etmeye başlayabilirsiniz.

3. Doğrulanabilir Ödeme Kimlik Bilgilerinin Yükselişini İzleyin: Bir ödeme token'ı taşıyan bir VC kavramı güçlüdür ancak henüz standartlaştırılmamıştır. Buradaki rolünüz aktif bir gözlemci ve katılımcı olmaktır.

   • Eylem: EMVCo ve W3C gibi standart kuruluşlarındaki ilerlemeyi yakından takip edin. Standartlaştırılmış Doğrulanabilir Ödeme Kimlik Bilgileri, mevcut passkey tabanlı akışlara göre net bir avantaj sağladığında ve sağlarsa, bunlardan yararlanmaya hazır olun.

4. Kimlik Kullanım Durumları İçin Dijital Kimlik Bilgilerini Entegre Edin: Dijital kimlik cüzdanları (EUDI Cüzdanı gibi) yaygınlaştıkça, Dijital Kimlik Bilgileri API'sini ödemeler için değil, kimlikle ilgili görevler için entegre edin.

   • Eylem: Mükemmel oldukları yüksek güvenceli süreçler için VC sunumlarını kullanın:
     • Katılım ve KYC: Yeni hesap kurulumunu kolaylaştırın.
     • Step-Up Authentication: Yüksek riskli eylemler için kimliği doğrulayın.
     • Hesap Kurtarma: Cihazlarını kaybeden kullanıcılar için güvenli bir yol sağlayın.

Herhangi bir yeni ödeme teknolojisinin benimsenmesinin önündeki nihai engel, kullanıcı sürtünmesidir. Basit bir passkey akışının yerini almadan önce, VC tabanlı bir alternatifin sadece daha güvenli değil, aynı zamanda eşit derecede sorunsuz olduğunu kanıtlaması gerekir.

5. Tek Tık Deneyimine Karşı Sürekli Kıyaslama Yapın: Modern bir ödeme deneyiminin standardı, Apple Pay ve Web'deki yakın takipçisi PayPal gibi liderler tarafından belirlenir. Tanıttığınız her yeni akış, onların neredeyse anlık, tek tıkla onaylarıyla rekabet etmelidir. Mevcut tüm sinyaller, işlemlerin büyük çoğunluğu için passkey'lerin phishing direncinin yeterli düzeyde koruma ve üstün bir kullanıcı deneyimi sağladığını göstermektedir. Herhangi bir fark edilebilir sürtünme yaratıyorsa, bir ödeme akışına VC sunum adımı eklemeyin.

6. WebAuthn İçindeki Bant İçi Cihaz Sinyallerini İzleyin: Passkey'lerin evrimi statik değildir. Cihaza özgü sinyaller sağlama konusundaki ilk girişimler durdurulmuş olsa da, standart kuruluşları daha güçlü cihaz bağlama güven sinyallerini doğrudan WebAuthn protokolüne entegre etmek için aktif olarak çalışmaktadır. Bu, bir RP'nin bir passkey kimlik doğrulaması sırasında güvenilir bir cihazı tanımlamasına olanak tanıyarak, ayrı, bant dışı bir VC sunumu gerektirmeden risk motorları için sinyali daha da güçlendirecektir. Bu alanı yakından izleyin, çünkü passkey'in sürtünmesiz deneyiminden ödün vermeden gelişmiş güvenliğe giden en olası yoldur.

Bu aşamalı oyun kitabını izleyerek, bir ihraççı, bugün güvenliği en üst düzeye çıkaran ve kullanıcı deneyimini geliştiren, aynı zamanda yarının doğrulanabilir ödeme teknolojilerini düşünceli bir şekilde benimsemeye hazırlanan sağlam, pratik bir strateji oluşturabilir.

Dijital kimlik bilgilerinin, sadece KYC desteği veya kullanıcıları ödeme hesaplarına doğrulamak ötesinde ödeme süreçlerinin ayrılmaz bir parçası haline gelmesi için birkaç önemli zorluğun ele alınması gerekir:

1. Ödemeye Özgü VC'lerin Standardizasyonu: Ödemeler için özel, güvenli ve yaygın olarak kabul edilen bir doğrulanabilir kimlik bilgisi formatının geliştirilmesi gerekiyor. Bu, ödeme token'larını, işleme özgü verileri ve potansiyel olarak dinamik güvenlik unsurlarını kapsamalı ve mevcut kimlik odaklı mdoc'ların veya genel VC'lerin kapsamını çok aşmalıdır.
2. Ödeme Ağlarıyla Entegrasyon: Herhangi bir VC tabanlı ödeme çözümü, mevcut küresel ödeme ağlarıyla (Visa, Mastercard vb.) sorunsuz bir şekilde entegre olmalı veya uygulanabilir yeni raylar önermelidir. Bu, karmaşık teknik, güvenlik ve iş modeli uyumlarını içerir.
3. Mevzuata Uygunluk: Ödemeler yoğun bir şekilde düzenlenmektedir (ör. Avrupa'da PSD2/SCA, küresel olarak PCI DSS). VC tabanlı bir ödeme sistemi, güvenlik, tüketici koruması ve dolandırıcılıkla mücadele dahil olmak üzere ilgili tüm finansal düzenlemeleri karşılamalıdır.
4. İhraççı ve Edinen Benimsemesi: Bankalar, finansal kurumlar (ödeme VC'lerinin ihraççıları olarak) ve satıcı edinenleri, böyle bir sistemi desteklemek için altyapıya yatırım yapmak zorunda kalacaktır.
5. Güvenlik Modeli: Ödeme VC'leri için özel olarak, düzenleme, depolama (ideal olarak donanım destekli güvenli öğelerde), sunum ve finansal bir bağlamda iptali kapsayan sağlam bir güvenlik modeli gerekli olacaktır.
6. Kullanıcı Deneyimi: VC'ler kullanıcı kontrolü sunabilse de, ödeme deneyiminin yaygın olarak benimsenmesi için hızlı, sezgisel ve güvenilir kalması gerekir.

Gelecekteki Olasılıklar:

• Ödeme Yetkilendirme Fişleri için VC'ler: VC'ler, bağlantılı bir hesaptan ödeme yapmak için kriptografik olarak imzalanmış bir "yetkilendirmeyi" temsil edebilir ve OpenID4VP aracılığıyla sunulabilir, gerçek fon transferi ise hala geleneksel raylar üzerinden gerçekleşir.
• Ödeme Token'ları İçeren VC'ler: Mevcut ödeme altyapıları tarafından işlenen bir ödeme token'ını (bir EMV DPAN'ına benzer şekilde) güvenli bir şekilde tutmak için standartlaştırılmış bir VC tanımlanabilir.
• Kapalı Döngü Ödeme VC'leri: Belirli ihraççılar veya topluluklar, kendi kapalı döngü sistemleri içinde ödemeler için VC'ler oluşturabilir.

Ancak, bunlar şu anda büyük ölçüde kavramsal düzeydedir. Mevcut VC ve mdoc gelişiminin arkasındaki birincil itici güç, şimdi tarayıcı API'lerinin somut uygulamalarıyla pekiştirilmiş olarak, ödeme yürütme değil, kimlik doğrulama ve özellik beyanına odaklanmaya devam etmektedir.

Dijital kimlik ve ödemelerin yakınlaşması, karmaşık ancak yönetilebilir bir manzara sunuyor. Tek, evrensel bir "doğrulanabilir ödeme kimlik bilgisi" vaadi cazip olsa da, bu makale bugün ödeme ihraççıları için en etkili ve pratik stratejinin farklı bir gerçekliğe dayandığı sonucuna varıyor: en iyi kullanıcı deneyimi için verilen savaş her şeyden önemlidir ve passkey'ler en güçlü silahtır.

Stratejik oyun kitabı açık. Acil, düşük pişmanlık getiren hamle, rakipsiz bir native uygulama oluşturmaya odaklanmak, bunu Apple Pay ve PayPal tarafından belirlenen sürtünmesiz "tek tık" standardına rakip olabilecek passkey tabanlı ödemeleri dağıtmak için bir araç olarak kullanmaktır. Bu yaklaşım, olgun, yaygın olarak benimsenen teknolojiyi kullanarak bugün güvenliğin (phishing direnci yoluyla) ve kullanıcı deneyiminin temel ihtiyaçlarını karşılar.

Bu modelde, Doğrulanabilir Kimlik Bilgileri kendi önemli, ancak farklı rollerini bulur. Henüz ödeme eyleminin kendisi için bir araç değillerdir, ancak onu çevreleyen yüksek güvenceli kimlik görevleri için vazgeçilmezdirler: güvenli katılım, sağlam hesap kurtarma ve düzenleyici KYC.

Ödemelerin geleceği tek bir teknoloji tarafından değil, kullanıcıya amansız bir odaklanma ile belirlenecektir. Başarı, önce kendi uygulamalarında passkey odaklı deneyimde ustalaşan, aynı zamanda doğrulanabilir kimlik bilgilerinin ve bant içi passkey güven sinyallerinin evrimini düşünceli bir şekilde izleyen ihraççılara gelecektir. Bu yeni teknolojileri sadece mevcut olduklarında değil, yalnızca gerçekten sorunsuz, güvenli ve üstün bir ödeme deneyiminin zorlu ölçütünü karşılayabildiklerinde entegre etmeye hazır olmalıdırlar.