splitRules — tanto em POST /v1/charges quanto em POST /v1/sessions. Na sessão, a existência dos sellers é validada na criação; na captura da cobrança, o fluxo de transações efetiva o vínculo com o provedor de acordo com o estado do recebedor.
Todo recebedor deve estar vinculado a um
merchantId válido. A listagem de sellers sem merchant e o split agnóstico foram descontinuados. Veja os detalhes na release de jun/2026.Status de recebedor
A criação de um Seller nos provedores ocorre de forma assíncrona, e além disso não é realizada de forma imediata, uma vez que critérios precisam ser analisados, assim como uma transação financeira. Para ser notificado sobre atualizações nesse processo, utilize os webhooks. Os status possíveis para um seller são:| Status | Descrição |
|---|---|
| pending | Informações recebidas e pendentes de validação no provedor |
| active | Recebedor ativo para transações e saque dos valores |
| partial | Apenas parte dos provedores está ativa para o recebedor |
| inactive | Recebedor não pode transacionar nem sacar valores |
| blocked | Recebedor bloqueado |
Provedores suportados
Veja os provedores que suportam criação deSellers na nossa tabela de provedores e meios de pagamento suportados.
Exemplo de criação de recebedor
Caso precise realizar um recebedor do tipo pessoa física, utilize a propriedade owner:Identificador do banco: bank e ispb
A bankAccount aceita dois identificadores da instituição financeira:
bank— código COMPE de 3 dígitos do banco (ex.:077para Banco Inter). Consulte a tabela de códigos COMPE dos principais bancos.ispb— identificador ISPB da instituição no Sistema de Pagamentos Brasileiro, com 8 dígitos numéricos. A relação canônica de ISPBs é publicada pelo Banco Central (BCB).
- Pelo menos um obrigatório. Na criação (
POST /v1/sellers), enviebank,ispbou ambos — não vale omitir os dois. ispbtem precedência. Quando os dois forem enviados, o roteamento downstream usa oispb; obankpermanece aceito como fallback/auxiliar.- Semântica PATCH. Em
PATCH /v1/sellers/{id}, omitir a chave preserva o valor persistido; enviarnullem um dos identificadores limpa aquele valor. A invariante “ao menos um identificador” é validada considerando o estado mesclado (payload + persistido). - Erro. Se o merge final ficaria sem
banke semispb, a API responde400comerror.key = bank_identifier_required.
Exemplo de criação identificando o banco apenas por ispb
Exemplo de PATCH trocando bank por ispb
A troca é aceita porque o estado mesclado mantém ao menos um identificador (ispb):
bankAccount.bank. Como alternativa, o campo bankAccount.ispb pode ser usado para identificar a instituição financeira pelo código publicado pelo Banco Central (BCB).