# 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-modelo-de-pago
title: Las piezas y cómo encajan
audience: Desarrollador que ya tiene el modelo mental y viene a por la estructura y los campos
objetivo: >
  Al terminar, el espectador sabe cuántas piezas maneja —dos, y una tercera solo si reparte—, qué
  declara cada una y dónde se engancha con la siguiente. Se lleva la distinción que más se confunde:
  el destino HABILITA el reparto, la sesión lo DETALLA.
cta: 'Siguiente: ''Las formas de recibir un pago'', o ''Split'' si vas a repartir.'
target_duration_s: 203
storyboard:
  - 'n': 1
    on_screen: Dos piezas, y una tercera si repartes
    narracion: >-
      Para recibir pagos con la API Productos manejas dos piezas, y una tercera solo si repartes: el
      destino, que en la API se llama acuerdo; la sesión de pago; y el partner. Aquí están sus
      formas y por dónde se enganchan. Si lo que buscas es el relato de cómo funciona un pago de
      principio a fin, eso está en Conceptos base.
    visual: Dos piezas encajadas y una tercera al lado, marcada como opcional.
    duracion_s: 24
  - 'n': 2
    on_screen: 'El destino: dónde declaras cómo recibes'
    narracion: >-
      La primera pieza es el destino: un juego de reglas que dice cómo recibes el dinero. Declara
      qué métodos aceptas —débito inmediato, pago móvil, cripto—, a qué cuenta tuya se acredita por
      defecto, y si lo que llegue ahí puede repartirse. Se define una vez y se reutiliza: no creas
      uno por pago, sino uno por cada forma distinta de recibir que tenga tu negocio.
    visual: >-
      El acuerdo abierto con sus cuatro campos: métodos, cuenta por defecto, si admite reparto, y
      reglas.
    duracion_s: 25
  - 'n': 3
    on_screen: Un campo que todavía no puedes usar
    narracion: >-
      Y hay un cuarto campo del que conviene saber una cosa antes de diseñar nada: las reglas, que
      enrutan a una cuenta u otra según desde qué banco te pague la persona. El contrato lo marca En
      Desarrollo. Déjalo vacío y usa la cuenta por defecto, que es la que sí sabemos que funciona.
    visual: >-
      El campo rules marcado con un sello de En Desarrollo, y la cuenta por defecto marcada como la
      que sí funciona.
    duracion_s: 21
  - 'n': 4
    on_screen: 'La sesión: cada pago concreto'
    visual: Lámina de sección, sin voz.
    duracion_s: 3
  - 'n': 5
    on_screen: Una sesión por cada pago
    narracion: >-
      Con el destino definido, la segunda pieza es la sesión: cada pago que recibes es una, y la
      creas con una sola llamada sobre ese destino. SPIDI te devuelve la URL de pago, dentro del
      objeto data, y un status que arranca en pendiente.
    visual: Una sesión creada sobre un destino; en la respuesta, la URL de pago y el status pendiente.
    duracion_s: 17
  - 'n': 6
    on_screen: Y en cada una eliges dos cosas
    narracion: >-
      Y en cada sesión eliges dos cosas que no dependen entre sí. Cuánto vive esa dirección: minutos
      con un Botón, hasta una fecha con una Solicitud, o para siempre dentro de una Parada. Y si el
      dinero va a una cuenta o repartido.
    visual: 'Sobre la misma sesión, las dos decisiones: cuánto vive el enlace, y a cuántas cuentas va.'
    duracion_s: 17
  - 'n': 7
    on_screen: 'El partner: quién más recibe'
    visual: Lámina de sección, sin voz.
    duracion_s: 3
  - 'n': 8
    on_screen: No tiene por qué ser cliente de SPIDI
    narracion: >-
      Si repartes un pago, la otra parte tiene que poder recibirlo. Pero no tiene por qué ser
      cliente de SPIDI. Un partner es un receptor de fondos: una persona o un negocio con una cuenta
      bancaria donde llega su cuotaparte. No es una cuenta en SPIDI: no se registra, no tiene token,
      y no entra a ningún sitio.
    visual: >-
      Un partner recibiendo su parte en su cuenta bancaria, sin ninguna cuenta de plataforma de por
      medio.
    duracion_s: 22
  - 'n': 9
    on_screen: Lo das de alta tú, sin que él haga nada
    narracion: >-
      Y esto es lo que decide si un marketplace puede repartir o no: lo das de alta tú, por API, sin
      que él haga nada. Ni un correo, ni una clave, ni una confirmación. Lo que sí necesitas son sus
      datos bancarios exactos, porque se validan de verdad: un dígito mal y el alta no pasa.
    visual: >-
      El alta hecha por ti, sin correo ni clave para el partner; al lado, los datos bancarios
      validados de verdad.
    duracion_s: 22
  - 'n': 10
    on_screen: Su identificador ES su acuerdo de recepción
    narracion: >-
      Al darlo de alta recibes un identificador que empieza por r-c-v. Y ese identificador es su
      acuerdo de recepción: dice a qué cuenta va su parte, y es lo que usas en cada sesión para
      indicar cuánto le toca. Hay además un endpoint dedicado, para cuando necesites reglas más
      finas que esta cuenta, pero al usarlos son indistinguibles: la sesión solo lleva el
      identificador, y ningún campo dice de qué endpoint salió.
    visual: El identificador rcv_ saliendo del alta y entrando directamente en la sesión.
    duracion_s: 28
  - 'n': 11
    on_screen: El destino habilita; la sesión detalla
    narracion: >-
      Y con las tres piezas vistas, queda la distinción que más se confunde: el destino habilita el
      reparto, la sesión lo detalla. Poner el reparto en el destino no distribuye nada por sí solo:
      dice que por ahí puede entrar un pago repartido. Cuánto le toca a cada receptor se dice en
      cada sesión.
    visual: >-
      Cierre de marca; el destino con un interruptor de habilitar, y la sesión con el detalle del
      reparto.
    duracion_s: 21