--- url: 'https://www.corbado.com/tr/blog/dijital-kimlik-bilgileri-odemeler' title: 'Dijital Kimlik Bilgileri ve Ödemeler: Apple ve Google Cüzdan Stratejisi' description: 'Dijital kimlik bilgilerinin ödemeler üzerindeki etkisini ve ihraççıların Apple Pay ve Google Cüzdan ile rekabet edebilmek için izleyebileceği stratejileri inceliyoruz.' lang: 'tr' author: 'Vincent Delitz' date: '2025-07-25T07:00:35.532Z' lastModified: '2026-03-27T07:08:42.233Z' keywords: 'dijital kimlik bilgileri, ödeme' category: 'Passkeys Strategy' --- # Dijital Kimlik Bilgileri ve Ödemeler: Apple ve Google Cüzdan Stratejisi ### Özet: Bir İhraççının Stratejik Oyun Kitabı | Aşama | Temel Stratejiniz | Önemli Adımlar | | :------------------- | :------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **1. Şimdi** | 📱 **Uygulamayı Öne Çıkarın, Passkey'lerde Ustalaşın** | Native uygulama kullanımını sürekli teşvik edin. Apple Pay ve PayPal'a rakip olacak tek tıkla ödeme deneyimi için passkey'leri kullanın. | | **2. Yakın Gelecek** | 🆔 **VC'leri Ödemeler İçin Değil, Kimlik İçin Kullanın** | KYC ve hesap kurtarma gibi yüksek güvence gerektiren görevler için dijital kimlik bilgilerini entegre edin. Doğrulanabilir ödeme kimlik bilgilerini izleyin, ancak bu alana girmek için acele etmeyin. | | **3. Gelecek** | ⚖️ **VC'leri Gelişen Passkey'lerle Karşılaştırın** | Herhangi bir VC ödeme akışını en iyilerle kıyaslayın. Yalnızca zorunlu olduğunda veya daha üstün bir net değer sağladıklarında ödemeler için benimseyin. Bant içi cihaz sinyalleri gibi passkey geliştirmelerini takip edin. | ## 1. Giriş Dijital [ödemeler](https://www.corbado.com/passkeys-for-payment) 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](https://www.corbado.com/tr/blog/mobil-surucu-belgesi) belgeleri (mdoc'lar) gibi [dijital kimlik](https://www.corbado.com/tr/glossary/open-id-4-vp) 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](https://www.corbado.com/passkeys-for-payment) de çok daha iyi veya daha basit hale getirebilir mi? Bu makale, [dijital kimlik](https://www.corbado.com/tr/glossary/open-id-4-vp) bilgilerinin (ISO [mdoc](https://www.corbado.com/glossary/mdoc)'ları ve [OpenID4VC](https://www.corbado.com/glossary/open-id-4-vc) kullanılarak gönderilen VC'ler dahil) [ödemeler](https://www.corbado.com/passkeys-for-payment) dünyasıyla nasıl bağlantı kurduğunu inceliyor. Ele alacağımız konular: - Mevcut telefon cüzdanlarının (Apple [Wallet](https://www.corbado.com/blog/digital-wallet-assurance), [Google Wallet](https://www.corbado.com/blog/how-to-use-google-pay)) kimlik bilgilerini ödeme kartlarına kıyasla nasıl işlediği. - [ISO 18013-5](https://www.corbado.com/glossary/iso-18013-5)/7 [mdoc](https://www.corbado.com/glossary/mdoc)'ları gibi mevcut [dijital kimlik](https://www.corbado.com/tr/glossary/open-id-4-vp) standartlarının neden doğrudan ödeme araçları olarak pek uygun olmadığı. - [OpenID4VC](https://www.corbado.com/glossary/open-id-4-vc) gibi protokollerin gelecekteki ödeme yöntemlerinde ne gibi bir rol oynayabileceği. - Diğer (üçüncü taraf) [cüzdan](https://www.corbado.com/tr/blog/dijital-cuzdan-guvencesi) 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](https://www.corbado.com/tr/blog/dijital-kimlik-bilgileri-passkeys) ve [Passkey'ler](https://www.corbado.com/tr/blog/tamamen-sifresiz-sisteme-nasil-gecilir) üzerine olan diğer tartışmamızı tamamlıyor. ## 2. Mevcut Durumu Anlamak: Kimlik ve Ödeme Yığınları 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](https://www.corbado.com/blog/digital-wallet-assurance), Google [Wallet](https://www.corbado.com/blog/digital-wallet-assurance)) kimlik bilgilerini ödemelerin işlenme şeklinden nasıl ayrı tuttuğunu anlamamız gerekiyor. ### 2.1 Native Platform Cüzdanları: Kimlik ve Ödemeler İçin Ayrı Silolar 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](https://www.corbado.com/blog/wwdc25-passkeys-os26) 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](https://www.corbado.com/blog/how-to-use-google-pay) da [ISO 18013-5](https://www.corbado.com/glossary/iso-18013-5) tabanlı [mDL](https://www.corbado.com/blog/mobile-drivers-license)'leri destekler. Altta yatan [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) Credential Manager daha esnek bir çerçeve sunar. [Dijital Kimlik Bilgileri API](https://www.corbado.com/tr/blog/digital-credentials-api)'sinin uygulanması protokolden bağımsız olsa da, [Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) taşıma mekanizması olarak [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp) kullanan varsayılan bir uygulama sağlar. - **Ödeme Araçları (ör. Kredi/Banka Kartları):** - Hem [Apple Pay](https://www.corbado.com/blog/how-to-use-apple-pay) (Apple Wallet içinde) hem de [Google Pay](https://www.corbado.com/blog/how-to-use-google-pay) (Google Wallet içinde), yerleşik ve sıkı bir şekilde düzenlenmiş ödeme teknolojilerini kullanır. Bunlar öncelikle EMV (Europay, [Mastercard](https://www.corbado.com/blog/mastercard-passkeys), [Visa](https://www.corbado.com/blog/visa-passkeys)) standartlarına dayanır ve tokenizasyon (işlemler için gerçek kart numaralarının yerini alan Cihaz [PAN](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/mastercard-passkeys), 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](https://www.corbado.com/glossary/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. ### 2.2 ISO 18013-5 mdoc'ları Neden Ödeme Aracı Değildir? ISO/IEC 18013-5 standardı, [mDL](https://www.corbado.com/blog/mobile-drivers-license)'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: | Özellik | ISO 18013-5'in Belirttiği (Kimlik mdoc'ları için) | Bunun Ödemeler İçin Sorun Olma Nedeni | | :---------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Birincil Kapsam** | Mobil Sürücü Belgeleri ve diğer kimlik belgeleri. | Kart ağları, ödemeye özgü veri elemanlarına ve kriptogramlara ihtiyaç duyar. | | **Veri Modeli** | Sabit kimlikle ilgili veri elemanları (ör. portre, ad, doğum tarihi). Genişletilebilir, ancak yine de bir "kimlik" ad alanına bağlıdır. | Kart PAN'ları, token'laştırılmış DPAN'lar, CVM'ler, dinamik kriptogramlar bu kimlik elemanlarıyla temiz bir şekilde eşleşmez. | | **Tehdit Modeli ve Güvenlik** | Hamili hazır ("gözetimli") doğrulama; kimlik özellikleri için seçici ifşa ile çevrimdışı "dokunarak doğrula". mdoc'tan güvenli veri alımı. | Ödemeler, çevrimiçi yetkilendirme, dinamik kriptogram oluşturma (EMV tarzı), finansal işlemlere özgü dolandırıcılık önleme ve fon kaynaklarına bağlantılar için sağlam mekanizmalar gerektirir. mdoc güvenliği, finansal işlem işleme için değil, kimlik bütünlüğü içindir. | | **Standart Onayı** | ISO 18013-5, kendisini açıkça yüz yüze kimlik tespiti ile sınırlar. ISO/IEC 18013-7 ve ISO/IEC 23220, mdoc'lar için çevrimiçi sunum mekanizmalarını belirtir (ör. Dijital Kimlik Bilgileri API'si aracılığıyla web tabanlı kimlik doğrulaması için), ancak bunlar hala _uzaktan kimlik doğrulamasına_ odaklanır, ödeme raylarına değil. | Ödemeler, özellikle çevrimiçi olanlar, mdoc standartlarının kendi kapsamı dışında kalır. | Bir mdoc'a teorik olarak bir [PAN](https://www.corbado.com/glossary/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](https://www.corbado.com/glossary/iso-18013-5) mdoc'unu doğrudan bir ödeme aracı olarak kullanmanın bir yolu yoktur. ### 2.3 Step-Up Authentication: mdoc'ları Ödeme İçin Değil, Kimlik Kanıtlama İçin Kullanma 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](https://www.corbado.com/glossary/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](https://www.corbado.com/tr/blog/dijital-cuzdan-guvencesi)ı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](https://www.corbado.com/glossary/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. ## 3. Olası Ödeme Senaryolarında OpenID4VC'nin Rolü mdoc'lar kendileri ödeme aracı olmasa da, Doğrulanabilir Kimlik Bilgileri için OpenID (OpenID4VC – sunum için [OpenID4VP](https://www.corbado.com/glossary/open-id-4-vp) ve düzenleme için [OpenID4VCI](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://www.corbado.com/tr/blog/dijital-cuzdan-guvencesi)ı ile bir satıcı/[PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) 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. ## 4. Üçüncü Taraf Cüzdanlar ve Ödemeler Native platform cüzdanlarının ötesinde, büyüyen bir üçüncü taraf cüzdan ekosistemi (ör. [EUDI Cüzdan](https://www.corbado.com/tr/blog/digital-credentials-api)ı, 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](https://www.corbado.com/blog/digital-credentials-passkeys#34-payment-scenarios-low-friction), çünkü [phishing](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding) aşamasındadır. Peki bu cüzdanlar, özellikle dijital kimlik özellikleriyle birlikte ödemelere nasıl yaklaşabilir? ### 4.1 Ödemeler İçin Mevcut Etkileşim Modelleri 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](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://www.corbado.com/tr/blog/tamamen-sifresiz-sisteme-nasil-gecilir) hem de [dijital kimlik bilgileri](https://www.corbado.com/tr/blog/dijital-kimlik-bilgileri-passkeys) 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. ### 4.2 Tarayıcı Entegrasyonu: Önce Kimlik, Ödemeler Ayrı [WWDC25](https://www.corbado.com/blog/wwdc25-passkeys-os26)'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](https://www.corbado.com/tr/blog/digital-credentials-api) ile ödeme işleme arasındaki ayrımı pekiştirdi. Platformlar, üçüncü taraf cüzdanların W3C [Dijital Kimlik Bilgileri](https://www.corbado.com/tr/blog/dijital-kimlik-bilgileri-passkeys) 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](https://www.corbado.com/tr/blog/digital-credentials-api)'si desteğini resmi olarak duyurdu. ["Web'de kimlik belgelerini doğrulayın" oturumlarında](https://developer.apple.com/videos/play/wwdc2025/232/) 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](https://www.corbado.com/glossary/open-id-4-vp) 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](https://cleanmymac.com/) 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](https://www.corbado.com/blog/mobile-drivers-license)'yi tarayıcının [Dijital Kimlik Bilgileri API](https://www.corbado.com/tr/blog/digital-credentials-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](https://www.corbado.com/blog/how-to-use-apple-pay), [Google Pay](https://www.corbado.com/blog/how-to-use-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. ## 5. Pratikte AB Dijital Kimlik Cüzdanı 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](https://www.corbado.com/tr/blog/digital-credentials-api) 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. ### 5.1 Etkileşim Modeli Karşılaştırması: Kimlik ve Ödeme aşağıdaki tablo, [EUDI Cüzdan](https://www.corbado.com/tr/blog/digital-credentials-api)ı'nın [kimlik doğrulama](https://www.corbado.com/tr/blog/digital-credentials-api) veya ödeme yetkilendirmesi için nasıl çağrılabileceğini platformlar arasındaki farklı destekleri vurgulayarak ayırmaktadır. | Entegrasyon Modeli | Kimlik (Android) | Kimlik (iOS) | Ödeme (Android) | Ödeme (iOS) | | :---------------------------------------- | :--------------: | :----------: | :-------------: | :---------: | | **Dijital Kimlik Bilgileri API'si** | ✅ | ✅ | ✅\* | ❌ | | **Native Cüzdan Seçici** | ✅ | ✅ | ✅ | ❌ | | **Uygulamadan Uygulamaya Derin Bağlantı** | ✅ | ✅ | ✅ | ✅ | | **Standartlaştırılmış Cihazlar Arası** | ✅ | ❌ | ✅ | ❌ | **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](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://www.corbado.com/tr/blog/digital-credentials-api)ı 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. ### 5.2 Perde Arkası: EWC Ödeme Onay Akışı 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`](https://github.com/EWC-consortium/eudi-wallet-rfcs/blob/main/payment-rfcs/ewc-rfc-008-payment-data-confirmation.md) 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: | Adım | Eylem | Anahtar yapılar | | ---- | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | **Yetkilendirme Talebi** | Satıcı veya PSP, cüzdana bir _Ödeme Cüzdanı Beyanı_ referansı içeren bir `presentation_definition` **ve** base64url ile kodlanmış bir `transaction_data` nesnesi (tutar, para birimi, alacaklı) içeren bir OpenID4VP talebi gönderir. | | 2 | **Kullanıcı İncelemesi ve Onayı** | Cüzdan, insan tarafından okunabilir ödeme ayrıntılarını (ör. _Satıcı XYZ_'ye 23,58 €) görüntüler ve kullanıcıdan biyometrik bir hareket veya PIN ile onaylamasını ister. | | 3 | **Doğrulanabilir Sunum** | Cüzdan, (a) seçilen Ödeme Cüzdanı Beyanını (bir SD-JWT VC olarak) ve (b) `transaction_data_hashes` iddiası kullanıcının 1. adımdaki tam yükü imzaladığını kanıtlayan bir anahtar bağlama JWT'sini içeren bir Doğrulanabilir Sunum döndürür. | | 4 | **Doğrulama** | PSP, sunumu doğrular, orijinal `transaction_data` karmasının JWT'dekiyle eşleştiğini kontrol eder ve zaman damgasının güncel olduğundan emin olur. | | 5 | **Fon Hareketi** | SCA'yı karşılayan PSP, kullanıcının işlem ayrıntılarını açıkça onayladığından emin olarak normal kart veya hesap ödemesine devam eder. | #### Örnek: İşlem Veri Yükü 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. ```json { "payee": "Merchant XYZ", "currency_amount": { "currency": "EUR", "value": "23.58" }, "recurring_schedule": { "start_date": "2024-11-01", "expiry_date": "2025-10-31", "frequency": 30 } } ``` #### Örnek: Anahtar Bağlama JWT İddiaları 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. ```json { "nonce": "n-0S6_WzA2Mj", "aud": "https://example.com/verifier", "iat": 1709838604, "sd_hash": "Dy-RYwZfaaoC3inJbLslgPvMp09bH-clYP_3qbRqtW4", "transaction_data_hashes": ["fOBUSQvo46yQO-wRwXBcGqvnbKIueISEL961_Sjd4do"] } ``` ## 6. Sektörün Yanıtı: Ödemeler ve Kimliğin Yakınsaması 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. ### 6.1 Ödeme Tokenizasyonu ile Paralellikler 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](https://www.corbado.com/blog/mastercard-passkeys) 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](https://www.corbado.com/glossary/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. ### 6.2 Doğrulanabilir Ödeme Kimlik Bilgilerinin Yükselişi 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**](https://www.corbado.com/blog/emv-3ds-acs-passkeys-fido-and-spc), FIDO standartlarını EMV [3-D Secure](https://www.corbado.com/glossary/3d-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](https://www.corbado.com/glossary/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**](https://www.corbado.com/blog/visa-passkeys) 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**](https://www.corbado.com/blog/mastercard-passkeys) 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. ## 7. Düzenleyici Ortam: Avrupa'nın Katalizör Rolü Bu inovasyonun büyük bir kısmı, özellikle Avrupa Birliği'nden gelen güçlü düzenleyici rüzgarlarla hızlanıyor. ### 7.1 EUDI Cüzdanı'nın Güçlü Müşteri Kimlik Doğrulaması'ndaki (SCA) Rolü AB'nin [eIDAS 2.0 düzenlemesi](https://digital-strategy.ec.europa.eu/en/policies/eidas-regulation) sadece vatandaşlara dijital bir kimlik sağlamakla kalmıyor; [EUDI Cüzdanı'nı](https://commission.europa.eu/strategy-and-policy/priorities-2019-2024/europe-fit-digital-age/european-digital-identity_en) açıkça çevrimiçi ödemeler için [SCA](https://www.corbado.com/tr/blog/psd2-ve-passkeys) 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](https://www.corbado.com/passkeys-for-banking) uygulamalarına veya SMS kodlarına standartlara dayalı bir alternatif sunacağı anlamına geliyor. ### 7.2 Apple'ın NFC Kapalı Bahçesi Artık Açık (Avrupa'da) AB'deki dönüm noktası niteliğindeki bir [antitröst anlaşması](https://ec.europa.eu/commission/presscorner/detail/en/ip_24_3706), Apple'ı iPhone'lardaki daha önce kapalı olan NFC arayüzünü açmaya zorladı. 5 Mart 2024'te yayınlanan [iOS 17](https://www.corbado.com/blog/apple-passkeys-integration).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](https://www.corbado.com/blog/how-to-use-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](https://www.corbado.com/faq/is-face-id-passkey) 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. ## 8. Bir İhraççının Oyun Kitabı: Doğrulanabilir Ödemeler İçin Pratik Bir Strateji Ö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. ### Aşama 1: Kapsamı Genişletin ve Passkey'lerle Ödemeleri Güvence Altına Alın (Bugün) 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ı](https://www.corbado.com/blog/psd2-sca-requirements) (SCA) gerektiren düzenleyici ortamlar için [PayPal](https://www.corbado.com/blog/paypal-passkeys)'ın pragmatik yaklaşımını benimseyin: - Passkey'leri birincil kimlik doğrulama faktörü olarak kullanın. - [SCA](https://www.corbado.com/tr/blog/psd2-ve-passkeys)'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. ### Aşama 2: Gelişen Teknolojilerle Yetenekleri Geliştirin (Önümüzdeki 24-36 Ay) 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. ### Aşama 3: Pürüzsüz Bir Deneyimi Kıyas Noktası Alın ve Passkey Gelişimini İzleyin 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](https://www.corbado.com/blog/paypal-passkeys) 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. ## 9. Ödemelerde VC'ler İçin Zorluklar ve Gelecek Perspektifi Dijital kimlik bilgilerinin, sadece [KYC](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding) 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](https://www.corbado.com/blog/psd2-passkeys)/[SCA](https://www.corbado.com/tr/blog/psd2-ve-passkeys), küresel olarak [PCI DSS](https://www.corbado.com/blog/pci-dss-4-0-authentication-passkeys)). 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](https://www.corbado.com/passkeys-for-critical-infrastructure) 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ı](https://www.corbado.com/passkeys-for-critical-infrastructure) 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. ## 10. Sonuç: İhraççılar İçin İleriye Yönelik Pragmatik Bir Yol 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](https://www.corbado.com/blog/paypal-passkeys) 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](https://www.corbado.com/tr/blog/tamamen-sifresiz-sisteme-nasil-gecilir) ve düzenleyici [KYC](https://www.corbado.com/blog/iso-18013-7-mdl-bank-kyc-onboarding). Ö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.