Guia de Cash Out (PIX Out)
Guia de Cash Out (PIX Out)
Este guia explica passo a passo como realizar transferências PIX (cash out) com consulta prévia de chave. O pagamento de boleto, que é o outro cash out da API, está em Pagamento de Boleto no fim desta página.
Visão Geral
O Cash Out permite enviar dinheiro via PIX para qualquer chave cadastrada no sistema PIX brasileiro. O fluxo recomendado é:
- Consultar a chave - Validar e obter os dados do destinatário
- Confirmar os dados - Exibir para o usuário para confirmação
- Executar a transferência - Enviar o PIX
Fluxo de Integração
Tipos de Chave PIX
Passo 1: Consultar a Chave PIX (Opcional mas Recomendado)
Antes de transferir, consulte a chave para validar o destinatário e exibir os dados para confirmação do usuário:
A API consulta a chave automaticamente durante a transferência — a consulta prévia é opcional, mas melhora a experiência do usuário. O resultado fica em cache por 24 h (use ?noCache=true para forçar uma consulta nova ao DICT) e consome cota de consultas conforme as políticas do tenant. O consumo de DICT é medido em tempo real e acompanhado pela CorpX: antes de integrar, leia Consultas de chave PIX.
O que a transferência devolve
A resposta da transferência não repete os dados do destinatário: ela traz o desfecho da operação (status, paymentId, endToEndId). Nome e documento de quem recebeu aparecem no extrato e no lookup do pagamento.
Passo 2: Executar a Transferência
Execute a transferência PIX via chave:
Request
Parâmetros do Body
A conta de origem vem do path ({accountId}) e a moeda é sempre BRL — nenhum dos dois é enviado no body.
Resposta de Sucesso
O status HTTP reflete o desfecho: 200 (COMPLETED), 422 (FAILED),
202 (TIMEOUT/PENDING — indeterminado; confira o extrato antes de
reenviar).
Rejeições imediatas do liquidante (antifraude ou saldo insuficiente na
liquidação) retornam 422 FAILED na hora, com errorCode
(partner_rejected / insufficient_funds) e errorReason preenchidos.
Transferências retidas no banco liquidante aparecem como
PENDING_APPROVAL nas consultas e aguardam o desfecho por até ~25 minutos
antes de marcar TIMEOUT; o resultado chega pelos webhooks
pix.out.completed / pix.out.failed / pix.out.timeout.
Nesse estado a consulta e o pix.out.timeout trazem hold
(owner: "partner" + reason) e o estado bruto em
partnerStatus/partnerStatusId. PENDING_APPROVAL nunca significa
aprovação pendente do seu lado ou do nosso: a decisão é do liquidante.
E TIMEOUT não é o fim — seguimos consultando por até 7 dias e, se ele
liquidar ou recusar, você recebe pix.out.completed / pix.out.failed
com late: true e o mesmo paymentId.
Resposta de Erro
Timeout no fluxo síncrono
Se o liquidante não confirmar dentro da janela, a API responde 202 com
status: "TIMEOUT" e um campo warning — não existe 207. O PIX pode ter
sido enviado: consulte o extrato ou o lookup do pagamento antes de reenviar.
O desfecho tardio chega por webhook (pix.out.completed / pix.out.failed).
Fluxo assíncrono (recomendado para alto volume)
Use POST /v1/accounts/{accountId}/pix/out/async para agendar o pagamento e receber 202 imediato:
Resposta:
A resposta 202 inclui o header Location apontando para
/v1/accounts/{accountId}/payments/{identifier} — um alias mantido por
compatibilidade, que responde com headers Deprecation. A rota canônica de
consulta é GET /v1/accounts/{accountId}/pix/payments/lookup?identifier=.
O resultado final (sucesso/falha) é entregue por webhook e também pode ser
consultado por identifier/paymentId.
Passo 3: Consultar Status da Transferência
Após executar uma transferência, você pode consultar seu status usando o ID E2E:
Request
Parâmetros de Query
*Pelo menos um dos dois (endToEndId ou identifier) é obrigatório. O accountId vai no path, não na query.
Resposta de Sucesso (200 OK)
Esta rota responde no mesmo envelope do extrato (items[]), com 0 ou 1
item. Os horários (timestamp) saem em horário de Brasília (-03:00).
Para receber um único objeto (em vez do envelope items[]), use
GET /v1/accounts/{accountId}/pix/payments/lookup?identifier=... (ou
?endToEnd=...).
Status Possíveis
Fluxo de estados
- O resultado final chega pelos webhooks
pix.out.completed/pix.out.failed. Em caso deTIMEOUT, a API também emitepix.out.timeout(estado indeterminado — confira o extrato; umcompleted/failedtardio ainda pode chegar depois, comlate: truee o mesmopaymentId). - Reenvio com a mesma
Idempotency-Keydepende do desfecho anterior: se o pagamento terminou emFAILED, a chave é liberada e a nova requisição reexecuta o pagamento (desde v2.43.3); se terminou emTIMEOUT, o reenvio não acontece — o estado é indeterminado e a API devolve o resultado registrado. Com uma chave nova, você pode duplicar o envio. Detalhes em Idempotência.
Sempre salve o identifier das transferências e consulte o status por ele — é o ID que você define, estável e disponível desde a criação (o endToEndId só existe após a liquidação).
Exemplo Completo: Script de Cash Out
Consultar QR Code (Decode)
Antes de pagar, você pode decodificar o QR Code para exibir os dados do beneficiário ao usuário:
Resposta (QR dinâmico imediato):
Para QR de cobrança com vencimento (dynamic-due-date), o response
inclui também os componentes do valor (discount, deduction,
interest, penalty), originalAmount (valor de face antes dos
ajustes), dueDate, paymentDeadline e payeeTradeName (nome
fantasia da PJ). Veja o exemplo correspondente no OpenAPI.
Você pode reutilizar decodeId no body do POST /pix/out/qr-code/async
para pular um segundo decode na hora do pagamento.
Após confirmar, use o endpoint de pagamento abaixo para executar.
Pagar QR Code (PIX Out via EMV)
Se você possui um código EMV (QR Code copia e cola), use o endpoint assíncrono (canônico):
Fluxo assíncrono (recomendado)
POST /v1/accounts/{accountId}/pix/out/qr-code/async — resposta 202 imediata:
Resposta:
A resposta 202 inclui o header Location apontando para o lookup do
pagamento. O resultado final (sucesso/falha/timeout) chega por webhook
(pix.out.completed, pix.out.failed, pix.out.timeout) e também pode
ser consultado por identifier/paymentId.
Endpoint síncrono (deprecated)
POST /v1/accounts/{accountId}/pix/out/qr-code (sync) está deprecated.
Continue funcionando por compatibilidade e devolve headers Deprecation,
Sunset e Link (sunset previsto: 2026-11-21). Migre para
/pix/out/qr-code/async.
Webhook de Transferência
Após a transferência, você receberá um webhook no envelope canônico
(id, type, occurredAt, schemaVersion, data):
O evento equivalente de falha é pix.out.failed (com error no data) e o
de estado indeterminado é pix.out.timeout. A referência completa dos campos
está em Webhooks.
BigPix (descontinuado)
O limite de R$ 15.000 por transação foi removido — POST /v1/accounts/{accountId}/pix/out
agora aceita qualquer valor em uma única transação. O BigPix (que dividia valores
grandes em múltiplos PIX) não é mais necessário e está descontinuado.
Os endpoints /pix/out/bigpix e /pix/out/bank-account/bigpix continuam funcionais
por retrocompatibilidade, mas retornam o header Deprecation: true. Migre para
POST /pix/out (ou /pix/out/bank-account). A data de remoção definitiva será
anunciada no changelog com antecedência.
Pagamento de Boleto
Boleto é o outro cash out disponível na v2 (na v1 esses endpoints respondiam
503). São três rotas: uma para ler o boleto antes de pagar, uma para pagar e
uma para consultar o resultado.
Passo 1: Preview (ler o boleto)
Resolve a linha digitável no parceiro e devolve 200 com os dados do título
(beneficiário, pagador, valores, vencimento) para você exibir antes de debitar.
O campo canônico é line; barcode é aceito como alias. Boleto não encontrado
no parceiro devolve 404 not_found.
Pague o totalUpdated, não o amount
amount é o valor de face — o mesmo número que está gravado no código de
barras. totalUpdated é o que o liquidante aceita hoje: face + juros +
multa − desconto.
Em título vencido os dois diferem, e o liquidante recusa qualquer valor que não
seja o atualizado (boleto_amount_mismatch). Como os encargos correm por dia, o
totalUpdated de ontem já não serve: faça o preview no dia do pagamento, e
garanta saldo para o valor atualizado, não para o de face.
Passo 2: Pagar
Valor divergente volta como boleto_amount_mismatch (422), e a mensagem traz o
valor que o liquidante espera — refaça o preview e reenvie com ele.
A resposta é sempre 202, nunca 200: o pagamento roda de forma
assíncrona e o corpo traz paymentId (= boletoId, no formato bol_{uuid}),
status: "PROCESSING" e um header Location apontando para a consulta de
status.
O boletoId é derivado de (accountId, Idempotency-Key), então repetir a
requisição com a mesma chave devolve o mesmo paymentId e reaproveita a
execução em curso — sem débito duplicado.
Passo 3: Consultar o resultado
Aceita tanto o paymentId canônico (bol_...) quanto a referência do
parceiro. Enquanto o parceiro ainda não devolveu a referência, a rota responde
200 com o último status local conhecido (PROCESSING) em vez de erro.
O desfecho também chega por webhook: boleto.paid e boleto.failed
(ver Webhooks). A compensação de um boleto pode levar horas —
até o dia útil seguinte — então trate PROCESSING como estado normal e
prolongado, não como falha.
Erros Comuns
A lista completa com mensagens e semântica está em Erros.
Reenviar a mesma Idempotency-Key em PIX out não devolve 409: a API
retorna o resultado já registrado (ou reexecuta, se o desfecho anterior foi
FAILED).
Boas Práticas
- Sempre consulte a chave antes de transferir para validar o destinatário
- Confirme com o usuário os dados antes de executar
- Use uma Idempotency Key única por transferência — e reutilize a mesma chave ao repetir a requisição, nunca uma nova
- Salve o E2E para rastreamento e suporte
- Configure webhooks para receber confirmações assíncronas
- Implemente retry com exponential backoff para falhas temporárias
Limites
Não há mais limite fixo por transação — o valor é limitado apenas pelos
limites operacionais da conta (consulte GET /v1/accounts/{accountId}/pix/limits).
Os limites podem ser personalizados. Entre em contato com o suporte para mais informações.
Próximos Passos
- Guia de Devolução - Estornar transferências recebidas
- Webhooks - Configurar notificações
- Erros - Lista completa de códigos de erro