> ## Documentation Index
> Fetch the complete documentation index at: https://docs.spherepay.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Flujos de Tercera Parte

> Caminos de implementación post-descubrimiento cuando los fondos se mueven hacia o desde otra entidad legal, o cuando una plataforma sirve a clientes finales.

**Cuándo Sphere te enruta aquí:** El descubrimiento confirmó que el remitente, el cliente de registro y el beneficiario no son todos la misma entidad legal — o tu plataforma habilita a clientes finales a mover fondos.

Los flujos de tercera parte requieren **más definición** que los de primera parte: partes, propósito del pago, documentos, disponibilidad del corredor, configuración del beneficiario y el camino correcto del endpoint del producto. Esta página define qué validar antes de que comience la ingeniería. No reemplaza a [Soluciones](/es/solutions/overview) ni a la [Referencia API](/es/api-reference/customer/post).

<Warning>
  La disponibilidad de pagos de tercera parte depende de la geografía, el riel, el perfil del cliente y la aprobación de cumplimiento. Los pagos de tercera parte **no están disponibles en Texas ni Pennsylvania**. Confirma los corredores y regiones soportados con SpherePay antes de construir.
</Warning>

<Note>
  ¿Moviendo fondos entre la **propia** cuenta bancaria y la **propia** billetera de un cliente? Usa [Flujos de Primera Parte](/es/implementation-guides/first-party-flows) en su lugar.
</Note>

## Salida de definición

Al final del descubrimiento, tú y SpherePay deben acordar sobre:

* Entidad legal de la plataforma (si aplica)
* **Cliente de registro**
* **Remitente** y **beneficiario**
* **Propietario de fondos** en cada paso
* Si la **plataforma está en el flujo de fondos**
* Tipo de usuario final — empresa, consumidor, o ambos
* Patrón de implementación — pago a proveedor, B2B de plataforma, o integración para consumidores
* Propósito del pago y razón del pago
* Documentos de respaldo e información de relación con el beneficiario, si es requerido
* Visibilidad requerida de remitente/destinatario en el wire o estado de cuenta
* Divisa fiat y riel; stablecoin y red si aplica
* Volumen mensual esperado, tamaño de transacción promedio y máximo
* **Propietario de RFI y soporte al cliente**
* **Camino de endpoint y producto aprobado** para la creación de pagos y polling de estado

## Elige tu patrón

<CardGroup cols={3}>
  <Card title="Empresa paga proveedor" icon="receipt" href="#pattern-business-pays-supplier">
    Paga a un proveedor, vendedor, contratista o exportador — pueden aplican propósito del pago y documentos.
  </Card>

  <Card title="Plataforma sirve clientes empresariales" icon="building" href="#pattern-platform-serves-business-customers">
    Fintech o plataforma que habilita a clientes empresariales finales a mover fondos.
  </Card>

  <Card title="Banco o fintech sirve consumidores" icon="smartphone" href="#pattern-bank-or-fintech-serves-consumers">
    Ramps integrados para usuarios finales individuales — primero define el alcance del KYC, fraude y piloto.
  </Card>
</CardGroup>

| Patrón                                                                                 | Señales del descubrimiento                                       | Enfoque principal de definición                       |
| -------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ----------------------------------------------------- |
| [Empresa paga proveedor](#pattern-business-pays-supplier)                              | Entidad legal diferente recibe fondos; pago de factura/proveedor | Configuración del beneficiario, propósito, documentos |
| [Plataforma sirve clientes empresariales](#pattern-platform-serves-business-customers) | Plataforma + empresas finales; mapeo de ID de cliente            | Cliente de registro, alcance de incorporación         |
| [Banco o fintech sirve consumidores](#pattern-bank-or-fintech-serves-consumers)        | Usuarios finales individuales; UX integrada                      | Clasificación de usuarios, modelo de cumplimiento     |

## Patrón: Empresa paga proveedor

**Usar cuando:** Una empresa incorporada paga a un proveedor, vendedor, contratista, exportador u otro beneficiario tercero.

**Señales del descubrimiento:**

* El destinatario **no** es la misma entidad legal que el remitente
* Pago vinculado a una factura, orden de compra, contrato o relación de servicio
* Pueden ser requeridos el propósito del pago, el memo o los documentos de respaldo
* Puede aplicar liquidación transfronteriza — consulta [Financiamiento comercial transfronterizo](/es/solutions/cross-border-trade-finance)

**Partes a confirmar:**

| Parte                 | Pregunta de definición                                                    |
| --------------------- | ------------------------------------------------------------------------- |
| Cliente de registro   | ¿Quién está incorporado con SpherePay — el pagador, la plataforma u otro? |
| Remitente             | ¿Quién inicia y financia el pago?                                         |
| Beneficiario          | ¿Quién recibe los fondos — y cómo deben ser registrados o revisados?      |
| Propietario de fondos | ¿De quién es el dinero que se mueve en cada paso?                         |

<Steps>
  <Step title="Incorporar a las partes requeridas">
    Registra al pagador vía [POST /v2/customer](/es/api-reference/customer/post) y completa el [KYB empresarial](/es/concepts/onboarding/business-kyb) o el [KYC individual](/es/concepts/onboarding/individual-kyc) según corresponda.
  </Step>

  <Step title="Registrar el instrumento de origen del pagador">
    Vincula la [cuenta bancaria](/es/api-reference/bank-account/post) o [billetera](/es/api-reference/wallet/post) del pagador.
  </Step>

  <Step title="Confirmar la configuración del beneficiario">
    Dependiendo del flujo, es posible que el beneficiario deba ser incorporado como cliente de SpherePay o revisado/registrado de alguna otra manera antes de que se puedan enviar los fondos. Confirma con SpherePay antes de la implementación.
  </Step>

  <Step title="Recopilar propósito y documentos">
    Reúne el propósito del pago, la razón del pago, el contexto de la relación y los documentos de respaldo — consulta [Requisitos adicionales](#additional-requirements-for-third-party-payments). Para pagos por **SWIFT** se requiere un documento de respaldo — consulta [Documentos de respaldo para pagos de tercera parte por SWIFT](#documentos-de-respaldo-para-pagos-de-tercera-parte-por-swift).
  </Step>

  <Step title="Crear el pago">
    Usa el **endpoint soportado para tu flujo de tercera parte aprobado** — confirma el camino con SpherePay antes de que comience la ingeniería.
  </Step>

  <Step title="Rastrear y conciliar">
    Consulta el estado usando el camino de recuperación confirmado para tu flujo. Concilia contra registros de facturas u órdenes de compra.
  </Step>
</Steps>

<Note>
  Los pagos de tercera parte no son "transferencias de primera parte con un destinatario diferente." El camino del endpoint, el modelo del beneficiario, los campos de cumplimiento y el manejo del estado pueden diferir. No asumas que [POST /v2/transfer](/es/api-reference/transfer/post) aplica.
</Note>

## Patrón: Plataforma sirve clientes empresariales

**Usar cuando:** Una fintech o plataforma habilita a sus clientes empresariales a mover fondos a través de SpherePay.

**Señales del descubrimiento:**

* Tu cliente es una **plataforma**, no solo un pagador final
* Las empresas finales envían o reciben fondos a través de tu producto
* Los IDs de clientes internos deben mapearse a los IDs de clientes de SpherePay
* La propiedad de RFI y soporte debe definirse antes del lanzamiento

<Steps>
  <Step title="Confirmar el alcance de incorporación">
    Decide si la entidad de la plataforma, cada empresa final, o ambas deben ser incorporadas — confirma con SpherePay.
  </Step>

  <Step title="Elegir un modelo de incorporación">
    Si usas la [incorporación Platform-Managed](/es/concepts/onboarding/overview#onboarding-models), confirma la elegibilidad con el Área de Cumplimiento de Sphere antes de construir.
  </Step>

  <Step title="Crear y mapear registros de clientes">
    Usa [POST /v2/customer](/es/api-reference/customer/post) para cada entidad que deba ser verificada. Mapea IDs internos a IDs de clientes de SpherePay.
  </Step>

  <Step title="Registrar instrumentos por parte">
    Registra [cuentas bancarias](/es/concepts/transfers/bank-accounts) y [billeteras](/es/concepts/transfers/wallets) en los registros de clientes correctos.
  </Step>

  <Step title="Definir el camino de pago">
    Confirma el camino del endpoint para la creación de pagos y el polling de estado. Para resultados de aceptación fiat, consulta [Aceptación de pagos](/es/solutions/payment-acceptance).
  </Step>
</Steps>

<Warning>
  No asumas que incorporar solo a la plataforma es suficiente. Dependiendo del flujo, cada empresa subyacente también puede necesitar ser incorporada y verificada antes de poder enviar o recibir fondos.
</Warning>

## Patrón: Banco o fintech sirve consumidores

**Usar cuando:** Una institución regulada o fintech expone ramps a usuarios finales individuales a escala.

**Señales del descubrimiento:**

* Los usuarios finales incluyen **consumidores** (no solo empresas)
* Se requiere on-ramp/off-ramp integrado o UX alojada
* La propiedad del KYC, los controles de fraude y las consideraciones de contracargo difieren del B2B
* Un piloto limitado en un corredor y segmento de usuarios es apropiado antes del despliegue amplio

<Steps>
  <Step title="Clasificar a los usuarios finales">
    Separa a los usuarios empresariales de los consumidores — los caminos de incorporación y los requisitos de socios difieren.
  </Step>

  <Step title="Confirmar la responsabilidad de incorporación">
    Define si SpherePay, tu plataforma, o un modelo híbrido maneja KYC/KYB, RFIs y soporte.
  </Step>

  <Step title="Definir la transferencia de datos">
    Documenta qué campos recopilas de forma previa vs. qué recopila SpherePay vía API o [enlace alojado](/es/concepts/onboarding/kyc-via-link).
  </Step>

  <Step title="Elegir tu UX">
    Integración API vs [Ramp Widget](/widget/overview) — basado en quién posee la experiencia de frontend.
  </Step>

  <Step title="Comenzar con un piloto limitado">
    Valida un corredor, un riel y un tipo de usuario antes de escalar el volumen o los segmentos de usuarios.
  </Step>
</Steps>

<Warning>
  Los flujos de consumidores pueden requerir diferentes consideraciones de incorporación, fraude y socios que el B2B. Confirma la elegibilidad con SpherePay antes de asumir que un patrón de tercera parte empresarial escala a consumidores.
</Warning>

## Requisitos adicionales para pagos de tercera parte

Planifica recopilar y pasar lo siguiente cuando tu corredor aprobado lo requiera:

* **Propósito del pago** — clasificación para cumplimiento y socios bancarios
* **Razón del pago** — descripción en lenguaje natural de por qué se mueven los fondos
* **Código de propósito del pago** — los valores permitidos varían por corredor; confirma el conjunto con SpherePay antes de construir
* **Documentos de respaldo** — contratos, facturas o evidencia de relación cuando se requiera
* **Información de relación con el beneficiario** — proveedor, contratista, vendedor de marketplace, etc.
* **Visibilidad de remitente/destinatario** — lo que el beneficiario ve en el wire o estado de cuenta
* **Revisión antes de la liquidación** — algunos flujos requieren revisión de documentos o manual; planifica la UX de estado en consecuencia

Usa solo los campos y estados documentados en la API pública para tu camino de producto aprobado.

## Documentos de respaldo para pagos de tercera parte por SWIFT

Los pagos por SWIFT (USD entregados a una cuenta bancaria internacional) son con frecuencia **pagos de tercera parte** — el beneficiario es una entidad legal diferente a tu cliente incorporado. Un pago SWIFT de tercera parte debe llevar un **documento de respaldo** (normalmente la factura que liquida) junto con una razón y una descripción del pago. El pago se rechaza si falta cualquiera de estos.

<Warning>
  SWIFT requiere el **perfil de verificación C** — no se puede crear una cuenta bancaria SWIFT en USD hasta que el perfil C esté aprobado. Registra al beneficiario como una cuenta bancaria SWIFT en USD (`currency: "usd"`, `networks: ["swift"]`) con un `accountNumber` (IBAN o BBAN) y un `bic`, más hasta tres `intermediaryBics` opcionales. Confirma con SpherePay que el perfil C esté habilitado antes de construir.
</Warning>

### Documentos elegibles

Sube el único documento que mejor evidencie el pago — lo más común es la **factura** que liquida. Otra evidencia aceptable incluye órdenes de compra, contratos firmados y acuerdos de servicio. Los formatos aceptados son **PDF, JPEG y PNG**, de hasta **10 MB**.

### Cómo funciona

<Steps>
  <Step title="Subir el documento de respaldo">
    Llama a [POST /v2/document](/es/api-reference/document/post) con `target: "transfer"` y adjunta el archivo. No se necesita ningún `documentType` para este target. La respuesta devuelve el `id` del documento (por ejemplo, `document_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6`).
  </Step>

  <Step title="Crear el pago con el documento y los campos de tercera parte">
    Crea la transferencia SWIFT con `isThirdParty: true` e incluye `documentId` (el `id` del paso 1), `paymentReason` y `paymentDescription`. Para un pago de tercera parte **los tres son requeridos** — la solicitud se rechaza con un `422` si falta alguno, y el documento debe pertenecer a tu aplicación.
  </Step>

  <Step title="Rastrear y conciliar">
    Consulta el estado como de costumbre y concilia contra la factura o la orden de compra que representa el documento.
  </Step>
</Steps>

<Tip>
  **Reutiliza el mismo documento en varios pagos.** Un `documentId` no se consume cuando lo referencias — puedes pasar el mismo en varias transferencias. Esto es útil para **pagos recurrentes contra un único contrato u orden de compra**: sube el documento de respaldo una vez y luego referencia su `documentId` en cada pago de la serie en lugar de volver a subirlo cada vez.
</Tip>

`paymentReason` acepta uno de: `personal`, `investment`, `real_estate`, `tax`, `loan`, `bills`, `reimbursement`, `professional_services`, `family_support`, `education`, `rent`, `donation`, `gift`, `insurance`, `medical`, `savings`, `travel`, `mortgage`, `fine`, `dividend`, `agriculture`, `import_export`, `art`, o `other`.

### Qué poner en la descripción del documento

Cuando subas el documento, usa el campo opcional `description` para darle a SpherePay **contexto que pueda usar para revisar y enrutar el pago más rápido** — no solo una repetición del nombre del archivo. Incluye, cuando sea relevante:

* Qué es el documento — p. ej., "Factura comercial INV-2024-0098"
* El propósito del pago — p. ej., "Pago por servicios de fabricación del Q2"
* Las partes y su relación — p. ej., "De Acme Inc. a Shenzhen Supplier Co., fabricante contratado"
* El número de factura u orden de compra que liquida el pago, y el monto si difiere del total completo de la factura

<Tip>
  Las descripciones claras y específicas reducen la probabilidad de un RFI de cumplimiento y aceleran la revisión. La `description` del documento y la `paymentDescription` del pago (de 1 a 500 caracteres) son campos separados — usa ambos para dar contexto completo.
</Tip>

## Confirmar antes de construir

<Steps>
  <Step title="Identificar a las partes">
    Confirma el cliente de registro, el remitente, el beneficiario y el propietario de los fondos en cada paso.
  </Step>

  <Step title="Definir el alcance del rol de la plataforma">
    Determina si la plataforma está en el flujo de fondos y si los usuarios finales son empresas, consumidores, o ambos.
  </Step>

  <Step title="Validar corredor y geografía">
    Confirma la disponibilidad de riel, divisa y región — incluyendo las restricciones de TX/PA para pagos de tercera parte.
  </Step>

  <Step title="Confirmar entradas de cumplimiento">
    Define el propósito del pago, los documentos requeridos, el modelo de configuración del beneficiario y la visibilidad de remitente/destinatario.
  </Step>

  <Step title="Confirmar el camino del endpoint">
    Verifica el camino aprobado para la creación de pagos y el polling de estado con SpherePay — consulta [Creación de pagos y estado](#payment-creation-and-status).
  </Step>

  <Step title="Asignar propiedad operacional">
    Define quién maneja los RFIs y el soporte al cliente antes del lanzamiento.
  </Step>
</Steps>

## Creación de pagos y estado

Los caminos de pago de tercera parte son **específicos del producto**. La [Referencia API](/es/api-reference/transfer/post) pública documenta `POST /v2/transfer` para flujos de on-ramp/off-ramp y transferencia cotizada. **La creación de pagos B2B de tercera parte puede usar un camino de endpoint diferente** — confirma con SpherePay antes de la implementación.

| Tipo de flujo                                          | Orientación                                                                                                                            |
| ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------- |
| On-ramp/off-ramp de primera parte                      | [POST /v2/transfer](/es/api-reference/transfer/post) — consulta [Flujos de Primera Parte](/es/implementation-guides/first-party-flows) |
| Corredor fiat-a-fiat cotizado (cuando está habilitado) | [POST /v2/quote](/es/api-reference/quote/post) luego creación de transferencia con `quoteId` — confirma aplicabilidad                  |
| Pagos B2B de tercera parte aprobados                   | Usa el camino del endpoint confirmado por SpherePay — no asumas la transferencia v2 de primera parte                                   |

<Tip>
  Consulta el estado usando el camino de recuperación confirmado para tu flujo aprobado. Las respuestas de tercera parte pueden incluir campos y estados más allá del [ciclo de vida de la transferencia de primera parte](/es/concepts/transfers/lifecycle) — confirma el conjunto completo con SpherePay.
</Tip>

## Qué enviar a Sphere antes del inicio

* Entidad legal de la plataforma (si aplica)
* Cliente de registro
* Remitente y beneficiario
* Propiedad de fondos en cada paso
* Si la plataforma está en el flujo de fondos
* Tipo de usuario final: empresa, consumidor, o ambos
* Patrón seleccionado: pago a proveedor, B2B de plataforma, o integración para consumidores
* Código de propósito del pago y razón del pago
* Tipo de documentación de respaldo, si es requerida
* Relación del beneficiario / contexto del destinatario
* Visibilidad requerida de remitente/destinatario
* Divisa fiat y riel; stablecoin y red si aplica
* Volumen mensual esperado
* Tamaño de transacción promedio y máximo
* Propietario de RFI/soporte
* Guía de Soluciones relacionada, si se identificó

## Validar antes de que comience la ingeniería

| Bloqueo                                                  | Por qué importa                                                                                                   |
| -------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| Perfil de verificación no aprobado                       | El perfil KYC/KYB requerido está incompleto, pendiente, faltante o rechazado                                      |
| Proveedor/corredor no habilitado                         | Cliente aprobado en general pero no habilitado para el corredor o riel específico                                 |
| Restricción de geografía/corredor                        | Los pagos de tercera parte no están disponibles en **Texas ni Pennsylvania**; otras regiones pueden tener límites |
| Cliente de registro poco claro                           | SpherePay no puede determinar quién debe ser incorporado                                                          |
| Plataforma en el flujo de fondos                         | Puede cambiar los requisitos de incorporación, cumplimiento y socios                                              |
| Beneficiario no identificado                             | El pago no puede evaluarse ni enrutarse                                                                           |
| Propósito de pago faltante o no soportado                | Código de propósito requerido o razón faltante o no habilitada para el corredor                                   |
| Documentos de respaldo faltantes                         | La liquidación puede bloquearse hasta que se proporcionen los documentos                                          |
| Flujo de tercera parte usando supuestos de primera parte | Los patrones de tesorería/on-ramp pueden no aplicar a pagos de proveedores o plataformas                          |
| Endpoint incorrecto asumido                              | El camino de creación de pagos debe coincidir con tu producto de tercera parte aprobado                           |
| Escala de consumidores con patrón B2B                    | La integración para consumidores puede requerir un camino diferente                                               |

## Lista de verificación pre-inicio

* [ ] Cliente de registro, remitente y beneficiario identificados
* [ ] Propiedad de fondos y rol de plataforma documentados
* [ ] Patrón seleccionado y confirmado con SpherePay
* [ ] Partes requeridas incorporadas o configuración del beneficiario confirmada para el corredor
* [ ] Proveedor/corredor y geografía validados (incluyendo TX/PA)
* [ ] Propósito del pago, razón y documentos recopilados si es requerido
* [ ] Para SWIFT: perfil de verificación C aprobado, cuenta beneficiaria SWIFT en USD registrada, y (para tercera parte) `paymentReason`, `paymentDescription` y un `documentId` subido listos
* [ ] Camino del endpoint para creación y estado confirmado con SpherePay
* [ ] Propietario de RFI/soporte definido
* [ ] Plan de conciliación definido
* [ ] Entradas de inicio enviadas a SpherePay

## Antes del lanzamiento

SpherePay no tiene un sandbox separado — las pruebas de integración se ejecutan contra producción con datos de identidad reales. Ejecuta una transferencia en vivo de bajo monto en cada corredor antes del lanzamiento.

La primera transferencia a un nuevo beneficiario puede activar un RFI de cumplimiento del socio bancario. Establece esta expectativa con tu cliente desde el inicio, y asegúrate de que tu [propietario de RFI y soporte al cliente](#salida-de-definición) esté listo para responder.

Para preguntas de liquidación de usuarios finales, comparte los artículos de la Base de Conocimiento de SpherePay [When will the funds land in my account?](https://spherepay-knowledge-base.help.usepylon.com/articles/9934878291-when-will-the-funds-land-in-my-account) y [My funds are missing or have not landed in my account](https://spherepay-knowledge-base.help.usepylon.com/articles/9884755317-my-funds-are-missing-or-have-not-landed-in-my-account-what-should-i-do) para que los usuarios se autoatiendan en lugar de abrir tickets de soporte contigo.

## Profundizar

<CardGroup cols={2}>
  <Card title="Nómina" icon="banknote" href="/es/solutions/payroll">
    Desembolsos de tercera parte a empleados y contratistas.
  </Card>

  <Card title="Financiamiento comercial transfronterizo" icon="ship" href="/es/solutions/cross-border-trade-finance">
    Patrones de liquidación de importador–exportador y facturas.
  </Card>

  <Card title="Aceptación de pagos" icon="hand-coins" href="/es/solutions/payment-acceptance">
    Aceptación fiat mediada por plataforma con liquidación en stablecoin.
  </Card>

  <Card title="Flujos de Primera Parte" icon="landmark" href="/es/implementation-guides/first-party-flows">
    Cuando origen y destino pertenecen a la misma entidad legal.
  </Card>

  <Card title="Base de Conocimiento y FAQ" icon="book-open" href="https://spherepay-knowledge-base.help.usepylon.com/">
    Artículos de soporte para usuarios finales — tiempos de liquidación, fondos faltantes, mínimos y guías del panel — para compartir con tus usuarios.
  </Card>
</CardGroup>