Apple Pay en nested iframes — reproducción del error de ATT

Cada escenario monta el mismo Checkout Embebido de Conekta (Apple Pay + card) dentro de un iframe wrapper con un atributo allow distinto. El objetivo es identificar exactamente qué configuración del wrapper rompe Apple Pay con "SecurityError: Trying to start an Apple Pay session from a document with an insecure parent frame". Abre esta página en Safari sobre macOS con Apple Pay configurado y deja la consola abierta.

🎯 Réplica fiel del setup de ATT: /att-replica → (clona la estructura exacta de la página de pago de ATT con srcdoc, que es el root cause real).

Cómo leerlo

Cada tarjeta es un escenario. Presiona Cargar escenario para que el iframe wrapper se monte con sus atributos.
Dentro del iframe corre att-checkout-host.html: crea un Order/checkout en Conekta y monta el Embedded Component con Apple Pay activado.
El host reporta de vuelta vía postMessage si: ApplePaySession.canMakePayments() contestó true, si document.featurePolicy.allowsFeature('payment') da true, si el botón aparece, y cualquier error de consola.
El escenario #3 es la teoría principal: ATT escribió allow="payments *" en plural en vez de allow="payment *".

Checklist a pedirle a ATT si todos los wrappers correctos siguen fallando

Output de curl -sI <la URL de su página> | grep -i permissions-policy — un header Permissions-Policy: payment=() tumba todo.
Captura del DOM real (Inspect → buscar el iframe title="Pago seguro Conekta") para confirmar que el atributo allow está en el HTML del iframe antes de set src, no añadido vía JS después.
Que confirmen que ese iframe no vive dentro de otro iframe (preview de CMS, A/B testing tool, GTM, etc.). Cada nivel intermedio necesita su propio allow="payment *".
Que validen que no tienen sandbox en el iframe wrapper. Sandbox sin allow-same-origin crea opaque origin → "insecure parent frame".