Why do payment SDKs like Stripe Elements use cross-origin iframes?

To achieve PCI-DSS SAQ A compliance. Rendering inputs in cross-origin iframes on the processor domain ensures merchant JavaScript and third-party scripts cannot read raw credit card numbers, expiration dates, or CVC codes.

How does focus proxying work between isolated iframe fields?

When a user finishes entering a card number or hits Tab, the iframe notifies the host coordinator via postMessage. The host then programmatically signals the next iframe (e.g. Expiry Date) to take focus, preserving natural keyboard navigation.

Why is unrestricted merchant CSS dangerous inside payment iframes?

CSS can act as a keylogger using attribute selectors (e.g., input[value$="4"] { background: url(...) }) to leak digits over network requests. The SDK prevents this with a strict allowlist of visual properties and sanitization.

Design an Embedded Payment SDK (Stripe Elements)

hardCore ConceptFintechSecurity

Asked at

Amazon, PayPal, Shopify, Stripe

Problem statement

Embed payment inputs into merchant DOMs with PCI SAQ A isolation. Cross-origin iframe sandboxing, sanitized style injection, focus proxying, and direct tokenization.

Premium

The full solution is part of HelloFrontend Pro

The question above is free to read in full. Upgrade to unlock the interactive workspace and the senior-level walkthrough that go with it.

Full RADIO-framework walkthrough with architecture diagrams
Data model, API design, and rendering strategy trade-offs
Performance, accessibility, and offline sections plus a model answer

Unlock the full solution →

Already a member? Log in to open the workspace.

Design an Embedded Payment SDK (Stripe Elements)

Problem statement

The full solution is part of HelloFrontend Pro

More System Design questions

Design a News Feed UI

Design a Component Library / Design System

Design Travel Booking Platform (Expedia/Booking.com)

Design Perplexity (RAG Search with Citations)