Saque em duas etapas​

Criar Intenção de Saque recebe o saque completo mais o holderDocument, confere se a chave PIX pertence mesmo a esse titular e devolve o nome do recebedor com um intentId válido por 5 minutos. Confirmar Intenção de Saque efetiva o saque a partir desse intentId, enviando apenas a idempotencyKey, com a mesma resposta de Solicitar Saque.

O ganho está na conferência do titular: você descobre que a chave não pertence a quem esperava antes de o dinheiro sair. Cada intenção vale para um saque só e é consumida na confirmação.

A criação direta em uma única chamada continua existindo e não mudou.

MED de saque​

Três páginas novas para os MEDs abertos sobre saques, que são separados dos MEDs de transação: Abrir MED de Saque, Listar MEDs de Saque e Buscar MED de Saque.

Diferente dos MEDs de transação, que chegam pelo adquirente, estes são abertos por você informando o endToEnd do saque contestado. Por isso o campo origin aceita USER, valor que não aparece nos MEDs de transação.

Versão da documentação: 5.1.0

O que mudou na documentação​

O saldo é calculado com cinco casas decimais, por causa da aplicação de taxas. Em centavos, isso significa que ele pode vir com fração: um saldo de R$ 8.488,15900 retorna 848815.9.

Os seguintes documentos passaram a descrever esse comportamento, que já era o da API:

• Buscar Saldo
• Listar Lançamentos, nos campos amount, balanceBefore e balanceAfter
• Dashboard do Usuário

Nenhum comportamento da API foi alterado. Os endpoints de entrada continuam exigindo centavo inteiro, como sempre.

Como usar o saldo para sacar​

Buscar Saldo ganhou uma seção explicando que, para sacar o saldo todo, é preciso descartar a fração e não arredondar. Arredondar para cima pede mais do que existe na carteira e a operação é recusada por saldo insuficiente.

Versão da documentação: 5.0.3

O que muda​

Nada na API: POST /med/{id}/appeal é o método correto e sempre foi. Quem seguiu a documentação à risca recebia erro de método não permitido.

A correção vale para o bloco Endpoint e para os dois exemplos de requisição da página.

Status APPEALED, não APPEAL​

O status de MED em contestação é APPEALED. As páginas Buscar MED, Listar MEDs e Webhook de MED traziam APPEAL, tanto nas tabelas quanto nos exemplos e no filtro de busca. Quem filtrava por status=APPEAL não recebia resultado.

O mesmo valor aparecia no filtro de Criar Relatório, que também aceita status de MED.

Versão da documentação: 5.0.2

Paginação nas listagens de carteira e MED​

Listar Lançamentos, Listar Saldos Diários e Listar MEDs ainda documentavam o campo total na resposta, removido da paginação em julho, e não mencionavam o snapshot. As três páginas foram alinhadas ao restante das listagens.

Caminhos dos endpoints da carteira​

As páginas da carteira informavam o caminho sem o prefixo /wallet no bloco Endpoint (por exemplo /balance em vez de /wallet/balance), embora os exemplos de requisição já usassem o caminho correto. Corrigido em Buscar Saldo, Listar Lançamentos, Buscar Saldo Diário e Listar Saldo Diário.

Filtro de valor em Listar Transações​

Em Listar Transações, o maxAmount passou a exigir valor maior ou igual ao minAmount quando ambos são informados. A validação não estava documentada.

Tamanho da mensagem de defesa no MED​

Em Recurso de MED, o campo message aceita até 1000 caracteres, e não 510 como constava.

Versão da documentação: 5.0.1

Campos renomeados​

Nas contas Vendedor, Account Manager, Gateway e Transacional:

No sub-objeto paymentMethods:

Novos campos na Conta Transacional​

A Conta Transacional passa a retornar também transactionVolume, transactionCreatedVolume e middleTicketValue, que já existiam nos demais tipos de conta.

Versão da documentação: 5.0.0

Buscar status do saque​

O novo Buscar Status do Saque responde apenas com o id e o status do saque, sem os demais dados do registro. Use quando precisar somente acompanhar o andamento; para o registro completo, continue usando Buscar Saque.

Novos campos no saldo da carteira​

Buscar Saldo passa a retornar balance, reserve, pendingDebit e frozen. O campo amount continua sendo retornado, mas está depreciado: use balance no lugar dele.

Versão da documentação: 4.3.0

Janela de 1 hora​

O resultado da operação associado a uma idempotencyKey é mantido por 1 hora a partir do primeiro envio. Reenvios com a mesma chave dentro dessa janela retornam o resultado da operação original; após esse período, a chave expira e um reenvio pode gerar uma nova operação.

Esse comportamento já existia, apenas não estava documentado.

Versão da documentação: 4.2.1

Restrito a usuários manager​

Assim como ACCOUNT, o tipo ACCOUNT_FINANCIAL_SUMMARY só pode ser solicitado por um usuário com papel de manager. Uma conta sem esse papel recebe 403 ao tentar gerá-lo.

Versão da documentação: 4.2.0

observation é somente para uso interno​

O campo é opcional (máximo de 255 caracteres), é armazenado junto com o saque, mas não é retornado em Buscar Saque nem em Listar Saques.

Versão da documentação: 4.1.0

O que muda​

Se sua integração envia ou lê address.zipCode, será necessário migrar para address.postalCode. O tipo e o formato do valor (CEP do Brasil) não mudaram, apenas o nome do campo.

Versão da documentação: 4.0.0

O que muda​

Se sua integração depende de total para exibir a contagem total de itens, ela vai parar de recebê-lo nesses endpoints. totalPages, currentPage e perPage continuam sendo retornados normalmente.

Versão da documentação: 3.0.0

Como funciona​

snapshot não é um ponteiro para a "próxima página": é um identificador fixo da sessão de paginação. Pegue o valor de snapshot retornado na primeira resposta (feita sem enviar snapshot) e reenvie esse mesmo valor, sem alterá-lo, nas páginas seguintes, junto com page incrementando normalmente e os mesmos filtros/perPage usados originalmente. Se algum desses valores mudar enquanto um snapshot antigo é reenviado, a API retorna erro.

Confira um exemplo completo em Listar Transações.

Versão da documentação: 2.2.0

Comprovante de transação​

O exemplo de requisição de Comprovante usava o método GET, mas o endpoint sempre exigiu POST /transaction/{id}/receipt. O exemplo foi corrigido.

Buscar Notificação (dispatcher)​

Em Buscar Notificação, o histórico de status (statusHistory) documentava um campo timestamp que não existe: o campo real é date, e também estava faltando durationInMilliseconds. O campo error foi corrigido para refletir que retorna null (não uma string vazia) quando não há erro. E o objeto de resposta de cada execução (response) ganhou a documentação do campo responseTime, que já existia na API mas nunca tinha sido documentado.

Versão da documentação: 2.1.1

Ao criar um saque recorrente, a API gera automaticamente todos os agendamentos com base na frequência (a cada X dias/meses, ou em um dia fixo do mês) e na duração informadas. Cada agendamento é processado individualmente, na sua data prevista, como um saque comum.

Novos endpoints​

Confira a documentação completa em Saque Recorrente.

Versão da documentação: 2.1.0