v2.63.0 — Sócio administrador conferido no POST da PJ

POST /v1/accreditations/pj passa a exigir exatamente um sócio com partners[].isAdministrator: true. O liquidante aceita um único administrador por empresa e só dizia isso depois — com os links de biometria já emitidos, o reconhecimento facial de todos os sócios já feito e os PDFs societários já enviados. Mais de um administrador agora é recusado na hora, com 400 invalid_field, mensagem nomeando partners[].isAdministrator e os índices marcados. Nenhum link é emitido e nada é cobrado da jornada.
A quantidade de sócios não mudou. O limite conta administradores: empresa com vários sócios e um único administrador segue passando normalmente.
Nenhum administrador continua recusado com 400 invalid_payload, como já era antes.
GET /v1/accreditations/{id} passa a devolver o bloco partner nas recusas vindas do liquidante — o mesmo que já ia no webhook accreditation.failed. Antes, quem consultava a API via menos do que quem capturava o webhook. O campo é omitido quando não há recusa do parceiro.
A documentação de erros foi corrigida em dois pontos. O campo do motivo chama-se errorReason (a tabela dizia reason), e o bloco partner reflete o que o liquidante enviou: code, message e field são todos opcionais, e há recusas que chegam só com message — nesses casos o campo não é nomeado.

Atenção / ação necessária

Se você monta o partners[] marcando todos os sócios como administradores, a chamada passa a responder 400 em vez de ser aceita e falhar horas depois. Marque apenas o administrador da empresa e envie os demais com isAdministrator: false.

v2.64.0 — PIX out retido no banco liquidante: quem está segurando, e o desfecho tardio

hold diz de quem é a espera. A consulta de pagamento (GET /v1/accounts/{accountId}/pix/payments/lookup) e o webhook pix.out.timeout passam a trazer hold, com owner: "partner" e reason (partner_authorization, partner_risk_analysis ou partner_unspecified), quando a ordem está retida no banco liquidante. Quando esse objeto aparece, não há nada a aprovar do seu lado nem do nosso.
partnerStatus e partnerStatusId trazem o estado bruto no liquidante, para você anexar em ticket. São valores dele, fora do nosso vocabulário canônico: não use em comparação de status.
status continua igual. PENDING_APPROVAL segue com o mesmo valor de sempre — nenhuma integração que compara status precisa mudar. O campo é ambíguo de nascença (cobre a fila de autorização interna do liquidante e a análise de risco dele) e será desdobrado numa versão maior; até lá, hold é a resposta para “quem precisa agir”.
TIMEOUT deixou de ser o fim da linha. Quando a ordem fica retida, seguimos consultando o liquidante por até 7 dias. Se ele liquidar ou recusar nesse período, você recebe pix.out.completed ou pix.out.failed com late: true e o mesmo paymentId do pix.out.timeout anterior — é a correção daquele desfecho, não um segundo pagamento. Antes, uma liberação tardia podia nunca chegar até você.
O evento tardio não duplica nada. O identificador do evento é o do pagamento, então confirmação tardia e reconciliação convergem para um único evento terminal por ordem.
A mensagem de prazo na timeline agora diz o prazo real. O evento pix_out.timeout afirmava “prazo de 5 minutos” mesmo quando a espera foi de 25 minutos, e não dizia que a ordem estava retida no liquidante.

Atenção / ação necessária

Se o seu sistema trata pix.out.timeout como desfecho final, ajuste para aceitar um pix.out.completed / pix.out.failed posterior com o mesmo paymentId (identifique-o por late: true). Reprocessar o pagamento nesse caso duplicaria o valor.