Evaluate Redsys inSite embedded checkout

[agustinjch]

Goal

Evaluate and implement an embedded Redsys inSite checkout as an optional successor to the hosted-redirect booking experience introduced in #365.

This is a UX follow-up, not a replacement for the authoritative payment lifecycle fixed in #365. Deposit creation and reservation confirmation must continue to happen only after verified final authorization, through the same idempotent server-side finalizer.

Discovery requirements

• Confirm inSite is enabled for each intended merchant/terminal and document bank-side activation requirements.
• Define how allowed inSite domains are registered for a multi-tenant widget embedded on hotel-owned domains.
• Document required host-page CSP directives for Redsys scripts, frames, form actions, and network calls.
• Compare the unified all-in-one iframe with individual hosted fields; prefer the unified iframe for the first implementation unless product/accessibility testing demonstrates a blocker.
• Confirm supported browsers, mobile behavior, localization, accessibility, and failure messaging.
• Decide when hosted redirect remains available as a fallback.

Proposed flow

1. The server creates a provisional booking/payment intent and a Redsys order.
2. Redsys-hosted fields collect card data; HAIP never receives raw PAN/CVV.
3. The widget receives idOper and sends it to the HAIP API.
4. The API performs the signed authorization request.
5. Frictionless authorization completes immediately; a required EMV 3-D Secure challenge is displayed in an embedded, accessible challenge surface.
6. The API verifies the final provider result and invokes the existing idempotent payment/deposit/reservation finalizer.
7. The UI renders processing, authorized, failed, or recovery guidance from server state, never from browser-controlled flags.

Acceptance criteria

• Raw card data never reaches HAIP application code, logs, storage, analytics, or error reporting.
• idOper expiry, reuse, order binding, amount/currency binding, and replay behavior are tested.
• Frictionless and challenge 3DS flows are covered in automated tests and the real Redsys sandbox.
• Duplicate and out-of-order callbacks/responses cannot duplicate deposits, confirmations, audits, or notifications.
• Every property-owned lookup is tenant scoped.
• Domain-registration and CSP onboarding are documented for standalone and embedded booking pages.
• Keyboard, screen-reader, responsive/mobile, loading, cancellation, timeout, and bank-app return behavior are manually verified.
• Observability excludes card data, signing keys, raw capabilities, and signed provider payloads.
• Hosted redirect fallback behavior and rollout/rollback strategy are documented.
• Production rollout includes merchant activation checks and sandbox-to-production configuration validation.

Out of scope

• Reopening the hosted-redirect lifecycle design fixed in feat(payments): end-to-end Redsys hosted-redirect for Spain #365.
• Treating an iframe/browser callback as proof of payment.
• Storing card data or implementing custom card-field cryptography.