> ## 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.

# Fluxos de Terceiros (Third-Party)

> Caminhos de implementação pós-descoberta quando os fundos se movem para ou de outra entidade legal, ou quando uma plataforma atende clientes downstream.

**Quando o Sphere direciona você aqui:** A descoberta confirmou que o remetente, o cliente de registro e o beneficiário não são todos a mesma entidade legal — ou sua plataforma permite que clientes downstream movam fundos.

Fluxos de terceiros requerem **mais escopo** do que os próprios (first-party): partes, propósito do pagamento, documentos, disponibilidade de corredor, configuração do beneficiário e o caminho correto de endpoint do produto. Esta página define o que validar antes de iniciar a engenharia. Ela não substitui [Soluções](/pt-BR/solutions/overview) nem a [Referência da API](/pt-BR/api-reference/customer/post).

<Warning>
  A disponibilidade de pagamentos de terceiros depende de geografia, rail, perfil do cliente e aprovação de conformidade. Pagamentos de terceiros **não estão disponíveis no Texas ou na Pensilvânia**. Confirme os corredores e regiões suportados com o SpherePay antes de construir.
</Warning>

<Note>
  Movendo fundos entre a **própria** conta bancária e a **própria** carteira de um cliente? Use [Fluxos Próprios](/pt-BR/implementation-guides/first-party-flows).
</Note>

## Output de escopo

Ao final da descoberta, você e o SpherePay devem concordar em:

* Entidade legal da plataforma (se aplicável)
* **Cliente de registro**
* **Remetente** e **beneficiário**
* **Proprietário dos fundos** em cada etapa
* Se a **plataforma está no fluxo de fundos**
* Tipo de usuário downstream — empresa, consumidor ou ambos
* Padrão de implementação — pagamento a fornecedor, B2B de plataforma ou incorporação para consumidor
* Propósito do pagamento e motivo do pagamento
* Documentos de suporte e contexto do relacionamento com beneficiário, se necessário
* Visibilidade de remetente/destinatário obrigatória no wire ou extrato
* Moeda fiat e rail; stablecoin e rede, se aplicável
* Volume mensal esperado, tamanho médio e máximo de transação
* **Proprietário de RFI e suporte ao cliente**
* **Caminho de endpoint e produto** aprovado para criação e consulta de pagamento

## Escolha seu padrão

<CardGroup cols={3}>
  <Card title="Empresa paga fornecedor" icon="receipt" href="#padrão-empresa-paga-fornecedor">
    Pague um fornecedor, vendedor, prestador de serviços ou exportador — propósito do pagamento e documentos podem ser necessários.
  </Card>

  <Card title="Plataforma atende clientes empresariais" icon="building" href="#padrão-plataforma-atende-clientes-empresariais">
    Fintech ou plataforma que permite que clientes empresariais downstream movam fundos.
  </Card>

  <Card title="Banco ou fintech atende consumidores" icon="smartphone" href="#padrão-banco-ou-fintech-atende-consumidores">
    Ramps incorporados para usuários finais individuais — defina o escopo de KYC, fraude e piloto primeiro.
  </Card>
</CardGroup>

| Padrão                                                                                     | Sinais de descoberta                                                  | Foco principal de escopo                            |
| ------------------------------------------------------------------------------------------ | --------------------------------------------------------------------- | --------------------------------------------------- |
| [Empresa paga fornecedor](#padrão-empresa-paga-fornecedor)                                 | Entidade legal diferente recebe fundos; fatura/pagamento a fornecedor | Configuração de beneficiário, propósito, documentos |
| [Plataforma atende clientes empresariais](#padrão-plataforma-atende-clientes-empresariais) | Plataforma + empresas downstream; mapeamento de ID de cliente         | Cliente de registro, escopo de onboarding           |
| [Banco ou fintech atende consumidores](#padrão-banco-ou-fintech-atende-consumidores)       | Usuários finais individuais; UX incorporada                           | Classificação de usuário, modelo de conformidade    |

## Padrão: Empresa paga fornecedor

**Use quando:** Uma empresa cadastrada paga um fornecedor, vendedor, prestador de serviços, exportador ou outro beneficiário terceiro.

**Sinais de descoberta:**

* O destinatário **não** é a mesma entidade legal do remetente
* Pagamento vinculado a uma fatura, ordem de compra, contrato ou relacionamento de serviço
* Propósito do pagamento, memo ou documentos de suporte podem ser necessários
* Liquidação internacional pode se aplicar — consulte [Financiamento de comércio internacional](/pt-BR/solutions/cross-border-trade-finance)

**Partes a confirmar:**

| Parte                   | Questão de escopo                                                 |
| ----------------------- | ----------------------------------------------------------------- |
| Cliente de registro     | Quem está cadastrado no SpherePay — pagador, plataforma ou outro? |
| Remetente               | Quem inicia e financia o pagamento?                               |
| Beneficiário            | Quem recebe os fundos — e como deve ser registrado ou analisado?  |
| Proprietário dos fundos | De quem é o dinheiro que está se movendo em cada etapa?           |

<Steps>
  <Step title="Cadastrar as partes obrigatórias">
    Registre o pagador via [POST /v2/customer](/pt-BR/api-reference/customer/post) e complete o [KYB empresarial](/pt-BR/concepts/onboarding/business-kyb) ou o [KYC individual](/pt-BR/concepts/onboarding/individual-kyc) conforme aplicável.
  </Step>

  <Step title="Registrar o instrumento de origem do pagador">
    Vincule a [conta bancária](/pt-BR/api-reference/bank-account/post) ou [carteira](/pt-BR/api-reference/wallet/post) do pagador.
  </Step>

  <Step title="Confirmar configuração do beneficiário">
    Dependendo do fluxo, o beneficiário pode precisar ser cadastrado como cliente SpherePay ou de outra forma analisado/registrado antes que os fundos possam ser enviados. Confirme com o SpherePay antes da implementação.
  </Step>

  <Step title="Coletar propósito e documentos">
    Reúna propósito do pagamento, motivo do pagamento, contexto do relacionamento e documentos de suporte — consulte [Requisitos adicionais](#requisitos-adicionais-para-pagamentos-de-terceiros). Para pagamentos **SWIFT** é necessário um documento de suporte — consulte [Documentos de suporte para pagamentos SWIFT de terceiros](#documentos-de-suporte-para-pagamentos-swift-de-terceiros).
  </Step>

  <Step title="Criar o pagamento">
    Use o **endpoint suportado para seu fluxo de terceiros aprovado** — confirme o caminho com o SpherePay antes de iniciar a engenharia.
  </Step>

  <Step title="Rastrear e reconciliar">
    Consulte o status usando o caminho de recuperação confirmado para o seu fluxo. Reconcilie contra registros de fatura ou ordem de compra.
  </Step>
</Steps>

<Note>
  Pagamentos de terceiros não são "transferências próprias com destinatário diferente." Caminho de endpoint, modelo de beneficiário, campos de conformidade e tratamento de status podem todos diferir. Não assuma que [POST /v2/transfer](/pt-BR/api-reference/transfer/post) se aplica.
</Note>

## Padrão: Plataforma atende clientes empresariais

**Use quando:** Uma fintech ou plataforma permite que seus clientes empresariais movam fundos pelo SpherePay.

**Sinais de descoberta:**

* Seu cliente é uma **plataforma**, não apenas um pagador final
* Empresas downstream enviam ou recebem fundos através do seu produto
* IDs internos de clientes devem ser mapeados para IDs de clientes SpherePay
* A propriedade de RFI e suporte deve ser definida antes de entrar em produção

<Steps>
  <Step title="Confirmar escopo de onboarding">
    Decida se a entidade da plataforma, cada empresa downstream ou ambas devem ser cadastradas — confirme com o SpherePay.
  </Step>

  <Step title="Escolher um modelo de onboarding">
    Se estiver usando [onboarding Platform-Managed](/pt-BR/concepts/onboarding/overview#modelos-de-onboarding), confirme a elegibilidade com a Conformidade do Sphere antes de construir.
  </Step>

  <Step title="Criar e mapear registros de clientes">
    Use [POST /v2/customer](/pt-BR/api-reference/customer/post) para cada entidade que deve ser verificada. Mapeie IDs internos para IDs de clientes SpherePay.
  </Step>

  <Step title="Registrar instrumentos por parte">
    Registre [contas bancárias](/pt-BR/concepts/transfers/bank-accounts) e [carteiras](/pt-BR/concepts/transfers/wallets) nos registros de clientes corretos.
  </Step>

  <Step title="Definir caminho de pagamento">
    Confirme o caminho de endpoint para criação de pagamento e consulta de status. Para resultados de aceitação de fiat, consulte [Aceitação de pagamentos](/pt-BR/solutions/payment-acceptance).
  </Step>
</Steps>

<Warning>
  Não assuma que cadastrar apenas a plataforma é suficiente. Dependendo do fluxo, cada empresa subjacente pode precisar ser cadastrada e verificada antes de poder enviar ou receber fundos.
</Warning>

## Padrão: Banco ou fintech atende consumidores

**Use quando:** Uma instituição regulada ou fintech expõe ramps para usuários finais individuais em escala.

**Sinais de descoberta:**

* Os usuários downstream incluem **consumidores** (não apenas empresas)
* É necessária UX incorporada de on-ramp/off-ramp ou hospedada
* A propriedade do KYC, controles de fraude e considerações de estorno diferem do B2B
* Um piloto limitado em um corredor e segmento de usuário é apropriado antes de um lançamento amplo

<Steps>
  <Step title="Classificar usuários downstream">
    Separe usuários empresariais de usuários consumidores — os caminhos de onboarding e os requisitos de parceiro diferem.
  </Step>

  <Step title="Confirmar responsabilidade de onboarding">
    Defina se o SpherePay, sua plataforma ou um modelo híbrido cuida do KYC/KYB, RFIs e suporte.
  </Step>

  <Step title="Definir handoff de dados">
    Documente quais campos você coleta upstream vs. quais o SpherePay coleta via API ou [link hospedado](/pt-BR/concepts/onboarding/kyc-via-link).
  </Step>

  <Step title="Escolher sua UX">
    Integração por API vs. [Ramp Widget](/widget/overview) — com base em quem possui a experiência de frontend.
  </Step>

  <Step title="Começar com um piloto limitado">
    Valide um corredor, um rail e um tipo de usuário antes de escalar volume ou segmentos de usuário.
  </Step>
</Steps>

<Warning>
  Fluxos para consumidores podem exigir considerações de onboarding, fraude e parceiro diferentes do B2B. Confirme a elegibilidade com o SpherePay antes de assumir que um padrão de terceiros B2B escala para consumidores.
</Warning>

## Requisitos adicionais para pagamentos de terceiros

Planeje coletar e passar o seguinte quando seu corredor aprovado os exigir:

* **Propósito do pagamento** — classificação para conformidade e parceiros bancários
* **Motivo do pagamento** — descrição em linguagem comum de por que os fundos estão se movendo
* **Código de propósito do pagamento** — valores permitidos variam por corredor; confirme o conjunto com o SpherePay antes de construir
* **Documentos de suporte** — contratos, faturas ou evidência de relacionamento quando necessário
* **Informações do relacionamento com beneficiário** — fornecedor, prestador de serviços, vendedor de marketplace, etc.
* **Visibilidade de remetente/destinatário** — o que o beneficiário vê no wire ou extrato
* **Análise antes da liquidação** — alguns fluxos requerem análise de documentos ou manual; planeje a UX de status de acordo

Use apenas campos e status documentados na API pública para o caminho do produto aprovado.

## Documentos de suporte para pagamentos SWIFT de terceiros

Pagamentos SWIFT (USD entregue a uma conta bancária internacional) são frequentemente **pagamentos de terceiros** — o beneficiário é uma entidade legal diferente do seu cliente cadastrado. Um pagamento SWIFT de terceiros deve carregar um **documento de suporte** (normalmente a fatura que ele liquida) junto com um motivo e uma descrição de pagamento. O pagamento é rejeitado se algum deles estiver ausente.

<Warning>
  O SWIFT exige o **perfil de verificação C** — uma conta bancária SWIFT em USD não pode ser criada até que o perfil C seja aprovado. Registre o beneficiário como uma conta bancária SWIFT em USD (`currency: "usd"`, `networks: ["swift"]`) com um `accountNumber` (IBAN ou BBAN) e `bic`, além de até três `intermediaryBics` opcionais. Confirme que o perfil C está habilitado com o SpherePay antes de construir.
</Warning>

### Documentos elegíveis

Faça upload do único documento que melhor comprove o pagamento — mais comumente a **fatura** que ele liquida. Outras evidências aceitáveis incluem ordens de compra, contratos assinados e acordos de serviço. Os formatos aceitos são **PDF, JPEG e PNG**, de até **10 MB**.

### Como funciona

<Steps>
  <Step title="Fazer upload do documento de suporte">
    Chame [POST /v2/document](/pt-BR/api-reference/document/post) com `target: "transfer"` e anexe o arquivo. Nenhum `documentType` é necessário para esse target. A resposta retorna o `id` do documento (por exemplo, `document_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6`).
  </Step>

  <Step title="Criar o pagamento com o documento e os campos de terceiros">
    Crie a transferência SWIFT com `isThirdParty: true` e inclua `documentId` (o `id` da etapa 1), `paymentReason` e `paymentDescription`. Para um pagamento de terceiros **todos os três são obrigatórios** — a requisição é rejeitada com um `422` se algum estiver ausente, e o documento deve pertencer à sua aplicação.
  </Step>

  <Step title="Rastrear e reconciliar">
    Consulte o status normalmente e reconcilie contra a fatura ou ordem de compra que o documento representa.
  </Step>
</Steps>

<Tip>
  **Reutilize o mesmo documento em vários pagamentos.** Um `documentId` não é consumido quando você o referencia — você pode passar o mesmo em várias transferências. Isso é útil para **pagamentos recorrentes vinculados a um único contrato ou ordem de compra**: faça upload do documento de suporte uma vez e, em seguida, referencie seu `documentId` em cada pagamento da série em vez de fazer o upload novamente a cada vez.
</Tip>

`paymentReason` aceita um dos seguintes: `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` ou `other`.

### O que colocar na descrição do documento

Ao fazer o upload do documento, use o campo opcional `description` para dar ao SpherePay **contexto que ele pode usar para analisar e rotear o pagamento mais rapidamente** — não apenas uma repetição do nome do arquivo. Inclua, quando relevante:

* O que é o documento — por exemplo, "Fatura comercial INV-2024-0098"
* O propósito do pagamento — por exemplo, "Pagamento por serviços de manufatura do Q2"
* As partes e seu relacionamento — por exemplo, "Da Acme Inc. para a Shenzhen Supplier Co., fabricante contratado"
* O número da fatura ou da ordem de compra que o pagamento liquida, e o valor caso difira do total integral da fatura

<Tip>
  Descrições claras e específicas reduzem a chance de um RFI de conformidade e aceleram a análise. O `description` do documento e o `paymentDescription` do pagamento (de 1 a 500 caracteres) são campos separados — use ambos para fornecer o contexto completo.
</Tip>

## Confirmar antes de construir

<Steps>
  <Step title="Identificar as partes">
    Confirme cliente de registro, remetente, beneficiário e proprietário dos fundos em cada etapa.
  </Step>

  <Step title="Definir o escopo da função da plataforma">
    Determine se a plataforma está no fluxo de fundos e se os usuários downstream são empresas, consumidores ou ambos.
  </Step>

  <Step title="Validar corredor e geografia">
    Confirme disponibilidade de rail, moeda e região — incluindo restrições de TX/PA para pagamentos de terceiros.
  </Step>

  <Step title="Confirmar inputs de conformidade">
    Defina propósito do pagamento, documentos obrigatórios, modelo de configuração do beneficiário e visibilidade de remetente/destinatário.
  </Step>

  <Step title="Confirmar caminho de endpoint">
    Verifique o caminho aprovado para criação e consulta de pagamento com o SpherePay — consulte [Criação e status de pagamento](#criação-e-status-de-pagamento).
  </Step>

  <Step title="Atribuir propriedade operacional">
    Defina quem cuida de RFIs e suporte ao cliente antes de entrar em produção.
  </Step>
</Steps>

## Criação e status de pagamento

Caminhos de pagamento de terceiros são **específicos do produto**. A [Referência da API](/pt-BR/api-reference/transfer/post) pública documenta `POST /v2/transfer` para fluxos de on-ramp/off-ramp e transferência cotada. **A criação de pagamento B2B de terceiros pode usar um caminho de endpoint diferente** — confirme com o SpherePay antes da implementação.

| Tipo de fluxo                                         | Orientação                                                                                                                           |
| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| On-ramp/off-ramp próprio (first-party)                | [POST /v2/transfer](/pt-BR/api-reference/transfer/post) — consulte [Fluxos Próprios](/pt-BR/implementation-guides/first-party-flows) |
| Corredor cotado de fiat para fiat (quando habilitado) | [POST /v2/quote](/pt-BR/api-reference/quote/post) e criação de transferência com `quoteId` — confirme aplicabilidade                 |
| Pagamentos B2B de terceiros aprovados                 | Use o caminho de endpoint confirmado pelo SpherePay — não assuma transferência v2 própria (first-party)                              |

<Tip>
  Consulte o status usando o caminho de recuperação confirmado para seu fluxo aprovado. Respostas de terceiros podem incluir campos e status além do [ciclo de vida de transferência própria (first-party)](/pt-BR/concepts/transfers/lifecycle) — confirme o conjunto completo com o SpherePay.
</Tip>

## O que enviar ao Sphere antes do kickoff

* Entidade legal da plataforma (se aplicável)
* Cliente de registro
* Remetente e beneficiário
* Propriedade dos fundos em cada etapa
* Se a plataforma está no fluxo de fundos
* Tipo de usuário downstream: empresa, consumidor ou ambos
* Padrão selecionado: pagamento a fornecedor, B2B de plataforma ou incorporação para consumidor
* Código de propósito do pagamento e motivo do pagamento
* Tipo de documentação de suporte, se necessário
* Relacionamento com beneficiário / contexto do destinatário
* Visibilidade obrigatória de remetente/destinatário
* Moeda fiat e rail; stablecoin e rede, se aplicável
* Volume mensal esperado
* Tamanho médio e máximo de transação
* Proprietário de RFI/suporte
* Guia de Solução relacionado, se identificado

## Validar antes de iniciar a engenharia

| Bloqueador                                              | Por que importa                                                                                                |
| ------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| Perfil de verificação não aprovado                      | O perfil de KYC/KYB obrigatório está incompleto, pendente, ausente ou rejeitado                                |
| Provedor/corredor não habilitado                        | Cliente aprovado em geral, mas não habilitado para o corredor ou rail específico                               |
| Restrição de geografia/corredor                         | Pagamentos de terceiros não estão disponíveis no **Texas ou na Pensilvânia**; outras regiões podem ter limites |
| Cliente de registro indefinido                          | O SpherePay não pode determinar quem deve ser cadastrado                                                       |
| Plataforma no fluxo de fundos                           | Pode alterar requisitos de onboarding, conformidade e parceiro                                                 |
| Beneficiário não identificado                           | O pagamento não pode ser avaliado ou roteado                                                                   |
| Propósito de pagamento ausente ou não suportado         | Código de propósito obrigatório ou motivo ausente ou não habilitado para o corredor                            |
| Documentos de suporte ausentes                          | A liquidação pode ser bloqueada até que os documentos sejam fornecidos                                         |
| Fluxo de terceiros usando premissas de primeiro partido | Padrões de tesouraria/on-ramp podem não se aplicar a pagamentos de fornecedores ou plataformas                 |
| Endpoint errado assumido                                | O caminho de criação de pagamento deve corresponder ao seu produto de terceiros aprovado                       |
| Escala para consumidores com padrão B2B                 | A incorporação para consumidores pode exigir um caminho diferente                                              |

## Lista de verificação pré-kickoff

* [ ] Cliente de registro, remetente e beneficiário identificados
* [ ] Propriedade dos fundos e função da plataforma documentadas
* [ ] Padrão selecionado e confirmado com o SpherePay
* [ ] Partes obrigatórias cadastradas ou configuração do beneficiário confirmada para o corredor
* [ ] Provedor/corredor e geografia validados (incluindo TX/PA)
* [ ] Propósito do pagamento, motivo e documentos coletados se necessário
* [ ] Para SWIFT: perfil de verificação C aprovado, conta de beneficiário SWIFT em USD registrada e (para terceiros) `paymentReason`, `paymentDescription` e um `documentId` carregado prontos
* [ ] Caminho de endpoint para criação e status confirmado com o SpherePay
* [ ] Proprietário de RFI/suporte definido
* [ ] Plano de reconciliação definido
* [ ] Inputs de kickoff enviados ao SpherePay

## Antes de entrar em produção

O SpherePay não possui sandbox separado — os testes de integração rodam em produção com dados de identidade reais. Execute uma transferência ao vivo de baixo valor em cada corredor antes do lançamento.

A primeira transferência para um novo beneficiário pode acionar um RFI de conformidade do parceiro bancário. Defina essa expectativa com seu cliente desde o início e garanta que seu [proprietário de RFI e suporte ao cliente](#output-de-escopo) esteja pronto para responder.

Para dúvidas de liquidação de usuários finais, compartilhe os artigos da Base de Conhecimento do 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) e [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 os usuários se autoatendam em vez de abrir tickets de suporte com você.

## Aprofundar

<CardGroup cols={2}>
  <Card title="Folha de pagamento" icon="banknote" href="/pt-BR/solutions/payroll">
    Desembolsos de terceiros para funcionários e prestadores de serviços.
  </Card>

  <Card title="Financiamento de comércio internacional" icon="ship" href="/pt-BR/solutions/cross-border-trade-finance">
    Padrões de pagamento importer–exportador e liquidação de faturas.
  </Card>

  <Card title="Aceitação de pagamentos" icon="hand-coins" href="/pt-BR/solutions/payment-acceptance">
    Aceitação de fiat mediada por plataforma com liquidação em stablecoin.
  </Card>

  <Card title="Fluxos Próprios" icon="landmark" href="/pt-BR/implementation-guides/first-party-flows">
    Quando origem e destino pertencem à mesma entidade legal.
  </Card>

  <Card title="Base de Conhecimento e FAQ" icon="book-open" href="https://spherepay-knowledge-base.help.usepylon.com/">
    Artigos de suporte para usuários finais — prazos de liquidação, fundos ausentes, mínimos e guias do painel — para repassar aos seus usuários.
  </Card>
</CardGroup>