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: 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
1
Cadastrar as partes obrigatórias
Registre o pagador via POST /v2/customer e complete o KYB empresarial ou o KYC individual conforme aplicável.
2
Registrar o instrumento de origem do pagador
Vincule a conta bancária ou carteira do pagador.
3
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.
4
Coletar propósito e documentos
Reúna propósito do pagamento, motivo do pagamento, contexto do relacionamento e documentos de suporte — consulte Requisitos adicionais. Para pagamentos SWIFT é necessário um documento de suporte — consulte Documentos de suporte para pagamentos SWIFT de terceiros.
5
Criar o pagamento
Use o endpoint suportado para seu fluxo de terceiros aprovado — confirme o caminho com o SpherePay antes de iniciar a engenharia.
6
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.
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
1
Confirmar escopo de onboarding
Decida se a entidade da plataforma, cada empresa downstream ou ambas devem ser cadastradas — confirme com o SpherePay.
2
Escolher um modelo de onboarding
Se estiver usando onboarding Platform-Managed, confirme a elegibilidade com a Conformidade do Sphere antes de construir.
3
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.
4
Registrar instrumentos por parte
Registre contas bancárias e carteiras nos registros de clientes corretos.
5
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
1
Classificar usuários downstream
Separe usuários empresariais de usuários consumidores — os caminhos de onboarding e os requisitos de parceiro diferem.
2
Confirmar responsabilidade de onboarding
Defina se o SpherePay, sua plataforma ou um modelo híbrido cuida do KYC/KYB, RFIs e suporte.
3
Definir handoff de dados
Documente quais campos você coleta upstream vs. quais o SpherePay coleta via API ou link hospedado.
4
Escolher sua UX
Integração por API vs. Ramp Widget — com base em quem possui a experiência de frontend.
5
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.
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
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.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
1
Fazer upload do documento de suporte
Chame POST /v2/document 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).2
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.3
Rastrear e reconciliar
Consulte o status normalmente e reconcilie contra a fatura ou ordem de compra que o documento representa.
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 opcionaldescription 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
Confirmar antes de construir
1
Identificar as partes
Confirme cliente de registro, remetente, beneficiário e proprietário dos fundos em cada etapa.
2
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.
3
Validar corredor e geografia
Confirme disponibilidade de rail, moeda e região — incluindo restrições de TX/PA para pagamentos de terceiros.
4
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.
5
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.
6
Atribuir propriedade operacional
Defina quem cuida de RFIs e suporte ao cliente antes de entrar em produção.
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.
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
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,paymentDescriptione umdocumentIdcarregado 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 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.