How does Apple’s SPC limitation block passkey checkouts?

Apple’s limited support for Secure Payment Confirmation (SPC) significantly impacts the ability of payment providers to deliver a unified, seamless passkey checkout experience across different browsers. SPC, a web standard led by Google, is designed to standardize how payment providers authenticate users across multiple merchant sites, ensuring a frictionless and secure payment process similar to native solutions like Apple Pay.

Safari blocks passkey creation (navigator.credentials.create()) in cross-origin iframes. While authentication using existing passkeys is permitted, the inability to create new passkeys within embedded third-party contexts severely disrupts a smooth user experience during checkout.

Apple has not implemented SPC in Safari, likely as a strategic decision to keep Apple Pay as the preferred payment method within its ecosystem. Consequently, payment providers are forced into using alternative, less unified methods such as redirects or relying on passkeys previously established on their own domains.

Users experience increased friction as they're redirected away from merchants’ websites or are required to undergo additional steps, negatively affecting conversion rates and checkout fluidity.

Hybrid Approaches:

• Providers often use iframe-based methods for browsers supporting SPC and redirects for Safari to ensure compatibility.
• Native apps rely on system browser sessions like ASWebAuthenticationSession (iOS) or Chrome Custom Tabs (Android) to bypass embedded WebView constraints.

By strategically addressing these barriers, payment providers can still offer robust passkey authentication solutions, although the friction introduced by Apple's restrictions remains a significant challenge to achieving a truly unified, cross-browser checkout experience.