# Guion del vídeo, para comentar o para lo que necesites.
# Es una PROYECCIÓN del nuestro: lleva el contenido —qué se dice, qué se ve, en
# qué orden y cuánto dura— y no la maquinaria que lo convierte en vídeo.
id: empezar-arquitectura
title: 'Arquitectura recomendada: las seis piezas'
audience: Desarrollador que va a decidir qué parte de su sistema habla con SPIDI
objetivo: >
  Al terminar, el espectador sabe qué pieza hace cada cosa y, sobre todo, qué NO debe hacer su
  frontend: ni guardar el token ni crear sesiones. Y entiende que la vuelta tiene dos vías —el aviso
  y la consulta— que se combinan, no se eligen.
cta: 'Siguiente: ''Recibe tu primer pago'' para montarlo, o ''Success URL'' para el detalle de la vuelta.'
target_duration_s: 102
storyboard:
  - 'n': 1
    on_screen: Los dos errores clásicos
    narracion: >-
      Una integración con SPIDI tiene seis piezas, y conocerlas evita los dos errores clásicos:
      crear sesiones desde el navegador, y confiar en la redirección como prueba de pago. Vamos a
      ver dónde encaja cada una.
    visual: 'Dos errores marcados: el navegador creando sesiones, y la redirección tomada como prueba.'
    duracion_s: 13
  - 'n': 2
    on_screen: Tu frontend pide; tu backend crea
    narracion: >-
      Empieza por el reparto de responsabilidades, que es lo que evita el primer error. Tu frontend
      solo pide: quiero recibir un pago de tanto. No guarda tu token y no crea sesiones, nunca. Tu
      backend es quien guarda el token, que es un secreto, quien crea la sesión contra la API, y
      quien recibe los avisos.
    visual: El frontend pidiendo, el backend creando la sesión con el token guardado a salvo.
    duracion_s: 22
  - 'n': 3
    on_screen: Y de ahí sale la URL de pago
    narracion: >-
      La API devuelve la URL de pago y un status en pendiente. Tu backend se la pasa al frontend, y
      el frontend lleva a la persona ahí. Esa pantalla es de SPIDI: es donde paga, y al terminar
      vuelve a tu URL de éxito.
    visual: >-
      La URL de pago viajando de vuelta hasta el navegador, y la persona pagando en la página de
      SPIDI.
    duracion_s: 17
  - 'n': 4
    on_screen: Y cómo vuelve la verdad
    visual: Lámina de sección, sin voz.
    duracion_s: 3
  - 'n': 5
    on_screen: Dos vías, y se combinan
    narracion: >-
      Queda el segundo error, y aquí está la clave: que la persona vuelva a tu sitio no es la prueba
      de nada. La verdad vuelve por otras dos vías. El aviso, que SPIDI empuja a tu backend cuando
      hay un pagado o una acreditación, y que es la vía fiable porque no depende de que nadie
      vuelva. Y la consulta, que tu backend hace cuando quiere confirmar o reconciliar.
    visual: 'Dos vías llegando al backend: el aviso que llega solo, y la consulta que se pregunta.'
    duracion_s: 27
  - 'n': 6
    on_screen: Las seis, en su sitio
    narracion: >-
      Y no eliges entre las dos: las combinas. El aviso te avisa en cuanto ocurre; la consulta te
      sirve de respaldo, al volver a tu pantalla de éxito o como reconciliación periódica. Con eso
      las seis piezas quedan en su sitio, y el token no ha pasado nunca por el navegador.
    visual: >-
      Cierre de marca; las seis piezas montadas, con el frontend claramente fuera del camino del
      secreto.
    duracion_s: 20