# 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: productos-boton-web
title: 'Botón web: recibir el pago dentro de tu web o app'
audience: Desarrollador que va a poner un checkout de SPIDI en su web o en su app
objetivo: >
  Al terminar, el espectador sabe crear una sesión de Botón, por qué tiene que abrir su
  `payment_url` una vez antes de dársela a nadie, que la redirección no confirma nada, y cuáles son
  los límites que conviene conocer antes de diseñar: vigencia, monto mínimo, ventana de medianoche y
  las cinco monedas de referencia.
cta: 'Siguiente: ''Manejar notificaciones'' o ''Usar el simulador''.'
target_duration_s: 227
storyboard:
  - 'n': 1
    on_screen: Cuando tu cliente está delante
    narracion: >-
      El Botón es la sesión para cuando tu cliente está delante, decidiendo ahora: el enlace solo
      tiene que durar lo que dure la compra. Creas la sesión, llevas a la persona a su URL de pago,
      y confirmas desde tu backend. Vamos por partes.
    visual: Una persona frente a un checkout en una web, decidiendo ahora.
    duracion_s: 17
  - 'n': 2
    on_screen: 1 · Crea la sesión
    narracion: >-
      Se crea con una sola llamada, y son ocho los campos obligatorios. Van agrupados por lo que
      dicen: por qué destino lo enrutas; cuánto y en qué moneda lo fijas; a quién se lo pides y por
      qué concepto; y a dónde vuelve la persona al terminar, tanto si pagó como si no. La respuesta
      trae la URL de pago y el identificador de sesión, los dos dentro del objeto data, y la sesión
      nace en pendiente.
    visual: La llamada de creación con los ocho campos obligatorios agrupados por lo que dicen.
    duracion_s: 30
  - 'n': 3
    on_screen: Ábrelo una vez antes de dárselo a nadie
    narracion: >-
      Y aquí va una comprobación de un minuto que se hace una sola vez y evita el fallo más
      silencioso de todo el ciclo. Abre tu URL de pago con una sesión de prueba y confirma que
      muestra el monto que esperas. Un enlace mal formado no da error: lleva a una pantalla
      plausible donde le piden los datos a tu cliente, y ahí se pierde el pago sin que nadie se
      entere.
    visual: >-
      Un enlace mal formado llevando a una pantalla plausible donde alguien introduce sus datos y el
      pago se pierde.
    duracion_s: 28
  - 'n': 4
    on_screen: Confirma desde tu servidor
    visual: Lámina de sección, sin voz.
    duracion_s: 3
  - 'n': 5
    on_screen: La redirección no garantiza nada
    narracion: >-
      Con el enlace comprobado, se lo das a tu cliente y paga. Y al terminar, SPIDI lo redirige a tu
      URL de éxito o a la de fallo — pero eso es lo único que esa redirección significa: que la
      persona volvió. No garantiza que te pagaron. Pregúntale a SPIDI desde tu backend, consultando
      el estado de la sesión.
    visual: La persona volviendo a la URL de éxito, con un signo de interrogación sobre si pagó de verdad.
    duracion_s: 23
  - 'n': 6
    on_screen: Y `paid` no es dinero acreditado
    narracion: >-
      Al llegar a pagado, además, te llega el aviso firmado a tu URL de webhook: lo verificas y
      respondes 2xx. Pero ojo con lo que confirma ese pagado: confirma el débito, la fase uno, no
      que el dinero ya esté en manos del receptor. La acreditación no cambia el status; te llega por
      un segundo aviso, o la consultas en receiver_credits, en la misma respuesta del estado.
    visual: El aviso firmado llegando al endpoint propio, y el status quedándose en pagado.
    duracion_s: 26
  - 'n': 7
    on_screen: Los límites, antes de diseñar
    visual: Lámina de sección, sin voz.
    duracion_s: 3
  - 'n': 8
    on_screen: La vigencia tiene techo
    narracion: >-
      Quedan las reglas que conviene conocer antes de diseñar. La vigencia la eliges tú, en minutos,
      y ese máximo es un techo: no hay forma de pedir más. Y si no envías el campo, la sesión caduca
      pronto. Por eso, si el pago va a esperar, un Botón no es la pieza: su enlace también es un
      enlace, se puede mandar por WhatsApp, y morirse antes de que lo abran. Para eso están las
      Solicitudes.
    visual: Un dial de vigencia con su techo marcado, y un enlace muerto llegando por chat.
    duracion_s: 29
  - 'n': 9
    on_screen: Monto mínimo · horario · monedas
    narracion: >-
      Tres más. Hay un monto mínimo: por debajo, la creación devuelve un cuatrocientos. No se
      permiten operaciones en las horas cercanas a la medianoche, que es la ventana de corte diario.
      Y las monedas de referencia son cinco, y el contrato las declara como lista cerrada: dólar,
      euro, peso colombiano, USDT y bolívar. Cualquier otro valor devuelve un cuatrocientos.
    visual: >-
      Un monto por debajo del mínimo rebotando, una ventana de medianoche cerrada, y cinco monedas
      admitidas.
    duracion_s: 23
  - 'n': 10
    on_screen: Qué texto poner en el botón
    narracion: >-
      Y una recomendación de SPIDI que viene con su razón: la etiqueta «Pagar con Bs y Cripto», y
      debajo, en pequeño, «Desarrollado por SPIDI». La primera dice de entrada las dos cosas que
      quien paga necesita para decidirse. La segunda evita que el botón se perciba como un monedero
      desconocido. No es obligatorio, pero si lo cambias, conserva las dos ideas: la moneda y el
      respaldo.
    visual: El botón con su etiqueta recomendada y el respaldo debajo en pequeño.
    duracion_s: 25
  - 'n': 11
    on_screen: En app, y cómo lo pruebas
    narracion: >-
      Por último, si integras desde una app móvil abres esa misma URL, por deeplink al navegador o
      dentro de un WebView: el retorno depende de tu plataforma, pero la confirmación es idéntica. Y
      para probarlo todo sin pagar nada, en el simulador fuerzas el desenlace que quieras desde el
      plano de control.
    visual: >-
      Cierre de marca; la misma URL abierta desde una app móvil, y el desenlace forzado en el
      simulador.
    duracion_s: 20