## Design an Embeddable Pay by Bank Widget Design a Pay by Bank widget that online businesses can embed in checkout or bill-payment pages. The widget's interface and code are controlled by the payment provider. A user selects a bank, completes bank authentication, and proceeds with payment. Explain how developers embed the widget, how data moves among the business frontend, business backend, widget frontend, and widget backend, and which APIs and technical choices are required for launch. Your design must use an `iframe` boundary and a carefully validated `postMessage` channel. ### Constraints & Assumptions - A business backend can authenticate to the provider with a server-side credential; that credential must never enter browser code. - Bank credentials and reusable bank authorization secrets must not be exposed to the embedding page. - Payment completion can be asynchronous and must not depend on the browser remaining open. - The widget can be embedded on many unrelated origins. - Exact bank-authentication rails, settlement guarantees, and regulatory requirements must be clarified for the target market. ### Clarifying Questions to Ask - Which browsers, devices, countries, banks, currencies, and accessibility standards are in scope? - Is bank authentication redirected, opened in a new window, or completed inside an approved embedded flow? - What does payment success mean: authorization created, bank confirmed, or funds settled? - Which customization may a business control without compromising security or accessibility? - What latency, availability, abandonment, and fraud targets define a successful launch? ### Part 1 — Embed and Isolate the Widget Describe the integration surface offered to a business developer. Explain how a provider script creates the `iframe`, how a short-lived client session is supplied, and how the two frames establish a message channel. #### What This Part Should Cover - A server-created payment session rather than browser use of a secret API key. - Origin allowlisting, `iframe` sandbox and permission policy, and content security policy. - Exact `targetOrigin` values and validation of message origin, source window, schema, and session. - Versioning, resizing, cancellation, completion, and error events. ```hint Treat messages as an API Every cross-frame message needs a named type, version, session binding, allowed sender, validated payload, and idempotent handling. ``` ### Part 2 — Design Data Flow and APIs Walk through session creation, widget loading, bank selection, bank authentication, payment initiation, asynchronous status changes, and final business notification. Define the essential API endpoints and idempotency boundaries. #### What This Part Should Cover - Business-backend session creation with amount, currency, order reference, and allowed origin. - A scoped client token used only by the widget. - Provider-controlled bank discovery and authentication state. - Server-to-server payment status, signed webhooks, and a status lookup API. - Idempotent payment creation and protection against replay or duplicated messages. ```hint The browser is not the final authority A completion message improves user experience, but the business backend should confirm the durable payment state through a signed server channel or authenticated status read. ``` ### Part 3 — Make Launch Choices Explicit Discuss security, privacy, failure recovery, browser compatibility, accessibility, version rollout, observability, and testing. Explain which state belongs in each component and how the flow resumes after refresh, redirect, or duplicate callback. #### What This Part Should Cover - Minimal sensitive data in browser messages, logs, and business-visible fields. - State machines for sessions, authorization, payment, and settlement. - Recovery from closed windows, expired sessions, delayed banks, and duplicate webhooks. - Contract tests for the SDK and message protocol plus end-to-end bank-flow tests. - Metrics segmented by business, bank, browser, and state transition without leaking credentials. ```hint Design resumability around durable IDs The browser may disappear at any point, so each transition should be recoverable from provider-side session and payment identifiers. ``` ### What a Strong Answer Covers - A small developer-facing integration that preserves provider control and cross-origin isolation. - A complete, authenticated data flow with no server credential or bank secret exposed to the embedding page. - Strict `postMessage` validation and a server-authoritative completion path. - Idempotent state transitions, asynchronous recovery, and launch-ready security, accessibility, testing, and observability. ### Follow-up Questions 1. How would you prevent a malicious embedding page from forging a successful payment message? 2. What should happen if the user authenticates successfully but closes the page before payment initiation returns? 3. How would you roll out a breaking message-protocol change without breaking existing businesses? 4. Which fields may safely cross `postMessage`, and which should remain provider-side only? 5. How would you diagnose a conversion drop isolated to one bank and one browser version?