결제 제공업체 패스키: 서드파티 SDK 구축 방법

패스키는 기존의 다중 인증(MFA) 방식과 비교해 보안과 편의성을 크게 향상시키며, 온라인 거래를 보호하고 승인하는 가장 효과적인 방법으로 부상하고 있습니다. 최근 PayPal이 패스키를 주요 독립형 MFA 솔루션으로 채택하면서 전 세계 결제 제공업체들에게 명확한 트렌드를 제시했습니다.

하지만 패스키는 원래 퍼스트파티(first-party) 컨텍스트를 염두에 두고 설계되었습니다. 즉, 사용자가 자격 증명을 소유한 웹사이트나 앱에서 직접 인증할 때 최적으로 작동합니다. 반면, 결제 제공업체는 일반적으로 서드파티(third-party) 컨텍스트에서 운영됩니다. 이들의 서비스(결제 양식이나 SDK 등)는 가맹점의 웹사이트와 앱에 내장되는 형태입니다. 패스키 설계와 결제 제공업체의 운영 모델 간의 이러한 근본적인 불일치는 원활한 통합에 있어 중요한 제약이 됩니다. 이러한 문제를 해결하기 위해 우리는 두 가지 중요한 질문을 탐구해야 합니다.

1. 결제 제공업체가 서드파티 컨텍스트에서 패스키를 사용할 때 현재의 한계점은 무엇인가? 2. 결제 제공업체는 이러한 한계를 극복하고 서드파티 패스키 통합을 성공적으로 구현하기 위해 어떻게 해야 하는가?

이 질문들을 검토함으로써, 우리는 패스키를 서드파티 컨텍스트에 적용하려는 업계의 지속적인 노력, 특히 보안 결제 확인(SPC)과 같은 웹 표준을 통한 노력이 Apple이 암묵적으로 부과한 전략적 장벽에 막혀 있음을 알게 될 것입니다. 구체적으로, Safari에서의 교차 출처 패스키 생성에 대한 Apple의 제한적인 지원과 보안 결제 확인 표준의 미지원은 서드파티 결제 제공업체에 의한 패스키 기반 인증의 원활한 도입을 복잡하게 만드는 중대한 장애물입니다. 이러한 장애물을 이해하고 극복하는 것은 마찰 없는 안전한 결제 경험을 제공하고자 하는 모든 제공업체에게 필수적입니다.

패스키는 결제 스택의 모든 계층에 피싱 방지 및 생체 인식 기반 로그인을 제공합니다. 아래는 결제 가치 사슬의 각 참여자가 패스키 인증을 통합함으로써 얻을 수 있는 이점을 분석한 것입니다.

영향: 더 빠른 결제, 더 높은 전환율, 장바구니 이탈 감소. 기회: SDK나 리디렉션 플로우를 통해 패스키를 제공하는 가맹점은 Apple Pay 수준의 UX를 모방하고 비밀번호나 OTP에 대한 의존도를 줄여 더 높은 신뢰도와 매출로 이어질 수 있습니다.

영향: 여러 기기에서 원활한 비밀번호 없는 인증. 기회: 패스키는 OTP나 SMS 코드보다 더 나은 UX를 제공하고 피싱 위험을 제거합니다. 패스키가 널리 채택되면 카드 소지자 확인의 새로운 기본값이 될 수 있습니다.

영향: 더 강력한 사기 방지. 기회: 발급사는 3DS 플로우에서 패스키 기반 스텝업 인증을 제공하여 OTP 비용을 낮추고 사용자 만족도를 향상시킬 수 있습니다.

영향: 더 높은 거래 승인율과 실패한 인증 감소. 기회: PSP를 통해 패스키를 지원하면 가맹점 성과를 개선하고 결제 또는 반복 청구 플로우 중 마찰을 줄일 수 있습니다.

영향: 사기 감소, 더 나은 가맹점 UX, 규정 준수 개선. 기회: 패스키 플로우를 내장하거나 리디렉션함으로써 PSP는 브라우저와 네이티브 앱 전반에 걸쳐 호환성을 유지하면서 차세대 인증을 제공할 수 있습니다.

영향: 거절된 결제 감소로 간소화된 거래 승인. 기회: 결제 처리 회사는 API에 패스키 확인을 통합하여 위험을 줄이고 규정을 준수하는 플로우를 위한 생체 인식 SCA 대안을 지원할 수 있습니다.

영향: 안전한 자격 증명 저장 및 마찰 없는 재인증. 기회: Apple Pay 및 Google Pay와 같은 지갑 제공업체는 이미 패스키와 유사한 플로우를 사용하고 있습니다.

다음에서는 주요 결제 및 신용카드 제공업체를 간략히 살펴보고 그들이 패스키를 구현했는지, 그리고 어떻게 구현했는지 분석합니다.

Mastercard는 EMV 3DS 플로우에 내장된 비밀번호 없는 인증 경험을 제공하는 Payment Passkey Service를 공식 출시했습니다. 사용자는 Mastercard의 인증 도메인(예: verify.mastercard.com)에 연결된 패스키를 생성하고 사용하여 참여 가맹점 전반에서 안전한 생체 인식 로그인을 할 수 있습니다. 이 출시는 결제 산업에서 피싱 방지 및 PSD2 준수 인증을 향한 중요한 단계입니다. 더 읽어보기: Mastercard 패스키

Visa는 "Click to Pay" 플로우에 패스키를 통합한 Visa Payment Passkey Service를 도입했습니다. 사용자가 비밀번호나 OTP 대신 생체 인식을 사용하여 원활하게 인증할 수 있도록 함으로써, Visa는 향상된 보안과 사용자 편의성으로 온라인 결제 경험을 현대화하는 것을 목표로 하고 있습니다. 더 읽어보기: VISA 패스키

American Express는 아직 패스키 제공을 공개적으로 발표하지 않았습니다. 그러나 FIDO Alliance의 이사회급 회원으로서, American Express가 더 넓은 산업 동향에 맞춰 가까운 미래에 패스키 기반 인증 솔루션을 출시할 가능성이 높습니다.

PayPal은 패스키를 채택한 최초의 결제 제공업체 중 하나였습니다. 이들의 출시는 여러 기기에서 개인 및 비즈니스 계정에 대한 원활한 생체 인식 로그인을 지원합니다. 패스키는 PayPal의 도메인에 바인딩되며 이미 많은 지역에서 사용할 수 있습니다. 그러나 특히 다중 기기 플로우 및 플랫폼 감지 측면에서 개선의 여지가 있습니다. 더 읽어보기: PayPal 패스키

Klarna는 아직 공식적으로 패스키 지원을 도입하지 않았습니다. 우리의 관찰에 따르면, Klarna는 앱과 결제 SDK에서 내장된 WebView에 크게 의존합니다. Safari와 iOS가 iframes / WebViews에서의 패스키 생성을 제한하기 때문에, 이것이 Klarna가 지금까지 패스키를 출시하지 않은 이유일 수 있습니다.

Square는 개발자 대시보드 및 관리 콘솔에 패스키 로그인을 도입하여 내부 도구에 대한 안전한 비밀번호 없는 액세스를 허용합니다. 그러나 최종 사용자나 가맹점을 위한 결제 플로우나 API에서의 패스키 지원에 대한 발표는 없었습니다.

Stripe는 대시보드에 패스키 로그인을 출시하여 개발자가 생체 인식을 사용하여 인증할 수 있도록 했습니다. Stripe Checkout 또는 Elements용 패스키는 아직 사용할 수 없습니다. Stripe가 리디렉션 기반 플로우를 강력하게 옹호하는 것을 고려할 때, 만약 결제에 패스키가 구현된다면 동일한 리디렉션 아키텍처를 따를 가능성이 높습니다.

현재까지 BILL은 인증을 위한 패스키와 관련된 공개 발표나 제품 업데이트를 하지 않았습니다.

Remitly는 서비스에 패스키 인증을 구현하는 것에 대한 계획이나 공개 정보를 공개하지 않았습니다.

Payoneer가 패스키 기반 로그인 또는 거래 플로우를 채택했거나 테스트 중임을 나타내는 공개 보고서나 제품 문서는 없습니다.

Adyen은 아직 인증 또는 결제 플로우에 패스키를 도입하지 않았습니다. 패스키 지원에 대한 공개 성명이나 개발자 문서는 없습니다.

Worldpay는 현재까지 패스키 지원을 발표하지 않았습니다. 이들의 인증 스택은 여전히 비밀번호, OTP, 3DS 기반 플로우와 같은 전통적인 방법에 의존하고 있습니다.

Checkout.com은 공개적으로 패스키 지원을 출시하지 않았습니다. 패스키 채택에 관한 개발자 업데이트, 블로그 게시물 또는 공식 발표는 없습니다.

AliPay는 공식적으로 패스키를 출시하지 않았습니다. 중국 결제 생태계 내에서 생체 인증의 증가 추세를 고려할 때, 미래에 출시될 수 있지만 현재 이를 확인하는 문서는 없습니다.

Mollie는 인증 또는 결제 시스템에 패스키를 채택하는 것과 관련하여 어떠한 공개 성명이나 제품 업데이트도 하지 않았습니다.

Amazon은 메인 플랫폼에서 사용자 로그인을 위한 패스키 지원을 출시했습니다. 이 기술을 Amazon Pay로 확장하는 것은 자연스러운 다음 단계일 것입니다. 특히 많은 사용자가 이미 Amazon에 패스키를 등록했기 때문에 결제 중 사용자 온보딩을 크게 단순화할 수 있습니다.

PayPal 회사인 Braintree는 아직 공식적으로 패스키 인증을 채택하지 않았습니다. 현재 문서에는 사용자 로그인 또는 가맹점 API와 관련하여 패스키가 언급되어 있지 않습니다.

Stripe의 원클릭 결제 솔루션인 Link가 패스키를 출시했으며, 이는 소비자 결제에서 Stripe의 패스키 전략의 기반이 될 수 있습니다. 그러나 Stripe는 Link에 대한 패스키 지원이나 출시에 대한 구체적인 계획을 공식적으로 발표하지 않았습니다.

Afterpay는 패스키 지원과 관련된 성명이나 기능을 발표하지 않았습니다. Klarna와 마찬가지로, 이들의 결제 통합은 앱 기반이 강하며, 이는 내장된 WebView 제약으로 인해 패스키 채택에 기술적 장애물이 될 수 있습니다.

서드파티 결제 제공업체의 패스키 채택은 주로 Apple의 Safari에서의 제한적인 정책으로 인해 전략적 장애물에 직면해 있습니다. 두 가지 중요한 표준화 시도가 지속적으로 방해를 받아왔습니다.

• 보안 결제 확인 (SPC)

• Iframes에서의 서드파티 패스키 생성

보안 결제 확인(SPC)은 주로 Google이 주도하는 업계의 가장 중요한 노력으로, 안전한 결제 승인을 위해 특별히 맞춤화된 패스키의 원활한 교차 출처 사용을 가능하게 합니다. SPC는 결제 제공업체가 보안이나 사용자 경험을 저해하지 않으면서 여러 가맹점 사이트에서 사용자를 인증하는 방법을 표준화합니다. 그러나 Apple은 자사 생태계 내에서 Apple Pay가 가장 마찰 없는 선호되는 결제 솔루션으로 남도록 하기 위한 전략적 조치로 Safari 내에서 SPC 지원을 지속적으로 보류해 왔습니다. Apple의 SPC 채택 거부는 서드파티 컨텍스트에서 패스키의 광범위한 배포를 제한할 뿐만 아니라, 표준화된 결제 인증의 더 넓은 산업 채택을 효과적으로 지연시킵니다.

자세한 내용을 알고 싶다면 SPC에 대한 이 블로그 게시물을 읽어보세요.

또 다른 중요한 장벽은 교차 출처 iframes 내에서의 패스키 생성을 Apple이 의도적으로 제한하는 것과 관련이 있습니다. Safari는 서드파티 iframe에서 기존 패스키를 인증(navigator.credentials.get())에 사용하는 것은 허용하지만, 이러한 컨텍스트에서 패스키 등록(navigator.credentials.create())은 명시적으로 차단합니다.

이러한 제한은 가맹점 결제 플로우 중에 새로운 패스키를 원활하게 생성하는 데 의존하는 결제 제공업체를 심각하게 제약합니다. 결과적으로 제공업체는 리디렉션 기반 접근 방식을 사용하거나, 이전에 자사 도메인에서 직접 설정한 기존 패스키에 의존해야 합니다. Apple의 이 결정은 가맹점 통합의 실용성과 유동성에 직접적인 영향을 미치며, 소비자와 제공업체 모두에게 상당한 마찰 지점을 만듭니다.

이 접근 방식에서 가맹점은 귀사의 결제 제공업체 도메인(예: https://pay.provider.com)에서 제공되는 <iframe>에 결제 양식을 포함합니다. 사용자는 가맹점의 도메인(예: https://www.mystore.com)에 머무르면서 내장된 iframe에서 귀사의 결제 UI를 보고 신뢰 당사자 ID pay.provider.com에 바인딩된 패스키로 인증합니다.

주요 사항:

• 교차 출처: iframe이 다른 도메인에 있기 때문에, iframe 내에서 패스키 작업을 허용하려면 publickey-credentials-get 및 publickey-credentials-create에 대한 권한 정책을 구성해야 합니다.

• 생성 제한: 일부 브라우저(특히 구형 버전 및 Safari)는 여전히 교차 출처 iframe에서 패스키 생성을 허용하지 않습니다. 인증(navigator.credentials.get())은 더 널리 지원되지만, 등록(navigator.credentials.create())은 특정 환경, 특히 Safari에서 실패할 수 있습니다.

• 사용자 활성화: 패스키 플로우는 일반적으로 "일시적 활성화"(예: 사용자의 직접적인 버튼 클릭)가 필요합니다. iframe 인터페이스가 사용자가 시작한 이벤트 내에서 패스키 절차를 트리거하는지 확인해야 합니다.

• 보안 및 UX: iframe 접근 방식은 부드러운 인라인 결제 경험을 제공하지만, 사용자의 브라우저가 서드파티 쿠키나 로컬 스토리지를 차단하거나 제한하면 패스키 플로우가 중단될 수 있습니다.

리디렉션 기반 플로우를 사용하면 사용자를 가맹점 도메인에서 결제 도메인으로 보내거나, https://pay.provider.com/checkout과 같은 주소를 가리키는 새 탭/창을 엽니다. 그런 다음 패스키는 퍼스트파티 컨텍스트에서 귀사의 도메인에서 직접 생성되거나 사용됩니다.

주요 사항:

• 퍼스트파티의 단순성: 전체 패스키 워크플로우(생성, 인증)가 결제 제공업체의 도메인에서 발생하므로 교차 출처 제한이 없습니다. 모든 주요 브라우저는 퍼스트파티 컨텍스트에서 패스키 생성 및 로그인을 지원합니다.

• 리디렉션 UX: 사용자는 인증을 완료하기 위해 가맹점 페이지를 떠나거나 팝업을 보게 됩니다. 이는 덜 원활할 수 있지만, 패스키 아키텍처를 단순화하고 교차 출처 복잡성을 줄입니다.

• 호환되지 않는 브라우저를 위한 폴백: 패스키를 사용할 수 없는 경우(예: 구형 브라우저) 추가적인 교차 출처 권한 처리 없이 결제 도메인에서 대체 로그인 방법을 제공하여 정상적으로 대체할 수 있습니다.

네이티브 모바일 앱 내에 패스키를 통합하는 것은 웹 기반 시나리오에 비해 독특한 과제를 제시합니다. 가맹점용 네이티브 앱(iOS 및 Android 모두)은 원활한 사용자 경험을 유지하기 위해 내장된 WebView를 사용하여 애플리케이션 내에 결제 플로우를 포함하는 경우가 많습니다. 그러나 이러한 내장된 컨텍스트에서 서드파티 패스키 인증을 구현하는 것은 엄격한 브라우저 출처 정책 및 플랫폼별 제한으로 인해 문제가 될 수 있습니다.

패스키는 본질적으로 특정 도메인("신뢰 당사자 ID")에 바인딩되어 있으며, 이는 자격 증명이 관련 없는 웹사이트나 앱에서 오용될 수 없도록 보장하는 핵심 보안 원칙입니다. 결제 제공업체가 자체 도메인(예: pay.provider.com) 하에 패스키를 생성하면, 해당 패스키는 iOS와 Android 모두에서 해당 도메인으로 엄격하게 범위가 지정됩니다. 결과적으로, 가맹점의 네이티브 앱(자연스럽게 가맹점 자체 앱 식별자 및 도메인 하에서 작동)은 제공업체의 패스키를 "퍼스트파티" 자격 증명으로 직접 호출할 수 없습니다. 그렇게 하려면 개인 키의 교차 출처 공유가 필요한데, 이는 운영 체제와 WebAuthn 사양이 피싱 및 자격 증명 도용을 방지하기 위해 명시적으로 허용하지 않습니다.

기기 관점에서 볼 때, 가맹점의 네이티브 앱은 결제 제공업체의 도메인과 다른 "출처"입니다. 별도의 출처에 등록된 자격 증명에 대해 네이티브로 인증을 시도하면 패스키의 근본적인 출처 기반 보안 모델이 깨지게 됩니다. 이것이 바로 가맹점 컨텍스트에서 서드파티 패스키 사용이 시스템 브라우저나 시스템 기반 WebView(iOS의 ASWebAuthenticationSession 또는 Android의 Chrome 맞춤 탭 등)에 의존하는 이유입니다. 이러한 특수 플로우는 제공업체의 원래 도메인 컨텍스트를 보존하여 패스키가 안전하게 출처에 바인딩되도록 하면서도, 사용자가 가맹점 앱 내에서 결제 제공업체로 인증할 수 있도록 합니다. 다음 섹션에서는 이것이 어떻게 작동하는지 살펴보겠습니다.

내장된 WebView(예: iOS의 WKWebView 또는 Android의 WebView)는 앱이 웹 콘텐츠를 네이티브 인터페이스에 직접 내장할 수 있게 하여 긴밀한 통합과 UX 일관성을 제공하기 때문에 널리 선호됩니다. 그러나 이러한 내장 환경은 출처 및 보안 정책으로 인해 서드파티 패스키를 처리할 때 상당한 제약을 받습니다.

• 출처 불일치: 패스키는 안전한 자격 증명 처리를 위해 도메인 출처에 엄격하게 의존합니다. 내장된 WebView는 표시하는 콘텐츠의 도메인(종종 가맹점의 도메인) 하에서 작동하므로, 서드파티 결제 제공업체의 도메인에 명시적으로 연결된 패스키를 생성하거나 인증하기가 어렵거나 불가능합니다.

• 플랫폼 보안 제약: Apple(iOS)과 Google(Android) 모두 인증, 특히 보안 자격 증명을 다룰 때 내장된 WebView의 기능을 점진적으로 제한해 왔습니다. 이러한 제약은 사용자 개인 정보 보호와 보안을 보호하기 위해 설계되었지만, 서드파티 패스키 구현을 현저하게 더 복잡하게 만듭니다.

전반적으로, 내장된 WebView는 UX 관점에서 가맹점에게 매력적이지만, 강력한 서드파티 패스키 인증 플로우를 구현하는 데 상당한 실질적인 제한을 초래합니다.

내장된 WebView와 관련된 제한을 고려할 때, 결제 제공업체는 일반적으로 네이티브 모바일 앱에서 서드파티 패스키를 안정적으로 구현하기 위해 두 가지 대안 전략 중 하나를 채택합니다.

iOS (ASWebAuthenticationSession):

Apple은 호스트 애플리케이션의 컨텍스트 외부에서 안전한 브라우저와 유사한 환경으로 ASWebAuthenticationSession을 제공합니다. 이는 기본 Safari 브라우저와 쿠키 저장소를 공유하며, 자격 증명이 결제 제공업체의 출처 도메인과 일치하기 때문에 서드파티 패스키를 안정적으로 지원합니다.

다음 예는 BOSS 네이티브 앱 내에서 "PayPal로 결제" 기능을 보여줍니다. ASWebAuthenticationSession 시스템 웹뷰가 열리고, 이것이 Safari 쿠키와 상태를 공유하여 패스키 대화 상자가 즉시 시작되는 방법을 보여줍니다.

Android (Chrome 맞춤 탭):

마찬가지로, Android의 맞춤 탭은 일관된 패스키 생성 및 인증을 허용하는 거의 브라우저에 가까운 환경을 제공합니다. ASWebAuthenticationSession과 마찬가지로, 맞춤 탭은 가맹점 앱 컨텍스트와 별도로 실행되어 도메인 및 자격 증명 무결성을 보장합니다.

Android의 BOSS 네이티브 앱에서 동일한 예를 여기에서 확인하세요:

또 다른 접근 방식은 사용자를 네이티브 앱에서 모바일 기기의 기본 웹 브라우저(iOS의 Safari, Android의 Chrome)로 리디렉션하는 것입니다. 이는 결제 플로우, 즉 패스키 관리가 결제 제공업체의 도메인과 관련된 신뢰할 수 있는 퍼스트파티 컨텍스트에서 완전히 발생하도록 보장합니다. 사용자는 성공적인 인증 또는 결제 완료 후 가맹점 앱으로 돌아옵니다. 이 옵션은 사용자가 앱을 떠나야 하므로 고객에게 매우 불편합니다.

두 솔루션 모두 사용자를 가맹점의 네이티브 앱 환경에서 일시적으로 전환해야 합니다. 내장된 솔루션에 비해 약간 덜 원활하지만, 이러한 접근 방식은 서드파티 패스키 작업의 호환성, 보안 및 신뢰성을 크게 향상시킵니다.

궁극적으로, 네이티브 SDK를 개발하는 결제 제공업체는 사용자 경험 고려 사항과 실질적인 기술적 제약 사이에서 신중하게 균형을 맞춰야 합니다. 완전히 내장된 경험에 대한 가맹점의 선호에도 불구하고, 시스템 WebView 또는 외부 브라우저 리디렉션을 활용하는 것이 네이티브 앱 내에서 안전하고 신뢰할 수 있는 서드파티 패스키 인증을 보장하는 최선의 방법으로 남아 있습니다.

결제 SDK에 서드파티 패스키를 통합하기 위해 내장(iframe) 방식과 리디렉션 기반 방식 중 하나를 선택하는 것은 사용자 경험, 브라우저 호환성, 기술적 복잡성 및 가맹점 선호도 전반에 걸친 장단점을 평가하는 것을 포함합니다.

두 솔루션 모두 뚜렷한 장단점이 있으며, 결제 제공업체는 대상 시장, 원하는 UX 및 기술 인프라에 따라 신중하게 고려해야 합니다.

내장(iframe) 방식은 가맹점에게 매우 매력적인 원활한 가맹점 브랜드 사용자 경험을 제공하지만, 특히 Safari가 교차 출처 패스키 생성을 허용하지 않는 등 제한된 브라우저 호환성으로 인해 방해를 받습니다. 이러한 제한은 가맹점과 제공업체가 종종 기능성을 저해하거나 불완전한 패스키 등록 지원으로 이어지는 복잡한 해결책 기반 솔루션을 사용하도록 강요합니다.

반대로, 리디렉션 방식은 퍼스트파티 도메인 컨텍스트에서 작동하여 브라우저와 네이티브 모바일 플랫폼 전반에 걸쳐 포괄적인 호환성을 제공합니다. 이는 통합을 크게 단순화하고 신뢰성을 향상시키며 완전한 패스키 생성 및 인증 지원을 보장합니다. 주요 단점은 사용자를 가맹점 웹사이트나 앱에서 멀리 리디렉션함으로써 발생하는 잠재적인 마찰이지만, 이는 신중한 UX 설계, 명확하게 전달된 기대치 또는 Corbado와 같은 신뢰할 수 있는 플랫폼과의 통합으로 완화될 수 있습니다.

이러한 고려 사항을 감안할 때, 하이브리드 접근 방식이 종종 이상적이며, 결제 제공업체가 사용자의 브라우저가 지원할 때 내장 iframe 모델을 활용하고 그렇지 않은 경우 리디렉션 방식으로 정상적으로 폴백할 수 있도록 합니다. 이 결합된 전략은 다양한 환경에서 호환성, 가맹점 매력도 및 고객 만족도를 극대화합니다.

서드파티 패스키 결제 SDK를 구현하는 것은 사용자 경험, 브라우저 호환성, 네이티브 앱 제약, 분석 및 보안 사이의 균형을 맞추는 것을 포함합니다. 특히 Apple 관련 장애물(예: 교차 출처 패스키 생성 차단, SPC 지원 부재)을 고려할 때 더욱 그렇습니다. 아래는 웹 또는 네이티브 결제 플로우에 패스키를 통합할 때 최상의 결과를 보장하기 위한 주요 권장 사항입니다.

다양한 브라우저 지원과 일관성 없는 Apple의 동작 때문에, 내장(iframe 기반) 방식과 리디렉션 방식을 모두 지원하는 것이 중요합니다.

• Iframe 결제 (내장)

  • 교차 출처 패스키 작업을 허용하는 최신 브라우저(주로 인증용)에 원활한 페이지 내 경험을 제공합니다.

  • publickey-credentials-get/publickey-credentials-create에 대한 올바른 Permissions-Policy를 설정해야 합니다.

  • Safari 및 일부 구형 브라우저는 iframe에서 교차 출처 패스키 생성을 차단합니다.

• 리디렉션 플로우

  • 퍼스트파티 컨텍스트에서 패스키 등록과 로그인을 모두 안정적으로 지원합니다.

  • 추가 리디렉션이나 팝업으로 인해 마찰이 약간 더 있지만, 교차 브라우저 호환성을 위해 보편적으로 더 안전합니다.

  • 현재 iframe에서 서드파티 패스키 생성을 허용하지 않는 Safari에 이상적인 폴백입니다.

두 가지 접근 방식을 모두 제공함으로써, 어떤 것을 사용할지 동적으로 결정하거나 가맹점이 결정하게 하여 모든 사용자 환경에 대한 호환성을 극대화할 수 있습니다.

User-Agent 세분성 감소와 플랫폼 전반에 걸친 Client Hints의 일관성 없는 지원으로 인해 브라우저 기능을 정확하게 감지하는 것은 여전히 어렵습니다.

브라우저가 사용자 개인 정보 보호를 위해 User-Agent 문자열의 세부 정보를 줄임에 따라 전통적인 파싱은 점점 더 신뢰할 수 없게 되고 있습니다. Windows 10 대 Windows 11, 정확한 macOS 버전 또는 CPU 아키텍처와 같은 필수 세부 정보를 구별하는 것은 이제 User-Agent만으로는 어렵거나 불가능합니다.

Client Hints는 개인 정보를 존중하는 방식으로 높은 엔트로피 데이터를 제공하지만, Chromium 기반 브라우저만 이를 완전히 지원합니다. Safari와 Firefox는 Client Hint를 지원하지 않아 Apple 기기에서의 정밀한 기능 감지를 심각하게 제한합니다.

내장된 WebView는 일반적으로 상세한 기기 정보에 대한 액세스를 제한하며 Client Hints를 거의 지원하지 않습니다. 이러한 제한은 네이티브 앱 컨텍스트 내에서 패스키 기능 감지를 특히 어렵게 만듭니다.

이러한 제약을 고려할 때, 특히 서드파티 결제 SDK에서 교차 출처 패스키 지원을 안정적으로 감지하려면 동적 Client Hint 쿼리(사용 가능한 경우), 폴백 User-Agent 휴리스틱, 그리고 Safari 및 Firefox와 같은 브라우저에 대한 보수적인 기본 동작의 신중한 조합이 필요합니다.

네이티브 가맹점 앱은 종종 WKWebView(iOS) 또는 Android WebView에 웹 콘텐츠를 내장하는데, 이는 패스키에 매우 제한적입니다. 일반적인 전략은 다음과 같습니다.

• 시스템 브라우저 세션: ASWebAuthenticationSession(iOS) 또는 맞춤 탭(Android)을 사용하여 패스키 생성/로그인을 안전한 "퍼스트파티" 브라우저 컨텍스트로 전환합니다.

• 기본 브라우저로 리디렉션: 덜 원활하지만 패스키 작업의 도메인 무결성을 보장하는 매우 신뢰할 수 있는 접근 방식입니다.

결제 제공업체로서 강력한 보안 및 규제 준수(PCI, PSD2 SCA 등)는 핵심입니다.

• 헤더 및 콘텐츠 보안: 교차 출처 플로우에 대해 엄격한 Permissions-Policy 헤더와 강력한 CSP 규칙을 구현합니다.

• 로깅 및 모니터링: 사기 방지 및 규정 준수 감사를 위해 패스키 생성 및 사용 이벤트를 철저히 기록합니다.

• 최소한의 PII 저장: 해시된 식별자를 사용하여 사용자를 패스키에 매핑하여 GDPR 또는 유사한 데이터 보호법에 따른 노출을 줄입니다.

• 감사 추적: 각 패스키 생성 및 인증 이벤트를 기록하여 이상 징후를 감지하고 규정 준수 감사를 만족시킵니다.

패스키는 여전히 진화하고 있으므로 지속적인 확인이 필요합니다.

• 교차 브라우저 및 교차 OS 테스트: Safari, Chrome, Edge, Firefox 및 주요 모바일 OS 버전에서 테스트를 자동화합니다.

• 잦은 업데이트: W3C WebAuthn 사양, FIDO Alliance 가이드라인 또는 SPC 제안의 변경 사항을 추적합니다.

• 사용자 피드백 및 오류율: 패스키 오류(생성 또는 로그인)를 기록하여 특히 Apple 기반 사용자의 문제를 신속하게 해결합니다.

강력한 KPI 프레임워크는 서드파티 패스키 통합이 실제로 보안과 사용자 경험을 개선하는지 추적하는 데 도움이 됩니다. 이 기사는 SDK 구현에 관한 것이지만, 이 사용 사례에서도 패스키 채택이 핵심이라는 점을 명심하는 것이 중요합니다. 패스키의 생성률과 사용률은 신중한 분석과 최적화가 필요합니다.

• 정의: 요청 시(예: 결제 또는 계정 설정 시) 성공적으로 패스키를 생성하는 사용자의 비율입니다.

• 중요한 이유: 높은 생성률은 패스키에 대한 온보딩/넛지 플로우가 매력적이고 마찰이 없음을 의미합니다.

• 목표: 50-80%의 비율을 목표로 해야 합니다.

• 정의: 생성 절차를 시작한 사용자( "패스키 생성" 클릭) 중 중단이나 오류 없이 완료하는 사용자는 몇 명입니까?

• 중요한 이유: 교차 출처 또는 리디렉션 플로우가 얼마나 잘 작동하는지 나타냅니다.

• 목표: 이상적으로는 사용자가 옵트인하면 ~95–100%의 수치를 가져야 합니다.

• 정의: 폴백 방법과 대조적으로 패스키를 통해 수행되는 총 결제 승인(또는 로그인)의 비율입니다.

• 중요한 이유: 사용자가 이전 방법으로 되돌아가면 생성은 의미가 없습니다.

• 목표: 50–80%의 비율은 강력한 패스키 채택을 의미합니다.

• 정의: 오류나 폴백 없이 성공하는 패스키 로그인 시도의 비율입니다.

• 중요한 이유: 실제 사용성의 반영입니다.

• 목표: 일반적으로 패스키를 "마찰 없음"으로 간주하려면 90–95%를 초과해야 합니다.

• 정의: 사용자가 절차 중간에 패스키에 실패하고 비밀번호나 OTP로 전환하는 빈도는 얼마입니까?

• 중요한 이유: 높은 폴백 사용은 기술적 또는 UX 장애물이 패스키가 레거시 방법을 대체하는 것을 막고 있음을 시사합니다.

• 목표: 이상적으로 폴백 사용은 1-5% 미만입니다.

결제 제공업체의 경우, 패스키가 사기를 줄이고, 결제를 가속화하거나, 장바구니 이탈을 낮추는지 측정합니다. 전체적인 관점을 위해 패스키 사용 데이터를 결제 전환 또는 3-D Secure 성공 지표와 결합합니다.

이러한 KPI를 모니터링하면 어떤 환경이나 사용자 여정에 개선이 필요한지 정확히 파악하는 데 도움이 됩니다. 예를 들어, Safari iOS가 교차 출처 차단으로 인해 이탈률이 더 높다면 해당 사용자를 체계적으로 리디렉션 플로우로 유도할 수 있습니다.

서드파티 패스키 SDK를 구축하는 데 있어 가장 중요한 과제 중 하나는 사용자가 실제로 패스키를 등록하는 원활하고 일관된 생성 플로우를 조율하는 것입니다. 이것이 은행 포털에서 발생하든, 결제 제공업체의 자체 계정 설정 내에서 발생하든, 또는 가맹점의 결제 페이지에서 바로 발생하든, 핵심 패스키 등록 단계는 매우 유사합니다. 결과적으로, 패스키 생성에 대한 접근 방식은 플로우를 iframe에 내장하든 사용자를 퍼스트파티 페이지로 리디렉션하든 근본적으로 변하지 않습니다. 가장 중요한 것은 명확하고 사용자 친화적인 화면을 제공하고, 교차 출처 제약을 관리하며, 사용자가 패스키를 얼마나 효과적으로 채택하는지 보여주는 필수 지표를 추적하는 것입니다. 아래는 모범 사례 패스키 생성 플로우의 주요 측면과 Corbado가 이를 어떻게 지원하는지 설명합니다.

사용자가 패스키를 생성하라는 메시지를 받는 위치가 은행의 온라인 뱅킹 환경이든, 결제 제공업체의 자체 웹사이트/앱이든, 가맹점의 결제 페이지이든 상관없이 Corbado는 사용자 프롬프트, 성공 확인 및 오류 처리를 위한 사전 구축된 맞춤형 구성 요소를 제공합니다.

이러한 구성 요소는 일관된 모양과 느낌을 보장하면서 화이트 라벨 브랜딩을 허용하여 각 은행이나 가맹점이 필요한 경우 고유한 디자인 요소를 유지할 수 있도록 합니다.

VicRoads 디자인으로 브랜딩된 패스키 생성 화면에 대한 다음 UI 구성 요소를 참조하세요.

Corbado는 모든 생성 엔드포인트에서 데이터를 수집하고 통합합니다.

• 패스키가 처음 제공되는 은행 웹사이트 또는 앱.

• 사용자가 자격 증명을 관리할 수 있는 결제 제공업체의 개인 계정 설정.

• 선택적으로 "즉석에서" 패스키 생성을 허용하는 가맹점 결제 페이지.

이 통합된 접근 방식을 통해 어떤 채널이 패스키 등록을 시작하든 상관없이 패스키 생성률, 생성 성공률, 사용자 이탈 지점 및 모든 기술적 오류를 쉽게 측정할 수 있습니다.

Corbado는 화면 지침, 버튼 텍스트 및 프롬프트 타이밍을 미세 조정하기 위한 A/B 테스트 기능을 제공합니다. 문구의 미묘한 변경(예: "지금 패스키를 생성하세요 - 더 이상 비밀번호는 필요 없습니다!" 대 "패스키로 다음 결제를 보호하세요!")은 종종 사용자 수용도에 상당한 차이를 가져옵니다.

A/B 테스트 결과를 바탕으로 다음 KPI를 최적화할 수 있습니다.

• 생성률: 프롬프트를 받은 사용자 중 성공적으로 패스키를 설정한 비율.

• 생성 성공률: 절차를 중단하거나 오류 없이 완료한 사용자의 비율.

• 폴백 사용: 사용자가 이전 로그인 방법을 선호하여 패스키 생성을 건너뛰는 비율.

• 전환 영향: 가맹점의 경우, 결제 시 패스키 생성이 장바구니 이탈을 줄이는지 측정합니다.

사용자는 다음 컨텍스트에서 패스키를 생성할 수 있습니다.

• 은행 컨텍스트: 사용자가 은행에 로그인한 후 트리거되는 생성 플로우로, 뱅킹 환경의 신뢰와 친숙함을 활용합니다.

• 결제 제공업체 계정 설정: 사용자는 결제 제공업체 도메인의 "내 프로필" 또는 "보안" 설정에서 직접 패스키를 설정합니다.

• 가맹점 결제: 최종 결제 단계에서 프롬프트, 특히 사용자가 이전에 패스키를 생성하지 않은 경우. 이는 내장(iframe) 또는 리디렉션을 통해 가능합니다.

각 시나리오에서 기본 패스키 절차는 동일한 단계를 따릅니다 - 사용자 확인, 생체 인식/PIN 프롬프트 및 자격 증명 등록. Corbado의 SDK는 교차 출처 제약(내장된 경우) 또는 퍼스트파티 도메인 컨텍스트(리디렉션된 경우)가 백그라운드에서 원활하게 처리되도록 보장합니다.

Corbado는 각 새 패스키를 적절한 사용자 식별자(예: "bankPrefix_userId" 또는 결제 제공업체 시스템의 내부 사용자 참조)에 연결하여 모든 후속 사용이 올바른 사용자 계정으로 추적될 수 있도록 합니다.

이 메타데이터는 고급 분석에도 중요합니다. 예를 들어, RBC의 패스키 생성 캠페인이 TD와 비교하여 어떻게 수행되는지, 또는 가맹점 결제와 직접적인 "계정 설정" 플로우 간에 생성률이 어떻게 다른지 확인할 수 있습니다.

동일한 Corbado SDK 로직은 교차 출처 패스키 생성이 허용되는지(최신 Chrome 또는 Edge에서) 또는 Safari의 경우 리디렉션으로 정상적으로 전환해야 하는지에 따라 적응할 수 있습니다.

내장된 오류 보고는 특정 사용자 하위 집합이 지속적으로 패스키 생성에 실패하는지(예: 구형 iOS 버전, 기업용 Windows 장치) 식별하는 데 도움이 되므로 제품 팀이 지침이나 폴백 전략을 구체화할 수 있습니다.

우리 팀은 기업 고객과 함께 광범위한 패스키 생성 실험을 수행하여 어떤 문구, 버튼 배치 및 타이밍이 최고의 채택률을 가져오는지 배웠습니다.

우리는 이러한 모범 사례를 모든 생성 화면에 통합하면서도 브랜딩 및 규정 준수 요구 사항에 대한 완전한 사용자 정의를 허용합니다.

전반적으로, 패스키 생성은 높은 채택률을 보장하는 가장 중요한 단계입니다. 가장 우아한 패스키 로그인 플로우라도 사용자가 애초에 자격 증명을 등록하지 않으면 소용이 없습니다. Corbado는 은행, 결제 제공업체 도메인 또는 가맹점 결제 등 모든 가능한 채널에 걸쳐 통일되고 추적 가능한 생성 화면을 제공하고 KPI 분석 및 A/B 테스트를 통해 이를 계측함으로써 결제 제공업체가 Apple Pay와 같은 네이티브 솔루션의 사용자 경험을 모방하여 진정으로 확장 가능한 패스키 채택을 주도하도록 돕습니다.

사용자가 패스키를 생성한 후 다음 단계는 Apple Pay가 Apple Pay 결제 플로우를 제시하는 것처럼 빠르고 마찰 없는 결제를 위해 실제로 해당 패스키를 사용하도록 하는 것입니다.

Corbado에서는 사용자의 환경에 유효한 패스키가 있을 가능성이 높을 때 자동으로 감지하여 진정한 원탭 결제 경험을 가능하게 하는 "Passkey Intelligence" 메커니즘을 개발했습니다. 아래는 이를 가능하게 하는 핵심 요소입니다.

재방문 사용자가 인식되면 Corbado의 프런트엔드는 폴백 자격 증명 입력을 강요하는 대신 전용 버튼(예: "패스키로 결제")을 표시합니다.

이 버튼을 한 번 탭하면 WebAuthn get() 플로우(또는 네이티브 패스키 프롬프트)가 트리거되어 사용자가 추가 단계나 양식 입력 없이 생체 인식/PIN을 통해 즉시 인증할 수 있습니다.

Corbado의 SDK는 신호(예: 로컬 스토리지 쿠키, 이전의 성공적인 패스키 사용, 환경 감지)를 수집하여 현재 장치 + 브라우저에 이 사용자에 대한 유효한 패스키가 있을 가능성이 있는지 예측합니다.

쿠키가 삭제되거나 사용할 수 없는 경우 Corbado는 추가 휴리스틱(예: 사용자의 기존 알려진 환경, 가맹점이 제공한 사용자 힌트)으로 폴백하여 패스키 플로우를 자동으로 시작하는 것이 안전한지 결정합니다.

패스키가 존재한다는 충분한 증거가 없는 경우 UI는 정상적으로 폴백 플로우를 제공하거나 사용자에게 패스키가 있는지 확인하도록 요청합니다.

Corbado는 전체 이메일이나 이름과 같은 개인 식별 정보(PII)를 저장하지 않습니다.

대신, 가맹점은 해시되거나 마스킹된 식별자(예: 이메일 해시 또는 내부 사용자 ID)를 전달할 수 있습니다. Corbado는 이를 사용하여 잠재적인 패스키 등록을 조회한 다음 패스키 인증을 시작할지 또는 더 일반적인 접근 방식으로 되돌릴지 결정합니다. 결제 제공업체에서 지원하는 경우 가맹점이 제공한 정보를 조회하여 내부 사용자 ID를 조회할 수 있습니다.

이는 여전히 높은 정확도의 환경 매칭을 허용하면서 사용자 개인 정보 보호를 보장합니다.

사용자의 패스키가 존재했지만 감지할 수 없는 시나리오(예: 쿠키가 지워짐, 새 장치)에서 Corbado의 Passkey Intelligence는 패스키 프롬프트를 자동으로 시작하는 것이 합리적인지 신중하게 분석합니다.

대신, 사용자는 대체 폴백 플로우나 "다른 장치에서 패스키 스캔" 옵션을 보게 되며, 사용자가 수동으로 패스키가 있음을 확인할 수 있는 경우 패스키 사용으로 빠르게 돌아갈 수 있는 경로를 유지합니다.

Corbado가 원탭 패스키 프롬프트를 시작하거나 건너뛰기로 결정할 때마다 해당 결정이 기록됩니다. 시간이 지남에 따라 어떤 브라우저나 장치 유형이 가장 높은 패스키 커버리지를 보이는지, 그리고 어떤 것이 자주 폴백으로 되돌아가는지 정확하게 볼 수 있습니다.

이 분석 피드백 루프를 통해 성능이 저조한 환경(예: 특정 iOS 또는 Android 버전)이나 패스키 사용이 낮은 사용자 세그먼트를 식별하여 온보딩 또는 교육 전략을 구체화할 수 있습니다.

사용자가 은행의 패스키 생성 캠페인에서 오든 가맹점의 결제에서 직접 오든, 원탭 로직은 일관되게 유지됩니다.

Corbado는 패스키가 발견되면(도메인 쿠키, 로컬 스토리지 토큰 또는 passkey intelligence 신호 기반) 사용자에게 즉시 가장 마찰 없는 로그인/결제 플로우를 제시하도록 보장합니다.

요약

요컨대, 원탭 패스키 사용은 애초에 패스키를 생성한 것에 대한 궁극적인 보상입니다. Passkey Intelligence(환경 감지, 최소한의 PII 사용 및 폴백 로직의 혼합)를 활용하여 Corbado는 사용자가 성공할 가능성이 높을 때만 패스키 인증을 제시하도록 보장합니다. 이는 실패한 시도를 극적으로 줄이고 사용자 불만을 피하며 습관 형성적인 패스키 사용을 촉진하여 Apple Pay나 다른 네이티브 결제 경험의 편의성에 필적하는 원탭 결제 플로우로 귀결됩니다.

단순히 패스키를 활성화하는 것 이상으로, 다양한 장치, 브라우저 및 사용자 여정에서 패스키가 얼마나 효과적으로 채택되고 사용되는지 이해하는 것이 중요합니다. 결제 제공업체는 패스키가 실제로 마찰을 줄이고, 사기를 줄이며, 전환을 개선하는지에 대한 확실한 데이터가 필요합니다. 패스키 구매 대 구축 가이드 모범 사례를 바탕으로 Corbado는 실시간으로 패스키 성능을 추적, 세분화 및 최적화할 수 있는 풍부한 분석 계층을 제공합니다.

아래는 주요 하이라이트입니다.

Corbado는 모든 패스키 이벤트를 퍼널로 구성합니다: 사용자가 패스키를 생성하라는 메시지를 받는 순간부터 성공적인 등록, 후속 로그인/결제(패스키 사용)까지.

이 퍼널 시각화를 통해 사용자가 어디에서 이탈하는지 확인할 수 있습니다. 예를 들어, 얼마나 많은 사용자가 생성을 시작하지 않는지, 얼마나 많은 사용자가 절차 중간에 포기하는지, 또는 얼마나 많은 사용자가 로그인 시 폴백 방법으로 되돌아가는지.

기업이 패스키를 구현하는 데 도움을 준 광범위한 경험을 바탕으로, 우리는 ROI와 사용자 만족도에 직접적인 영향을 미치는 지표에 중점을 둡니다.

• 패스키 수락률: 생성 프롬프트를 본 사용자 중 실제로 패스키 등록을 완료하는 사용자는 몇 명입니까?

• 패스키 생성 성공률: 절차를 시작한 사용자( "패스키 생성" 클릭) 중 오류나 포기 없이 완료하는 비율은 얼마입니까?

• 패스키 사용률: 재방문 사용자가 일상적인 인증이나 결제에 비밀번호나 OTP 대신 실제로 패스키를 얼마나 자주 선택합니까?

• 패스키 로그인 성공률: 폴백이나 사용자 불만 없이 성공하는 패스키 시도의 비율입니다.

• 폴백 사용: 패스키 플로우를 시작했지만 이전 방법으로 되돌아가는 사용자는 몇 명입니까? 이는 잠재적인 UX 또는 기술적 장벽을 나타냅니다.

Corbado는 각 이벤트에 운영 체제(Windows, macOS, iOS, Android) 및 브라우저(Chrome, Safari, Edge, Firefox 등)를 자동으로 태그합니다.

이 세분화를 통해 예를 들어 iOS Safari의 패스키 포기율이 더 높은지, 또는 Windows Chrome이 더 나은 패스키 채택률을 보이는지 확인할 수 있습니다.

이 데이터는 또한 폴백 전략을 미세 조정하는 데 도움이 됩니다. 특히 Apple의 교차 출처 제한이 예상보다 사용자 기반에 더 많은 영향을 미치는 경우에 그렇습니다.

우리는 패스키 퍼널의 각 단계에 대한 대시보드 뷰를 제공합니다: 생성 프롬프트, 성공적인 등록, 사용자 로그인, 폴백 사용.

실시간 차트를 통해 제품 관리자는 추세를 신속하게 파악할 수 있습니다(예: 새 OS 업데이트가 패스키 플로우를 깨뜨리는 경우).

자동화된 알림은 패스키 성공률이 크게 떨어지면 팀에 알려주므로 새로운 브라우저 버그나 구성 문제를 신속하게 조사할 수 있습니다.

모든 패스키 플로우(생성에서 로그인까지)는 타임스탬프가 찍힌 단계별 이벤트로 기록되어 심층적인 포렌식 분석이 가능합니다.

사용자 해시, 세션 ID 또는 장치 서명으로 신속하게 검색하여 사용자가 어디에서 어려움을 겪었는지 또는 어떤 오류 코드가 반환되었는지 정확하게 확인할 수 있습니다.

이는 일화적인 지원 티켓에 의존할 수 없고 사용자 문제를 해결하기 위해 정확한 데이터가 필요한 대규모 출시에서 중요합니다.

Corbado의 분석 플랫폼은 패스키 퍼널에 통합된 A/B 테스트를 지원합니다: 결제 플로우에서 다른 CTA 텍스트, 생성 프롬프트, 폴백 메시지 또는 "패스키 생성" 버튼의 배치를 테스트합니다.

"패스키 수락률" 또는 "폴백률"과 같은 지표는 각 변형에 대해 나란히 측정할 수 있습니다.

이 접근 방식은 시간이 지남에 따라 플로우를 개선하는 선도적인 패스키 채택자의 성공을 모방하여 지속적인 개선을 보장합니다.

Corbado의 대시보드는 즉시 사용 가능한 시각적 인터페이스를 제공하지만, 주요 데이터 포인트(예: 패스키 생성 성공, 로그인)를 BI 또는 SIEM 도구로 내보내거나 웹훅으로 보낼 수도 있습니다.

이를 통해 결제 제공업체는 패스키 KPI를 더 넓은 분석 스위트에 통합하여 다른 보안, 마케팅 또는 운영 지표와 함께 패스키의 ROI를 추적할 수 있습니다.

요약

OS/브라우저 조합, 생성 플로우 및 로그인 시나리오 전반에 걸쳐 패스키 여정의 모든 단계를 측정하고 시각화함으로써 Corbado는 패스키 제공을 지속적으로 개선하는 데 필요한 통찰력을 제공합니다. 이러한 분석은 패스키가 활성화되었음을 확인하는 데 그치지 않고, 사용자가 실제로 대규모로 채택하고 있는지 증명하고, 마찰 지점을 식별하며, 패스키가 안전하고 마찰 없는 결제를 위해 진정으로 비밀번호를 대체하는 지점까지 사용률을 높이는 데 도움이 됩니다.

결제 제공업체의 경우, 사용자당 하나의 패스키를 생성하는 것만으로는 진정으로 원활한 인증 경험을 제공하기에 충분하지 않은 경우가 많습니다. 실제로는 사용자가 직장의 노트북에서 개인 스마트폰, 태블릿, 심지어 공유 가족 컴퓨터에 이르기까지 장치를 자주 전환합니다. 모든 장치가 동일한 계정에 대해 유효한 패스키를 갖도록 보장하는 것은 마찰을 줄이고 비밀번호로의 폴백을 방지하는 데 중요합니다. Apple Pay는 모든 iCloud 연결 장치에서 iCloud 계정을 활용할 수 있어 이를 달성합니다.

아래는 Corbado가 사용자 수명 주기 동안 다중 장치 커버리지를 유지하는 데 어떻게 도움이 되는지 설명합니다.

• 기본 패스키 생성 화면: Corbado는 처음에 각 사용자가 결제 플로우를 처음 접하는 곳(예: 결제 시, 은행의 온라인 포털 또는 계정 설정)에서 최소한 하나의 패스키, 즉 "기본" 패스키를 등록하도록 하는 데 중점을 둡니다.

• 보조 패스키 생성 화면: 사용자가 첫 번째 패스키를 성공적으로 등록한 후 다른 장치에서의 후속 로그인은 자동으로 짧은 "이 장치 추가" 플로우를 프롬프트할 수 있습니다. 이를 통해 사용자는 비밀번호를 다시 입력하거나 폴백 방법으로 전환하지 않고도 모든 관련 장치에서 신속하게 마찰 없는 패스키 액세스를 얻을 수 있습니다.

사용자가 한 장치에 패스키가 있더라도 두 번째 장치에는 로컬 패스키가 없는 것처럼 보일 수 있습니다(새 OS 설치, 쿠키 삭제 또는 해당 장치에서 패스키를 생성한 적이 없는 경우).

Corbado의 접근 방식은 종종 하이브리드 단계를 사용합니다: 사용자는 휴대폰의 기존 패스키나 폴백 방법으로 로그인한 다음 현재 장치에 패스키를 생성하여 즉시 격차를 "치유"할 수 있습니다.

이 자가 복구 프로세스는 커버리지를 높게 유지하고 향후 반복적인 폴백 사용을 제거하는 데 도움이 됩니다.

교차 장치 신호와 Corbado의 "Passkey Intelligence"를 통해 시스템은 기존 패스키를 가진 사용자가 등록되지 않은 장치로 전환했음을 감지할 수 있습니다.

UX 전략이 최대 커버리지를 목표로 하는 경우 Corbado는 자동으로 프롬프트할 수 있습니다: "다음에 폴백하지 않도록 이 장치에 패스키를 추가하시겠습니까?"

사용자는 일회성 장치에 있는 경우 이를 건너뛸 수 있지만, 일반적으로 패스키 기반 생체 인식 로그인의 편리함을 설명하면 고마워합니다.

Corbado의 SDK는 "첫 패스키 생성"(즉, 사용자가 처음으로 자격 증명을 등록하는 경우)과 "보조 장치" 생성에 대해 별개의 화면 플로우를 제공합니다.

메시지는 다를 수 있습니다. 예: "이 새 장치를 패스키로 보호하세요" 대 "첫 패스키를 설정하세요."

이는 최종 사용자에게 명확성을 보장하여 초기 등록과 추가 장치로의 커버리지 확장 간의 차이점을 이해하도록 합니다.

때로는 패스키 생성이 절차 중간에 실패하거나 사용자의 OS가 오래되었을 수 있습니다. 이러한 시나리오에서 Corbado는 부분적인 시도를 기록하고 가능한 해결책(리디렉션, 수동 폴백 또는 교차 장치 QR 플로우)을 정상적으로 제안합니다.

사용자는 다음 로그인 시도 시 해당 장치에 패스키를 다시 추가하거나 다른 장치의 기존 패스키에 의존할 수 있습니다.

Corbado의 분석은 처음에 얼마나 많은 사용자가 패스키를 생성했는지뿐만 아니라 얼마나 많은 사용자가 여러 장치로 패스키를 확장했는지도 보여줍니다.

장치 커버리지 비율(예: 1개 장치 대 2개 이상)을 추적하고 이것이 폴백 사용 감소 또는 결제 성공 개선과 어떻게 상관관계가 있는지 확인할 수 있습니다.

이는 팀이 다중 장치 패스키 보급률을 높이기 위해 사용자 교육, 앱 프롬프트 또는 은행 기반 등록 플로우의 우선순위를 정하는 데 도움이 됩니다.

요약: 다중 장치 커버리지가 중요한 이유

모든 사용자 장치에 걸쳐 일관된 커버리지가 없으면 사용자가 "패스키 없는" 장치에 있을 때마다 폴백 인증 수단으로 강제될 위험이 있습니다. 이는 마찰 없는 경험을 깨뜨리고 운영 비용을 높게 유지합니다(예: SMS 요금, 지원 오버헤드). 보조 패스키 생성 화면, 하이브리드 폴백 치유 및 환경 기반 프롬프트를 제공함으로써 Corbado는 모든 사용자가 결국 사용하는 모든 장치에서 패스키를 유지할 수 있도록 보장하여 전반적인 채택률을 높이고 실망스러운 폴백 순간을 최소화합니다.

서드파티 패스키 SDK를 구축할 때 가장 큰 오해 중 하나는 가장 어려운 부분이 WebAuthn 호출(예: navigator.credentials.create() 또는 navigator.credentials.get())을 구현하는 것이라고 생각하는 것입니다.

실제로 이것은 "쉬운" 부분입니다. 기본 절차를 트리거하기 위한 한두 개의 API 호출입니다. 진정한 복잡성과 성공의 실제 결정 요인은 대규모 채택을 보장하고 해당 API 호출을 중심으로 완전한 생태계를 구축하는 데 있습니다.

아래는 패스키 구매 대 구축 가이드에 의해 강화된 핵심 사항으로, 최소한의 절차 전용 구현이 종종 실제 결과를 제공하지 못하는 이유를 강조합니다.

• 절차 구현: 패스키를 생성하거나 인증하는 것은 일반적으로 navigator.credentials.create() 또는 navigator.credentials.get()을 호출하기 위한 몇 줄의 JavaScript만 포함합니다.

• 실제 복잡성: 패스키 플로우가 많은 브라우저에서 작동하도록 보장하고, 실패를 정상적으로 처리하며, 구형 시스템에 대한 폴백을 제공합니다. 또한 강력한 세션 관리, 오류 로깅, 분석, 장치 커버리지 전략 등이 필요합니다.

• 예상치 못한 함정: 패스키의 "기술 데모"를 넘어서면 교차 출처 차단, 내장된 WebView 제한 및 다중 장치 동기화 복잡성과 같은 엣지 케이스를 발견하게 됩니다. 이것들은 순진한 자체 구축을 탈선시키는 미지의 미지수입니다.

• 절차 대 채택: 완벽한 WebAuthn 절차를 가지고 있더라도 낮은 사용자 채택률(예: <5% 패스키 사용률)은 최소한의 보안 또는 UX 이점만 가져올 것입니다.

• 전체론적 접근: 성공적인 패스키 출시는 매력적인 사용자 프롬프트와 A/B 테스트된 카피라이팅에서부터 다중 장치 커버리지 플로우, 폴백 처리 및 지속적인 분석에 이르기까지 모든 것을 요구하며, 이는 기본 절차 호출을 훨씬 뛰어넘습니다.

• 구매 대 구축 가이드의 통찰력: 이 가이드는 패스키를 활성화하는 것뿐만 아니라 패스키 채택을 주도하는 것이 궁극적으로 ROI를 결정한다고 강조합니다. 사용자가 등록하고 적극적으로 패스키를 사용하지 않으면 프로젝트는 전환율 개선 없이 "MFA 2.0"에서 사실상 정체됩니다.

• 불완전한 폴백 및 오류 처리: 고급 폴백 로직이나 실시간 디버깅이 없으면 사용자 잠금 및 더 높은 지원 비용으로 이어질 수 있습니다.

• 단편적인 다중 장치 커버리지: 추가 장치를 동기화하거나 패스키 격차를 "치유"할 계획이 없으면 사용자는 플랫폼을 전환할 때마다 비밀번호로 되돌아갑니다.

• 제한된 분석 및 A/B 테스트: 패스키 생성 퍼널이나 환경 사용에 대한 데이터가 부족하면 채택률을 체계적으로 개선하거나 새로운 브라우저 특성을 신속하게 해결할 수 없습니다.

• 사전 구축된 UI 및 모범 사례: 단순히 절차 엔드포인트를 노출하는 대신, 적절한 솔루션(Corbado와 같은)은 화이트 라벨 화면, 폴백 플로우, 오류 처리 및 교차 장치 커버리지를 번들로 제공합니다.

• 적응형 인텔리전스 및 로깅: 가능성 있는 패스키 존재를 자동 감지하고, 사용자가 누락된 패스키를 생성하거나 수정하도록 안내하며, 세분화된 이벤트 로그를 캡처합니다.

• 채택 중심의 "미지의 미지수": 이메일 기반 폴백이나 기업 장치를 처리하는 방법과 같은 많은 세부 사항은 사용자가 실제 배포에서 마주치기 전까지는 명확하지 않습니다.

• 채택 전략에 대한 심층 분석: 패스키 구매 대 구축 가이드는 비용, 시장 출시 시간 및 강력한 패스키 솔루션의 숨겨진 복잡성 간의 균형을 맞추는 방법을 강조합니다.

• 실제 벤치마크: 주요 은행 및 전자 상거래 제공업체의 대규모 출시가 "간단한" 절차 로직을 코딩한 후에 발생하는 미지의 미지수를 어떻게 극복했는지 알아보세요.

• 지속적인 성공: 입증된 채택 패턴을 가진 기존 플랫폼에 투자하면 바퀴를 재발명하고 그 과정에서 비용이 많이 드는 놀라움을 발견하는 데 갇히지 않도록 보장합니다.

요약

단순히 WebAuthn 절차를 연결하는 것만으로는 의미 있는 패스키 채택을 달성하기에 충분하지 않습니다. 진정한 성공은 폴백, 분석, 다중 장치 확장 및 A/B 테스트된 사용자 여정과 같은 엔드투엔드 플로우를 조율하는 데 달려 있습니다. "단순한 절차"를 넘어서는 미묘한 복잡성을 해결함으로써 패스키 프로젝트를 기술적 호기심에서 진정으로 마찰 없고 널리 사용되며 비용을 절감하는 인증 솔루션으로 전환할 수 있습니다.

교차 출처 플로우, 사용자 채택 및 패스키 수명 주기 관리와 관련된 복잡성 외에도 호스팅 및 배포 고려 사항은 모든 대규모 패스키 솔루션에 중요합니다. 결제 제공업체는 종종 지역에 따라 크게 다를 수 있는 엄격한 규정 준수, 데이터 상주 요구 사항 및 복원력 요구 사항을 다룹니다. 아래는 Corbado(또는 유사하게 강력한 솔루션)가 이러한 우려를 어떻게 해결하는지 설명합니다.

데이터 주권 또는 규제 프레임워크(예: 유럽의 GDPR, 캐나다의 PIPEDA 또는 미국의 NIST/HIPAA)를 준수하기 위해 일부 제공업체는 특정 지리적 경계 내에 데이터를 보관해야 합니다.

지역 무관 아키텍처는 패스키 서비스를 원하는 AWS 지역에 배포하여 성능이나 확장성을 희생하지 않고 현지 규정 준수 요구 사항을 충족할 수 있도록 보장합니다.

이러한 유연성은 사용자 기반이 여러 국가에 걸쳐 있고 각 국가가 다른 데이터 처리 규칙을 시행하는 경우 특히 중요합니다.

중요한 결제 인증 플로우의 경우 다운타임은 선택 사항이 아닙니다. Corbado는 다중 AZ 배포를 사용하여 여러 가용 영역에 주요 구성 요소를 분산시킵니다.

이 설정은 한 AZ에서 중단이나 연결 문제가 발생하더라도 다른 영역의 패스키 인프라가 온라인 상태를 유지하여 사용자가 계속 인증할 수 있도록 보장합니다.

그 결과, 짧은 다운타임도 상당한 수익 영향으로 이어질 수 있는 금융 서비스 및 전자 상거래 사이트에 대한 엄격한 SLA를 충족하는 더 탄력적인 시스템이 됩니다.

일부 결제 제공업체는 더 엄격한 데이터 격리, 맞춤형 규정 준수 확인 또는 패치 및 업데이트에 대한 더 깊은 제어를 위해 개인 전용 클러스터를 선호합니다.

유연한 솔루션은 두 가지 극단을 모두 지원할 수 있습니다.

• SaaS / 다중 테넌트: 구현이 빠르고 비용이 저렴하며 많은 중규모 배포에 적합합니다.

• 전용 클라우드 인스턴스: 추가적인 격리 또는 규정 준수가 필요한 경우 선택한 지역의 별도 계정 및 데이터베이스 인스턴스입니다.

패스키는 급증하는 워크로드를 처리해야 합니다. 엄청난 트래픽 급증(예: 휴일 쇼핑 피크 또는 이벤트 티켓 판매)은 고정 용량 시스템을 압도할 수 있습니다.

최신 패스키 백엔드는 실시간으로 수평적으로 확장되어 사용 패턴에 따라 컴퓨팅 인스턴스를 추가하거나 제거합니다. 이 자동 확장은 수동 개입 없이 일관된 성능을 보장합니다.

PCI-DSS, PSD2 SCA 또는 ISO 27001과 같은 산업 표준은 종종 결제 제공업체에 적용됩니다. 강력한 패스키 제공업체는 일반적으로 알려진 규정 준수 프레임워크와 즉시 통합됩니다.

• 저장 및 전송 중 암호화: 강력한 TLS 및 저장된 자격 증명에 대한 서버 측 또는 클라이언트 측 암호화로 데이터를 보호합니다.

• 로깅 및 감사 추적: 규제 기관이나 사고 조사에 적합한 각 패스키 작업에 대한 상세 로그입니다.

• 정기적인 보안 패치: 특히 유동적인 다중 AZ 환경에서 취약점을 방지하기 위한 자동 OS 및 컨테이너 패치입니다.

진정한 복원력은 단일 지역을 넘어 확장됩니다. 일부 제공업체는 대규모 재해 시 비즈니스 연속성을 유지하기 위해 교차 지역 복제를 의무화합니다.

지역 이중화는 다른 지역이나 대륙에 패스키 데이터를 복제하여 전체 지역의 다운타임이 인증 플로우를 중단시키지 않도록 보장합니다.

요약: 다중 AZ 및 지역 독립적

쉽게 확장하고, 지리적으로 적응하며, 로컬 중단과 대규모 재해 모두에 저항하는 패스키 솔루션을 선택하는 것은 현대 결제 제공업체, 특히 여러 국가에서 운영하거나 엄격한 규정 준수 하에 있는 제공업체에게 필수적입니다. 다중 AZ 배포 및 지역 무관 구성을 지원함으로써 Corbado(또는 유사한 솔루션)는 사용자나 데이터가 어디에 있든 결제 패스키 서비스가 가용성과 규정 준수를 모두 유지하도록 보장합니다.

패스키는 실제로 안전하고 사용자 친화적인 인증의 차세대 기술을 대표합니다. 그러나 결제 제공업체는 전통적인 WebAuthn 설계가 직접적으로 해결하지 못하는 독특한 과제에 직면해 있습니다. 이러한 한계는 다음에서 가장 두드러집니다.

1. Safari가 교차 출처 패스키 생성(특히 iframe에서)을 허용하지 않아 리디렉션 기반 접근 방식을 강요하거나 이전에 생성된 패스키에 의존하게 만듭니다.

2. Apple이 보안 결제 확인(SPC)을 지원하지 않아 브라우저와 플랫폼 전반에 걸쳐 마찰 없는 표준화된 결제 플로우를 막습니다.

그럼에도 불구하고, 패스키는 Apple Pay와 같은 결제 경험(간소화되고, 안전하며, 최종 사용자에게 매우 간단한)을 제공하려는 결제 제공업체에게 여전히 필수적입니다. 아래는 이러한 과제를 해결하는 방법과 Corbado가 어떻게 도움이 되는지 설명합니다.

1. 결제 제공업체가 서드파티 컨텍스트에서 패스키를 사용할 때 현재의 한계점은 무엇입니까?

• 교차 출처 제한: Safari(및 일부 구형 브라우저)는 iframe을 통해 내장될 때 navigator.credentials.create()를 차단합니다. 이는 해당 브라우저의 가맹점 내장 플로우에서 새로운 패스키를 원활하게 생성할 수 없음을 의미합니다.

• SPC 지원 부재: Apple이 SPC 채택을 거부함에 따라 교차 출처 결제 확인을 표준화하는 능력이 제한되어 제공업체는 Safari 대 Chrome/Edge에 대해 별도의 접근 방식을 유지해야 합니다.

• WebView 및 네이티브 앱 제약: 내장된 WebView는 종종 패스키 플로우를 깨뜨리므로 도메인 출처 정렬을 관리하기 위해 시스템 브라우저 세션이나 다른 특수 접근 방식이 필요합니다.

• 단편적인 장치 커버리지: 사용자가 한 장치나 브라우저에서 패스키를 생성하더라도 다른 장치에서는 커버리지가 부족하여 폴백 사용을 유발할 수 있습니다.

2. 결제 제공업체는 이러한 한계를 극복하고 서드파티 패스키 통합을 성공적으로 구현하기 위해 어떻게 해야 합니까?

• 하이브리드(Iframe + 리디렉션) 전략 활용:

  • 교차 출처 패스키를 완전히 지원하는 브라우저에는 iframe을 사용하여 원활한 내장 UI를 제공합니다.

  • Safari나 호환되지 않는 설정에 대한 폴백으로 리디렉션을 사용하여 강력한 패스키 생성이 항상 가능하도록 보장합니다.

• 네이티브 앱에서 시스템 WebView 또는 브라우저 리디렉션 사용:

  • 가맹점 앱에 iframe을 내장하는 대신, ASWebAuthenticationSession(iOS) 또는 Chrome 맞춤 탭(Android)으로 전환하여 도메인 연속성을 유지합니다.

  • 채택 중심 툴킷: 매력적인 패스키 생성 프롬프트, 다중 장치 커버리지 플로우 및 폴백 "치유" 단계를 제공하여 사용률을 높게 유지합니다.

  • 고급 분석 및 A/B 테스트:

    • 패스키 성공/폴백률, 환경 커버리지 및 사용자 피드백을 지속적으로 측정하여 플로우를 개선합니다.

    • 패스키 인텔리전스를 사용하여 성공 가능성이 높을 때만 자동으로 패스키를 제시합니다.

이 가이드 전반에 걸쳐, 우리는 단순히 navigator.credentials.create()를 연결하는 것만으로는 충분하지 않다고 강조했습니다. 진정한 성공은 높은 패스키 채택, 일관된 사용자 경험 및 탄력적인 다중 장치 커버리지에 달려 있습니다. 바로 이 지점에서 Corbado가 뛰어납니다.

• Iframe 및 리디렉션에 대한 통합 지원: Corbado의 SDK는 내장된 패스키 플로우가 가능한지(예: Chrome 또는 Edge) 또는 리디렉션이 필요한지(예: Safari) 자동으로 감지합니다. 이는 가맹점이 여러 코드 경로를 유지할 필요 없이 호환성을 극대화합니다.

  • 원탭 결제 경험: Passkey Intelligence를 통해 Corbado는 사용자의 환경에 유효한 패스키가 있을 가능성이 있는지 즉시 감지하여 마찰 없는 "패스키로 결제" 플로우를 트리거합니다. 이 접근 방식은 Apple Pay의 원탭 결제와 유사하며, 드물게 사용되는 MFA 단계로 격하시키는 대신 일상적인 패스키 사용을 촉진합니다.

  • 강력한 다중 장치 커버리지: Corbado는 초기 패스키 생성 대 보조 패스키 확장을 위한 특수 플로우를 제공하여 각 사용자가 폴백 또는 교차 장치 QR을 통해 로그인한 후 새 장치에 대한 커버리지를 신속하게 추가할 수 있도록 합니다.

  • 풀스택 채택 중심: 통합된 분석, A/B 테스트 및 오류 처리를 통해 Corbado는 제공업체가 마찰 지점을 식별하고 체계적으로 패스키 수용도를 최적화하도록 돕습니다. 이는 은행의 첫 패스키 프롬프트에서부터 가맹점의 결제 경험에 이르기까지 확장됩니다.

  • 유연하고 규정을 준수하는 호스팅: Corbado의 다중 AZ, 지역 무관 배포는 엄격한 결제 산업 규정 준수(PCI DSS, PSD2 SCA 등)와 일치하여 전 세계적으로 가동 시간과 데이터 상주 규칙 준수를 보장합니다.

Apple의 제한적인 정책이 피할 수 없는 마찰을 만들지만, 결제 제공업체는 다음을 통해 서드파티 패스키를 성공적으로 구현할 수 있습니다.

1. 내장 접근 방식(iframe)과 리디렉션 폴백 결합.

2. 네이티브 앱을 위한 특수 시스템 웹뷰 또는 외부 브라우저 플로우 채택.

3. 강력한 채택 전략에 집중: 다중 장치 커버리지, 폴백 "치유", 고급 분석 및 A/B 테스트.

Corbado는 이 모든 요소를 하나로 모아 패스키 등록, 원탭 사용, 분석 기반 최적화 및 글로벌 규모 호스팅을 포괄하는 엔터프라이즈 패스키 플랫폼을 제공합니다. 그 결과: 자체 결제 서비스를 위한 Apple Pay와 같은 진정으로 마찰 없는 경험으로, 향상된 보안과 우수한 사용자 여정을 모두 제공합니다.