Movendo fundos entre a própria conta bancária e a própria carteira de um cliente? Use Fluxos Próprios.
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
Empresa paga fornecedor
Pague um fornecedor, vendedor, prestador de serviços ou exportador — propósito do pagamento e documentos podem ser necessários.
Plataforma atende clientes empresariais
Fintech ou plataforma que permite que clientes empresariais downstream movam fundos.
Banco ou fintech atende consumidores
Ramps incorporados para usuários finais individuais — defina o escopo de KYC, fraude e piloto primeiro.
| Padrão | Sinais de descoberta | Foco principal de escopo |
|---|---|---|
| Empresa paga fornecedor | Entidade legal diferente recebe fundos; fatura/pagamento a fornecedor | Configuração de beneficiário, propósito, documentos |
| Plataforma atende clientes empresariais | Plataforma + empresas downstream; mapeamento de ID de cliente | Cliente de registro, escopo de onboarding |
| 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
| 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? |
Cadastrar as partes obrigatórias
Registre o pagador via POST /v2/customer e complete o KYB empresarial ou o KYC individual conforme aplicável.
Registrar o instrumento de origem do pagador
Vincule a conta bancária ou carteira do pagador.
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.
Coletar propósito e documentos
Reúna propósito do pagamento, motivo do pagamento, contexto do relacionamento e documentos de suporte — consulte Requisitos adicionais.
Criar o pagamento
Use o endpoint suportado para seu fluxo de terceiros aprovado — confirme o caminho com o SpherePay antes de iniciar a engenharia.
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 se aplica.
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
Confirmar escopo de onboarding
Decida se a entidade da plataforma, cada empresa downstream ou ambas devem ser cadastradas — confirme com o SpherePay.
Escolher um modelo de onboarding
Se estiver usando onboarding Platform-Managed, confirme a elegibilidade com a Conformidade do Sphere antes de construir.
Criar e mapear registros de clientes
Use POST /v2/customer para cada entidade que deve ser verificada. Mapeie IDs internos para IDs de clientes SpherePay.
Registrar instrumentos por parte
Registre contas bancárias e carteiras nos registros de clientes corretos.
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.
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
Classificar usuários downstream
Separe usuários empresariais de usuários consumidores — os caminhos de onboarding e os requisitos de parceiro diferem.
Confirmar responsabilidade de onboarding
Defina se o SpherePay, sua plataforma ou um modelo híbrido cuida do KYC/KYB, RFIs e suporte.
Definir handoff de dados
Documente quais campos você coleta upstream vs. quais o SpherePay coleta via API ou link hospedado.
Escolher sua UX
Integração por API vs. Ramp Widget — com base em quem possui a experiência de frontend.
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
Confirmar antes de construir
Identificar as partes
Confirme cliente de registro, remetente, beneficiário e proprietário dos fundos em cada etapa.
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.
Validar corredor e geografia
Confirme disponibilidade de rail, moeda e região — incluindo restrições de TX/PA para pagamentos de terceiros.
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.
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
Caminhos de pagamento de terceiros são específicos do produto. A Referência da API pública documentaPOST /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 — consulte Fluxos Próprios |
| Corredor cotado de fiat para fiat (quando habilitado) | POST /v2/quote 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) |
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
- 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 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? e My funds are missing or have not landed in my account para que os usuários se autoatendam em vez de abrir tickets de suporte com você.Aprofundar
Folha de pagamento
Desembolsos de terceiros para funcionários e prestadores de serviços.
Financiamento de comércio internacional
Padrões de pagamento importer–exportador e liquidação de faturas.
Aceitação de pagamentos
Aceitação de fiat mediada por plataforma com liquidação em stablecoin.
Fluxos Próprios
Quando origem e destino pertencem à mesma entidade legal.
Base de Conhecimento e FAQ
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.